From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Description of problem: This was a redhat 9 machine, upgraded to fedora core 2 by CDROM. Upgrade process went flawlessly. When done, and rebooting for the first time, I get the grub menu, select the only kernel choice (2.6.5), and then am presented with this screen: Booting Command-List root hd(0,0) Filesystem type is ext2, partition type 0xfd kernel /vmlinuz-2.6.5-1.358 ro root=/dev/md0 [Linux-bzImage, setup=0x1400, size=0x125fcd] initrd /initrd-2.6.5-1.358.img [Linux-initrd@0x7fc0000,0x2fc6a bytes] And that's it. Machine frozen completely. I have to hard reset it. Now, I can boot from cdrom just fine, and go into recovery mode, and get into the system from there. Everything otherwise seems to run and looks good. Except that I cannot boot from the drive(s)? I also tried upgrading kernel to 2.6.6-1.435.2.3, no change. Also reinstalled grub, no change. Tried acpi=off, no change. Help? Version-Release number of selected component (if applicable): kernel 2.6.5-1.358 & kernel 2.6.6-1.435.2.3 How reproducible: Didn't try Additional info: Hardware of machine in question: Generic Intel VX chipset motherboard P233mmx cpu 128mb ram SiI680 PCI ide controller Two Maxtor 6E040L0's Software RAID-1 (md1 is /boot, md0 is /, md2 is /var)
I now have a similar issue: FC2 x86_64 installed just fine on this machine, with kernel-2.6.5-1.358. I upgraded to the latest kernel-2.6.8-1.521, and everything worked. I then completely wiped out all partitions, and re-installed with a software RAID-1 configuration. Again, the installation was flawless, and the system booted just fine. However, when I installed kernel-2.6.7-1.494.2.2 or kernel-2.6.8-1.521, I experienced the problem described in this bug. I could still boot kernel-2.6.5-1.358, but the later kernels just hang in the grub screen as described earlier in the bug. Hardware: ASUS KV8 Delux SE AMD64 3200+ 1GB RAM (ECC) RAID-1 using two Maxtor 80GB drives /proc/mdstat: Personalities : [raid1] md1 : active raid1 hdg2[1] hda2[0] 2047488 blocks [2/2] [UU] md2 : active raid1 hdg3[1] hda3[0] 76027136 blocks [2/2] [UU] md0 : active raid1 hdg1[1] hda1[0] 102144 blocks [2/2] [UU] unused devices: <none> lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800 South] 00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 00:08.0 RAID bus controller: Promise Technology, Inc. PDC20378 (SATA150 TX) (rev 02) 00:0a.0 Ethernet controller: Marvell Yukon Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13) 00:0c.0 Unknown mass storage controller: Promise Technology, Inc. 20262 (rev 01)00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge 01:00.0 VGA compatible controller: nVidia Corporation NV31 [GeForce FX 5600XT] (rev a1) /proc/ide/via: ----------VIA BusMastering IDE Configuration---------------- Driver Version: 3.38 South Bridge: VIA vt8237 Revision: ISA 0x0 IDE 0x6 Highest DMA rate: UDMA133 BM-DMA base: 0xfc00 PCI clock: 33.3MHz Master Read Cycle IRDY: 0ws Master Write Cycle IRDY: 0ws BM IDE Status Register Read Retry: yes Max DRDY Pulse Width: No limit -----------------------Primary IDE-------Secondary IDE------ Read DMA FIFO flush: yes yes End Sector FIFO flush: no no Prefetch Buffer: yes yes Post Write Buffer: yes yes Enabled: yes yes Simplex only: no no Cable Type: 80w 80w -------------------drive0----drive1----drive2----drive3----- Transfer Mode: UDMA PIO UDMA PIO Address Setup: 120ns 120ns 120ns 120ns Cmd Active: 90ns 90ns 90ns 90ns Cmd Recovery: 30ns 30ns 30ns 30ns Data Active: 90ns 330ns 90ns 330ns Data Recovery: 30ns 270ns 30ns 270ns Cycle Time: 15ns 600ns 60ns 600ns Transfer Rate: 133.3MB/s 3.3MB/s 33.3MB/s 3.3MB/s /proc/ide/pdc202xx: Ultra66 Chipset. ------------------------------- General Status ---------------------------------Burst Mode : enabled Host Mode : Normal Bus Clocking : 33 PCI Internal IO pad select : 6 mA Status Polling Period : 9 Interrupt Check Status Polling Delay : 8 --------------- Primary Channel ---------------- Secondary Channel ------------- enabled enabled 66 Clocking disabled disabled Mode PCI Mode PCI FIFO Empty FIFO Empty --------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------DMA enabled: no no yes no DMA Mode: NOTSET NOTSET UDMA 4 NOTSET PIO Mode: NOTSET NOTSET PIO 4 NOTSET /proc/ide/hda/model: MAXTOR 6L080J4 /proc/ide/hdc/model: _NEC DV-5500A /proc/ide/hde/model: CD-RW BCE5224IM /proc/ide/hdg/model: MAXTOR 6L080J4 /etc/grub.conf: # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/md2 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz password --md5 $1$lmtwMRB/$CuaPgOjCkm/uxQIZKFNlO/ title Fedora Core (2.6.5-1.358) root (hd0,0) kernel /vmlinuz-2.6.5-1.358 ro root=/dev/md2 initrd /initrd-2.6.5-1.358.img
I've made some progress on this, and come up with a workaround. Since the system booted OK on the same kernel without RAID-1, I shutdown and disconnected hdg (the second drive in the RAID-1 with hda). The system booted on the new kernel, no problem. I shutdown again, and swapped hdg and hdc (a DVD player). The two hard drives were now on hda and hdc. Again, the system booted no problem. I updated /etc/raidtab, raidhotadd'ed the hdc partitions, waited for the RAID-1 devices to sync, then shutdown and rebooted. The system came up fine, and the RAID-1 arrays on the two drives were all correctly detected and mounted. It now appears that the drives in the array have to be BIOS accessible in order to boot the array (hdg was not, in the original configuration). This strikes me as strange, since hda is BIOS accessible, has the grub bootloader on it, and grub boots (hd0,0). Once the kernel gets control, it can access the drive, and previous kernels had no trouble booting on this configuration. The original configuration was preferable, because it split the RAID-1 drives across two different controllers. A controller failure will now cause both drives to fail, defeating some of the benefit of a RAID-1 configuration. Apparently, the way the kernel handles IDE drives has changed in the 2.6.7 and 2.6.8 kernels, and not for the better.
I am also having this problem. I upgraded from FC1 to FC2 and I cannot boot any 2.6.X kernels. i had to install the latest 2.4 kernel for FC1 just to be able to use my system. They all stop at the same point described in the bug. My devices are as follows: /hda = Windows 98 SE /hdb = Fedora Core /hdc = cd/dvd burner (ide-scsi emulation) /hdd = none /hde = 80 gig drive on an IDE expansion card. If you need any more info on my system, please let me know.
any better with the 2.6.10 updates ?
Good timing. :-) I had recently reconfigured back to the configuration I previously had (comment #1), but I'm now using FC3 with the 2.6.10-1.760_FC3 kernel. It's working fine for me now.
My issue was solved by removing the QUIET option from grub.conf in FC3 (I've upgraded since I added my name to this list). I guess my issue was really with RHGB in that it doesn't actually tell you not to worry and that the system is booting. On systems like mine, booting could take a minute or two, which does a pretty good imitation of freezing when you don't get notified by the system.
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.