Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 232595 - boot-up error message: "Could not find the root block device in ." (livecd-amd64-installer-2008.0-r1)
Summary: boot-up error message: "Could not find the root block device in ." (livecd-am...
Status: RESOLVED DUPLICATE of bug 224895
Alias: None
Product: Gentoo Release Media
Classification: Unclassified
Component: LiveCD/DVD (show other bugs)
Hardware: AMD64 Linux
: High major with 2 votes (vote)
Assignee: Gentoo Release Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-21 20:30 UTC by Jarry
Modified: 2011-06-19 13:14 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jarry 2008-07-21 20:30:35 UTC
When booting livecd-amd64-installer-2008.0-r1.iso, I get these messages:
_______________________________________
<< Load keymap (Enter for default):

>> Keeping default keymap
>> Making tmpfs for /newroot
>> Looking for the cdrom
>> Attempting to mount media:- /dev/sr0
>> Attempting to mount media:- /dev/sda1
... (similar messages for /dev/sda2 - /dev/sda12)...
... (and similar messages for /dev/sdb1 = /dev/sdb12)...
!! Media not found
!! Could not find CD to boot, something else needed!
>> Determining root device...
!! Could not find the root block device in .
   Please specify another value or: press Enter for the same,
   type "shell" for a shell, or "q" to skip...
root block device() :: _ 
_______________________________________


Reproducible: Always

Steps to Reproduce:
1. insert cd-r with burned image (livecd-amd64-installer-2008.0-r1)
2. boot-up
3. select kernel/option "gentoo nox"

Actual Results:  
boot-up process stops.

Expected Results:  
boot-up process should continue up to shell prompt.

Relevant hardware configuration:
mobo: Asus A8N-SLI DeLuxe (nForce4 chipset)
cpu: AMD Athlon64/X2 4800+
disk: 2x Seagate 7200.10 (sata)
cd/dvd: Samsung SH-203P (sata)
both disks and dvd-drive attached to the same sata-controller (part of nForce4)

I get the same error also when using install-amd64-minimal-2008.0.iso

I DO NOT get this error when booting with old "2007.0" version.
Both install-amd64-minimal-2007.0.iso and livecd-amd64-installer-2007.0.iso
boot-up without any problem, up to shell prompt!

I think problem in 2008.0-r1 is with sata_nv module. Maybe missing support
for cd-fs? Hard-drives are detected correctly, all partitions visible...
Comment 1 Ruedi 2008-07-22 16:12:38 UTC
Same here.
The laptop I try to install is a Dell D830.
I don't think this is a drivers-issue.
In my case the LED on the DVD-drive is flickering, so there is a kind of communication with the device at least.
After getting the error, I entered "shell".
On that shell i tried to ...
mount /dev/hda /newroot/
... which gives me "invalid argument"
when I type "mount -t iso9660 /dev/hda /nweroot/"
the CD is mounted as expected. I unfortunately don't know enough about the desing of the installer-cd, but I hope this comment might be helpfull :-)
Comment 2 Ruedi 2008-07-22 16:54:04 UTC
For me it works, when I follow the istructions in:

http://www.gentoo.org/doc/en/liveusb.xml

With the memory-stick everything seems OK, installation still in progress, but past this mount-error at least ;-)
Comment 3 thoralf 2008-08-15 10:00:48 UTC
i can confirm this bug - the hardware in this case is a dell d630.
both the livecd-amd64-installer-2008.0-r1.iso and the install-amd64-minimal-2007.0.iso images are failing with this error. in both cases, it is possible to mount the cd manually with the -t iso9660 option as described by Ruedi. the cd-rom drive shows up as /dev/hda during booting - so I guess this is not a driver issue.
is there any way to resume the the installation from this point? just exit'ing the busybox shell, pressing 'q' to continue and doing some other stuff like adding /dev/hda to /etc/fstab doesn't fix it-.

with kind regards,
thoralf.
Comment 4 Justin Clift 2008-08-16 09:01:15 UTC
This also occurs when booting with the livecd-amd64-installer-2008.0-r1 on a Dell Inspirion 1525 laptop. :(
Comment 5 Justin Clift 2008-08-16 14:00:54 UTC
Ok, I've found what's causing this problem for my system, and the workaround I used to fix it.

After a lot of digging, incorrectly thinking it was a missing driver or something, the problem turned out to be that the mount commands used in the boot cd's init scripts.

They pretty much say:

  mount -o ro ${REAL_ROOT} ${NEW_ROOT}

That's line 396 of the init script.  Notice that it doesn't specify a filesystem type?  On most systems, the filesystem type will be "figured out" by the mount command.  On my laptop however, that's not happening.  So, this mount command doesn't figure out that should be using the "iso9660" type, and fails.

The workaround I used is to boot the cd image with:

  gentoo debug

The "debug" just tells the system to give me a shell prompt before doing the cd mounting stuff.

After the drivers load in the boot process and the system gives me the shell prompt, I type:

  echo "iso9660" > /etc/filesystems

and exit the shell, leaving the system to continue the LiveCD boot process.

The /etc/filesystems file tell the mount command which filesystems to try.  So, now when it runs, it picks the correct filesystem type automatically and things just work as they're supposed to.  For me anyway. ;->

In a perfect world, it'd be nice to let the guys/gals responsible for the init scripts know about this, in case it's easy and workable to add the "-t iso9660" option to the mount command line.

Anyone know who they are?
Comment 6 thoralf 2008-08-18 08:23:43 UTC
thank you justin!
just wondering why this seems to be an issue on dell hardware only. from my understanding, this should be a general bug ... unfortunately, i don't have any other 64bit hardware for testing at my disposal.

with kind regards,
thoralf.
Comment 7 Justin Clift 2008-08-18 11:28:09 UTC
Hi Thoralf,

Yeah, I don't know why either.  On a 64 bit Acer desktop at my work the exact same cd used to build the laptop, instead loads fine without any issues.

As it is, I'm mostly likely to return this laptop because it doesn't support VT, which is a pre-requisite for my development work.  (The Intel website claims my CPU has VT support when it actually doesn't, effectively making it useless for me.  Wish I could bill them for my wasted time... :/ )
Comment 8 Jarry 2008-08-18 15:39:44 UTC
(In reply to comment #6)
> just wondering why this seems to be an issue on dell hardware only. from my
> understanding, this should be a general bug ... unfortunately, i don't have any
> other 64bit hardware for testing at my disposal.

As I wrote in bug reporting, I discovered this problem on my 64bit hardware (Athlon64/X2, nForce4 chipset). It seems on some HW auto-mounting CD simply does not work. I could not even mount cd manually, because there was no /dev/sdc at all (where my dvd-writer should be).

Fortunatelly, install-amd64-minimal-2007.0.iso does not have this problem, so I could use it for installation...
Comment 9 Damien 2008-12-06 13:25:07 UTC
Also reproducible on x86 2008.0-r1 on hp pavillion laptop with ide disks.
Comment 10 Warren Wilkinson 2008-12-08 05:44:29 UTC
Okay, I had this problem and got past it.

This may well be what Justin mentioned first,
what I did was edit the GRUB boot line for GENTOO-NOFB, and add 
'debug' to the very end... and then it booted without any problems from the CD; I didn't get to a shell, nor did I have to 'echo iso9660' > /etc/filesystems, yet the livecd booted normally.
Comment 11 Sylvain Raybaud 2009-03-27 09:24:01 UTC
Hello

  I confirm the bug with livecd-2008-r1 and minimal-2008-r1 amd64.
my hardware is:
sata pioneer dvd drive
intel core i7 processor
msi 58x pro mobo

> The workaround I used is to boot the cd image with:
> 
>   gentoo debug
> 
> The "debug" just tells the system to give me a shell prompt before doing the cd
> mounting stuff.
> 
> After the drivers load in the boot process and the system gives me the shell
> prompt, I type:
> 
>   echo "iso9660" > /etc/filesystems
> 
> and exit the shell, leaving the system to continue the LiveCD boot process.
> 
> The /etc/filesystems file tell the mount command which filesystems to try.  So,
> now when it runs, it picks the correct filesystem type automatically and things
> just work as they're supposed to.  For me anyway. ;->
> 

not for me unfortunately... after I add iso9660 to /etc/filesystems I just get the same "Could not find root block device in ." if I "skip" the step (pressing 'q'), I get:
mount: can't find /newroot in /etc/fstab

good luck with the fix...
Comment 12 Sylvain Raybaud 2009-03-27 10:30:58 UTC
(In reply to comment #11)
> Hello
> 
>   I confirm the bug with livecd-2008-r1 and minimal-2008-r1 amd64.

I just tried with the minimal from 2007, same problem... So I guess I've got a specific problem. I will try another installation procedure and stop bothering you.
Comment 13 Justin Clift 2009-03-28 05:26:40 UTC
Not sure if it help, but my first thought here is that you should be able to use  "gentoo debug" at start up in order to get a shell prompt, and then try and determine from there whether your cd/dvd drive is even being detected by kernel at all.

It kind of sounds like it's not. :(

Do you have BIOS settings to change the mode the SATA/IDE controller it's connected to operates in?

ie. change it to/from AHCI and try again?

I've found it makes a definite difference with some things.
Comment 14 Justin Clift 2009-03-28 05:31:17 UTC
Oh, you may be able to get the 2007 release cd/dvd working instead (unsure).

After you've built and updated your system, you'd be running the same end result (latest) version of Gentoo anyway.

Just mentioning in case you're not yet all that familiar with how Gentoo works. :)
Comment 15 sf 2009-07-22 11:20:11 UTC
This seems to be a duplicate of bug #224895.
Comment 16 Ken Alker 2010-06-19 13:47:24 UTC
I bumped into this same problem and found a fix for my situation.  My CD-ROM drive is an older parallel IDE drive (not SATA).  The jumper on the CD-ROM was set to "SLAVE" rather than "MASTER" and it was the only device on the secondary IDE bus.  Because of this, it was not being recognized as a place to mount media (even though I could boot off of it just fine, and get as far as Jarry).

I changed the jumper setting to "MASTER" and upon the next reboot the CD-ROM was recognized as "hdc" (when viewing the many messages that scroll across the screen after booting off the CD).  Now during the attempt to mount media, it still fails on /dev/sda1 and /dev/sda2 (the two devices it had been trying, in my case) but then has success on /dev/hdc (a device that was not even displaying before correcting the jumper setting).

It would be nice if the init script could have pointed me in the proper direction.  Maybe it should have reported that it could not find anything on /dev/hdc, but perhaps that device did not even "exist" when it was trying to determine where to mount media.  Perhaps some type of warning after trying all devices to the effect of "no device found to boot, be sure that the device you are trying to boot from is listed in the devices tried above".  In this way, it might cause someone like me, who is not real familiar with device naming conventions, to have studied that list of devices it was trying a little more carefully and led me to the proper conclusion sooner.  But perhaps this would just make the init script too verbose.  Food for thought.
Comment 17 Elliott Berglund 2011-01-14 20:08:53 UTC
I'm having the same issue on my Intel DP45SG motherboard, it detects my hard drives fine, but won't detect my DVD drive. I've tried all the fixes here except using an old build because I am out of discs. I was using 'install-amd64-minimal-20110106.iso' when I got this error. Its not possible to mount the disc manually, because the /dev/sdc node doesn't even exist after booting. I have tried starting with 'gentoo docache' and 'gentoo mem=2048M' as well as 'gentoo-nofb' and 'gentoo debug'.
Comment 18 Jorge Manuel B. S. Vicetto (RETIRED) Gentoo Infrastructure gentoo-dev 2011-06-19 13:14:10 UTC

*** This bug has been marked as a duplicate of bug 224895 ***