Bug 139506 - Boot freezes at SELinux "Unregister netfilter hooks"
Summary: Boot freezes at SELinux "Unregister netfilter hooks"
Alias: None
Product: Fedora
Classification: Fedora
Component: udev   
(Show other bugs)
Version: 3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-16 13:55 UTC by Andrew Meredith
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version: mkinitrd-4.1.18-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-22 16:33:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Andrew Meredith 2004-11-16 13:55:38 UTC
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:

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 18:07:59 UTC
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:




(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 11:58:18 UTC
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

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 16:46:41 UTC
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 10:44:40 UTC
did you update via anaconda/boot CD?

Comment 5 Andrew Meredith 2004-11-22 13:52:28 UTC
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 14:19:17 UTC
I would recommend using the udev package from the FC3 updates and
rerun mkinitrd after installation.

Comment 7 Andrew Meredith 2004-11-22 16:05:37 UTC
Already done that.

Comment 8 Harald Hoyer 2004-11-22 16:16:02 UTC
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 16:33:37 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.