had the same problem after installing the latest selinux-policy-strict package.
when rebooting the machine (before relabing) the machine hangs with kernel panic.

forgot to mention, that I don't think it is a selinux problem, but a problem
with the kernel. 

if you add 'dontpanic' to the boot command line, it should continue past the
point where it would have hung.  If it then boots to a command line, can you
attach the output of dmesg -s 128000 please ?

I'm also seeing this (Athlon MP).  The problem seems to have appeared in
2.6.14-1.1712_FC5smp, because 2.6.14-1.1711_FC5smp boots without problems
without any changes to the userland packages.

With "dontpanic", the system still hangs, but no panic message is printed before
it does so.

I added the "dontpanic" to the boot command line.  The system no longer panics,
but hangs at the "Initializing hardware..." step.  I left it at that stage for
15 minutes before rebooting.

BTW, I have seen the same behaviour with the last two FC5 kernels
(2.6.14-1.1715_FC5smp and the one that came before that).

I also tried the Non-SMP FC5 kernels (same versions) and they also hang (no
kernel panic) at "Initializing hardware...".

Since I "yum -y upgrade"'d the system from FC4, I still have the
2.6.14-1.1637_FC4smp installed on the FC5 system.  I can successfully boot the
system with the FC4 kernel.  Would a dmesg or any other diagnostic output be
useful from this kernel on the FC5 system?

not really. the bit of info I'm after is the backtrace from the panic.

can you edit the /etc/rc.sysinit file and find the bit that looks like this..

load_module () {
    for module in $blacklist ; do
        [ "$1" = "$module" ] && return
    done
    modprobe $1 >/dev/null 2>&1
}

and change it so that there's an

echo $1 on the line before the modprobe ?

that'll tell me which driver is being loaded which is causing the lockup
(hopefully).

I added the echo statement in load_module (), but the system panicked before any
output was produced.  So I put a "set -x" at the beginning of /etc/rc.sysinit
and here is the output from the udev part:

+ /sbin/start_udev
Starting udev:   [OK]
++ cat /proc/cmdline
+ cmdline='ro root=/dev/hda3 acpi=off'
+ sysctl -w kernel.hotplug=/sbin/udevsend
+ '[' -f /proc/sys/kernel/modprobe ']'
+ strstr 'ro root=/dev/hda3 acpi=off' nomodules
+ '[' 'ro root=/dev/hda3 acpi=off' = 'ro root=/dev/hda3 acpi=off' ']'
+ return 1
+ '[' -f /proc/modules ']'
+ sysctl -w 'Initializing hardware... '
Initializing hardware... + ide=
+ scsi=
+ network=
+ audio=
+ other=
++ kmodule -d
++ read devtype mod
Kernel panic - not syncing: bad locking

the 1720 kernel at http://people.redhat.com/davej/kernels/Fedora/devel/
should have this fixed. the ehci usb driver had some bad locking.

*** Bug 174438 has been marked as a duplicate of this bug. ***

This appears to be fixed on my test system.

There remains the question of why nobody actually saw the BUG() and the
backtrace -- only the panic. That really needs fixing.

I tried the 2.6.14-1.1721_FC5 kernel at
http://people.redhat.com/davej/kernels/Fedora/devel/ and it fixed it for me. 
The system no longer panics and I can successfully boot the system.

probably got missed due to people having 'quiet' in their boot command line.
Those msgs don't seem to have printk levels, so they get hushed. I'll send a
patch upstream to fix that.

I had 'debug' on my command line and I still didn't see it.

Installed the latest updated kernel 2.6.14-1.1719 and I got the crash during
initializing hardware again. This doesnt occur with 2.6.14-1.1715, I tried one
of the latest ones on DaveJs space (2.6.14-1.1725) and the crash still occurs.

My Hardware:
Pentium-M 1.6
Intel 915 Mobo
GF 6200 TC
Fujitsu 60Gb SATA
Intel Pro 100/IPW2200 BG

Matthew

Have updated the kernel using yum today to 2.6.14-1.1729 still having the crash
during initializing hardware.

Matt

ok, can you try the procedure mentioned in comment #6 ?

also, make sure you dont have 'quiet' on your boot command line.

Did as you asked, removed quiet from boot:

Kernel booted ok (saw lots of stuff wizz past me)
Initializing hardware....ahci
ata_piix
ahci
floppy

Then it froze, rebooted again to check and it didnt even get that far, on the
third reboot my laptop beeped at me when it froze again.

Updated to Kernel 2.6.14-1.1735
Same issue stops at the same place, just a quick thing would it matter if I dont
have a floppy drive? The laptop doesnt have a floppy drive or floppy controller.

The 1707 UP kernel is the last kernel that works on my Pentium M based Shuttle
PC. I get a few lines worth of backtrace on the console, doesn't look too
specific to me, but nothing gets to the logs. I'm attaching a screenshot instead
in hopes that it clears things up anyway. Apart from perhaps addresses, which I
haven't compared, the backtrace looks identical on UP and SMP kernels.

Created attachment 121796 [details]
UP kernel 1735 panic screenshot

Is there anything else I can do to help you test this problem with Pentium M's?
Should I try the SMP Kernel? I still dont get any Kernel Panics, Udev now
freezes and no hardware shows as of Kernel 2.6.14-1.1739, lucky I still have
Kernel 2.6.14-1.1715 to boot with :D

Matt

Managed to get it to boot some drivers again still having issues after it hits
the floppy driver.

Installed Kernel 2.6.14-1.1740 (it crashes) and added a "set -x" to the top of
my rc.sysinit to see what the output is.

+echo floppy
floppy
+modprobe floppy

I think that is the cause of my problem, no floppy drive or controller, is there
a way to exclude this from being initialized?

Turns out, once i got to test this a little more thoroughly, that MY problem was
due to LVM on top of MD devices and the init process - I need to file a
different bug for that - once i get all the details sorted out, but it's clearly
unrelated to this bug. I reinstalled and i'm now booting with no problems on
2.6.14-1.1743_FC5smp and 2.6.14-1.1743_FC5 with no problems.

I have a new Kernel Panic on Kernels after 1760:

http://www.delta-firebird.co.uk/fedora-dev/kernel-1760.jpg

I have udev set to debug atm due to the problems it is giving me, would you
prefer a non debug view?

Matt

booting with vga=791 will get you more lines of text onscreen, so you may be
able to get the top of the oops.

Tomorrows build will also pause after the first oops, which should give you a
better chance to grab the first one (Which is usually the only one that matters).

Hi Dave

Still having the boot issue, managed to get a vga=791 screenshot this time:

http://www.delta-firebird.co.uk/fedora-dev/kernel-1786.jpg

In addition when I update my kernel i get a error when installing it, have
forgotten to take a screenshot sorry, not sure whether this is causing a problem.

You will know better than me.

Matt

Hi Dave 

I grabbed the install error when updating to 2.6.14-1.1796 this morning:

/var/tmp/rpm-tmp.36540: line 1:  2960 Segmentation fault 
/usr/sbin/module_upgrade 2.6.14-1.1796_FC5

This is the install error, not the boot one, will let you know if i still get it
with 1796.

Matt

Same booting problem during initializing hardware as 1786.

module_upgrade segfaulting is a kudzu bug, can you file a separate one for that
please ?  (If it dropped a core dump someplace, installing kudzu-debuginfo and
doing 'gdb /usr/sbin/module_upgrade core.dumpfilename' should show a backtrace
which should be interesting.

Hi Dave

Neva managed to get the Kadzu grab as my install crash and I havent been able to
recover it. An now when I install I cant get into a GUI fedora, had to
re-install and how I cant boot fedora as it cant use the launch kernel (SMP
issue) and so far the only working kernel 2.6.14-1.1715 (due to the continuing
problems I have after  1715) and I dont have a copy of it anywhere (unless you
can provide one?). Think I am going to have to wait for test 2.

Matt

was test3 any better ?

No response to request for information.  Closing.  If it still
happens in FC5 final, reopen.