On Tuesday 19 December 2006 16:01, Duncan wrote:
> Now, part of what I don't quite understand is how that
> all fits together and whether the "microcore" is a dependency or
> actually compiled as part of the LILO compile and install process, or
> whether it's similar to the binary blob at the core of the NVidia
> video drivers (which I won't run as that blob isn't free software) and
> the LILO compile process simply builds a wrapper around that core.
I'm not sure about the "microcore" thing: you could be right, since I
noticed that many files which used to be in /boot now are gone, and they
have possibly been linked into the lilo executable. In
particular, /etc/lilo.conf.example mentions that now boot.b is linked
directly into the /sbin/lilo binary. So, the LILO executable (the
program the user runs after installing a new kernel image) might very
well be a sort of hybrid.
Regarding the binary blob, however, I think your fears are not justified:
there are no binary files inside the LILO source tarball, so everything
must be built from sources one way or another. (Compare this with, for
example, the nvidia-drivers, which instead contains lots of binary
executable and object files - it's actually a .run file, a sort of mix
between a shell script and a .tgz archive, which in turn contains the
binary blobs, most notably the infamous nv-kernel.o).
After a brief look at the LILO Makefile, my understanding is that the
parts which make up what you call the "microcore" (eg, the mbr, the
various stages of the loader and other bootloader pieces) are built from
assembly (.S) source files, using gcc -E, as86 and ld86 (the last two
are from the bin86 package, which LILO depends upon).
So, while it might be difficult to understand all the internal trickery
employed by the LILO executable behind the scenes when it runs, it
certainly can't be likened to nvidia-like binary blobs, since here
everything is built from sources, and certainly qualifies (IMHO at
least) as "free software" (portage lists the LILO license as BSD GPL-2).
FWIW, here's my understanding of what /sbin/lilo does:
- if not already done, install suitable mbr and first and second stage
loaders (probably reading them from somewhere inside the "microcore" and
writing the raw disk sectors in place); note that this is similar to
what grub-install (or the equivalent command in the GRUB interactive
- create or update the so-called "map file", which lists where the
various parts of the kernel are located on the disk, so that at boot
time the loader can find them, load them into memory and finally run the
kernel. The map is needed because, as you probably know already, the
LILO loader is not able to read a file system, so it needs to have a
lower level physical map of the disk sectors where the kernel file
resides. The GRUB loader, OTOH, is able to understand and read from the
most popular filesystems, so it does not need any map and its loader can
literally read the kernel file from /boot (or wherever it is) and thus
autonomously do all the work at boot time.
I hope the above is (mostly) correct and that helps a bit.
> I decided it was better to spend
> my time learning it than trying to trace down and figure out all the
> ins and outs of the LILO thing to my satisfaction, so that's exactly
> what I did, and indeed, I AM rather happier with GRUB, now that I
> actually took the time to learn how to work with it.
I was once a LILO-only user (mostly because GRUB was not popular when I
first started using linux, so I simply stayed with LILO), but I must
admit that I'm slowly migrating to GRUB. The great feature is (among
other things) the ability to fully edit the command line before booting,
which gives you more control than LILO over the boot process.
> FWIW, now I'm looking at LinuxBIOS, which I've already verified IS
> known to work on my mobo.
> As I understand it now, I can use GRUB as the payload (making the grub
> first stage what amounts to a second stage after the LinuxBIOS), or
> one of the two options that normally come with LinuxBIOS, or even load
> a shrunken Linux kernel with just enough functionality to read the
> main kernel off the disk and kexec into it.
> Still, it might be a year or two, but I'll probably do it eventually,
> thus ridding my system of yet one more proprietary software (firmware)
This sounds really interesting and promising. I wonder how they can do "3
seconds from power-on to Linux console". Even if the LinuxBIOS loads
straightly a kernel as the payload, the kernel still takes more than 3
seconds to initialize...this alone would be a good enough reason to do
the switch! I hope you eventually succeed in the task.
email@example.com mailing list