FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 11-16-2007, 12:03 PM
Vidar Langseid
 
Default "Waiting for root file system..." hang solved

Hi

> [This message has also been posted to linux.debian.user.]
>
> 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. In my case, if the
hpt366 kernel module is loaded first, the disks attached to it will be named
hda, hdb, hdc and hdd. It the piix kernel module is loaded first, then those
disks will be named hda, hdb, hdc and hdd (the hpt366 disks will then be
named hde, hdf, hdg and hdh) .

This was never a problem with Sarge kernel images because there the generic
IDE controller drivers was compiled into the kernel (thus loaded before any
modules) while other IDE drivers (like hpt366) was compiled as modules.
I guess everyone with multiple IDE controllers will end up with the same
problem and the debian installer doesn't warn you about this.

I was going to report this as bug report but not sure in which package the bug
report should be assigned to. I guess relevant packages are kernel, debian
installer, mkinitrd?
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 ?
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......


PS
Please CC me on any reply as I am not subscribed to the list.
Sorry for also messing up the threading but had to cut&past from the archive (
http://lists.debian.org/debian-user/2007/11/msg00215.html ) and had no idea
how to set the message-id correctly when replying...

Best regards,
Vidar L

--
vl@ez.no | eZ systems | ez.no


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-16-2007, 06:54 PM
"Cameron L. Spitzer"
 
Default "Waiting for root file system..." hang solved

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
 

Thread Tools




All times are GMT. The time now is 04:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org