Ubuntu

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

Reported by Steve Langasek on 2009-02-05
56
This bug affects 5 people
Affects Status Importance Assigned to Milestone
udev
Fix Released
Undecided
Unassigned
udev (Ubuntu)
High
Scott James Remnant (Canonical)
Jaunty
High
Scott James Remnant (Canonical)

Bug Description

Binary package hint: udev

Since mid-January, the cryptsetup initramfs hook in jaunty is failing to correctly detect that my rootfs is on a luks-crypted LVM partition and copying the necessary code to the initramfs.

Stepping through the cryptsetup hook by hand, the failure is because of the following:

$ readlink -e /dev/disk/by-uuid/d5107244-d7b3-4448-9628-3b0067cf1cca
/dev/dm-4
$ sudo dmsetup deps /dev/dm-4
dm_task_set_name: Device /dev/dm-4 not found
Command failed
$

Steve Langasek (vorlon) on 2009-02-05
Changed in udev:
importance: Undecided → High
milestone: none → jaunty-alpha-5
status: New → Confirmed

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

Changed in udev:
status: New → Fix Committed
status: Confirmed → Fix Committed
Kees Cook (kees) on 2009-02-09
Changed in udev:
assignee: nobody → scott
Per Hermansson (hermansson-per) wrote :

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>

Steve Langasek (vorlon) 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.

Changed in udev:
status: Fix Committed → In Progress

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>

Changed in udev:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in udev:
status: Fix Committed → Fix Released
Per Hermansson (hermansson-per) wrote :

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?

Manuel Siggen (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.

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>

Mikael Frykholm (mikael) wrote :

>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.

Mikael Frykholm (mikael) wrote :

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.

Manuel Siggen (manuel-siggen) wrote :

>> 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.

Steve Langasek (vorlon) 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:
status: Fix Released → Confirmed
Eric Shattow (eshattow) wrote :

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.

Phoenix (phoenix-dominion) wrote :

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

José Dapena Paz (jdapena) wrote :

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.

Martin Meyer (elreydetodo) wrote :

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!

Steve Langasek (vorlon) wrote :

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

Changed in udev:
status: Confirmed → Fix Released

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>

souplin (klage) 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
(look at bug #317442)
the system can't be booted any longer, unless you provide a cryptroot file and create an initramfs file yourself ....

MichaelEvans (mjevans1983) wrote :

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>

Mikael Frykholm (mikael) wrote :

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

souplin (klage) wrote :

$ 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

Steve Langasek (vorlon) 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.

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>

Martin Pitt (pitti) on 2010-04-16
Changed in udev:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments