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

["Cameron L. Spitzer" <cls@truffula.sj.ca.us>]

Vidar Langseid wrote:

Hi

In article <9l0Hy-3FQ-5@gated-at.bofh.it>, Johannes Wiedersich wrote:
  

Cameron L. Spitzer wrote:
[snip upgrade instructions]
Thanks for posting your experience! I am sure it will be useful to
others.

      

You could have a debate about whether this is an installer
bug, a kernel package bug, a udev bug, or operator error.
        

If I understand correctly, you upgraded the kernel and the new kernel
would not boot. Then it would be a kernel bug.
      

That was my initial conclusion.  But then I spent some time
googling for the error messages.  A lot of people have had this
same hang, and most of them got there by some other path than I did.
So I think it may be a more general problem than that.
    

Yes, and I is one of them who just experienced it. Just installed Etch but on 
first boot after installation I got the "Waiting for root file system..."

My (old) mainbord (BE6) have two IDE hardisk controlles onboard. One generic 
IDE controller (piix) and a hpt366 controller.

It seems that in default kernel in Etch that all IDE drivers are loaded as 
modules. If you then have multiple IDE controllers you are in trouble because 
the IDE kernel modules will be loaded in random order.
  

I guess everyone with multiple IDE controllers will end up with the same 
problem and the debian installer doesn't warn you about this. 

Not sure how this should be fixed either. Using ext2/ext3 labels in fstab and 
grub config is one way I guess. Using UUID ( 
http://michael-prokop.at/blog/2006/08/11/stable-root-device-aka-uuid/  ) in 
fstab and grub config is probably another way.
A 3rd solution would be to enforce that that one kernel module (piix in my 
case) is loaded before an other (hpt366 in my case) but that is not possible 
AFAIK. Or is it ?
  

It seems to me the real issue isn't the association between drivers
and partitions.
The problem is that the association between device names and partitions
isn't stable.

Suppose I built a machine with a PIIX motherboard and an Adaptec
add-in card.  Then my PIIX motherboard shorts out, and the only
available replacement is a VIA motherboard.
If my device names to partitions association depended on PIIX getting
loaded first, I just lost that stability.  I've got a 50/50 chance I'll have
to rescue that machine before it will boot correctly.
Volume labels or UUIDs in grub/menu.lst and /etc/fstab is the only
way I can see to fix that.

Not sure if it is possible to fix this with udev rules. I suspect the IDE 
kernel modules are loaded before udev daemon is started though......
  

Udev is a secondary issue.  It would be nice to have the association
between device names and partitions stable.  Then the device icons
on your desktop wouldn't break when you replace your motherboard.
That can be nailed down in the udev rules.
Multiple sound cards can be dealt with in /etc/modules
because sound is never in the boot path.
NIC cards have the same problem as the broken motherboard.
If I associate an ethN name with a MAC address in udev rules,
then my network, and possibly my boot, break when I have
to replace the NIC card.  But maybe there is no way around that.

It would also be nice to have a minimal set of permanent device
nodes that survive without udev.  Once upon a time you could
boot a unix system with only /bin/sh installed.  Now we need an
initrd and an automatic module loader because there are too
many device types to compile them all in.

It seems to me that requiring for boot
a user space daemon which is difficult to configure and poorly
documented is a bad idea in general.  Needlessly failure prone.
The fact that it broke the upgrade from Sarge to Etch is a
strong signal.  Perhaps udev is worth it.  In that case the
Debian installer should use volume labels or UUIDs.


Cameron