From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera
Description of problem:
I upgraded my system from fc2 to fc3 recently. After upgrade, the
system always hangs when I try to use initrd. This is not so bad, as
I always compile the required filesystem and storage drivers in the
kernel. However, I need to use the initrd because of the udev setup,
to get rid of the "warning: unable to open initial console".
When I include initrd in the grub.conf, the system hangs with the
Creating root device
Mounting root filesystem
mount: error 6 mounting ext3
mount: error 2 mounting none
switchroot: mount failed: 22
umount /initrd/dev failed: 2
Kernel panic - not syncing: Attempted to kill init!
This happens when I try to use the old 2.6.8-1.521 and the new 2.6.9-
1.724_FC3 kernel versions as delivered by fedora. The same happens
when I use self-compiled kernels from these versions (fedora source
tree) or the vanilla 2.6.10. I tried to use mkinitrd-4.0.6, mkinitrd-
4.1.18-2 and mkinitrd-4.1.20-1, but nothing changed. It does not
matter if I include "quiet" or "rhgb" as kernel options.
Here is my grub.conf:
title Windows XP
title Fedora Core (2.6.10)
kernel /vmlinuz-2.6.10 ro rhgb quiet video=radeonfb vga=791
title Fedora Core (2.6.9-1.724, Custom Build)
kernel /vmlinuz-2.6.9-1.724custom ro rhgb quiet
title Fedora Core (2.6.9-1.724, Fedora Build)
kernel /vmlinuz-2.6.9-1.724_FC3 ro rhgb quiet
title Fedora Core (2.6.8-1.521, Custom Build)
kernel /vmlinuz-2.6.8-1.521custom ro rhgb quiet
title Fedora Core (2.6.8-1.521, Fedora Build)
kernel /vmlinuz-2.6.8-1.521 ro rhgb quiet
The system _only_ boots when I delete the initrd line from grub. Here
is my disk layout:
Disk /dev/hda: 40.0 GB, 40007761920 bytes
240 heads, 63 sectors/track, 5168 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 3017 22808488+ 7 HPFS/NTFS
/dev/hda2 3018 5093 15694560 5 Extended
/dev/hda3 5094 5168 567000 a0 IBM Thinkpad
/dev/hda5 3018 3852 6312568+ 83 Linux
/dev/hda6 3853 3866 105808+ 83 Linux
/dev/hda7 3867 4954 8225248+ 83 Linux
/dev/hda8 4955 5093 1050808+ 82 Linux swap
# This file is edited by fstab-sync - see 'man fstab-sync' for
/dev/hda7 / ext3 defaults
/dev/hda6 /boot ext3 defaults
/dev/hda5 /home/arne ext3 defaults
none /dev/pts devpts gid=5,
mode=620 0 0
none /dev/shm tmpfs defaults
none /proc proc defaults
none /sys sysfs defaults
/dev/hda8 swap swap defaults
/dev/hda1 /windows/c ntfs ro,
umask=0222,nls=utf8 0 0
/dev/sda5 /windows/d ntfs noauto,ro,
umask=0222,nls=utf8 0 0
#/dev/sdb5 /windows/d ntfs noauto,ro,
umask=0222,nls=utf8 0 0
/dev/hdc /media/cdrecorder auto pamconsole,
exec,noauto,managed 0 0
System is a Thinkpad T40 (P4, i845 Chipset, Ati Radeon).
I tried the following mkinitrd commands:
mkinitrd -v -f /boot/initrd-2.6.10.img 2.6.10
mkinitrd -v -f --builtin=ide-disk --builtin=ext3 /boot/initrd-2.6.10.
Same result every time.
Version-Release number of selected component (if applicable):
mkinitrd-4.0.6 mkinitrd-4.1.18-2 mkinitrd-4.1.20-1
Steps to Reproduce:
1. compile kernel (with or without needed modules) or take a
2. create an initrd for that kernel (or use the created one)
3. include thin initrd in boot entry
Actual Results: system hangs
Expected Results: system boots :)
Appeared after upgrade FC2->FC3 using yum
Problem vanishes after including root=/dev/hda7 as kernel paramters.
Applies to all tested kernel versions as well as the new 2.6.10-1.737
Before the upgrade, it did work without the root=something at all. So
perhaps this bug is in the wrong section.
It's possible that this is related to bug #144441. That shouldn't
affect FC3, but may still catch you when you're doing a live update
from FC2 -> FC3.
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present. Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.
Setting status to "INSUFFICIENT_DATA", however if you still
experience this problem after updating to our latest Fedora
release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.
Thank you in advance.