Steps...
At the very beginning, the BIOS locates "something bootable"--either a floppy boot sector or a master boot record on a hard disk. It loads this into memory and jumps to it. This will be LILO's primary loader unless LILO was installed in a disk partition (not the MBR). If so, there will be an extra step as the MBR program locates a partition, finds the boot sector, and loads that into memory and jumps to it.
In this illustration, we see the boot code being copied to memory. The gray expanse is the the disk drive. The only thing known so far is the location of the master boot record, because its location is fixed; and the position of the map file, because its location was inserted in the boot code when lilo wrote the boot sector.
As this code
(called the primary loader in the how
it's built section), begins to execute, the first "L" is
printed. What this code must do is load the secondary boot loader. To do
this it must read the map file first, because the map is the only file
it knows the location of.
If the map file can't be read, you'll see an error code following the "L". These codes generally describe errors returned by the disk controller. Sometimes a retry will succeed, in which case the process will proceed but you will see the code printed anyway. Hardware errors are the only thing that will prevent reading the map file--even if the information is wrong, it will get read anyway.
Once the map file is read, LILO can find out where the seconday bootloader (the rest of the boot.b file) is located. This is read into memory to be executed.

This "I"
is printed just before jumping to the secondary loader code. If
you see "LI" and then the computer stops, then what was supposed
to be the secondary loader...wasn't. One reason for this is what they call
a "geometry mismatch". The recorded locations
are obtained from the Linux kernel (when you run /sbin/lilo) but it's the
BIOS that uses these locations to read the files. If the BIOS's idea of
disk sector numbering differs from that of Linux, you have geometry mismatch.
This is more likely with hard disks, since floppies don't have many variations.
A more common cause of halting at this point is that the file just isn't there anymore. If map or boot.b are moved and you don't run /sbin/lilo the changes aren't recorded in the boot sector or map file. Remember also that if a copy or edit operation makes a new file somewhere, the old ("deleted") file may be left in its original location (without any directory entry to find it). The old pointer in the map file still points to it. Everything works properly until later when this old deleted file is overwritten as reclaimed space. On that day your LILO breaks.
A common oversight with floppies is to have some of the referred files (in lilo.conf) on the hard disk. The map is capable of pointing to different files on different disks. This will work fine until you move the floppy to another computer. Now the files aren't where they're supposed to be. The remedy for this (floppies only!) is to (a) ensure that lilo.conf refers to files on fd0, and (b) that the files are on the floppy. If you forget (b), lilo will remind you when you attempt to run it. Examples elsewhere..
The
first thing the secondary loader does is print the second "L".
Now it attempts to read the map file and find out where the rest of the
files it needs are. It also checks to see that it really got
loaded into the right location in memory. If any of this is wrong, you
will see a hyphen (-), question mark (?), or it will stop right there.
I've never seen this, and I've never seen anybody else say they've seen
this, so I won't treat it in any detail. The documentation says geometry
mismatches are usually the cause, or sometimes, the same things that cause
it to stop after "LI". A bad disk is also suggested.
The bootloaders
and "descriptors" (map contents) have all been loaded and verified,
and LILO can now successfully run. Ultimately control will be passed
to a Linux kernel, which has to be loaded and run, and then the startup
scripts have to succeed, you have to mount a root filesystem...but you
are past LILO at this point. Alternatively, LILO loads boot code
for a non-Linux system and jumps to it. At that point it's up to that system's
boot code to handle startup.