Re: "Waiting for root file system ..."



Robert P. J. Day 写道:
On Fri, 21 Aug 2009, Niu Kun wrote:

Robert P. J. Day 写道:
(NOTE: please ignore my earlier and utterly misinformed plea
for help. turns out that, in attempting to mount /dev/sda1 as the
alleged root filesystem, the new 2.6 kernel was finding the
external backup hard drive at /dev/sda1. no surprise that that
wasn't bootable. ack.)

so now i'm getting what appears to be another common diagnostic
as seen in the subject line. i can see that a common reason is
the remapping of device names from hda -> sda. however, even
under the old 2.4 kernel on this upgraded etch system, the devices
were accessed via sda (megaraid raid controller). so the advice
to rename from hda to sda isn't relevant. (but is there something
else about the megaraid controller that might be relevant? i've
opened up the relevant initrd image and it does in fact contain
megaraid modules.)

thoughts? the last few lines of boot diagnostics are:

Done.
Begin: Mounting root file system ...
Begin: Running /scripts/local-top ...
Done.
Begin: Waiting for root file system ...

then ... hang. it's pretty clearly a problem in just
seeing/accessing the sole hard drive in the system. i just can't
see what it is.

How about dig into your system with a live CD to see the device
mapping in your system?

already did that with a gentoo-based rescue CD, the current "sda"
nomenclature worked just fine. i could mount /dev/sda1, and it is the
root filesystem i'm going after, and it's what's in the grub conf
file.

And by the way, have you ever upgraded a sarge system with 2.4
kernel to a 2.6 lenny system?

that is the *ultimate* goal, but i'm doing this in steps. on the
chance that it's the default 2.6.18 etch kernel, i just upgraded that
to the 2.6.24 etchnhalf kernel. we'll see if that fixes things.

Will changing from hda to sda be sufficient?

even the 2.4.27 kernel under sarge was using "sda" notation already,
since the single hard drive was on a megaraid controller. so the
standard solution of s/hda/sda/g wasn't relevant here. anyway, time
to test the newly-installed 2.6.24 kernel. we'll see if that fixed
anything.

rday

p.s. this system started out as a not-fully-upgraded sarge system.
in steps, i brought it up to a fully-upgraded etch system but still
running the 2.4.27 kernel, after which i followed the docs to upgrade
the kernel to the default 2.6.18 etch kernel. and that's when things
failed to boot. so, just for the heck of it, i installed the 2.6.24
etchnhalf kernel as well. now we'll see.

--

========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA

Linux Consulting, Training and Annoying Kernel Pedantry.

Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
Have you ever run update-initramfs command manually on the pre-compiled kernel?
I remember that I fixed such a problem once.
Hope this will help. And look forward to your feedback.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx