[SOLVED] Cryptsetup problem

Nikosis · 10-01-2012, 07:16 AM

Tried to install Slackware64 14, with crypt (just LUKS, no LVM), install went just fine, but the problem begins when I boot it up, it gets to the point right after I type in the passkey to unlock root partition, and than I see this

Code:

device-mapper: remove ioctl on temporary-cryptsetup-1111 failed: Device or resource busy
udevd[1139]: failed to execute '/usr/sbin/dmsetup' '/usr/sbin/dmsetup' 'udevcomplete 5137555':No such file or directory

udevd[1143]: failed to execute '/usr/sbin/dmsetup' '/usr/sbin/dmsetup' 'udevcomplete 4217198':No such file or directory

udevd[1155]: inotify_add_watch(6, /dev/dm-0, 10) failed: No such file or directory

udevd[1160]: failed to execute '/usr/sbin/dmsetup' '/usr/sbin/dmsetup' 'udevcomplete 5117437':No such file or directory

udevd[1154]: inotify_add_watch(6, /dev/dm-0, 10) failed: No such file or directory

udevd[1161]: failed to execute '/usr/sbin/dmsetup' '/usr/sbin/dmsetup' 'udevcomplete 4234460':No such file or directory

udevd[1177]: failed to execute '/usr/sbin/dmsetup' '/usr/sbin/dmsetup' 'udevcomplete 4216921':No such file or directory

mount: mounting /dev/mapper/cryptroot 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.

/bin/sh: cant access tty; job control turned off

Here is what I did

Code:

$ echo "cryptroot /dev/sda6" > /mnt/etc/crypttab
$ echo "cryptswap /dev/sda5 none swap" >> /mnt/etc/crypttab
$ chroot /mnt
$ mkinitrd -c -k 3.2.29 -m ext4 -f ext4 -r cryptroot -C /dev/sda6
$ lilo

And here are edited files

lilo.conf

Code:

-------cut---------
image = /boot/vmlinuz-generic-3.2.29
initrd = /boot/initrd.gz
root = /dev/mapper/cryptroot
label = Linux
read-only 
-------cut---------

/etc/crypttab

Code:

-------cut---------
cryptroot  /dev/sda6
cryptswap  /dev/sda5  none  swap
-------cut---------

fstab

Code:

-------cut---------
/dev/mapper/cryptswap     swap             swap        defaults         0   0
/dev/mapper/cryptroot     /                ext4        defaults         1   1
-------cut---------

Where did it go wrong?

Thx

furrymonster · 10-01-2012, 01:07 PM

This may be the same thing I ran into (also using luks, no lvm), or at least something very similar. I settled on a 'solution' that seems to work (still some udev error messages at boot):
Instead of using 'cryptroot', try using /dev/mapper/lukssda2 (or in your case /dev/mapper/lukssda6). I base this on some of the error messages that I got plus the mkinitrd man page. I did a fresh install to get it working.

My setup does not include an encrypted swap partition, so that may change things, and I did not have any reference to the root partition in my crypttab. Otherwise, same steps as you, my mkinitrd line was:
# mkinitrd -c -k 3.2.29 -m ext4 -f ext4 -r /dev/mapper/lukssda2 -C /dev/sda2 -u -o /boot/initrd.gz

Hope this helps. As I said, I don't understand this behaviour yet, but I was eager to get my new HW running... :-)
Good luck.
~Tom

TracyTiger · 10-08-2012, 12:44 AM

Today I upgraded a system from Slack64-13.37 to Slack64-14.0. I had a similar problem and found a simple workaround that may be helpful to others and may relate to the previous two posts in this thread.

Problem: The encrypted block device in /dev/mapper does not match the name specified when initrd is created.

This is observed with the boot message (retyped from notes):

Code:

Unlocking LUKS encrypted device '/dev/md2' as LUKS mapped device 'luksmd2':
Enter passphrase for /dev/md2:

The problem is I configured the system, including the initrd.gz file to use a mapped device name of cryptroot. The new /boot/initrd-tree/rootdev file correctly shows the cryptroot name indicating that the mkinitrd -r option is working.

@Nikosis I recommend that you check the boot message line before the passphrase prompt to see if your problem is similar.

When booting the init script appears to just use the default name of 'luks' + base of the block device.

I spent a few minutes looking through through the init (in /boot/initrd-tree) script hoping to find something obvious to let me continue using the mapped name I choose. I noticed the introduction of udevd but didn't see anything obviously different from 13.37 in setting the ROOTDEV & CRYPTDEV variables. I'm not familiar with the workings of initrd creation. I'm just a user.

Workaround: Configure root device to match default name chosen when system boots.

Here are the details of how I implemented this workaround.

My system uses two disks for mirrored RAID with several partitions.

The /boot partition is RAID-1 with an ext2 file system. (/dev/md1)
The / partition is RAID-1, ext4 fs and encrypted via LUKS typed in key. No LVM. (/dev/md2)
Other partitions are RAID-1, encrypted via LUKS with key stored on root partition. No LVM
Lilo is used to boot.
The system had been working fine like this (13.37) for the previous 3 months.

The procedure in my case was to configure lilo to use the default mapped name (luksmd2) and configure /etc/fstab to also use that name.

Code:

(Boot from Slack64-13.37 DVD)

cryptsetup  luksOpen  /dev/md2  luksmd2

(Enter passphrase)

mount  -t ext4  /dev/mapper/luksmd2   /mnt      (root directory)
mount  -t ext2  /dev/md1             /mnt/boot  (boot directory)

mount  -o bind  /proc  /mnt/proc
mount  -o bind  /sys   /mnt/sys
mount  -o bind  /dev   /mnt/dev

chroot  /mnt

(Edit /etc/fstab replacing /dev/mapper/cryptroot with /dev/mapper/luksmd2)

(Edit /etc/lilo.conf replacing root = /dev/mapper/cryptroot with root = /dev/mapper/luksmd2)

lilo -v

exit  (from chroot)

(Remove DVD and reboot)

This worked for me. My other encrypted RAID partitions worked fine with their mapped names of crypthome, cryptswap, etc. Note that I use /etc/crypttab with stored keys and don't open them via the initrd creation.

If someone has a solution (patch) or a better workaround please let me know. I searched for this problem thinking it should have been reported before, but only found this thread. I've been away from LQ most of the last week so I may have missed another thread, new or old, on this issue.

GazL · 10-08-2012, 06:10 PM

I had a little to do with that section of the initrd, though Eric modified my original code a little. The initrd's init should still cope with the traditional style 'cryptroot' name when specified with the -r option on mkinitrd. The part of the code in question is

Code:

if /sbin/cryptsetup isLuks ${LUKSDEV} 1>/dev/null 2>/dev/null ; then
        if echo $ROOTDEV | grep -q "LABEL=" || echo $ROOTDEV | grep -q "UUID=" ; then
          CRYPTDEV="luks$(basename $LUKSDEV)"
        elif [ "x$ROOTDEV" = "x$(basename $ROOTDEV)" ]; then
          CRYPTDEV="$ROOTDEV"
        else
          CRYPTDEV="luks$(basename $LUKSDEV)"
        fi

... and the highlighted section should be executed in this case.

However, at the beginning of the initrd's init script it does this.

Code:

root=/dev/*)
      ROOTDEV=$(echo $ARG | cut -f2 -d=)

... in order to allow you to override it at boot time by manually entering kernel options at the prompt.

My suspicion is that the updated lilo version in 14.0 is passing the "root=" from it's lilo.conf to init as an argument when perhaps it didn't used to and the result is that $ROOTDEV as specified by lilo.conf is overriding the value specified on the -r option of mkinitrd.

If this is indeed what is happening it should be fairly trivial to change the init script to cope with this. However, there are additional implications. Do we really want a situation where those using grub(*) need to specify -r on mkinitrd, but for those using lilo it is ignored? That sort of inconsistency feels a bit ugly to me.

(*) Assuming grub doesn't already do the same as the new lilo.

TracyTiger · 10-08-2012, 06:42 PM

Quote:

Originally Posted by GazL

I had a little to do with that section of the initrd, though Eric modified my original code a little. The initrd's init should still cope with the traditional style 'cryptroot' name when specified with the -r option on mkinitrd.

However, at the beginning of the initrd's init script it does this.

Code:

root=/dev/*)
      ROOTDEV=$(echo $ARG | cut -f2 -d=)

... in order to allow you to override it at boot time by manually entering kernel options at the prompt.

Yesterday I considered hardcoding the ROOTDEV value or outputting some information from the init program to see if the problem was earlier or later in the execution stream. But since the system I upgraded was my primary production system, I needed it to be running for Monday morning and had to stay on task.

I have to build a new machine in a couple of weeks. If no one has found the cause/cure by then perhaps I can play around with it then and learn a little bit in the process.

dolphin77 · 10-09-2012, 01:43 AM

Try to pass

Code:

$ mkinitrd -c -k 3.2.29 -m ext4 -f ext4 -r /dev/mapper/cryptroot -C /dev/sda6

instead of

Code:

$ mkinitrd -c -k 3.2.29 -m ext4 -f ext4 -r cryptroot -C /dev/sda6

thats the problem, I guess. Don't beat me if I am wrong.

PS also pass append="resume=/dev/mapper/swap", If you use hybernation.

Edit: or maybe adding "-u" to mkinitrd?

Code:

mkinird --help
--cut--
-u      Include udev in the initrd
--cut--

Nikosis · 10-09-2012, 02:09 AM

Quote:

Originally Posted by Tracy Tiger

Code:

Unlocking LUKS encrypted device '/dev/md2' as LUKS mapped device 'luksmd2':
Enter passphrase for /dev/md2:

The problem is I configured the system, including the initrd.gz file to use a mapped device name of cryptroot. The new /boot/initrd-tree/rootdev file correctly shows the cryptroot name indicating that the mkinitrd -r option is working.

@Nikosis I recommend that you check the boot message line before the passphrase prompt to see if your problem is similar.

Yes I've got the same message, but with this:

Code:

mount: mounting /dev/mapper/cryptroot 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.

seems like at first it takes $CRYPTDEV to open crypt device and then it tries to mount it as $ROOTDEV
Strangely enough 13.37 did the same thing, and it worked (with /dev/mapper having 2 files cryptroot and lukssda). The init code didn't change that much, but with new udev something might not be adjusted, well I might have some spare time this week, so I'll try to investigate it a little further.

Nikosis · 10-09-2012, 02:12 AM

Quote:

Originally Posted by dolphin77

Try to pass

Code:

$ mkinitrd -c -k 3.2.29 -m ext4 -f ext4 -r /dev/mapper/cryptroot -C /dev/sda6

instead of

Code:

$ mkinitrd -c -k 3.2.29 -m ext4 -f ext4 -r cryptroot -C /dev/sda6

Already tried that, did not help.

TracyTiger · 10-09-2012, 11:23 AM

Quote:

Originally Posted by dolphin77

Try to pass

Code:

$ mkinitrd -c -k 3.2.29 -m ext4 -f ext4 -r /dev/mapper/cryptroot -C /dev/sda6

Just like Nikosis, I had entered the full path and it didn't fix the issue. The absolute path (/dev/mapper/cryptroot) was placed in the /boot/initrd-tree/rootdev file, again confirming the mkinitrd -r option works. If I remember correctly, the init script appears to be written to expect/want only the basename of the rootdev path, not the full path.

Nikosis wrote ...

Quote:

well I might have some spare time this week, so I'll try to investigate it a little further.

If you mess with this on the weekend you may want to to hardocde values for $ROOTDEV/$CRYPTDEV in the /boot/initrd-tree/init script in the section of code Gazl referenced and see if the symptoms change. Or capture the value of $ROOTDEV, if any, that may be passed to init as an argument as Gazl suggested.

@Dolphin77 - I noticed the introduction of udevd earlier in the init script. Like you & Nikosis I wondered about the impact of the udev system on this issue. I don't understand udev, but it is frequently suspected (and perhaps rightfully so) in many Linux issues.

Alien Bob · 10-09-2012, 02:10 PM

Did anyone yet try to remove the "root=" line in your lilo.conf ? I have been deleting that line for years as it is not needed, even confusing, when using an initrd.

Eric

TracyTiger · 10-09-2012, 11:21 PM

Quote:

Originally Posted by Alien Bob

Did anyone yet try to remove the "root=" line in your lilo.conf ? I have been deleting that line for years as it is not needed, even confusing, when using an initrd.

That Works! At least in my situation. Nikosis (OP) may still have a different issue.

When "root=" is removed from the image portion of the lilo.conf file the rootdev value defined with the mkinitrd is used at boot time.

GazL was correct about lilo passing the value of the "root=" lilo.conf line. An echo line added to the init script showed that ROOTDEV was being set to "/dev/mapper/cryptroot", the value from lilo.conf in my case.

The init scripts treats this incorrectly formed value unkindly (it should be simply "cryptroot") and replaces it with the default ("luksmd2" in my case).

If the base path value of "cryptroot" is added to lilo.conf ("root=cryptroot") then lilo fails and complains about an illegal "root=" specification. We can't make both lilo AND the init script happy with a non-default "root=" lilo.conf argument.

So it appears the solution is to NOT use "root=" in lilo.conf when an initrd is created, as Alien Bob suggested.

Of course the best solution may be to modify lilo to NOT send the value of "root=" when an initrd file is used. (perhaps lilo's previous behavior)

Note that when using the huge kernel and no initrd, the "root=" line is needed in lilo.conf.

Thanks Alien Bob !

dmslack · 10-10-2012, 02:33 AM

Quote:

Originally Posted by Alien Bob

Did anyone yet try to remove the "root=" line in your lilo.conf ? I have been deleting that line for years as it is not needed, even confusing, when using an initrd.

Hi Eric,
maybe useful to update Slackware README_CRYPT.TXT to reflect this.
At line 331 and 522, there are two examples of initrd used with the infamous line "root = ..."

Melke · 12-22-2015, 01:09 PM

I am sorry for resurrecting an old post. But I am having the same issue. However, I am not using lilo but elilo.

After changing the elilo.conf and removing the "root=" parameter it still gives the same error.

TracyTiger · 12-23-2015, 01:01 AM

I don't have any experience with elilo so I can't help.

Don't forget to rerun lilo/elilo after changing the configuration. This is a common mistake we've all made at one time or another.

You should give more information about your situation such as your Slackware version (32 or 64 bit), the release (13.37, 14.1, -current, etc), your kernel (huge, generic) use of initrd, RAID, LVM and the specific symptoms/errors you are seeing.

Rather than opening up a 3 year old thread, another option is to start a new one and reference (link) this thread from 2012.

Melke · 12-23-2015, 01:49 PM

Will do when i get home from visiting the family for the holidays!