Re: encrypted home start-up problem with keyfile

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Wed, 19 Nov 2008 17:43:54 +0100,
Bernd Speiser wrote:

Hi,

[....]
> /etc/init.d/boot.crypto
> (3) run insserv -v as root
> The /etc/init.d/.depend.boot was regenerated.

Yes, this does not only fix the wrong behaviour in opensuse multiboot, that
boot.crypto errouneously waits for boot.localfs to complete, which results in
boot.localfs detecting the encrypted partitions as defective, forcing the boot
process to run into the root emergency console, but also corrects the
startlinks in /etc/init.d/boot.d related to boot.crypto and boot.localfs, so
that the crypto devices are activated before the other local fs.

> Already ok - as an aside: I find conflicting information on the use of 
> options in the /etc/crypttab lines. My crypttab man page (openSUSE 11.0) 
> says that each line should contain exactly 4 entries (options should be 
> separated by ",").

The manpage on my system says:

The file /etc/crypttab contains descriptive informations about encrypted volumes. Each volume is
described on a separate line; columns on each line are separated by tabs or spaces.
                                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Thanks for the help.

I'm glad I could help you with so little, and you're welcome!

> The openSUSE people should definitely change this in the boot process 
> and/or this should also be added to the Encrypted_Root_File_System HOWTO 
> at en.opensuse.org.

They refuse, I tried it 2 times without success, they said the boot process is
ok, without giving me any facts to convince me. When you use unencrypted root
fs, it doesn't matter, but using an encrypted root fs, it's a bug. Definitely.
It's quite obvious that you can not mount an encrypted fs without having
successfully run devicemapper / cryptsetup on it first.

It's now up to them to fix it or leave it. I don't care any longer. Maybe it's 
caused by the fact that I used direct email to the maintainer to report the
bug, and not the official bugtracking system by Novell.

Regards, Heinz.

---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux