Description of problem: After installing the package kernel-2.6.19-1.2844.fc7 and rebooting, the system fails to start up, and ends with an error message along the lines of 'cannot find /dev/root', after running the initrd. kernel-2.6.18-1.2849.fc6 works fine. I'm booting from the IDE disk /dev/hde1 on a system using intel 965G chipset. It has only 1 IDE interface (/dev/hde and /dev/hdf). It won't boot kernels lower than 2.6.18 because the IDE on this chipset had bugs on older kernel versions, so wasn't supported. 2.6.19 should work however... Version-Release number of selected component (if applicable): kernel-2.6.19-1.2844.fc7 How reproducible: always Steps to Reproduce: 1. Install kernel-2.6.19-1.2844.fc7 on a system using i965 chipset 2. Boot the kernel Actual results: The system fails to startup, and halts after running the initrd Expected results: The system should boot up as usual Additional info:
same thing here with intel 82801 chipset but the error is: failed to execute /init kernel panic - not syncing: no init found.
The reason for this is that mkinitrd does not know about the fact that newer kernels use libata for accessing PATA drives, instead of the older IDE drivers. As a workaround, you may have success by rerunning mkinitrd after installing the kernel RPM, with the '--preload=ata_piix --preload=ahci' options. The actual driver that needs to be loaded depends on your hardware setup.
I'm getting the same symptoms on a system with software raid over scsi. The --preloads suggested in comment#2 didn't work for me.
there is no problem with some 82801BA chipset OR the issue is fixed in kernel-2.6.19-1.2877.fc7. i don't know because i do not have the other (82801) anymore.
both the 2877 kernel and the workaround don't help for me. it stll gives the same error with that kernel and a newly generated initrd...
I notice that the command raidautorun /dev/mdx is missing from the init. I can rerun minitrd using -with= for the raid modules and then hand jam raidautorun in init and recreate the .img file, but nothing I do allows mkinitrd to automatically determine that root is on a software raid set and load the appropriate modules. I believe the severity of this bug should be high and it should be a fc7 blocker.
uhm yeah, except that i'm not using raid... i have a standard msdos partition table with ext3 partitions. i think your problem is a different one, and you should open a new bug for that.
I got an idea today and tried something new. A while ago i booted a live-cd on this same machine (i think it was Ubuntu edgy) and from what i remember it assigned /dev/hda to the disk, instead of /dev/hde, like Fedora did. I always assumed the hde assignment was because the BIOS called it slot 4 (0 to 3 were sata ports). So i was wondering if Fedora would do the same on 2.6.19, with the ata driver changes and such, and it appears that indeed the device has changed, but not to /dev/hda, but /dev/sda. My system now boots fine on 2.6.19 with the fstab updated to the new device nodes.
(In reply to comment #8) > and it appears that indeed the device has changed, > but not to /dev/hda, but /dev/sda. My system now boots fine on 2.6.19 with the > fstab updated to the new device nodes. Had the same issue with the last kernels in rawhide. LABEL=whatever works fine, /dev/hdb1 not. When I was able to boot into the new kernel there were no entries for/dev/hd*, only /dev/sd*. (My mainboard has no sata support).
I'm having the same problem on my rawhide scsi system. Did not help: mkinitrd -f -v --preload=sym53c8xx /boot/initrd-2.6.19-1.2912.fc7.img 2.6.19-1.2912.fc7 Using LABEL=/ in /etc/fstab did not help either. /dev/sda is an MO drive /dev/sdb is my boot disk, sdb1 boot, sdb2 swap, sdb3 is / I tried root=/dev/sda3, just in case devices got swapped, but did not work either. When I boot using the working FC6 kernel, the scsi driver dumps a lot of information, including the scanned devices, before the kernel proceeds to mounting. When I boot using the failing FC7 kernel, the scsi driver does not display any information on devices. [root@leise ~]# cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: FUJITSU Model: MCF3064SS Rev: 0020 Type: Optical Device ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: DPSS-336950N Rev: S96H Type: Direct-Access ANSI SCSI revision: 03 [root@leise ~]# cat /proc/scsi/sym53c8xx/0 Chip sym53c896, device id 0xb, revision id 0x7 At PCI address 0000:00:06.0, IRQ 177 Min. period factor 10, Wide SCSI BUS Max. started commands 448, max. commands per LUN 64 [root@leise ~]# cat /proc/scsi/sym53c8xx/1 Chip sym53c896, device id 0xb, revision id 0x7 At PCI address 0000:00:06.1, IRQ 185 Min. period factor 10, Wide SCSI BUS Max. started commands 448, max. commands per LUN 64
Using LABEL= worked for me, although i had to manually label my filesystems now, since most of them didn't seem to have a label yet (i normally partition and format disks the old commandline way, i have no idea of what the official Fedora way is these days). I think i'll need that anyway now, since my root partition uses the same kind of device nodes as usb sticks/mp3 players/etc, and judging by the kernel startup output, it loads usb first, so / might be on /dev/sdb instead of /dev/sda if i have a usb drive inserted during bootup. Also, i think i know why my IDE drive moved from hdX to sdX. I saw in the motherboard manual today, that the IDE controller is a subsystem of the sata controller on this board, so i think that's why the kernel calls it sdX now. For FC7, i recommend to take a good look at all of this to make sure upgrades go right. I can find my way around linux by now, but new users will probably not be able to fix a broken startup...
I just gave Fedora 7 Test 1 LiveCD a try. Same problem, /dev/root is not found and I'm dropped into an "emergency shell", being asked to create a symlink. But /dev doesn't contain anything that looks like a CD device. Plain IDE device. Same system as mentioned in comment 10.
Is this the same issue as bug 220470? Is someone of you NOT using a SCSI system?
sata counts as scsi, right? (if not, i dont have a scsi system)
Regarding comment #12, I get the same on HP Pavilion ZE4201 with F7T1 Live CD. I'm attaching lspci -vv output.
Created attachment 147526 [details] HP ZE4201 hardware (lspci -vv) that fails to boot F7T1 Live CD
I have the same problem - I tried F7 test 2 live cd and it wouldn't boot, giving me the 'symlink /dev/root' problem. I've just tried F7 test 3 live cd and it has the same problem. This laptop is a HP/Compaq nx9005, I will attach lspci output, but it is similar to the one posted by Bojan S above. The output is from FC6 which is installed on the internal IDE hd and working fine. AFAIK the reason our IDE drives are reported as SCSI is that F7 has switched to using libata, surely that might have something to do with this error that isnt present in FC6?
Created attachment 151320 [details] FC6 output of lspci from nx9005 laptop that wont boot F7 test 3 livecd
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