Hendrik Boom <hendrik@???> wrote:

>> I don't understand this. My understanding of lilo is that is just finds
>> the blocks where the kernel is, and usually the kernel file is not placed
>> in any superblock or signature; shouldn't the file system driver ensure
>> that ?
>
> It has to find the partition with the kernel first. If I understand
> correctly, its block numbers are relative to the start of the partition.
>
> It's time to find someone who really knows. Where does it store its
> table of block numbers, for example?

Now, I do recall looking into some of this a loooot of years ago, when I was still very much a newbie and playing with the likes of Slackware (on 3 floppies) or a distro I vaguely recall as Purple Tentacle (on floppies) which supported the Adaptec SCSI card I'd acquired from somewhere. This was back when a 486 (I didn't have one !) was "wow, you've got one of those" technology, and I was scavenging RAM chips off SIMMs (probably 256kbyte) to make others into 9 bit modules.
So with my excuse for getting it wrong out of the way ...

When you "compile" the LILO bootloader, the compiler finds the second stage loader on disk and gets a list of sector numbers storing it. I strongly suspect that these are absolute relative to the disk, not relative to the partition.
The first stage loader, together with it's table, is (normally) stored in the MBR - the first couple of sectors of the disk.
The compiler also gets lists of sectors for each thing you want to be able to load, and I'm sure these will be stored in the boot partition as files - but again, the second stage loader will be given a list of sectors to read in order to get these lists.

The first stage loader has to use the BIOS interface, which on older computers is restricted in scope - remember the problems with "big" disks when disks grew beyond what we'd call "not worth bothering with" these days ? This is partly why the requirement for a separate /boot came about - it was the only way to guarantee that the second stage loader (not the kernel or initramfs) would be within the sectors that the first stage was capable of addressing.
Ah, this comes up as the first result :
http://www.tldp.org/HOWTO/Large-Disk-HOWTO-4.html
528Mbyte, yup, Meg, not Gig - how times have changed.

I also vaguely recall there being a Stage 1.5 loader for some situations. Though what those were escapes me.

OK, so when our computer boots, it loads whatever is in the first sector of the disk and executes it. This is the first bit of LILO, which then loads the second sector to get the rest of itself and the sector list for the second stage (or stage 1.5). It loads these into memory using the BIOS interface, and then transfers control to what it's loaded.

The second stage can be bigger as it doesn't need to fit into the first 512 bytes of the disk !

The second stage is able to offer a selection of things to boot, but I think it still uses block lists to read in the <whatever it's going to run>. It still doesn't have device drivers for everything, so still has to use the BIOS interface. When your kernel loads, it has the drivers for your hardware (I'm going back to pre-modular kernels here !) and so it can use the full capabilities of the interfaces, disks, etc - so it isn't bound by the 528M limit.

The different letters of LILO are printed as different bits of code load & run - so giving some rudimentary debug of where it's got stuck if it "doesn't work".

Ah, should have looked first - there's a Wikipedia page which seems to match what I recall.
https://en.wikipedia.org/wiki/LILO_(boot_loader)


So LILO is very fragile - if anything moves on a disk then LILO breaks. But it has the advantage of simplicity - as long as the system can read and execute the MBR, and then the first stage loader can load a list of sectors using the BIOS interface, then it can run. You don't get interactive configuration, but you also don't get the complexity of having to support all the sort of stuff Grub deals with.