[lug] LILO and LIes

[D. Stimits]

John Starkey wrote:
> 
> > What other hd's are present? What is in /etc/fstab? It sounds like lilo
> > is using the wrong lilo.conf, or else your boot loader is looking at the
> > wrong boot record, such as mixing up mbr and partition boot records. You
> > may want to forcibly name the conf file:
> > lilo -v -C /etc/lilo.conf
> 
> Damn. I tried it and was psyched. Looked like it'd worked. Even gave me
> the 'added vmnew' message. But same thing. Only shows 'linux' at the boot
> prompt. I think this is the right track though based on everyones in put.
> 
> To answer the question above. I've got 3 HDs.
> 
> (sorry I can't script this because I'm on ssh and pine).
> 
> /home   hdd1 (the whole drive)
> /usr    hdb1
> /var    hdb3
> /db     hdb4
> /       hda1
> /lfs    hda5
> 
> I'm not sure this is telling you what you wanna know. I don't know where
> to find the 'bootable' flags.
> 
> Everything else is unmounted. / is at 98%, maybe there's a problem with
> that? I'm not sure I understand the whole mbr being on the first 1024
> thing. I understand why but what's the mbr and how big is it really ?
> 
> Thanks.
> 
> john

Forgot one explanation. mbr is master boot record, it resides at the
beginning of each hard drive. Additionally, partitions each have a boot
record. Often the mbr points to various operating systems, and partition
boot records are not used. But instead of the mbr pointing directly at
an operating system, they can also point at a partition boot record,
which itself launches a secondary boot loader. A good example is if the
NT boot loader is installed, and it is asked to offer a choice to boot
linux, you'd point it at the partition boot record instead of linux; the
partition boot record is where you would put lilo as the secondary
loader. The NT boot loader doesn't understand linux, but it does
understand how to point at partition boot records, which then contain
the loader that understands linux (that is one scenario only). By naming
"boot=/dev/hda", you point at the mbr; had you done "boot=/dev/hda1",
you would have pointed it at the partition boot record for the first
partition. The "root=...." stuff points it at information to actually
find the initial filesystem. If your boot loader is run from mbr, but
you installed to partition boot record, mbr might never see the changes
(unless mbr already pointed at the secondary loader on the changed
partition boot record). Had you installed to the mbr of the 2nd hard
drive instead of the first, the changes still would not be visible,
unless the first drive lacked a boot record in the mbr, and the bios
decided to search for a boot record in the second drive. Confusing, eh?
Just remember that if you are using only lilo, very very likely you will
always install to the mbr of the first hard drive, which in turn points
directly at the o/s, and then does not need a paritition boot record at
all.

The 1024 thing is a bios limitation from the old days when it was
inconceivable we'd ever need this big of a drive (I started running
slackware within about a year of linux coming out, and manually ran this
lie). There are just so many bits reserved for naming the cylinder
within the hd (basically how deep the head must go towards the center of
the spindle) to get to a certain location. The bios simply did not
reserve enough bits to name more than the 1023rd cylinder. But what
works nicely, and had to be used in the early days before things like
bios supported LBA mode, was a good lie. The actual position on a disk
is given by the combination of cylinder and head (there is one head on
each side of a disk platter, and multiple platters)...how far in to move
and which surface to read. Once you know where the head moves, you also
need to know that this refers to an entire subset of the cylinder on
that one platter, called the sector. Cylinder, head, and sector (CHS) is
the geometry. You can never lie about the sector size (the chunk of the
one platter along a single cylinder), typically something like 512
bytes. You can lie all you want about cylinder and head so long as
cylinder times head remains constant. E.G., if you had 2048 cylinders
and 16 heads, the system works just fine to go to the same location by
specifying that it has 1024 cylinders and 32 heads; at some point during
the bootup you simply tell the kernel the true dimensions, which it then
uses. So if you had 4096 cylinders and 16 heads, you could still boot
the entire surface (because the bios can address it) by telling it
initially that you have 1024 cylinders 64 heads. Once you are booted,
linux does not use the bios for further access, so it is only a boot
limit. Modern bios modifications for large disks simply automate the
process of the lie, so the o/s doesn't need to worry about it...but only
up to the point where it can handle the number of heads. Some of the
newer lilo stuff is capable of ignoring the bios entirely, and newer
lilo won't require even the 1024 cylinder limit, bypassing the bios.

Sometimes if you place a kernel image on a partition that starts under
1024 but is so large that it exceeds the limits further out, it'll still
boot...if you got lucky and it happened to be below cylinder 1024. If
you ran lilo, and it wasn't below 1024, the lilo prompt would start
running, then it would suddenly stop before it ever found the kernel
image, acting lobotomized.

So that was a big long scary story about the days of computer cavemen.