Re: rootdelay=9 kernal option - why?
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
Re: rootdelay=9 kernal option - why?
On Sat, Jan 7, 2012 at 10:11 AM, Pascal Hambourg pas...@plouf.fr.eu.org wrote: Hello, Camaleón a écrit : I wonder how did you finally reached the conclusion for the rootdelay, I wouldn't either have imagined so after finding any clue over Internet, forums and mailing lists... even after reading the Relase Notes, you still have to connect the points to identify your booting problem with the solution showed there. OP : Without it, the root file system is not found and it drops you into the initramfs prompt. Release notes : The usual symptoms are that the boot will fail because the root file system cannot be mounted and you are dropped into a debug shell. Quite similar, isn't it ? I'm sure I didn't learn of the solution initially through the debian release notes. Today if this happens, there are 3 hints shown on the screen and rootdelay is one of several cause/solutions listed. However the first time it happened, I needed some googling to find the answer, and the system was down during the middle of a Debian upgrade until I did see the solution. It is still unclear why you're seeing the error, unless you're at any of the mentioned scenarios (using USB disks, RAID or LILO) the timing problem should not bit you. Older SCSI disks and controllers (2002 to 2006 vintage) running mirror boot disks with mdadm seems to trigger the flaw often here. We're poor, but we are in the first world. I can imagine this problem coming up often in other parts of the world. The kernel/initramfs folks should remember not everyone can green their equipment as frequently as some would like to. OP : We typically have mdadm style software raid on all boot systems, using /dev/md0 typically as root file system. To the OP : 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. The solution is within kernel params. Thus I'd think there is some room for the kernel to be part of the solution, or at least talk to the initramfs folks to explain the problem. My hardware is staying the same. It is the adoption of a newer kernel that is breaking things. Release notes do not prevent problems like this but offer a band-aid. Again, the release notes description of the symptoms and solution is not detailed enough to appear in search results. -- 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+akb6ghs3ksvakx0xn9usbfp3dq6nfantcwevu3uvoy6os...@mail.gmail.com
Re: rootdelay=9 kernal option - why?
On Lu, 09 ian 12, 15:17:11, francis picabia wrote: My hardware is staying the same. It is the adoption of a newer kernel that is breaking things. Release notes do not prevent problems like this but offer a band-aid. Again, the release notes description of the symptoms and solution is not detailed enough to appear in search results. It's still not late to send suggestions for improvement ;) Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: rootdelay=9 kernal option - why?
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. 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. 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. 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. -- 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/4f0b76d2.7000...@plouf.fr.eu.org
Re: rootdelay=9 kernal option - why?
On Fri, 06 Jan 2012 16:23:03 -0400, francis picabia wrote: On Thu, Jan 5, 2012 at 12:28 PM, Camaleón noela...@gmail.com wrote: On Thu, 05 Jan 2012 08:12:03 -0400, francis picabia wrote: On most of my older systems, I've needed to add the option rootdelay=9 to make the system boot when upgrading to the kernel and such for squeeze. Without it, the root file system is not found and it drops you into the initramfs prompt. Mmm, yes, it is documented: 4.6.3. Boot timing issues http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#boot-timing Thanks for the link... This type of documentation can always be found if you already know the problem and solution, but it is invisible if you only have a symptom. Sure! :-) I wonder how did you finally reached the conclusion for the rootdelay, I wouldn't either have imagined so after finding any clue over Internet, forums and mailing lists... even after reading the Relase Notes, you still have to connect the points to identify your booting problem with the solution showed there. I was already expecting it this time, but the first time I encountered it I took some time to find the problem. The better way to describe it is to include details on what kind of failure you will see, with some parts of the text as it appears on the screen. I would not call it boot timing issues, but rather No root file system on boot, drops to initramfs prompt. Calling it merely a debug shell is too vague and does not match google searches. People discussing it in forums and mailing lists match the search terms, while the Debian release notes do not. I agree, but this is something that comes with the years and experience. Old dogs have developed a sixth sense for identifying such issues :-) I generally print out the release notes prior to upgrade. In particular, it might help to place this in chapter 5 rather than 4. Chapter 5 is Issues to be aware of for squeeze. As this didn't happen in Debian 5, I would think it belongs there. There has been some improvement on the errors shown on the screen lately, with at least 3 potential problems listed when this goes sour, and one of them is the rootdelay option. It is still unclear why you're seeing the error, unless you're at any of the mentioned scenarios (using USB disks, RAID or LILO) the timing problem should not bit you. Greetings, -- Camaleón -- 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/pan.2012.01.07.11.59...@gmail.com
Re: rootdelay=9 kernal option - why?
Hello, Camaleón a écrit : I wonder how did you finally reached the conclusion for the rootdelay, I wouldn't either have imagined so after finding any clue over Internet, forums and mailing lists... even after reading the Relase Notes, you still have to connect the points to identify your booting problem with the solution showed there. OP : Without it, the root file system is not found and it drops you into the initramfs prompt. Release notes : The usual symptoms are that the boot will fail because the root file system cannot be mounted and you are dropped into a debug shell. Quite similar, isn't it ? It is still unclear why you're seeing the error, unless you're at any of the mentioned scenarios (using USB disks, RAID or LILO) the timing problem should not bit you. OP : We typically have mdadm style software raid on all boot systems, using /dev/md0 typically as root file system. To the OP : 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. -- 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/4f0852aa.9050...@plouf.fr.eu.org
Re: rootdelay=9 kernal option - why?
On Sat, 07 Jan 2012 15:11:54 +0100, Pascal Hambourg wrote: Hello, Camaleón a écrit : I wonder how did you finally reached the conclusion for the rootdelay, I wouldn't either have imagined so after finding any clue over Internet, forums and mailing lists... even after reading the Relase Notes, you still have to connect the points to identify your booting problem with the solution showed there. OP : Without it, the root file system is not found and it drops you into the initramfs prompt. Release notes : The usual symptoms are that the boot will fail because the root file system cannot be mounted and you are dropped into a debug shell. Quite similar, isn't it ? For the old guard, yes. For average users, not that similar :-) It is still unclear why you're seeing the error, unless you're at any of the mentioned scenarios (using USB disks, RAID or LILO) the timing problem should not bit you. OP : We typically have mdadm style software raid on all boot systems, using /dev/md0 typically as root file system. To the OP : 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. Uh? I did miss that message... ah, okay, it was said on a reply to Alexey. OTOH, Release Notes do not specifiy what kind of RAID triggers the problem (hardware raid, linux raid, fakeraid...). For instance, I have adaptec hardware RAID controllers and didn't notice this on my Lenny installs. I agree with Francis this is not normal or something expected. At least is not something I have experienced before. Greetings, -- Camaleón -- 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/pan.2012.01.07.16.07...@gmail.com
Re: rootdelay=9 kernal option - why?
On Thu, Jan 5, 2012 at 8:36 AM, Alexey Eromenko al4...@gmail.com wrote: Do you need this only for upgrade to squeeze or to run squeeze afterwards ? I am running Squeeze (amd64) on 4 PCs here (fresh install from DVD), and no problems. We need the kernel option from then on for the kernel used by squeeze. We typically have mdadm style software raid on all boot systems, using /dev/md0 typically as root file system. The rootdelay=9 doesn't cause much delay - that is the maximum it might wait, but for us it perhaps pauses for 1 second. On the most recent case, I saw this problem appear with an Intel based motherboard, the SE7520JR22, from around 2006. We are booting from a pair of SCSI drives on Ultra 320 with chipset Symbios Logic 53c1030. I also had a problem last year with an IBM xSeries 345. In that case we needed 'rootdelay=9' and also kernel option: 'scsi_mod.scan=sync'. Again, the up to date kernel from Debian 5 didn't require this option to boot up the system. -- 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+akb6fmybigswjux6fkz9q4iwoomuypllah316n_mbbzil...@mail.gmail.com
Re: rootdelay=9 kernal option - why?
On Thu, Jan 5, 2012 at 12:28 PM, Camaleón noela...@gmail.com wrote: On Thu, 05 Jan 2012 08:12:03 -0400, francis picabia wrote: On most of my older systems, I've needed to add the option rootdelay=9 to make the system boot when upgrading to the kernel and such for squeeze. Without it, the root file system is not found and it drops you into the initramfs prompt. Mmm, yes, it is documented: 4.6.3. Boot timing issues http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#boot-timing Thanks for the link... This type of documentation can always be found if you already know the problem and solution, but it is invisible if you only have a symptom. I was already expecting it this time, but the first time I encountered it I took some time to find the problem. The better way to describe it is to include details on what kind of failure you will see, with some parts of the text as it appears on the screen. I would not call it boot timing issues, but rather No root file system on boot, drops to initramfs prompt. Calling it merely a debug shell is too vague and does not match google searches. People discussing it in forums and mailing lists match the search terms, while the Debian release notes do not. I generally print out the release notes prior to upgrade. In particular, it might help to place this in chapter 5 rather than 4. Chapter 5 is Issues to be aware of for squeeze. As this didn't happen in Debian 5, I would think it belongs there. There has been some improvement on the errors shown on the screen lately, with at least 3 potential problems listed when this goes sour, and one of them is the rootdelay option. -- 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+akb6f+7dybhkaiku3azob_yurl1hvhygqqkq69inyykek...@mail.gmail.com
rootdelay=9 kernal option - why?
On most of my older systems, I've needed to add the option rootdelay=9 to make the system boot when upgrading to the kernel and such for squeeze. Without it, the root file system is not found and it drops you into the initramfs prompt. I've fixed this on about 5 or more systems, and it has come to the point where I have to wonder why does the kernel present this problem? Why not have a safer default? The solution isn't hard, but it seems pointless to break the boot up for so many systems. Really an issue for kernel devs, but I suppose the installer for Squeeze could possibly use some sort of magic to guess when it might be needed. Can rootdelay=9 cause any problems? -- 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+AKB6Ez4=W_92i+Do_3=q-d7uz1gj3nc4-gbn+d2vf9gf6...@mail.gmail.com
Re: rootdelay=9 kernal option - why?
Do you need this only for upgrade to squeeze or to run squeeze afterwards ? I am running Squeeze (amd64) on 4 PCs here (fresh install from DVD), and no problems. -- -Alexey Eromenko Technologov -- 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/CAOJ6w=fevzt-bc5uz583arnkcuo9g+cihqog04jbdnz47uv...@mail.gmail.com
Re: rootdelay=9 kernal option - why?
On Thu, 05 Jan 2012 08:12:03 -0400, francis picabia wrote: On most of my older systems, I've needed to add the option rootdelay=9 to make the system boot when upgrading to the kernel and such for squeeze. Without it, the root file system is not found and it drops you into the initramfs prompt. Mmm, yes, it is documented: 4.6.3. Boot timing issues http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#boot-timing I've fixed this on about 5 or more systems, and it has come to the point where I have to wonder why does the kernel present this problem? Why not have a safer default? The solution isn't hard, but it seems pointless to break the boot up for so many systems. Really an issue for kernel devs, but I suppose the installer for Squeeze could possibly use some sort of magic to guess when it might be needed. I would ask at Debian kernel mailing list. Can rootdelay=9 cause any problems? A delayed booting (+9 s)? :-) Greetings, -- Camaleón -- 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/pan.2012.01.05.16.28...@gmail.com
