Red Hat Bugzilla – Full Text Bug Listing
|Summary:||MAKEDEV failing to make devs - early in boot sequence|
|Product:||[Fedora] Fedora||Reporter:||Bob Gustafson <bobgus>|
|Component:||udev||Assignee:||Arjan van de Ven <arjanv>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Version:||rawhide||CC:||bmillett, lsomike, wtogami|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-21 14:05:28 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Bob Gustafson 2004-09-03 21:19:23 EDT
Description of problem: When I booted a few minutes ago after updating a number of components and modules, I saw a couple of pages of MAKEDEV failure ... The kernel did complete the boot and seems to be running OK. (but still comes up with eth0 inactive - this is a tale for a different bug report). The switch of the root partition to read/write occurs after those error messages. Perhaps MAKEDEV is trying to make devs on a read-only disk? Version-Release number of selected component (if applicable): [user1@hoho2 ~]$ cat /proc/version Linux version 2.6.8-1.541smp (email@example.com) (gcc version 3.4.1 20040831 (Red Hat 3.4.1-10)) #1 SMP Wed Sep 1 18:15:33 EDT 2004 [user1@hoho2 ~]$ /sbin/MAKEDEV -V MAKEDEV version 3.11 [user1@hoho2 ~]$ How reproducible: Only tried once. Steps to Reproduce: 1. become up2date 2. reboot 3. eyeball console messages during boot Actual results: as above Expected results: 'clean' boot Additional info: Maybe this has a bearing on the problem: Done after the reboot mentioned above. [root@hoho2 user1]# date Fri Sep 3 20:17:55 CDT 2004 [root@hoho2 user1]# yum update Setting up Update Process Setting up Repo: development repomd.xml 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files developmen: ################################################## 3526/3526 Excluding Packages Excluding Packages from Fedora Core 2 - Development Tree Resolving Dependencies Dependencies Resolved [u] dev.i386 0:3.11-1 - user Is this ok [y/N]: y Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Cannot install the dev package: mounted devfs detected. error: %pre(dev-3.11-1) scriptlet failed, exit status 1 error: install: %pre scriptlet failed (2), skipping dev-3.11-1 Complete! [root@hoho2 user1]#
Comment 1 Mike 2004-09-03 21:37:48 EDT
Bob, I just filed against the MAKEDEV package: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131761 a little while ago which may be related to this problem too. Regards, Mike Klinke
Comment 2 Bob Gustafson 2004-09-04 08:38:34 EDT
I booted again and watched the MAKEDEV action a couple of the failures are like MAKEDEV /dev/cpu/13 ... MAKEDEV /dev/cpu/14 ... MAKEDEV /dev/cpu/15 ... MAKEDEV /dev/loop ... MAKEDEV /dev/loop ... I don't have that many cpus.. This occurs after the SCSI disk setup and before the switch to rw disks. I also tried to manually 'rpm -i ...' install the dev package - even going to run level 1 and umounting various things (USB). Was not able to install dev. Is there something I can try? Or just wait for a new package?
Comment 3 Sammy 2004-09-04 10:07:52 EDT
I can confirm the same errors during the boot. I do have a scsi disk for which the module is installed from modprobe.conf. I am also having filesystem errors which I'll file saperately.
Comment 4 Bob Gustafson 2004-09-04 10:57:40 EDT
With latest yum update (a few minutes ago), the MAKEDEV messages seem to have changed. An example is below MAKEDEV /dev/loop7 unable to reset file creation context
Comment 5 Luke Hutchison 2004-09-06 11:37:52 EDT
I can confirm I have seen this, but I only saw errors for /dev//stdin, /dev//stdout, /dev//stderr and a couple of others.
Comment 6 Brian Millett 2004-09-06 16:17:04 EDT
Still a problem after going down to 2.6.8-1.540. When /sbin/start-udev starts at boot time, I get many " MAKEDEV <insert dev here> unable to reset file creation context" Booting 2.6.7-1.517 is fine. running: udev-030-20 MAKEDEV-3.11-1
Comment 7 Tomo Vuckovic 2004-09-07 03:06:59 EDT
I solve this problem. Initrd created with udev support genetate this messages. In /etc/udev/udev.conf change UDEV_INITRD parameter to "no" and make new initrd.
Comment 8 Brian Millett 2004-09-07 09:20:45 EDT
That (comment #7) worked for me. It also helped fix a bug where k3b did not notice that the cdrw was a writable device. Good job Tomo. How the heck did you think to look there? I guess I need to think more clearly.
Comment 9 Nalin Dahyabhai 2004-09-07 19:18:16 EDT
Problems noted in comment #4 through comment #6 are better explained in #131776, comment #1 is a duplicate of #131761, so marking this a duplicate of #131761. *** This bug has been marked as a duplicate of 131761 ***
Comment 10 Red Hat Bugzilla 2006-02-21 14:05:28 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.