Bug 221394
Summary: | FC7 kernel panic because no sata ide configuration | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | kmberry <kmberry> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> |
Severity: | urgent | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | allord_3, kaune, triage, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | bzcl34nup | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-05-07 01:04:21 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
kmberry
2007-01-04 13:56:18 UTC
Can you test the latest boot.iso to see if this has been fixed ? There have been a huge number of sata/pata & mkinitrd fixes since this bug was filed. I believe my problem is related to this report. Since FC6 (in the development of F7) all ide drives are no longer referenced in the configuration of the kernel and pata is used instead. Those of us who have a mixture of both ide and sata drives in our systems are then presented with problems: reference order of the drives that are discovered and assigned device names in the series /dev/sd? Now that would not be so bad if it was consistent. Early on in development, apparently pata modules were loaded before sata and hence the ide drives were named sda and sdb, in my case, followed by the sata drives being assigned sdc and sdd. I configured my system according to those expectations with assembly of a RAID5 assignment as well. Now the latest Test4 rescue disk loads the sata modules before the pata modules and the assignments are reversed and my drive designations in my fstab and RAID are messed up. I know, I know, I could and maybe should be using lvm, but I am from the old school where I want to see specific hard drive assignments rather than relative names. But the former conveys much more information and is difficult to cede. What hope do I have for not being confronted with the shifting sand in these mixed systems? Is there some means to fix drive assignments? use mount-by-label. It's the only way to make volumes persistent. Correct me if I am wrong, but I believe that does not solve the problem presented by the way mdadm defines and manipulates RAID drives. Does it not require specific device definition for assembly of an array? FC7 kernel config introduces a discrepency in drive order among installer/grub/kernel on systems with ide and sata drives. At least this happens on older (pre-sata) motherboards with add-on sata controllers. Among other config changes, # CONFIG_IDE is not set On a such a system with one ide drive and one sata drive, Grub sees 0 - IDE drive 1 - SATA drive F7 Live CD installer sees same order as grub and it claims that /dev/sda - IDE drive /dev/sdb - SATA drive After installation, Once bootstrap has begun, the system sees /dev/sda - SATA drive /dev/sdb - IDE drive After my installation to the SATA drive, and a reboot, there was a kernel panic, being unable to mount root filesystem. Two linux rescue sessions were needed. The first rescue session (very intricate) was needed to setup fstab to specify sda.. rather than sdb.. and to make sure that grub.conf referenced sda.. Once fstab agreed with bootup drive assignments, the second rescue session was finally able to proceed without errors, to allow "chroot /mnt/sysimage". Then it was possible to use mkinitrd to create an initrd image that would allow booting to contine without the kernel panic. There seems to be a need to insure that the drive order is consistent between ide and sata drives. Either the ide drives should always be lower numbers/alphanumbers or they should always be higher numbers/alphanumbers and the installer, the grub, and the kernel should agree on that. There is no possible way to guarantee drive order. We need to solve any fallout that causes. Using mount-by-label is the solution. Any problems with md and/or LVM need to be solved, if there are any -- but there can never be a stable set of drive names. Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp |