1 |
Etaoin Shrdlu <shrdlu@×××××××××××××.org> posted |
2 |
200612181510.08865.shrdlu@×××××××××××××.org, excerpted below, on Mon, 18 |
3 |
Dec 2006 15:10:08 +0100: |
4 |
|
5 |
> On Monday 18 December 2006 13:39, Duncan wrote: |
6 |
> |
7 |
>> My point, however, was that since everything else I run is 64-bit, if |
8 |
>> I didn't need the 32-bit tools to compile grub -- or if I was willing |
9 |
>> to settle for the pre-compiled grub-static -- I could save myself a |
10 |
>> *LOT* of extra work by simply using the no-multilib subprofile, thus |
11 |
>> saving myself all that time compiling the 32-bit side of glibc and gcc |
12 |
>> in particular. |
13 |
> |
14 |
> I believe that lilo can be built in a 64-bit only environment |
15 |
> (no-multilib). |
16 |
> I use the no-multilib subprofile, and a few days ago, I found out that |
17 |
> lilo was not masked (ie, "emerge -a lilo" did prompt me to install the |
18 |
> package), so I suppose that it should work even in my 64-bit, |
19 |
> no-multilib system. (However, I did not actually merge it, since |
20 |
> grub-static still works fine here, so I can't be 100% sure). |
21 |
> Looking at the changelog, it seems that my suppositions are correct: |
22 |
> |
23 |
> 06 Jan 2006; Olivier Crête <tester@g.o> lilo-22.7.ebuild: |
24 |
> Stable on amd64 |
25 |
> |
26 |
> So, it's been stable for almost a year now. |
27 |
> |
28 |
> Of course, this is not meant to be the start of another grub vs. lilo |
29 |
> flamewar, but rather just a FYI. |
30 |
|
31 |
No flamewar here as I had already learned LILO (but not GRUB) when I |
32 |
switched to Gentoo, and simply copied over and continued to use the |
33 |
Mandrake executable (which was at the time from the exact same RPM they |
34 |
used on i586) for awhile, then was running the precompiled binary from the |
35 |
LILO homepage for awhile, then the Gentoo/amd64 version when it finally |
36 |
worked, before I finally decided to get with the program and learn GRUB, |
37 |
since everybody said it was more flexible -- which it turned out to be. =8^) |
38 |
|
39 |
However, there's a bit more to the 64-bit LILO case than it first appears, |
40 |
and than you mention above. I'll admit it's a bit beyond my understanding |
41 |
as well, and you'd probably have to get it from the Gentoo devs |
42 |
responsible for working out the 64-bit stuff on it, but from what I could |
43 |
make out... |
44 |
|
45 |
LILO is actually two different pieces, the part that runs when you invoke |
46 |
it to install a new boot sector config, and the part that actually builds, |
47 |
that actually runs at boot time. |
48 |
|
49 |
As I understand it, formerly, the part invoked to do the build and install |
50 |
of the boot sector bit was a regular 32-bit executable. Now, it's a |
51 |
64-bit executable, that includes a 32-bit "microcore" (for lack of a |
52 |
better word). |
53 |
|
54 |
That was based on the remarks I read back when the 64-bit version was |
55 |
introduced. Now, part of what I don't quite understand is how that all |
56 |
fits together and whether the "microcore" is a dependency or actually |
57 |
compiled as part of the LILO compile and install process, or whether it's |
58 |
similar to the binary blob at the core of the NVidia video drivers (which |
59 |
I won't run as that blob isn't free software) and the LILO compile process |
60 |
simply builds a wrapper around that core. Actually, that was another |
61 |
reason I eventually switched to GRUB -- I wasn't particularly comfortable |
62 |
with my lack of understanding of the issues surrounding this microcore and |
63 |
whether it was a binary blob (which I don't like to and generally won't |
64 |
run, just as I won't run the NVidia binary blob) or whether it required |
65 |
the 32-bit parts of GCC, or whether it was "cross-compiled" as it were by |
66 |
the LILO build-process, or what. Since GRUB was rumored to be more |
67 |
flexible anyway, and was more the Gentoo way, I decided it was better to |
68 |
spend my time learning it than trying to trace down and figure out all the |
69 |
ins and outs of the LILO thing to my satisfaction, so that's exactly what |
70 |
I did, and indeed, I AM rather happier with GRUB, now that I actually took |
71 |
the time to learn how to work with it. |
72 |
|
73 |
FWIW, now I'm looking at LinuxBIOS, which I've already verified IS known |
74 |
to work on my mobo. I'd be rather more comfortable running it, as |
75 |
entirely freedomware code, than the ordinary vendor supplied proprietary |
76 |
BIOS I'm running now. However, that's a big step, and I've got a lot more |
77 |
research to do and possibly some hardware and tools to buy so I can keep |
78 |
my existing BIOS as-is while I experiment, before I'll be comfortable or |
79 |
ready to take that step. As I understand it now, I can use GRUB as the |
80 |
payload (making the grub first stage what amounts to a second stage after |
81 |
the LinuxBIOS), or one of the two options that normally come with |
82 |
LinuxBIOS, or even load a shrunken Linux kernel with just enough |
83 |
functionality to read the main kernel off the disk and kexec into it. |
84 |
What happens to all the stuff like memory timing options I can configure |
85 |
in the current proprietary BIOS? What defaults does it choose and is |
86 |
there a way to configure them if I don't like those defaults? It's those |
87 |
types of questions among others I still have to research -- or get the |
88 |
hardware to allow me to safely experiment and find out on my own, before |
89 |
I'm comfortable actually switching to LinuxBIOS. Still, it might be a |
90 |
year or two, but I'll probably do it eventually, thus ridding my system of |
91 |
yet one more proprietary software (firmware) bit. |
92 |
|
93 |
-- |
94 |
Duncan - List replies preferred. No HTML msgs. |
95 |
"Every nonfree program has a lord, a master -- |
96 |
and if you use the program, he is your master." Richard Stallman |
97 |
|
98 |
-- |
99 |
gentoo-amd64@g.o mailing list |