Re: rootdelay=9 kernal option - why?
On Mon, Jan 9, 2012 at 7:22 PM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> francis picabia a écrit :
>> On Sat, Jan 7, 2012 at 10:11 AM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>>
>> I'm sure I didn't learn of the solution initially through the debian
>> release notes.
>
> You wrote that you generally print out the release notes prior to
> upgrade. I supposed that you read them too.
No, I don't read every word. I skim through the headings as
many sections of the upgrade notes do not apply to me. The first time
the boot fail happened and I resolved it, it was about a year ago, so I don't
remember in detail what I found. But I can say that the release
notes description does not describe the problem from
the end user's point of view with enough detail.
I didn't see anything there about my sitting at an initramfs
prompt, so I went to google. I think there should be a section on
the boot failure in the section 4.5 "Possible issues during upgrade",
and call it specifically by what the end user sees. We don't see
a boot timing issue with udev. We see the initramfs prompt.
I'll make a bug report for upgrade-reports.
>> Older SCSI disks and controllers (2002 to 2006 vintage) running mirror boot
>> disks with mdadm seems to trigger the flaw often here.
>
> I suspect that SCSI enumeration may take quite a long time before the
> disks are available and the RAID arrays assembled, causing the problem.
Well, with all due respect, there was no problem like this in Lenny on
any of my systems, so it appears to me like a bug introduced with
the new kernel or some change related to the new kernel.
>>> This is not specific to Squeeze, the issue was already reported in Etch
>>> and Lenny release notes. And it is not a kernel issue but an initramfs
>>> issue.
I'll assume this is not a simple problem to automatically resolve
and resolve without options being passed along. But I'll say
that if the problem has been introduced by attempts to speed up
the boot process, they should back off. Especially for the
i686 kernel. There are many people without much money
using Debian (and other free distros), and it would be natural
to assume they might also be using hardware in its second life.
>> The solution is within kernel params.
>
> Actually, it is not really a kernel parameter here. Options passed to
> the kernel command line are not all directed to the kernel itself. It
> can be a convenient way to pass parameters to other pieced of software.
> I.e. the "break" option is used by the Debian initramfs to stop its
> execution at various stages ; rootdelay is used by both the kernel and
> the Debian initramfs.
>
> As a kernel parameter, rootdelay specifies the delay before mounting the
> root filesystem. But when an initramfs is used, the kernel itself does
> not mount the final root device, it mounts the initramfs instead. So
> there is no point in waiting for rootdelay. The initramfs enumerates the
> hardware, loads the needed modules to handle the disks and then mounts
> the actual root filesystem. But there can be some time between when a
> module is loaded and the hardware it handles becomes available.
>
> The Debian initramfs has been designed so that it uses the same
> rootdelay parameter (extracted from the kernel command line) before
> trying to mount the final root filesystem. But it could have been a
> different parameter name.
Thanks for the detailed description.
Reply to: