Re: Why can't ext4 file systems be used as a boot partition?

On Saturday 19 September 2009 08:25, someone identifying as *Hans-Peter
Diettrich* wrote in /comp.os.linux.setup:/

Aragorn schrieb:

Since GRUB can boot e.g. Windows systems as well - isn't there a
GRUB option, that a logical drive shall be booted in the
"traditional" (LILO) way?

I'm not sure I understand your question... :-/ Both GRUB and LILO
boot Windows in the same manner, i.e. by loading the Windows
partition's bootsector into memory and passing control of the machine
onto whatever code resides there, and this code in question would
then be the Windows bootloader.

I'm not sure how far this is a Windows specific convention - at least
the first boot stage must be invoked by the BIOS.

Well, yes, it is. The BIOS tables contain information on what hard disk
to boot from, and the BIOS will then read the master boot record of
that hard disk. This master boot record will by default - i.e. on a
new hard disk - always contain a secondary piece of code that will look
for the active primary partition and will then load the bootsector of
that active primary partition into its memory and pass control of the
machine onto whatever code resides in that bootsector of the active
primary partition. This is the /x86/ legacy real mode boot process.

However, when either LILO or GRUB are installed in the master boot
record - as opposed to installing them in a partition's bootsector -
the legacy boot code residing there on new disks (or on disks where the
original MBR has been restored) is overwritten by the first stage of
the LILO or GRUB bootloaders, and so when the BIOS approaches the hard
disk in order to load the legacy bootloader, it loads the first stage
of either LILO or GRUB instead. What happens next is where LILO and
GRUB are different.

In the event of LILO, the first stage contains a hardcoded logical block
offset - in the old days, this was a traditional cylinder/head/sector
offset - to the second stage, which is to be found in */boot/map* and
which contains both the rest of LILO and the again hardcoded logical
block offset to the Linux kernel. However, LILO is also capable of
executing a boot procedure similar to the one in the master boot record
of a new, unused hard disk, in that it can also load a partition's
bootsector into memory and pass control over the machine onto whatever
code resides there.

So in essence, one could say that if LILO is used to boot DOS, Windows,
OS/2 or any other non-Linux-based operating system, the LILO bootloader
only acts as an extra step between the BIOS code that looks for a
bootable hard disk and the legacy bootprocedure in which a partition'
bootsector is loaded into memory and given control of the machine.

GRUB on the other hand works differently. The first stage of the GRUB
bootloader is pretty much the same as with LILO, but then GRUB loads an
intermediary stage - dubbed "stage 1.5" - which contains a filesystem
driver for the filesystem containing the second stage of GRUB. This
second stage is more elaborate in functionality than is the case with
LILO and will load its configuration file via this (real mode)
filesystem access.

As such and as opposed to LILO, this means that any changes to the
configuration file are effective immediately, without running any
further configuration tools. With LILO, one must run the command
*/sbin/lilo* after updating the configuration file in order to
translate this configuration into binary code and update the hardcoded
offsets.

However, pertaining to the loading of other operating systems like DOS,
Windows or whatever, which cannot be bootstrapped directly by loading
their kernel into memory the way the Linux kernel is loaded, GRUB uses
the same methodology as LILO, i.e. it fakes an "original" blank
disk-style bootloader which loads a partition's bootsector into memory
and passes control of the machine to whatever code resides there, with
GRUB itself then only acting as an intermediary step between the
"natural" BIOS-based part of the legacy bootloader code and the legacy
on-disk bootloader.

The main advantage of either LILO or GRUB sitting in between the BIOS
bootloader code which approaches the hard disk marked as bootable in
the BIOS set-up and the legacy bootcode which loads a partition's
bootsector into memory is the fact that due to the mechanisms of
the /x86/ legacy, the bootloader code residing in the master boot
record of each new hard disk needs a way to determine which of the four
possible partition entries to load the bootsector of, and this is done
by marking the pertaining partition as "bootable" or "active", using a
partitioning tool, and that GRUB and LILO allow for faking this, so
that even a partition which is not marked as active or a partition
which isn't even primary can still be booted in the same way.

The above is of course all with regard to legacy /x86/ systems, of
course. /x86/ machines with LinuxBIOS/OpenBIOS or EFI are bootstrapped
differently, from within protected mode. They thus also require a
different version of LILO or GRUB. Non-x86 machines usually don't have
a real mode - which is basically nothing other than a DOS-compatible
8086 mode of operation, where there are no privilege rings (so
everything runs in "kernel mode") and where the maximum amount of
addressable memory is 1088 KB, BIOS-reserved addresses included - use a
similar approach.

As your question was pretty vague, I'm not sure whether my reply is
adequate, though.

Thanks, I think that I could figure out some facts :-)

It looks to me as if Linux prefers an single boot manager, not one for
every bootable logical drive.

Both approaches are possible. You can install LILO or GRUB inside a
partition's bootsector instead of in the master boot record and then
have another bootloader - which could be either a LILO or GRUB
installed in the master boot record or some other type of bootloader -
load the LILO or GRUB in the partition bootsector. This is called
"chainloading".

What's the problem with updating that boot manager, when a new
filesystem is used for an bootable drive?

LILO is filesystem-agnostic. The configuration in */etc/lilo.conf* - or
elsewhere if so specified - gets statically hardcoded into whatever
location you choose to write the bootloader to - be it a partition
bootsector or the master boot record. Therefore, any changes made to
the configuration must first be translated again and then explicitly
written to the master boot record (or partition bootsector) using
*/sbin/lilo.*

GRUB on the other hand uses a filesystem driver to load both the kernel
and its configuration information, which is typically stored in the
file */boot/grub/menu.lst* and often (but not always) symlinked to
*/etc/grub.conf* for UNIX compliance. The rationale behind the
symlinking is that the FHS - or File Hierarchy Standard, currently at
version 2.3 - states that configuration files should be put under
*/etc,* but since GRUB needs access to its configuration file when the
root partition isn't mounted - as would be the case when */boot* is on
a separate partition - the configuration file must be stored under
*/boot* for technical reasons.

Now, when you're installing a new filesystem for either */boot* or for
the root filesystem (or both), you will typically be re-installing the
system and therefore you will need to re-install at least part of the
bootloader as well. With LILO, this is taken care of by running the
executable */sbin/lilo.*

With GRUB on the other hand, considering that the second stage of GRUB
is dynamic, it all depends on what you're going to do. If you're going
to apply a new filesystem to the root partition while you have a
separate */boot* partition that won't be touched, then you needn't do
anything to the bootloader configuration. If you're going to apply a
new filesystem to */boot* then the GRUB configuration file and even the
1.5 and 2.0 stages of GRUB will be erased anyway, so you'll need to
recreate those using /grub-install/ or the interactive GRUB shell.

There is some very helpful documentation regarding the setting up of
either LILO or GRUB on a new system on the Gentoo website, with
step-by-step instructions on how to proceed, if you require the
handholding. Likewise, the documentation for the LFS (Linux From
Scratch) project is also excellent. ;-)

http://www.gentoo.org

http://www.linuxfromscratch.org

Hope this helps. ;-)

--
*Aragorn*
(registered GNU/Linux user #223157)
.

Relevant Pages

  • RE: Two OS - boot?
    ... It doesn't sound like you have choosen to use LILO or GRUB. ... linux disk if you want....the linux vmlinuz boot up will not be in the ... your BIOS to point to that disk to boot and leave it. ...
    (RedHat)
  • Re: Dual booting XP machine
    ... able to change the boot parameters in detail -- Grub can do this, LILO ... > doesn't it also store information on the MBR? ...
    (comp.os.linux.setup)
  • Re: Debian Rescue Floppy
    ... >> still using LILO? ... if you know all your grub and lilo options for its config file, ... boot info off the scsi disk which it can't until it has the scsi ... other kernel if the default failed, but how many peple use those ...
    (Debian-User)
  • Re: partitions question
    ... >> If that boot question is still applicable and this is that box, ... > when installing i had a question about where to install the loader and ... it seems you can use either grub or lilo. ...
    (comp.os.linux.setup)
  • Re: [GRUB]Resolution setup
    ... title Fedora Core ... the last entry was a try to go back to my LILO stored on hda1 MBR but it ... Some extra comments on GRUB / LILO comparison: when I started with Linux on ... bootloader stored" and I built a specific direct entry from LILO to FC3 ...
    (Fedora)