On Mon, Jan 9, 2012 at 7:22 PM, Pascal Hambourg <pas...@plouf.fr.eu.org> wrote: > francis picabia a écrit : >> On Sat, Jan 7, 2012 at 10:11 AM, Pascal Hambourg <pas...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+akb6f198yhzf7suvq2btvwjokfl2mko2qfkdrrhmx4b2d...@mail.gmail.com
