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 shell) does; - 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. >[cut] > 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. > [cut] > 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) > bit. 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 protected] mailing list
