From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64] Re: Emerging package as both 64 and 32 bit
Date: Tue, 19 Dec 2006 15:01:20 +0000 (UTC) [thread overview]
Message-ID: <em8us0$ipj$1@sea.gmane.org> (raw)
In-Reply-To: 200612181510.08865.shrdlu@unlimitedmail.org
Etaoin Shrdlu <shrdlu@unlimitedmail.org> posted
200612181510.08865.shrdlu@unlimitedmail.org, 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 <tester@gentoo.org> 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
--
gentoo-amd64@gentoo.org mailing list
next prev parent reply other threads:[~2006-12-19 15:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-16 15:45 [gentoo-amd64] Emerging package as both 64 and 32 bit Boky Boky
2006-12-16 17:09 ` Indarios
2006-12-16 18:15 ` Mike Doty
2006-12-16 18:17 ` [gentoo-amd64] " Duncan
2006-12-16 19:24 ` Boky
2006-12-16 20:08 ` Kevin F. Quinn
2006-12-16 20:41 ` Duncan
2006-12-18 9:31 ` Neil Bothwick
2006-12-18 10:22 ` Simon Stelling
2006-12-18 10:34 ` Neil Bothwick
2006-12-18 12:39 ` Duncan
2006-12-18 14:10 ` Etaoin Shrdlu
2006-12-19 15:01 ` Duncan [this message]
2006-12-20 21:49 ` Etaoin Shrdlu
2006-12-21 9:31 ` Duncan
2006-12-22 7:02 ` Mike Doty
2006-12-22 14:54 ` Boyd Stephen Smith Jr.
2006-12-22 21:20 ` Duncan
2006-12-23 3:44 ` Boyd Stephen Smith Jr.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='em8us0$ipj$1@sea.gmane.org' \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-amd64@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox