Disk layout for XO-1.5

[david at lang.hm]

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 
nothing else)

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 Lang

> 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 
>> time.
>> 
>> 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 
>>> crannies.
>>> 
>>> 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, ...
>>> 
>> 
>