mknod for /dev/pktcdvd/control fails after update to udev 136

[Michael Marley]

Binary package hint: udev

After a recent update in Kubuntu Jaunty 64-bit to udev version 136, my computer now displays an error message about a failure to mknod the /dev/pktcdvd/control device. I cannot get the exact error message, because it scrolls by too fast to write it down and I cannot find it in any log. I checked the /dev/pktcdvd folder, and it is a symlink to /dev/pktcdvd/control. (Yes, it appears to be a endless loop.)

[Scott James Remnant (Canonical) (canonical-scott)]

 status incomplete

On Sun, 2009-01-11 at 03:55 +0000, Michael Marley wrote:

> After a recent update in Kubuntu Jaunty 64-bit to udev version 136, my
> computer now displays an error message about a failure to mknod the
> /dev/pktcdvd/control device. I cannot get the exact error message,
> because it scrolls by too fast to write it down and I cannot find it in
> any log. I checked the /dev/pktcdvd folder, and it is a symlink to
> /dev/pktcdvd/control. (Yes, it appears to be a endless loop.)
>
Could you attach the output of:

  ls /etc/udev/rules.d /lib/udev/rules.d

Also:

  udevadm test $(find /sys -name pktcdvd)

Scott
--
Scott James Remnant
<email address hidden>

[Michael Marley (mamarley)]

OK. Here is the output.

[Scott James Remnant (Canonical) (canonical-scott)]

ls -l /dev/pktcdvd

udevadm info -q all -n pktcdvd

[Michael Marley (mamarley)]

michael@michaelspc:~$ ls -l /dev/pktcdvd
lrwxrwxrwx 1 root root 15 2009-01-12 15:35 /dev/pktcdvd -> pktcdvd/control
michael@michaelspc:~$ udevadm info -q all -n pktcdvd
device node not found

[Scott James Remnant (Canonical) (canonical-scott)]

What made that /dev/pktcdvd symlink? It's certainly not udev!

grep -r /dev/pktcdvd /etc

[Michael Marley (mamarley)]

This command returned nothing.

[Scott James Remnant (Canonical) (canonical-scott)]

Have you tried rebooting, does the symlink go away?

[Michael Marley (mamarley)]

No, rebooting does not remove the symlink. In fact, it is re-created automatically even if I "sudo rm" it.

[Scott James Remnant (Canonical) (canonical-scott)]

On Tue, 2009-01-13 at 01:41 +0000, Michael Marley wrote:

> No, rebooting does not remove the symlink. In fact, it is re-created
> automatically even if I "sudo rm" it.
>
Created automatically when?

After the reboot?

Immediately?

Scott
--
Scott James Remnant
<email address hidden>

[Michael Marley (mamarley)]

It is created upon reboot.

[Scott James Remnant (Canonical) (canonical-scott)]

Could you attach your /var/log/udev file for me?

Also run this:
  tar cf rules.tar /etc/udev/rules.d /lib/udev/rules.d

And attach rules.tar for me

[Melik Manukyan (djmelik)]

Yes I can confirm this bug as I'm experiencing it as well.

I'm on Ubuntu 9.04 32-bit.

[Scott James Remnant (Canonical) (canonical-scott)]

I'm afraid I can find nothing in your attached files that suggests udev is creating that errant symlink, could you try the following grep for me

grep -r pktcdvd /etc

[Michael Marley (mamarley)]

This command produces no output.

[Matti Lindell (mlind)]

Seems to be fixed upstream:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=8257730d392cf227fd3eba2915021aad6a2cc2e4
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=fc7d16f993df6cef0e6038c63942d17994fde672

[Michael Marley (mamarley)]

Would this be fixed in a minor update, or will we have to wait for 2.6.29?

[Scott James Remnant (Canonical) (canonical-scott)]

Oh, right! Scott, when you spend hours debugging something, it's polite to actually tell the bug what you found ;)

We discovered that what was happening was that udev in the initramfs made /dev/pktcdvd as an ordinary device node because it has no rules to change the name. We inherit /dev, including the udev db, in the full system and start udev up again - but this time with all the rules including the name change.

What should have happened is that udev renamed (or at least unlinked and made afresh) the /dev/pktcdvd node to /dev/pktcdvd/control. And this part was kinda working.

But then it got the old name stuck in its list, and thought it was a symlink it had to put back after; and thus overwrote the node with a symlink, and then couldn't put the new node in place.

We fixed udev to not restore old names or symlinks, and we fixed udev to clean up old nodes before adding the new node.

[Scott James Remnant (Canonical) (canonical-scott)]

This fix is applied to udev, and will be in the udev 137 release; it's unrelated to the kernel release schedule (2.6.29 isn't scheduled for jaunty anyway).

I imagine that'll happen this week sometime.

[Launchpad Janitor (janitor)]

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

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

  * New upstream release:
    - udevadm test no longer has force option.
    - udevd has --resolve-names=early|late|never option.
    - Group of IDE CD-ROM drives fixed. LP: #315997.
    - Group of DRI subsystem fixed. LP: #317430.
    - /etc/udev/rules.d not existing is not an error. LP: #315780.
    - Bug where device nodes would be replaced by symlinks on rename has been
      fixed. LP: #315979.

  * Use --resolve-names=never in the installer and initramfs, since we don't
    have a useful name service. LP: #319199.
  * Since we don't have to worry about group lookup, we may as well copy the
    default rules into the initramfs as well. This actually double-solves
    LP: #315979.
  * Make sure the root filesystem is writable before attempting to copy
    generated rules across. LP: #224870.
  * Remove /dev/MAKEDEV symlink; the FHS no longer requires it when /dev
    is automatically managed.

  * It is not permitted to call udevadm trigger or settle during an upgrade
    without depending on udev. Attempting this will fail.
  * Change /etc/init.d/udev restart to actually restart the daemon, with a
    bit of detection to print a warning if we missed events while the
    daemon was down.
  * Refreshing /dev is now /etc/init.d/udev refresh-devices
  * Restart udev daemon after upgrade. LP: #317944.

 -- Scott James Remnant <email address hidden> Fri, 23 Jan 2009 15:15:07 +0000

[Michael Marley (mamarley)]

This fix was released a long time ago.