udev has wrong name for devmapper devices, cryptsetup initramfs hook fails

Bug caused by string_escape=none actually ending up not assigning names due to the code being inside the if:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=10b2d011e70ddf9361c61f6147dc88f670d28abd

Secondary bug that we found where removing the OPTION resulted in a rules error was already fixed in git:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=647f7c49e8ddfbbe2afd9545484a3ad936f438e9

I've build and installed udev-137-3 from bzr but the boot still fails to detect my luks partition.

On Sun, 2009-02-15 at 17:05 +0000, Per Hermansson wrote:

> I've build and installed udev-137-3 from bzr but the boot still fails to
> detect my luks partition.
>
This bug is not marked Fix Released, so that is not surprising.

Scott
--
Scott James Remnant
<email address hidden>

According to Scott, the change that's been committed to bzr is only a partial fix which introduces some other regressions. It should be fixed tomorrow anyway with udev 138, but rolling this back to 'in progress' just to make sure we don't lose track.

On Fri, 2009-02-20 at 03:11 +0000, Steve Langasek wrote:

> According to Scott, the change that's been committed to bzr is only a
> partial fix which introduces some other regressions. It should be fixed
> tomorrow anyway with udev 138, but rolling this back to 'in progress'
> just to make sure we don't lose track.
>
Please don't do things like that.

 status fixcommitted

It's committed in bzr, therefore the status is Fix Committed.

Bug statuses are for me, as the maintainer.

Scott
--
Scott James Remnant
<email address hidden>

This bug was fixed in the package udev - 138-1

---------------
udev (138-1) jaunty; urgency=low

  * New upstream release:
    - Block device nodes watched with inotify for changes and
      /dev/disk/by-{uuid,label} updated automatically.
    - Loop devices now get persistent disk links too.

  * Apply NAME rules when string_escape=none. LP: #325690.

 -- Scott James Remnant <email address hidden> Fri, 20 Feb 2009 13:37:24 +0000

I've installed the 138-1 version using the rescue mode from the install cd,
but the system still fails to detect the luks partition.
Any ideas on how can I troubleshoot this?

No more luck here : I just installed the 138-1 version and the boot sequence still doesn't ask for the passphrase.

Also, until now I could easily fall back to an old kernel (2.6.28-5) and continue to use my machine without much trouble. But with the 138-1 version, the udevd daemon eats 40-50% CPU continuously (the disk LED blinks but no disk activity can be heard), and the whole machine is quite unstable (fortunately, the consoles still work). Is it possible that a mismatch between kernel and udev causes this problem ?

On Fri, Feb 20, 2009 at 07:40:45PM -0000, Manuel Siggen wrote:
> No more luck here : I just installed the 138-1 version and the boot
> sequence still doesn't ask for the passphrase.

After installing the new version of udev, you will also need to update your
initramfs (sudo update-initramfs -u -k 2.6.28-8-generic).

> Also, until now I could easily fall back to an old kernel (2.6.28-5) and
> continue to use my machine without much trouble. But with the 138-1
> version, the udevd daemon eats 40-50% CPU continuously (the disk LED
> blinks but no disk activity can be heard), and the whole machine is
> quite unstable (fortunately, the consoles still work). Is it possible
> that a mismatch between kernel and udev causes this problem ?

That sounds like quite another matter; I'll defer to Scott here.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

>After installing the new version of udev, you will also need to update your
>initramfs (sudo update-initramfs -u -k 2.6.28-8-generic).
It didn't work for me either. I installed 138-1 and did the initramfs thing. I am running dm-crypt as setup by the alternate installer.
I was able to fallback to the -6 kernel as usual though.

I am also getting 100% cpu on udevd. I attached a strace log spanning over maybe 5s.

>> No more luck here : I just installed the 138-1 version and the boot
>> sequence still doesn't ask for the passphrase.
>
> After installing the new version of udev, you will also need to update your
> initramfs (sudo update-initramfs -u -k 2.6.28-8-generic).
>

Ok, I'll try that. Thanks.

On the other hand, I installed the new version of udev through apt-get
dist-upgrade, so it's very much possible that initramfs is already
up-to-date, but I'll try nevertheless.

>> Also, until now I could easily fall back to an old kernel (2.6.28-5) and
>> continue to use my machine without much trouble. But with the 138-1
>> version, the udevd daemon eats 40-50% CPU continuously (the disk LED
>> blinks but no disk activity can be heard), and the whole machine is
>> quite unstable (fortunately, the consoles still work). Is it possible
>> that a mismatch between kernel and udev causes this problem ?
>
> That sounds like quite another matter; I'll defer to Scott here.

I rebooted several times to verify the behavior, and here how it goes :

  - boot with kernel 2.6.26-5 (nosplash)
  - ask for passphrase
  - boot continues a while then stops (disk LED blinks but no hearable
disk activity)
  - wait some minutes
  - me hit Ctrl+C => nothing
  - me hit Ctrl+Alt+Del => a warning appear briefly about a killed process
  - boot continue but / is mounted as read-only

Is there a way to found which process hang during the boot ?

Just wanted to add that I am also having problems with udev and 100% CPU usage after today's updates.

>> After installing the new version of udev, you will also need to update your
>> initramfs (sudo update-initramfs -u -k 2.6.28-8-generic).
>>
>
> Ok, I'll try that. Thanks.

I tried but it doesn't change anything.

Ok, I can confirm the behavior reported by the latest follow-ups. Rebooting after upgrade, the system hangs while starting udev and never advances. Downgrading to udev 1.37-2 and dmsetup 2:1.02.27-4ubuntu3 corrects this problem (while using an older initramfs that doesn't contain udev 1.38).

If this is specific to systems using devmapper for / then I suppose it makes sense to continue using this same bug for tracking the issue.

Me-too for the high CPU usage by udev 138-1. Downgrading udev to 137-1 and dmsetup to 1.02.27-3ubuntu2 there is normal CPU usage again. I have ext3 root filesystem on an LVM logical volume, home is mounted as eCryptFS.

In some earlier versions of the ubuntu installer, it was possible to encrypt the whole drive - whole means excl. /boot.

So I have a partition of sda1 and sda5, where sda1 is /boot and sda5 contains the LVM part with "system and swap"

2.6.27-11-generic is the latest kernel, where cryptsetup is still working,
config-2.6.28-8-generic does not offer to enter an ecryption key and thus fails.

The 2.6.27-11 fails on setting up the lvm part, so I have to do that in the initramfs (busybox?) shell with

- kvm
- kvm> lvchange -ay /dev/mapper/swap
- kvm> lvchange -ay /dev/mapper/system
- ^D (or exit)
- ^D

More info:
fdisk -l
/dev/sda1 * 1 31 248976 83 Linux
/dev/sda2 32 996 7751362+ 5 Extended
/dev/sda5 32 996 7751331 83 Linux

cryptsetup status /dev/mapper/sda5_crypt
/dev/mapper//dev/mapper/sda5_crypt is active:
  cipher: aes-cbc-essiv:sha256
  keysize: 256 bits
  device: /dev/sda5
  offset: 2056 sectors
  size: 15500606 sectors
  mode: read/write

lvm> lvmdiskscan
  /dev/ram0 [ 64.00 MB]
  /dev/block/254:0 [ 7.39 GB] LVM physical volume

lvm> lvdisplay
  --- Logical volume ---
  LV Name /dev/serenity/swap
  VG Name serenity
  LV UUID NcdDdy-tt8l-sspt-13u3-T2ti-yXXc-xJ1a1H
  LV Write Access read/write
  LV Status available
  # open 1
  LV Size 2.00 GB
  Current LE 513
  Segments 1
  Allocation inherit
  Read ahead sectors auto
  - currently set to 256
  Block device 254:1

  --- Logical volume ---
  LV Name /dev/serenity/system
  VG Name serenity
  LV UUID 1izsR7-JxkZ-gL1j-eDHD-UFWp-6A3K-18AZP7
  LV Write Access read/write
  LV Status available
  # open 2
  LV Size 5.39 GB
  Current LE 1379
  Segments 1
  Allocation inherit
  Read ahead sectors auto
  - currently set to 256
  Block device 254:2

Very similar issue here with udev 138. I can confirm also that going back to 137-2 fixes the problem. My system hangs on bootup, and never manages to mount the root.

I believe the udev CPU usage issue is bug 332270. Please comment in that bug (and provide the requested info) if you're affected by that issue.

FYI, my system still doesn't prompt me to unlock my encrypted partition during boot after this upgrade. I'm dropped to the initramfs prompt as before the upgrade, only now after I manually unlock the partition udev starts freaking out until I kill it. Good times!

marking this bug as fixed; using bug #332270 to track the new issue.

On Sat, 2009-02-21 at 18:26 +0000, Steve Langasek wrote:

> Ok, I can confirm the behavior reported by the latest follow-ups.
> Rebooting after upgrade, the system hangs while starting udev and never
> advances. Downgrading to udev 1.37-2 and dmsetup 2:1.02.27-4ubuntu3
> corrects this problem (while using an older initramfs that doesn't
> contain udev 1.38).
>
> If this is specific to systems using devmapper for / then I suppose it
> makes sense to continue using this same bug for tracking the issue.
>
> ** Changed in: udev (Ubuntu Jaunty)
> Status: Fix Released => Confirmed
>
Uh,

Surely you're confusing two entirely separate bugs here?

You've just unmarked *this* bug, caused by the failure to
name /dev/mapper devices properly, because of the existance of bug
#332270?

Are you saying you can prove that this bug is not fixed?

Scott
--
Scott James Remnant
<email address hidden>

I can confirm bug #332270 is fixed, by upgrading to the latest udev/lvm2 package - but #325690 is NOT fixed.

update-initramfs creates a new initram which doesn't contain the conf/conf.d/cryptroot file
(look at bug #317442)
the system can't be booted any longer, unless you provide a cryptroot file and create an initramfs file yourself ....

Interesting, I followed a different guide when setting up my lvm+cryptsetup system and I have not had an issue with initrds not containing cryptsetup, -except- once when I used -u instead of -c to run update-initramfs.

http://www.debuntu.org/how-to-encrypted-partitions-over-lvm-with-luks-page-3-install-and-config

This was an upgrade from an 8.10 system.

Are there any tests/details you might want? Does anyone still have problems with failure for booting with no prompt for a cryptsetup password?

On Tue, Feb 24, 2009 at 04:08:15AM -0000, souplin wrote:
> I can confirm bug #332270 is fixed, by upgrading to the latest udev/lvm2
> package - but #325690 is NOT fixed.

> update-initramfs creates a new initram which doesn't contain the
> conf/conf.d/cryptroot file

Sorry, can't corroborate this here. An initramfs generated after upgrade to
udev 138-2:

$ zcat /boot/initrd.img-2.6.28-8-generic | cpio -tv|grep cryptroot
-rwxr-xr-x 1 root root 7080 Feb 17 10:00 scripts/local-top/cryptroot
$

Everything appears to be in order here.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

worksforme.
I am using dm-crypt and did a manual sudo update-initramfs -u -k 2.6.28-8-generic just to be sure.

$ zcat /boot/initrd.img-2.6.28-8-generic | cpio -tv|grep cryptroot
46718 blocks
-rwxr-xr-x 1 root root 7080 Feb 17 18:49 scripts/local-top/cryptroot

Same here - BUT my system won't boot any longer, because i'm not asked for the cryptopassword until -> bug #317442
zcat /boot/initrd.img-2.6.28-8-generic | cpio -tv|grep cryptroot
-rw-r--r-- 1 root root 103 Feb 24 11:24 conf/conf.d/cryptroot
46718 blocks
-rwxr-xr-x 1 root root 7080 Feb 17 18:49 scripts/local-top/cryptroot

the conf/conf.d/cryptroot is generated/included in the initramfs, containing the information:
target=crypt,source=/dev/disk/by-uuid/XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX,key=none,lvm=jautyest-root

souplin, please file a separate bug report on the cryptsetup package for your issue. I don't know what this conf/conf.d/cryptroot file is, but it's unrelated to this udev bug; if local-top/cryptroot is in your initramfs, then this bug is fixed.

On Tue, 2009-02-24 at 19:00 +0000, Steve Langasek wrote:

> souplin, please file a separate bug report on the cryptsetup package for
> your issue. I don't know what this conf/conf.d/cryptroot file is, but
> it's unrelated to this udev bug; if local-top/cryptroot is in your
> initramfs, then this bug is fixed.
>
More to the point, if you _do_not_ have /dev/dm-* devices and
have /dev/mapper/* devices instead - the known udev portion of this bug
is fixed.

Scott
--
Scott James Remnant
<email address hidden>