script error in mkinitrd with -current

bonaire · 05-07-2010, 08:02 PM

Hello,

since an update to the latest -current version, it comes to an error inside the init script from the initrd.gz on my system, shortly behind the scan for encrpyted devices inside lvm containers.

The message is

Code:

mdadm: No arrays found in config file
  1 logical volume(s) in volume group "vg" now active
ash: missing ]
mount: mounting crypt-vg-root on /mnt/failed: No such file or directory
ERROR: No /sbin/init found on rootdev (or not mounted).  Trouble ahead.
       You can try to fix it. Type "exit" when things are done.

If i then unlock the crypted root device within the lvm, boot continues.
I think this is a bug, because configuration did not change, and it worked before the update.

I have not the time and qualification, to look into the script, but maybe someone has it and can help me here?

bonaire · 05-07-2010, 08:16 PM

Got it

Code:

 # Unlock any LUKS encrypted devices that were deferred above but have now
  # become available due to the vgscan (i.e. filesystems on LVM Logical Volumes)

  if [ -x /sbin/cryptsetup -a -n "${LUKSLIST_DEFERRED}"]; then
    for LUKSDEV in ${LUKSLIST_DEFERRED} ; do

should be

Code:

 # Unlock any LUKS encrypted devices that were deferred above but have now
  # become available due to the vgscan (i.e. filesystems on LVM Logical Volumes)

  if [ -x /sbin/cryptsetup -a -n "${LUKSLIST_DEFERRED}" ]; then
    for LUKSDEV in ${LUKSLIST_DEFERRED} ; do

mRgOBLIN · 05-07-2010, 08:54 PM

Well spotted.

Thanks for the report.

bonaire · 05-08-2010, 12:31 PM

Sorry for pushing that again, but i am a bit confused, after i spend some time with that. I was attracted to learn how it works.

Code:

 if [ -x /sbin/cryptsetup -a -n "${LUKSLIST_DEFERRED}" ];

Why does the test for /sbin/cryptsetup make use of parameters, parameters that are not available for the cryptsetup i have here? -a is at least unknown for the cryptsetup version, that is available when the system is up.

Another point i saw is:

Code:

KEYPART=$(echo $LUKSKEY |cut -f1 -d:)
LUKSPATH="/mountkey$(echo $LUKSKEY |cut -f2 -d:)"
# Catch possible mount failure:
if blkid -t TYPE=vfat $KEYPART 1>/dev/null 2>&1 ; then
  MOUNTOPTS="-t vfat -o shortname=mixed"
else
  MOUNTOPTS="-t auto"
fi

I can do anything, the return value of blkid is always 2 (with the blkid version available when the system is up). So this does not work for me. Currently this leads to the problem that my ext4 formatted stick partition is tried to be mounted as vfat. (The stick has two partitions, one is vfat, the other one ext4)

And a last thing is: The command

Code:

/sbin/cryptsetup isLuks ${LUKSDEV} 1>/dev/null 2>/dev/null

Forces udev to dump information on tty0. This leads to the problem that the udev message is written after "cryptsetup luksOpen" asks me for the passphrase. On my system, the output looks like that

Code:

Unlocking Luks encrypted device '/dev/mapper/vg-root' as luks mapped device 'crypt-vg-root' 
Enter passphrase for /dev/mapper/crypt-vg-root: udevd-work[1009]: device node '/dev/mapper/vg-root' already exists, link to '/dev/mapper/vg-root' will not overwrite it

This is not really a problem for myself, but users, who did not setup the system by there self, could be confused because boot does not continue and there is only a message, that has nothing to do with the passphrase.

Maybe the forum is not the best place for it, but before i write an email to pv, i think it is better to discuss that here.

XGizzmo · 05-08-2010, 01:51 PM

Code:

 if [ -x /sbin/cryptsetup -a -n "${LUKSLIST_DEFERRED}" ];

The -x -a and -n are for test not cryptsetup. In English it says "if /sbin/cryptseup is executable AND the length of ${LUKSLIST_DEFERRED} is NOT zero".

bonaire · 05-08-2010, 01:57 PM

Thanks for the explanation! The other stuff is also caused by my ignorance? Would be cool.

GazL · 05-09-2010, 05:15 AM

Quote:

Originally Posted by bonaire

Got it

Yes, nicely spotted bonaire. thankyou. The code that went into initrd has changed a little from what I gave Eric, but that error is entirely down to me.

My apologies to anyone affected by this.

P.S. The keyfile stuff is all Eric's so I can't offer any advice on that one.

As for the passphrase prompt getting overwritten, I have that problem here too, but with messages for my usb keyboard. I found that using a "WAIT=2" parameter on mkinitrd.conf sorts that one out as it allows udev time to do it's stuff before the cryptsetup stuff starts running.

GazL · 05-09-2010, 06:23 AM

Quote:

Originally Posted by bonaire

Unlocking Luks encrypted device '/dev/mapper/vg-root' as luks mapped device 'crypt-vg-root'
Enter passphrase for /dev/mapper/crypt-vg-root: udevd-work[1009]: device node '/dev/mapper/vg-root' already exists, link to '/dev/mapper/vg-root' will not overwrite it
[/code]
This is not really a problem for myself, but users, who did not setup the system by there self, could be confused because boot does not continue and there is only a message, that has nothing to do with the passphrase.

Maybe the forum is not the best place for it, but before i write an email to pv, i think it is better to discuss that here.

The new cryptsetup stuff is primarily a combination of work done by Eric and myself, so the forum is probably a better option for discussing this stuff than emailing pat.

I mentioned above that I use a WAIT to get around the prompt being overwritten by udev output but I don't think that's what's happening here.

From looking at the names of the devices, it looks like you're using an encrypted lvm logical volume rather than an encrypted lvm physical volume. My guess is that you're using -C /dev/mapper/vg-root -r crypt-vg-root ?

So, what will happen on your system is that the first run of the LUKS code won't find anything to unlock and your device will be added to the 'deferred' list. Then the "vgchange -ay" will run and will create the new device entries. udev will then stick its oar in and appears to also be trying to create the new device entries which then causes the "already exists" error message you're seeing. It's not the "cryptsetup isLuks" that is causing this.

Possible ways to resolve this:

1) Add a couple of seconds sleep after the following line:
" if [ -x /sbin/cryptsetup -a -n "${LUKSLIST_DEFERRED}"]; then"

This would slow down booting slightly, so it's not ideal.

2) Redirect udevd's output to /dev/null, but this reduces the amount of diagnostics going to the screen which may be undesirable.

3) Stop udev trying to process lvm logical volumes during the initrd's init, or stop it complaining when they already exist. I don't know if it's even possible but it may be worth looking into. I've avoided the majority of the udev stuff so far so it's not an area I know much about.

Eric do you have any thoughts on this?