Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Boot freezes at SELinux "Unregister netfilter hooks"|
|Product:||[Fedora] Fedora||Reporter:||Andrew Meredith <andrew>|
|Component:||udev||Assignee:||Harald Hoyer <harald>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||mkinitrd-4.1.18-2||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-11-22 11:33:37 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Andrew Meredith 2004-11-16 08:55:38 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: After a fresh upgrade to FC3 from FC2, the boot sequence halts after SELinux: Disabled at runtime SELinux: Unregister netfilter hooks Hitting return adds blank lines and ctrl-alt-del initiates a normal reboot, so init appears not to be frozen. Disk activity continues for a short while after the display stops rolling, but then stops. Machine left for 30+ minutes and didn't recover. DPMS blanked the screen, which unblanked on keypress. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Upgrade from FC2 2. Reboot 3. Watch console Actual Results: Screen freezes Expected Results: Full boot Additional info:
Comment 1 Andrew Meredith 2004-11-16 13:07:59 EST
Having worked on this all afternoon, I have finally tracked down where the problem lies .. or at least found a work-around. The issue was that the udev config mounts its filesystem over the top of /dev. I have edited the /etc/udev/udev.conf file and changed the line: udev_root="/dev/" to udev_root="/udev/" (and created the /udev directory) This probably isn't a proper fix, but as udev is a nice-to-have and a working machine is a must have, it works for now.
Comment 2 Andrew Meredith 2004-11-18 06:58:18 EST
Further info. The "screen shows nothing but boot continues" effect is down to the lack of a /dev/console device. Perhaps it isn't created by udev in time to get hooked properly by init. There is an undocumented flag to mkinitrd that leaves all the udev stuff out. If you want to disable udev completely, try this: - If you edited /etc/udev/udev.conf as above, then change it back - comment out the following line from /etc/rc.d/rc.sysinit "[ -x /sbin/start_udev ] && /sbin/start_udev" - rebuild the initrd without udev # mkinitrd --noudev /boot/initrd-$(uname -r).noudev.img $(uname -r) - Edit /etc/grub.conf or /etc/lilo.conf to reflect new initrd (It would be a good idea to keep the old line just in case.) - Reboot If, after doing all of this, you still get random freeze/thaw events happening, or /dev related errors during boot, then this is likely down to udev having cleared out some of the device files from the real /dev. If you need to recreate your device files, you might as well use udev as a one shot. The command udevstart just repopulates your devices then exits. Make sure that there isn't a stray udevd running, else your devices might just randomly disappear again. I should also note that I am running FC3 on two platforms at the moment. The server box is the one with the problems. The laptop seems to be behaving itself pretty much ok.
Comment 3 Andrew Meredith 2004-11-20 11:46:41 EST
I have now determined that some of the weird behaviour of the machine in question was down to a dud network card, but other behaviour was down to an incomplete set of device files. I have also determined that it isn't trivial to cleanly disable udev on FC3 as at least the hotplug system restarts udevd in order to process events. It is also not trivial to remove udev from the system without ripping out half the rest of the system as well. In order to avoid udev acting on /dev, one could edit /etc/udev/udev.conf as above (udev_root="/udev/") and rebuild the initrd, without udev support, again as above.
Comment 4 Harald Hoyer 2004-11-22 05:44:40 EST
did you update via anaconda/boot CD?
Comment 5 Andrew Meredith 2004-11-22 08:52:28 EST
I did try that, but it failed at the "Resolve dependancies" stage so I did it using yum instead. According to yum there are only the extras that I already knew about .. none to do with this area of the system. As a second test I checked through the system-config-packages tool with the FC3 install tree as the base, ensuring that all the relevant stuff was installed. Incidentally, as the previous platform was apparently incompatable with FC3, I have switched the drives into another machine and switched udev back on again. The original machine is ticking away happily under FC1 and the new platform seems to have less problems with udev. It does however sill glue up from time to time, but I don't suspect udev at this stage.
Comment 6 Harald Hoyer 2004-11-22 09:19:17 EST
I would recommend using the udev package from the FC3 updates and rerun mkinitrd after installation.
Comment 7 Andrew Meredith 2004-11-22 11:05:37 EST
Already done that.
Comment 8 Harald Hoyer 2004-11-22 11:16:02 EST
are you sure you updated everything? I had the black screen also, updating from FC2 to FC3 recently by hand (no anaconda) ... but a mkinitrd -f cured that one..
Comment 9 Andrew Meredith 2004-11-22 11:33:37 EST
I have been somewhat swamped with symptoms on this machine since the upgrade to FC3. The black screen on boot one went away when I switched off udev and reconstructed the ext3 based /dev. Now that I have reinstated udev on /dev/ under tmpfs, with a newly cooked initrd, the black screen is no longer an issue. I would suspect that it had a lot to do with the original initrd as you suggest. I have a feeling that the other major symptom (freeze/thaw) had less to do with udev than I first thought. I have just now removed a GBit ethernet card that was stacked up with a bunch of other stuff on IRQ 9 and this seems to have calmed the rest down. Why this setup wasn't an issue under FC2 (uptime in months) and was under FC3 (uptime in hours) is anyone's guess. Thanks very much for your feedback.