On Sunday 19 February 2017 01:09, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind PetePost by AragornOn Saturday 18 February 2017 04:15, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind PeteHard question; will it be sane, or even possible, to use LiLo on
a BIOS system?
LILO is no longer being maintained, but it /should/ still work on MBR
systems. I wouldn't advise it on GPT systems, though.
The biggest problem - that I know about - is that ext4 has been
enhanced since development of LiLo and Legacy Grub ceased.
That was already the case with ext3, and while grub-legacy was still
being developed. Even though I'm not using ext3/ext4 on this machine ─
I'm a fan of the XFS filesystem ─ I am running PCLinuxOS 2014.04 here,
which already features those enhancements, and it's still using grub-
legacy. PCLinuxOS 2016.x uses grub2.
On the other hand, LILO has still been maintained for quite a while
after by the Debian people, who took custody of the project. At present
time, it is no longer under active development, but the userspace tools
to write LILO to the MBR will have been updated to keep track of the
changes to ext3/ext4. For that matter, LILO is still the default boot
loader in Slackware. ;)
Post by blind PeteLegacy Grub follows the filesystem at boot time, so it is completely
stuffed by newer ext4 filesystems.
No, not quite. grub-legacy does have an ext4 driver, and ext4 only came
out after the changes to ext3 had already been implemented.
Post by blind PeteLiLo uses block addresses at boot time, so that is OK, but it has to
get those block addresses at configuration time.
Correct.
Post by blind PeteCan it rely on the OS to get those, or does it need to use its own
code? An older filesystem should be safe.
As I wrote higher up, the userspace tools of LILO have been adapted to
keep the changes to the ext3 filesystem into account.
Post by blind PetePost by AragornI don't like grub2 either ─ it's needlessly complex in comparison to
grub-legacy and LILO ─ but on a GPT system with BIOS firmware instead
of EFI, there's no alternative that I know of.
Most BIOS computers would not be able to interpret a GPT disk, until
after boot up.
Well, that is rather irrelevant, really. So long as the BIOS can find a
boot loader in the MBR, the machine will boot, and you can have a GPT-
partitioned disk with a protective MBR.
Post by blind PeteAre you using hybrid disks that have a Gnu Partition Table [...
Um, GPT stands for GUID Partition Table, and GUID stands for "Global
Unique IDentifier", not for GNU. :p
Post by blind Pete...] and a traditional Master Boot Record partition table?
Not at present time, no. This here is a refurbished computer with BIOS
firmware, and the hard disk I'm currently using came from a similar
machine that broke down. I've repurposed the existing partitions on it,
and it's still set up with an DOS-style partition table.
Post by blind PeteIt is supposed to be a nightmare to keep them consistent. Booting from
an MBR disk and then reading a second disk with a GPT is not a
problem.
I don't see why it would be a nightmare. Tools like gdisk, parted and
gparted can partition a drive with a GUID partition table and create a
protective MBR.
All you then still need to do in order to use that disk in a non-EFI
machine is create a small partition ─ about 2 MiB should suffice ─ of
the type "BIOS" as the first partition, and you don't need to create any
filesystem on it. This partition will then be used to house the
core.img stage of the GRUB boot loader.
Post by blind PeteAre you using an EFI machine in legacy mode? It be would be able, and
maybe willing, to boot from a GPT disk.
Nope, no EFI here. EFI in and of itself was a good idea, and a
necessity on non-x86 hardware. But UEFI is a whole different beast.
UEFI has been co-opted by Microsoft and has Microsoftisms all over it,
not to mention that dreaded (and pretty pointless) Secure Boot feature.
As I see it, there isn't anything that UEFI brings to the x86
architecture which couldn't also already be taken care of before by the
Linux kernel itself.
Linux doesn't use the BIOS at runtime, but the real mode bootstrap code
in the on-disk kernel image makes sure that information about the
hardware is read from the BIOS and then copied to a write-protected
location in protected mode memory before the actual runtime kernel ─
which is itself an image within the on-disk kernel image ─ is
decompressed and activated, and from that moment on, the kernel takes
care of initializing and handling all hardware access.
Everybody knows that the only reason why they've pushed UEFI into
adoption was because of the monopolistic strategy of Microsoft. UEFI
has Secure Boot, and Secure Boot forces operating system vendors to buy
a key from Microsoft, which effectively puts Microsoft in charge of what
was up until then a free and open hardware platform.
--
= Aragorn =