Disk layout for XO-1.5
david at lang.hm
david at lang.hm
Tue Jul 28 17:52:26 EDT 2009
On Tue, 28 Jul 2009, Mitch Bradley wrote:
> lilo is nearly worst of breed in terms of putting magic stuff in the Master
> Boot Record.
every boot loader puts stuff in the master boot record (it's own code if
lilo puts everything there needed to find the disk blocks it needs.
others have to have code in them to understand the filesystem layout to
find the blocks that they need.
if you are worried about the complications involved from having to support
many different filesystems, the lilo approach would seem easier.
if you have a well understood filesystem to start with, and are
moving/changing your boot kernel frequently, the grub approach avoids the
need to remember to run the lilo command.
since the kernels are going to be installed by a script, they can be smart
enough to not overwrite an existing file (avoiding that problem), and
running lilo to re-write the MBR (avoiding that problem). if the system
looses power in the middle of the MBR write you can have grief, but there
are so many cases where that sort of thing can cause problems that I don't
see that as being a dealbreaker.
I know that grub is the sexy standard for desktop/laptop use for
general-purpose distros, but I don't think that it's flexibility is needed
in this case.
or are you saying that openfirmware _is_ the bootloader on the XO?
if that's the case, consider having a lilo-like mode to avoid having to
teach it how to understand every filesystem in existance.
> david at lang.hm wrote:
>> On Tue, 28 Jul 2009, Mitch Bradley wrote:
>>> david at lang.hm wrote:
>>>> On Tue, 28 Jul 2009, Mitch Bradley wrote:
>>>>> Another important advantage to partitions is that the existence of a
>>>>> boot partition isolates the firmware from changes in the filesystem used
>>>>> for the root.
>>>> can you explain this a bit more?
>>> A conventional BIOS boots by reading a small chunk of 16-bit real-mode
>>> code from the Master Boot Record, which then does something magic, often
>>> involving chaining to some other chunk of code that is shoehorned into
>>> some location that is difficult to inspect (e.g. some reserved sectors
>>> near the beginning of a partition).
>> I'll point out that lilo allows it to boot from stuff anywhere in the
>> filesystem, and does not have to understand the specific filesystem at boot
>> there are cases where it doesn't work well, but in the limited case of the
>> XO laptops I think it would work well (and avoid the complexity you
>> describe below)
>> Davi dLang
>>> OFW instead reads the kernel and initrd files directly from the filesystem
>>> - there are no hidden chunks of 16-bit code tucked into nooks and
>>> Linux filesystems tend to evolve rapidly. ext2/3 sprouted numerous
>>> extensions over the years, some of them backwards compatible and some not.
>>> Now we have ext4, which an ext2 reader can't necessarily handle. At some
>>> point we might want to switch to btrfs, which would require yet another
>>> reader. OFW will probably eventually acquire a btrfs reader just for
>>> diagnostic purposes, but from a stability and ease of migration
>>> standpoint, it's better to pin down the format of the boot partition, thus
>>> decoupling the evolution of the OS from the firmware.
>>> UEFI has taken the same approach - a boot partition with a FAT filesystem.
>>> The boot partition is useful not only for the kernel, but also for
>>> firmware extensions like extra diagnostics, alternate startup graphics,
>>> alternate fonts, localizations, ...
More information about the Devel