Etaoin Shrdlu <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 18 Dec 2006 15:10:08 +0100:
> On Monday 18 December 2006 13:39, Duncan wrote: > >> My point, however, was that since everything else I run is 64-bit, if >> I didn't need the 32-bit tools to compile grub -- or if I was willing >> to settle for the pre-compiled grub-static -- I could save myself a >> *LOT* of extra work by simply using the no-multilib subprofile, thus >> saving myself all that time compiling the 32-bit side of glibc and gcc >> in particular. > > I believe that lilo can be built in a 64-bit only environment > (no-multilib). > I use the no-multilib subprofile, and a few days ago, I found out that > lilo was not masked (ie, "emerge -a lilo" did prompt me to install the > package), so I suppose that it should work even in my 64-bit, > no-multilib system. (However, I did not actually merge it, since > grub-static still works fine here, so I can't be 100% sure). > Looking at the changelog, it seems that my suppositions are correct: > > 06 Jan 2006; Olivier Crête <[EMAIL PROTECTED]> lilo-22.7.ebuild: > Stable on amd64 > > So, it's been stable for almost a year now. > > Of course, this is not meant to be the start of another grub vs. lilo > flamewar, but rather just a FYI. No flamewar here as I had already learned LILO (but not GRUB) when I switched to Gentoo, and simply copied over and continued to use the Mandrake executable (which was at the time from the exact same RPM they used on i586) for awhile, then was running the precompiled binary from the LILO homepage for awhile, then the Gentoo/amd64 version when it finally worked, before I finally decided to get with the program and learn GRUB, since everybody said it was more flexible -- which it turned out to be. =8^) However, there's a bit more to the 64-bit LILO case than it first appears, and than you mention above. I'll admit it's a bit beyond my understanding as well, and you'd probably have to get it from the Gentoo devs responsible for working out the 64-bit stuff on it, but from what I could make out... LILO is actually two different pieces, the part that runs when you invoke it to install a new boot sector config, and the part that actually builds, that actually runs at boot time. As I understand it, formerly, the part invoked to do the build and install of the boot sector bit was a regular 32-bit executable. Now, it's a 64-bit executable, that includes a 32-bit "microcore" (for lack of a better word). That was based on the remarks I read back when the 64-bit version was introduced. 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. Actually, that was another reason I eventually switched to GRUB -- I wasn't particularly comfortable with my lack of understanding of the issues surrounding this microcore and whether it was a binary blob (which I don't like to and generally won't run, just as I won't run the NVidia binary blob) or whether it required the 32-bit parts of GCC, or whether it was "cross-compiled" as it were by the LILO build-process, or what. Since GRUB was rumored to be more flexible anyway, and was more the Gentoo way, 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. FWIW, now I'm looking at LinuxBIOS, which I've already verified IS known to work on my mobo. I'd be rather more comfortable running it, as entirely freedomware code, than the ordinary vendor supplied proprietary BIOS I'm running now. However, that's a big step, and I've got a lot more research to do and possibly some hardware and tools to buy so I can keep my existing BIOS as-is while I experiment, before I'll be comfortable or ready to take that step. 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. What happens to all the stuff like memory timing options I can configure in the current proprietary BIOS? What defaults does it choose and is there a way to configure them if I don't like those defaults? It's those types of questions among others I still have to research -- or get the hardware to allow me to safely experiment and find out on my own, before I'm comfortable actually switching to LinuxBIOS. 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. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
