[TAG] Obscure LILO problem, 1-5 minute LILO delay uponbootup.
John Karns
jkarns at etb.net.co
Thu Feb 24 21:05:03 MSK 2005
On Thu, 24 Feb 2005, Justin Piszcz wrote:
> On Thu, 24 Feb 2005, John Karns wrote:
>
>>> at the LILO prompt or "LIL" I should say, it sits there for about 1-5
>>> minutes and then says Loading Linux... BIOS something for about
>>> another 60 seconds and THEN finally loads. Does anyone know what is
>>> up with this 5-6 minute delay to load Linux?
Notice what the exerpt from the bootdisk-HOWTO says under the 'LIL' entry:
===================================================
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
B. LILO boot error codes
Questions about these codes are asked so often on Usenet that we include
them here as a public service. This summary is excerpted from Werner
Almsberger's
[http://www.ibiblio.org/pub/Linux/system/boot/lilo/lilo-u-21.ps.gz] LILO
User Documentation.
When LILO loads itself, it displays the word LILO. Each letter is printed
before or after performing some specific action. If LILO fails at some
point, the letters printed so far can be used to identify the problem.
+---------+---------------------------------------------------------------+
|Output |Problem |
+---------+---------------------------------------------------------------+
.
.
+---------+---------------------------------------------------------------+
|LIL |The second stage boot loader has been started, but it can't |
| |load the descriptor table from the map file. This is typically |
| |caused by a media failure or by a geometry mismatch. |
+---------+---------------------------------------------------------------+
|LIL? |The second stage boot loader has been loaded at an incorrect |
| |address. This is typically caused by a subtle geometry mismatch|
| |or by moving /boot/boot.b without running the map installer. |
+---------+---------------------------------------------------------------+
|LIL- |The descriptor table is corrupt. This can either be caused by a|
| |geometry mismatch or by moving /boot/map without running the |
| |map installer. |
+---------+---------------------------------------------------------------+
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
===================================================
>> You don't specify the model of the controller, nor anything about the
>> kernel you're using: stock kernel? Custom compiled? If custom, is the
>> ide controller driver statically linked, or being loaded as an (initrd)
>> module? ... etc.
> The controller is a Promise 20269 ATA/133 controller, it is
> custom-compilied; statically linked into the kernel.
Well, it's usually best to err slightly on the side of too much info than
not enough ... just for grins, is it a 2.4 or 2.6 kernel?
> I believe it is a LILO problem as the LILO menu/etc has problems loading
> even before it touches the kernel.
I presume that while you were partitioning the new drive copying the
system to it, that there was no evidence of read problems (retries, read /
write delays, etc., which would tend to discount a surface area problem.
It might be worthwhile to try several iterations of a read test via dd, as
part of the process of elimination.
>> I'm not sure about the present state of ide booting requirements, but it
>> used to be that the important factor was the cylinder number, which is
>> related to, but not the same as, the size (in MB) of the boot partition,
>> depending on the data densityof the drive. With the older drives, the
>> relation ship was linear, as in N sectors per cylinder. That is no longer
>> the case however, with many / most / all of the more current generations
>> of hdd's.
> Agreed.
... and I forgot to mention that the max cylinder boundary was 1024.
However, I believe that some of the other settings such as LBA, etc.,
effectively change that, as the controller virtualizes the physical
geometry of the drive. It might be a good idea to check; however, if it
_does_ eventually boot, then I would agree with your presumption that
you're probably ok with that.
>>> I have also tried adding lba32 to lilo.conf && re-running lilo but this
>>> made no difference.
>>
>>> Anyone have any suggestions?
>>> Maybe linear addressing?
>>
>> That would certainly be an option. I've been in situations where using
>> that setting cured my boot problem.
> Any other thoughts?
>
> The weird part is it boots (after a 4-6min delay).. but it does boot. If
> there were a serious geometry/disk/issue one would think it would boot or
> fail, not have a delay and then work.
>
> Very odd...
I would also try it with the other drives disconnected, and out of the
scenario, as the controller behavior can be affected by the
characteristics of the combination of drives present on the ide bus.
--
John Karns
More information about the TAG
mailing list