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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.debian.org Links debian-announce debian-apache debian-arm-changes debian-beowulf debian-boot debian-cd debian-cd-vendors debian-changes debian-changes-digest debian-isp debian-kde debian-laptop debian-mirrors-announce debian-news debian-security debian-security-announce debian-testing debian-user debian-user-digest Request more information about Pantek

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

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