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

Bug #315979 reported by Michael Marley on 2009-01-11
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
udev
Fix Released
Undecided
Unassigned
udev (Ubuntu)
Undecided
Unassigned

Bug Description

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

 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>

Changed in udev:
status: New → Incomplete
Michael Marley (mamarley) wrote :

OK. Here is the output.

ls -l /dev/pktcdvd

udevadm info -q all -n pktcdvd

Michael Marley (mamarley) wrote :

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

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

grep -r /dev/pktcdvd /etc

Michael Marley (mamarley) wrote :

This command returned nothing.

Have you tried rebooting, does the symlink go away?

Michael Marley (mamarley) wrote :

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

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) wrote :

It is created upon reboot.

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

Michael Marley (mamarley) wrote :
Michael Marley (mamarley) wrote :
Melik Manukyan (djmelik) wrote :

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

I'm on Ubuntu 9.04 32-bit.

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) wrote :

This command produces no output.

Michael Marley (mamarley) wrote :

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

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.

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.

Changed in udev:
status: New → Fix Committed
status: Incomplete → Triaged
Changed in udev:
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in udev:
status: Fix Committed → Fix Released
tags: added: iso-testing
Michael Marley (mamarley) wrote :

This fix was released a long time ago.

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