Re: "Waiting for root file system..." hang solved
In article <9ldY5-Hs-17@gated-at.bofh.it>, Andrew Sackville-West wrote:
>
> On Fri, Nov 02, 2007 at 03:33:06PM -0700, cls@truffula.sj.ca.us wrote:
>> In article <9l0Hy-3FQ-5@gated-at.bofh.it>, Johannes Wiedersich wrote:
>> > Cameron L. Spitzer wrote:
[ when I upgraded Etch to Lenny, device names changed and the
Lenny kernel wouldn't boot, but the Etch kernel still worked. ]
>> > If I understand correctly, you upgraded the kernel and the new kernel
>> > would not boot. Then it would be a kernel bug.
[cls:]
>> My friend in Los Angeles tried to install Ubuntu for a friend,
>> and got stuck "waiting for root file system" in the middle of
>> a fresh install from CD. When he booted his trusty Knoppix CD
>> it revealed the root file system was just fine. I suspect udev
>> device names are less persistent than we have assumed they are.
> yeah, this is probably *not* a kernel bug but more likely either a
> udev bug or initramsf-tools bug. Something got changed there in the
> device naming and that's not really the kernel's fault, so far as I
> know.=20
>
> BTW, were you able to boot through the busybox?
I didn't have to try. The Etch kernel+initrd still worked.
As soon as the system was up I changed /etc/fstab and grub/menu.lst
to use volume labels which make the Lenny kernel+initrd work too.
> I've had to learn my
> way around that having just reconfigured my laptop. The critical item
> is the contents of $ROOT. The value of $ROOT gets set by the kernel
> command line and if it doesn't match, then you have trouble. If you
> change that to the appropriate value you can then 'exit' busybox and
> the boot will carry on.
I didn't know that. If I hadn't had a working option in GRUB
I would have tried editing the kernel command line next.
I've also rescued Debian by booting Knoppix, mounting stuff,
and running a chroot shell.
> Once you're up and running, then rebuil the
> initrd's.
I actually tried that before going to volume labels. Rebuilding
the initrd puts the same old /etc/fstab in the new initrd image.
That doesn't get you past the udev hang. I guess a more sophisticated
update-initrd would alert you to the difference between the
current mtab and the /etc/fstab contents. It wouldn't know whether
the difference was intended, so it would have to ask what to do.
And if I'd put a new device-names fstab in the Etch initrd then
my Etch kernel wouldn't have worked any more.
Come to think of it, I only learned about volume labels a few
months ago, solving a similar problem. I installed an Etch web
server on /dev/hde (a drive on an add-in ATA interface card),
in a test machine that already had an Etch workstation on /dev/hda.
And when I launched the hde kernel with GRUB it booted the
workstation instead! I fiddled around with the udev rules
but they were so poorly documented I wasn't confident I could
upgrade the machine remotely.
I've been using Debian for a long time. It's just *weird* to
see anything broken like that.
Cameron
Reply to: