http://bugzilla.novell.com/show_bug.cgi?id=556931 http://bugzilla.novell.com/show_bug.cgi?id=556931#c2 --- Comment #2 from Lukas Lipavsky 2009-11-19 16:33:52 UTC --- Created an attachment (id=328482) --> (http://bugzilla.novell.com/attachment.cgi?id=328482) screenshot (photo) of the unsuccessful boot It seems that it tries to detect lvm groups but does not try to decrypt the partition before. (Note that if I have only LVM encrypted partion which contains root, that this problem does not occur) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=556931 http://bugzilla.novell.com/show_bug.cgi?id=556931#c4 Ludwig Nussel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |aschnell@novell.com Info Provider| |llipavsky@novell.com --- Comment #4 from Ludwig Nussel 2009-11-19 16:45:41 UTC --- it's stupid fsck failing due to non-existing device. add nofail to the mount options to skip fsck. boot.crypto will do it later then. Alternatively chkconfig boot.crypto-early on to unlock the device before fsck. You should also set timeout=0 in crypttab then to avoid the fsck failure in case of timeout. However either method may not work depending on whether sda3 contains the luks volume and then lvm or first lvm and then luks. We'd need some kind of probe/unlock/fsck/mount loop during boot to really resolve such problems. So how is the setup? sda3->luks->lvm or sda3-lvm->luks? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=556931 http://bugzilla.novell.com/show_bug.cgi?id=556931#c6 --- Comment #6 from Ludwig Nussel 2009-11-27 09:37:24 UTC --- (In reply to comment #5)

(In reply to comment #4)

...

it's stupid fsck failing due to non-existing device. add nofail to the mount options to skip fsck. boot.crypto will do it later then.

Nofail helped, but the /data is not mounted during boot (since it's decrypted after the fstab is processed)

I overlooked that. After thinking about it I know it can't work :-) boot.crypto looks for the unlocked device in fstab but it's not there, just the lvm volumes it contains. Therefore boot.crypto-early is the only way to activate such devices. I'll try to get a patch upstream that makes fsck honor the nofail option itself so we don't need to skip fsck entirely. If that gets rejected fstype 'auto' would work too. Arvin: boot.crypto-early skips devices that don't exist yet so it should be safe to have yast just enable both init scripts. To avoid a warning message the 'noearly' option could be used for all crypto volumes that don't sit directly on top of a physical device but that's not mandatory. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=556931 http://bugzilla.novell.com/show_bug.cgi?id=556931#c Ludwig Nussel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@novell.com AssignedTo|lnussel@novell.com |aschnell@novell.com -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.