Red Hat Bugzilla – Bug 55860
After upgrading Roswell kernel to any version of 2.4.9, boot fails just prior to rootpivot with error message
Last modified: 2007-04-18 12:38:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.74 [en] (Win98; U)
Description of problem:
After manually upgrading Roswell kernel 2.4.6 to any version of 2.4.9 in 7.2 the system fails just prior to the rootpivot with error message "mount: error 19
on ext3" CPU is Cyrix MII-300, IDE is Promise Ultra66 with Maxtor 80 GB ATA66 drive. Manually redid mkinitrd in case something bogus happened during
install. Same results with any version of 2.4.9 from either the cd distro or the updates. Also tried i386 and i586 arch too. My guess is that the kernel isn't
recognizing the Promise controller. The MB built-in IDE is disabled in BIOS and doesn't show up anywhere else so shouldn't be confusing the boot. Tried
to see the IDE discovery on the boot screen, but it scrolls by too fast.
Version-Release number of selected component (if applicable): kernel-2.4.9-13
Steps to Reproduce:
1.Install Roswell release
2.Update kernel and dependent packages
Actual Results: Normal boot up to point where HD root file system is initially mounted. Mount gives error 19 when trying to mount the ext3 fs. Followed by
kernel panic except when running 2.4.9-13debug which drops into debug monitor.
Expected Results: Normal boot process
Also edited grub command line to try mounting as ext2 with same result. It appears the kernel doesn't detect the Promise card as an IDE controller. This
works in the 2.4.6 kernel of Roswell. Moving the drive to the built-in IDE isn't an option for testing - the MoBo locks up if it sees the drive on the internal
controller. Two things I have yet to try since they just occurred to me: try the boot floppy from the 7.2 distro and the -BOOT version of the kernel since I
initially avoided these as not being production quality.
In case you're wondering why not upgrade to 7.2 directly instead of this roundabout way: this system is my ftp mirror server but doesn't have a burner.
Install from HD failed - it couldn't find the distribution even though I created the merged directory structure. This may have been the first clue that something
was wrong with 7.2.
Officially beta->final upgrades are unsupported and there are few glitches known;
could you check if your / filesystem has an "/initrd" directory ? There MUST be
Yes, / fs has /initrd directory.
Can you attach the dmesg output from the working kernel ?
I can tell you we had the same problems until I noticed that when installing
the kernel, mkinitrd didn't add the ips.o module automaticaly.
This only happens when the previous kernel had ips built-in. Since I'm eager
to use Red Hat kernels on production-systems we're gradually upgrading
non-modular kernels with Red Hat modular ones.
The fact that the new kernels do mkinitrd automaticaly (but not always right)
is very confusing if you're used to do mkinitrd yourself (and check it manually).
This may or may not be the case here ofcourse ;-) Thought it was worth
I think I have a handle on it now. Wish the debug kernel was standard and included support for scroll lock (ctrl-s/q) throughout the boot process - it would have made
this MUCH easier to catch. Kernel 2.4.6 treated the Promise controller like a SCSI device, putting its drives at the head of the IDE chain - caused all sorts of problems
when I initially brought the new controller on line and had to do all sorts of editing to fstab. I finally caught a glimpse of the controller initialization for kernel
2.4.13debug and saw the drives initialized as hde and hdh instead of hda and hdd. Changed grub to point to root file system on hde2 instead of hda2 and got past
the hangup till it started reading fstab and tried to mount the wrong partitions. I can figure the rest out from here. I wonder why it started at hde when no other IDE
controller was found? Is this a bug in the Promise detection?
The big question is what is going to be the long term behavior with respect to how Promise is going to be handled? This is a real pain redoing the fstab depending on
the whim of a particular kernel!
Roswel had a wrong setting here; the current behavior is the final behavior....