Subject: LILO boot problem (still!)

From: Al Youngwerth <[email-masked]>
Date: Thu, 1 Aug 1996 16:20:32 -0600

After trying  everything everyone suggested a couple of weeks ago I gave up and went on vacation. I've been back all week but now I have to deal with it.

My problem is this: when booting from the hard disk I get "LI" from LILO and nothing else. I thought that this problem was caused by the fact that I was using a large drive in a machine with an old BIOS.

Assuming that the problem was the large drive, the obvious suggestion that the LILO documentation (and several of you) made was to use the LINEAR option. That didn't seem to help.

So I found the LILO documentation (which btw is excellent!). It pointed me into running lilo with the following options:

	lilo -v -v -v -t

which produced the following output:

LILO version 17, Copyright 1992-1995 Werner Almesberger

Reading boot sector from /dev/hda1
Device 0x0300: BIOS drive 0x80, 64 heads, 527 cylinders,
               63 sectors. Partition offset: 0 sectors.
Merging with /boot/boot.b
Device 0x0301: BIOS drive 0x80, 64 heads, 527 cylinders,
               63 sectors. Partition offset: 63 sectors.
Secondary loader: 7 sectors.
Device 0x0301: BIOS drive 0x80, 64 heads, 527 cylinders,
               63 sectors. Partition offset: 63 sectors.
Boot image: /boot/vmlinuz-2.0.0
Device 0x0301: BIOS drive 0x80, 64 heads, 527 cylinders,
               63 sectors. Partition offset: 63 sectors.
Setup length is 9 sectors.
Mapped 1008 sectors.
Added Linux *
    <dev=0xc0,hd=1,cyl=67,sct=85>
    "ro root=301"
Map file size: 8192 bytes.

I read further into the LILO technical documentation and it said the following about the "LILO" letters printing during startup:

The boot sector is loaded by the ROM-BIOS at address 0x07C00. It moves
itself to address 0x9A000, sets up the stack (growing downwards from
0x9B000 to 0x9A200), loads the secondary boot loader at address
0x9B000 and transfers control to it. It displays an ``L'' after moving
itself and an ``I'' before starting the secondary boot loader. If a read
error occurs when loading the secondary boot loader, a two-digit hex code
is displayed after the ``L''. This results in an endless stream of error
codes if the problem is permanent. Displaying these error codes is disabled
if the build-time option {NO1STDIAG} is set.
...
...
...
The secondary boot loader displays an ``L'' after being started and an ``O''
after loading the descriptor table and the default command line. Before
loading the descriptor table, it checks, whether it has been loaded at the
correct location and displays a question mark if it hasn't. If the
descriptor table has an incorrect checksum, a minus sign is displayed.

So my impression is that LILO is failing either during the load of the secondary boot loader or starting the secondary boot loader. In case it was the later (assuming a corrupted secondary boot loader) I downloaded a new lilo and installed (twice) with the same results.

So now I am assuming that the problem occurs during the loading of the secondary loader. But why? /dev/hda1 is the first partition on the drive and is only 200MB. It can't be crossing the 1024 sector limit. Why is lilo showing BIOS drive 0x80 as having 64 heads, 527 cylinders and 63 heads (this calculates out to the about the actual drive size using 512-byte sector size)? Is this the problem? The BIOS is actually set up as type 47 (user) with 16 heads, 2111 Cylinders and 63 sectors.

Any hints on where to go from here would be greatly appreciated.

Thanks,

Al Youngwerth
[email-masked]

---

From: "N. Salwen" <[email-masked]>
Date: Tue, 6 Aug 96 02:52:36 EDT

You are probably way ahead of me but I remember getting that error
under 2 conditions (I think).
1.  If the geometry of the disk didn't match its real geometry or the
	boot partition went past the 1024 sector (although
	it is supposedly possible to fake out the boot proms according
	to a little pamphlet by Matt Welsh that came with the old
	Infomagic CD set.)
2.  If I installed a new vmlinuz without rerunning lilo.

Good Luck,
Nathan