[gentoo-amd64] Re: Emerging package as both 64 and 32 bit

[Duncan <1i5t5.duncan@cox.net>]

Etaoin Shrdlu <shrdlu@unlimitedmail.org> posted
200612202249.56315.shrdlu@unlimitedmail.org, excerpted below, on  Wed, 20
Dec 2006 22:49:56 +0100:

Duncan wrote...

>> I decided it was better to spend my time learning [GRUB] 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.

Exactly.  That's the big bonus of GRUB and the reason more distributions
are defaulting to it.

Contrastingly, one of the weaknesses of GRUB for quite awhile was that it
didn't have a failsafe method to do an unattented/remote boot.  That is,
with LILO, one could remotely install a new kernel on their colocated
server and set it as a  once-only boot-to that would default to a known
good kernel on subsequent boots, if the first boot failed.  Combine that
with a hardware watchdog card to reboot if it didn't get its timer reset
periodically, and a new kernel that failed to boot didn't require onsite
intervention.  GRUB had nothing at the time like that, and would require
onsite intervention, so LILO remained the preferred choice for remotely
administered systems.  I'm not into that end of things so I'm poorly
informed on GRUB's current capacities in the area, but I understand that's
no longer the case, that it can do single-shot then return to a standard
default boot, just as can LILO, now.  Thus, there's now little reason
other than older sysadmin familiarity with it (and the odd corner case
hardware issue with one or the other) to keep LILO over GRUB.

>> FWIW, now I'm looking at LinuxBIOS
> 
> 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.

Well, one BIOS-specific but entirely practical reason I'm looking into
LinuxBIOS ATM is that the current proprietary BIOS on my main system has
some frustrating issues... Namely, despite ranking the boot order to put
the hard drive first, and turning off scan of the floppy (and DVD, tho
fortunately it's a bit faster), the BIOS still INSISTS on activating and
scanning both for media before activating the hard drive boot.  The only
way to avoid the issue appears to be to deactivate the offending hardware
entirely in the BIOS, thereby not allowing it to be used post-boot,
either.  Older BIOS versions didn't have this issue but had other issues,
including lacking the ability to limit memory timings.  As long time list
regulars will recall, I had a terrible time with (generic, yes, I
know) memory that simply wasn't stable at its rated speeds, and only
worked well once I upgraded the BIOS and got the ability to limit memory
clock speeds.

Thus, a large fraction of my reboot time is frustratingly going to this
totally unnecessary floppy and DVD-drive scan, and the rest of the
hardware, kernel, and general system init process, don't seem so long in
comparison, particularly when they are doing obviously useful things as I
can see from dmesg and the like. If there was only a way to disable the
stupid removable media scans properly...

Of course, I'm not a BIOS programmer by a LONG shot, so just having the
BIOS sources to tinker with wouldn't help me much, but having an open
choice is certainly appealing.  While at this stage there may be such
frustrating issues with LinuxBIOS as well, if it were to get to even a
decent fraction of the current Linux acceptance level, there'd be enough
momentum behind it to have a good chance of dealing with this sort of
issue on the majority of supported hardware.

As for the 3-second claim, what they are doing is taking a drastically
slimmed down kernel, customized for the particular hardware such that it's
not necessary to do much of the standard kernel init and hardware scan
process.  Combine that with the fact that they avoid the current situation
where the BIOS scans and inits much of the hardware, only to have the
kernel redo much of the same stuff, and the effect cutting out that
duplicated scanning has on the boot time, and a 3-second kernel init time
isn't so far fetched.

If I understand the way they do it, one of the tricks they use is to take
hardware configuration information from the running system and from the
config files at build time, and actually build not only a slimmed down
kernel that doesn't scan for hardware that's known not to be there, but
they actually pre-init part of the kernel at build-time, so it doesn't
have to do that scanning at all, it's simply loaded straight from
FLASH-ROM already partially initialized and ready to go.

Something else they mention on the site... they had originally predicted
BIOS ROM sizes to increase faster than they have, and expected 8-32 Mbit
(so 1-4 MByte) BIOS image sizes by now.  With that, they could have fit an
entire compressed main kernel image complete with initramfs in the BIOS
image.  Instead, 4-8 Mbit (half to 1 MB) BIOS capacities are now the norm,
and a boot directly to full-size kernel remains impractical.  Thus, they
use multi-stage approach, with a second in-BIOS stage consisting of either
a larger bootloader that reads off of disk or network, or an extremely
stripped down kernel (other second stages such as the OpenFirmware BIOS
that Macs use are also available), then making use of the still fairly
new Linux kernel kexec feature to allow the stripped down kernel to load
the full kernel off of disk and kexec into it.

My big question at this time, one I didn't find an answer to in my
initial round of preliminary research, is what happens to all the existing
proprietary BIOS functions such as memory configuration, and BIOS level
enabling/disabling of various on-board hardware.  I /did/ see that there's
a provision for cutting out the various firmware mini-drivers (such as the
common VideoBIOS, NetBIOS, and RAID firmwares, subpackaged into
proprietary BIOSs) and including the binary blob images in LinuxBIOS as
well (yes, the binary blobs are galling, but it's a further step in the
right direction from a full proprietary BIOS), so that's addressed, but
the functionality such as memory config normally provided by the BIOS
itself (AFAIK)?  I'm not sure I'm ready to forego the ability to
BIOS-disable the various on-board hardware, and BIOS-configure stuff such
as memory parameters.  From my limited look around, I /think/ a fair
amount of that is configurable via text based config files at
BIOS-build-time, which is reasonable, but ONLY if one has the hardware to
supply a known-working backup BIOS option should one screw up their config
while experimenting.  (Some mobos include such a backup BIOS as a feature,
making bricking a machine due to botched flash upgrade a threat for
others to worry about. My present one does not.)

The LinuxBIOS site /does/ point to sources for all the necessary BIOS
switcher hardware and extra BIOS chips, but the one link I clicked on was
either stale or required Flash (as in the browser plugin not the memory
type) or the like to load, and I didn't investigate that aspect further,
so I've yet no idea what the cost would be.  Still, the site implies it's
rather more reasonable than I had thought based on the limited outdated
information I'd run across earlier, but really, that's to be expected
given the rise in popularity and scale and dropping of cost of flash
memory technology over the last half-decade or so.  The implied cost on
the site is less than $100 (US) now, which is significantly less than the
$500 or more I had thought, based on old information, which at least makes
it reasonably economically accessible to those with a non-professional
interest in it, unlike the $500 price-point, and it sounded like a $20-50
investment may do it.

Like I said tho, I've got significantly more research to do before I'm
actually downloading and running BIOS-builders.  It's definitely a
mid-term interest, not something I'll be doing before new year's day.

-- 
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