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