There are certainly at least two different issues being discussed here. There are those who get the udev-work - /dev/null error and boot continues without error(possibly with a delay) and there are those who see the error message and boot fails. There are those who see the error on every boot, and those who only see the error part of the time.
Here is my observation regarding my part time, still boots, udev-work error. I recreated my /dev/null as a static node similar to what's described in #75 and it seems to have solved my issue. As for the proposed mdadm fix I don't think it is a direct fix, but rather causes a shift in boot processes that eliminates the race that causes /dev/null to not be ready when requested. Bear with me as I explain... The udev-work error happens early in the boot process. It is almost surely a udev thread trying to access /dev/null before another udev thread has created the node. Since it only happens sometimes it would indicate that most of the time the threads are timed correctly and the node is ready when requested. mdadm is a RAID array administration tool. /dev/null is not a disk, and it is almost certainly not a RAID array! Though by installing mdadm you have placed another process into the early boot sequence and this can, and probably does affect the timing of other early boot processes, allowing the udev processes to sync correctly. As for those who have recently upgraded and now cannot boot, it would certainly appear to be a real issue, but though you do see a udev error message, my guess is the issue goes deeper than udev. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/575333 Title: On boot keeps trying to mount "UDEVD-WORK..../dev/null" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/575333/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
