Bug 218444 - Kernel 2.6.19 can't find /dev/root
Summary: Kernel 2.6.19 can't find /dev/root
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: David Lawrence
Whiteboard: bzcl34nup
Depends On:
Blocks: FCMETA_SATA 228105
TreeView+ depends on / blocked
Reported: 2006-12-05 12:14 UTC by Mephisto
Modified: 2008-05-07 01:02 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-07 01:02:14 UTC

Attachments (Terms of Use)
HP ZE4201 hardware (lspci -vv) that fails to boot F7T1 Live CD (7.13 KB, text/plain)
2007-02-06 23:59 UTC, Bojan Smojver
no flags Details
FC6 output of lspci from nx9005 laptop that wont boot F7 test 3 livecd (10.61 KB, text/plain)
2007-03-30 19:10 UTC, pbsdesign
no flags Details

Description Mephisto 2006-12-05 12:14:09 UTC
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):

How reproducible:

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:

Comment 1 Steve 2006-12-05 17:39:01 UTC
same thing here with intel 82801 chipset but the error is:
failed to execute /init
kernel panic - not syncing: no init found.

Comment 2 Arnd Bergmann 2006-12-14 14:23:24 UTC
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.

Comment 3 John Ellson 2006-12-16 02:42:51 UTC
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.

Comment 4 Steve 2006-12-17 09:50:25 UTC
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)

Comment 5 Mephisto 2006-12-17 23:06:15 UTC
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...

Comment 6 Clyde E. Kunkel 2006-12-22 17:55:26 UTC
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.

Comment 7 Mephisto 2006-12-27 12:43:53 UTC
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.

Comment 8 Mephisto 2006-12-31 11:25:12 UTC
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.

Comment 9 Sebastian Vahl 2007-01-10 10:41:01 UTC
(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).

Comment 10 Kai Engert (:kaie) (inactive account) 2007-01-16 21:27:16 UTC
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

Comment 11 Mephisto 2007-01-17 14:45:00 UTC
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...

Comment 12 Kai Engert (:kaie) (inactive account) 2007-02-02 19:06:34 UTC
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.

Comment 13 Kai Engert (:kaie) (inactive account) 2007-02-05 20:50:56 UTC
Is this the same issue as bug 220470?

Is someone of you NOT using a SCSI system?

Comment 14 Mephisto 2007-02-06 12:29:42 UTC
sata counts as scsi, right?
(if not, i dont have a scsi system)

Comment 15 Bojan Smojver 2007-02-06 23:57:58 UTC
Regarding comment #12, I get the same on HP Pavilion ZE4201 with F7T1 Live CD.
I'm attaching lspci -vv output.

Comment 16 Bojan Smojver 2007-02-06 23:59:23 UTC
Created attachment 147526 [details]
HP ZE4201 hardware (lspci -vv) that fails to boot F7T1 Live CD

Comment 17 pbsdesign 2007-03-30 19:04:44 UTC
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? 

Comment 18 pbsdesign 2007-03-30 19:10:33 UTC
Created attachment 151320 [details]
FC6 output of lspci from nx9005 laptop that wont boot F7 test 3 livecd

Comment 19 Bug Zapper 2008-04-03 18:44:57 UTC
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:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 20 Bug Zapper 2008-05-07 01:02:12 UTC
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:

Note You need to log in before you can comment on or make changes to this bug.