[dm-crypt] Help: after crypttab modify > begin: waiting for root file system

[dm-crypt] Help: after crypttab modify > begin: waiting for root file system

[Tommaso]

Sorry for my poor english and for the not-so-clear topic, I hope someone
can help me because I'm in serious trouble :(

I run (ehm... I was running :( ) a headless debian lenny server with
encrypted LUKS filesystem. After I made an apparently harmless modify to
the crypttab file I can no longer boot the system. At startup I get the
message:

    Begin: waiting for root file system...


And all is hanged up. I have a plaintext /boot partition with the
bootloader (grub), while everything else is encrypted. My /etc/crypttab
file was something like this:

    lg0-lv0_crypt /dev/mapper/lg0-lv0 none luks


so that at boot time it was necessary to manually insert a passphrase to
unlock the filesystem (lg0-lv0_crypt is mounted as / on fstab). Now, I
must leave the place where the server resides for some weeks, so I
decided to temporarily override this behaviour with a cleartext key file
to avoid problems due to accidental rebooting. So I did:
1) put a random key_temp file in /boot with 600 permission
2) cryptsetup luksAddKey /dev/mapper/lg0-lv0 /boot/key_temp
3) edited /etc/crypttab to look like this:

    lg0-lv0_crypt /dev/mapper/lg0-lv0 /boot/key_temp luks

4) update-initramfs -u ALL

but when I rebooted... all was hanged up as I said before. I can't
manage even how to undo my changes now.

Can you help me please? U_U

Re: [dm-crypt] Help: after crypttab modify > begin: waiting for root file system

[Jonas Meurer]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

hey,

this is an issue with the debian/ubuntu cryptroot implementation.

On 31/08/2009 Tommaso wrote:
> I run (ehm... I was running :( ) a headless debian lenny server with
> encrypted LUKS filesystem. After I made an apparently harmless modify to
> the crypttab file I can no longer boot the system. At startup I get the
> message:
> 
>     Begin: waiting for root file system...
> 
> 
> And all is hanged up. I have a plaintext /boot partition with the
> bootloader (grub), while everything else is encrypted. My /etc/crypttab
> file was something like this:
> 
>     lg0-lv0_crypt /dev/mapper/lg0-lv0 none luks
> 
> so that at boot time it was necessary to manually insert a passphrase to
> unlock the filesystem (lg0-lv0_crypt is mounted as / on fstab). Now, I
> must leave the place where the server resides for some weeks, so I
> decided to temporarily override this behaviour with a cleartext key file
> to avoid problems due to accidental rebooting. So I did:
> 1) put a random key_temp file in /boot with 600 permission
> 2) cryptsetup luksAddKey /dev/mapper/lg0-lv0 /boot/key_temp
> 3) edited /etc/crypttab to look like this:
> 
>     lg0-lv0_crypt /dev/mapper/lg0-lv0 /boot/key_temp luks

i guess the problem here is that /boot is not mounted. try the
following:

- boot with boot parameter set to 'break' in grub
- when the initramfs emergency shell is started, mount /boot:

(initramfs) mount -t ext2 /dev/XXX /boot

- try to unlock the crypted rootfs manually:

(initramfs) cryptsetup --key-file=/boo/key_temp luksOpen /dev/mapper/lg0-lv0 lg0-lv0_crypt

if that works, you should change your /etc/crypttab to use the passdev
keyscript in order to mount the /boot filesystem:

lg0-lv0_crypt /dev/mapper/lg0-lv0 /dev/XXX:/key_temp luks,keyscript=/lib/cryptsetup/scripts/passdev

and regnerate your initramfs. for more information the see the section
'10. the "passdev" keyscript' in
/usr/share/doc/cryptsetup/README.initramfs.gz

> 4) update-initramfs -u ALL

that's never a good idea. better update the initramfs only for one
kernel first and later if everything works as expected, update the
others. you should have a backup of the old initramfs at initrd.img.bak
though (i.e /boot/initrd.img-$(uname -r).bak).
try booting with this old initramfs by adding '.bak' to the path of your
initramfs in grub.

greetings,
 jonas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [dm-crypt] Help: after crypttab modify > begin: waiting for root file system

[Tommaso]

Jonas Meurer wrote:
> hey

Thank you for your reply :) I already managed to rescue my system and
undo my changes using the initrd.imgXXX.bak as you said (phew! :) ),
however I still have a couple of problems, one of which is really WEIRD...

The first problem is that I still can't manage how to use the cleartext
key_temp on /boot to automatically start the system without requesting a
passphrase. However thank you for pointing me at the passdev script, I
didn't know that, suppose it's intended also for this, I'll give a look
at that as soon as possible.

The second, weird problem is the following. Being unable to use the
keyfile for the automount, I temporarily added a second passphrase slot
to the above device. So now, when at boot a passphrase is requested, you
can insert either passphrase1 (the old one) or passphrase2 (the new one,
which is known also by other trusted people who should so be able to
reboot the system in my absence).
The WEIRD problem now is: if I insert passphrase1 the system starts
normally and all is good. If I insert passphrase2... the passphrase is
accepted, the disk is unlocked, the system starts... and all works
EXCEPT for the network card o.O It hangs up on DHCPREQUEST and after a
minute or so it says:

eth1: device is not ready

I'm really unable to understand why the two issues (the different
passphrase and the eth1 not ready) should be related... but I succeeded
in reproducing this behaviour many times and I'm pretty sure it depends
on the passphrase...

Re: [dm-crypt] Help: after crypttab modify > begin: waiting for root file system

[Jonas Meurer]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

hey again,

On 01/09/2009 Tommaso wrote:
> Thank you for your reply :) I already managed to rescue my system and
> undo my changes using the initrd.imgXXX.bak as you said (phew! :) ),
> however I still have a couple of problems, one of which is really WEIRD...
> 
> The first problem is that I still can't manage how to use the cleartext
> key_temp on /boot to automatically start the system without requesting a
> passphrase. However thank you for pointing me at the passdev script, I
> didn't know that, suppose it's intended also for this, I'll give a look
> at that as soon as possible.

yes, that's exactly what passdev is meant for.

> The second, weird problem is the following. Being unable to use the
> keyfile for the automount, I temporarily added a second passphrase slot
> to the above device. So now, when at boot a passphrase is requested, you
> can insert either passphrase1 (the old one) or passphrase2 (the new one,
> which is known also by other trusted people who should so be able to
> reboot the system in my absence).
> The WEIRD problem now is: if I insert passphrase1 the system starts
> normally and all is good. If I insert passphrase2... the passphrase is
> accepted, the disk is unlocked, the system starts... and all works
> EXCEPT for the network card o.O It hangs up on DHCPREQUEST and after a
> minute or so it says:
> 
> eth1: device is not ready
> 
> I'm really unable to understand why the two issues (the different
> passphrase and the eth1 not ready) should be related... but I succeeded
> in reproducing this behaviour many times and I'm pretty sure it depends
> on the passphrase...

that really sounds weird. if the unlocked device _is_ the same for both
passphrases, then it will behave similar. thus i don't see how issues
with network should be related to the used keyslot.

greetings,
 jonas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [dm-crypt] Help: after crypttab modify > begin: waiting for root file system

[Tommaso]

Jonas Meurer wrote:
> yes, that's exactly what passdev is meant for.

Problem solved indeed, passdev works :)


> that really sounds weird. if the unlocked device _is_ the same for both
> passphrases, then it will behave similar. thus i don't see how issues
> with network should be related to the used keyslot.

Ok, maybe I got it, but maybe you won't like the answer.

The error I was getting with the new passphrase was:

    ADDRCONF(NETDEV_UP): eth1: link is not ready


I found many topics about, and I discovered that this is an issue of a
bad renaming of the network interfaces, see i.e.
http://marc.info/?l=debian-user&m=114369893509924&w=2

In fact I have two NICs on the server, one of which (eth0) is not used
(hasn't got even a cable). So it seems that, due to the dynamic
remapping of the interfaces at boot, if I insert the old passphrase the
interface names are right, but if I change the passphrase, probably
because of some kind of variation in the entropy pattern of the system,
the names are swapped. I solved this issue installing ifrename and
managing the interfaces name according to their MAC.

HOWEVER: if this is the case (that is, if the cause of the name swapping
is due to the passphrase inserted for cryptsetup), I believe it's not a
good thing. It would indicate some kind of fixed entropy pattern
variation according to a given passphrase, probably not a desiderable
behaviour in regard to the security of encrypted filesystems.

I also addressed this issue on
http://forums.debian.net/viewtopic.php?f=10&t=44690

Thank you :)