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

On 2009-09-18, The Natural Philosopher <tnp.RemoveThis@invalid.invalid> wrote:
> unruh wrote:
>>> On Sep 18, 8:07=A0am, Aragorn <arag....RemoveThis@chatfactory.invalid> wrote:
>>>> It was once postulated by chaoticians that a million monkeys sitting at
>>>> a computer would eventually come up with the collected works of William
>>>> Shakespeare. =A0Now, with the internet, we know that this is not true. :p
>>
>> Nope. they gave us Wikipedia instead.
>>
> ITYM facebook.

That's an insult to monkeys everywhere!

--keith


--
kkeller-usenet.RemoveThis@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

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.

[...]
> 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. What's the problem with updating that boot
manager, when a new filesystem is used for an bootable drive?

DoDi

Hans-Peter Diettrich wrote:
> 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.
>

yerrss.. I thought about that, but the boot LOADER - grub, lilo or
whatever, simply resides in the boot SECTOR, which isn't really a file
*system* at all.

So teh sequence is

Bios loads boot sector and jumps to execute into it.
Boot code takes over and loads splash screens and ultimately the kernel
and enough OS to bootstrap the rest.

So its really down to whether or not the boot loader understands the
disk .. and sometimes it dont..and booting fails!



> [...]
>> 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. What's the problem with updating that boot
> manager, when a new filesystem is used for an bootable drive?
> #

Dont see any really.

> DoDi

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)

On Saturday 19 September 2009 08:40, someone identifying as *The Natural
Philosopher* wrote in /comp.os.linux.setup:/

> Hans-Peter Diettrich wrote:
>
>> 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.
>
> yerrss.. I thought about that, but the boot LOADER - grub, lilo or
> whatever, simply resides in the boot SECTOR, which isn't really a file
> *system* at all.

Not necessarily so, though. One can have LILO or GRUB reside in a
partition's bootsector as well and then have it brought up by a primary
bootloader, being either the legacy /x86/ bootloader code residing in
the master boot record of each new hard disk, or another LILO, GRUB or
third-party bootloader.

> So teh sequence is
>
> Bios loads boot sector and jumps to execute into it.
> Boot code takes over and loads splash screens and ultimately the
> kernel and enough OS to bootstrap the rest.

Hmm... That's not entirely accurate. The splash screens - I'm assuming
that you're talking of the framebuffer eyecandy during the boot process
and not of the GRUB or LILO menu - reside in the /initrd,/ which is
only loaded after the kernel has already been decompressed into memory,
and this decompression occurs after the initial kernel bootstrap code
has set up the necessary pagetables, copied the boot parameters to a
memory location that won't be overwritten after the kernel gets
decompressed - so that the actual protected mode kernel can access that
information later on - and switched the boot processor into protected
mode.

Also note that one does not need an /initrd/ in order to boot, although
typically a distribution-supplied binary kernel will need one due to
the fact that a distribution kernel must be able to run on as many
different hardware configurations as available.

I normally build my kernels so that an /initrd/ is not needed, with all
static hardware - e.g. RAID controller - and main drivers statically
linked into the kernel itself, instead of compiling them as modules. I
do however advise people who roll their own kernel for a workstation-
or laptop-type of machine to leave the loading and unloading of modules
and module autoloading enabled, because proprietary drivers only come
as modules for obvious reasons. For a server, and especially in the
case of a machine with multiple user accounts, it is probably safer to
disable module loading altogether so that an eventual intruder or a
misbehaving user can't use some root exploit to load a malware module
into the kernel. (Note: These are not necessarily my words, but
instead it is a loose quote taken from the Gentoo manual.)

> So its really down to whether or not the boot loader understands the
> disk .. and sometimes it dont..and booting fails!

This in itself is an ambiguous statement, because it all depends on the
bootloader, the BIOS and the type of hard disk. And in the event of
GRUB, a filesystem driver for the partition from which the 1.5 and 2.0
stages of GRUB and the kernel must be loaded.

>>> 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. What's the problem with updating
>> that boot manager, when a new filesystem is used for an bootable
>> drive?
>> #
>
> Dont see any really.

The question itself was asked wrongly, in my opinion, but I have tried
to address that in my other reply.

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

I demand that piscesboy may or may not have written...

> Newbie question.

The filesystem is irrelevant to lilo, so I see no problem here

--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| Let's keep the pound sterling

This was the most unkind cut of all.

piscesboy wrote:

>
>
> Newbie question.


What problems are you having? As usual, before the kernel can boot a partition,
it must know about the filesystem on it via a driver. On the system in question,
is ext4 compiled into the kernel or otherwise provided in your initrd? Are you
running a current version of of boot manager? I run version 0.97 of grub and
have to apply a patch to allow for booting off ext4 partitions. Grub2 has it
built in, but is not the current stable version. You decide.

Check the net or go to bugs.gentoo.org for more information. Search "ALL grub"
and look for mention of ext4.

Just so you know, I've got several linux boxes with ext4 root partitions and
they boot without problems...


--

*****************************************************************************

From the desk of:
Jerome D. McBride

10:07:30 up 1 day, 15:47, 4 users, load average: 0.07, 0.17, 0.16

*****************************************************************************