Re: GRUB and the risk of block list corruption in extX

[Michael Chang <mchang@suse.com>]

2013/2/19 Chris Murphy <lists@colorremedies.com>:
>
> On Feb 18, 2013, at 10:02 PM, Andrey Borzenkov <arvidjaar@gmail.com> wrote:
>
>>
>> Chainloading is actually the only sane way to do multiboot. While it
>> may have started due to BIOS limitations, today chainloading is simply
>> passing control to another bootloader.
>
> If a system has only linux, chain loading doesn't need to be used at all. In particular if GRUB2 is employed.
>
> The only case I know of that necessitates chain loading with GRUB2 is Windows on BIOS hardware because there isn't a GRUB boot loader to replace the Windows OSLoader processes.
>
>> If you want to have "master" bootloader that loads everything else,
>> you have to ensure that when "something else" changes, it is reflected
>> in master bootloader configuration. That's unrealistic.
>
> It's also untrue. GRUB can first load a grub.cfg pointing to the grub.cfg of each distribution; those distribution specific grub.cfg's are updated by those distributions. The first grub.cfg only needs updating when a distribution is added/subtracted - which is no different than what you'd have to do with the first boot loaders config if you were chain loading to a 2nd bootloader rather than to merely a configuration file.

This is based on assumption that all foreign distribution must
maintain a grub.cfg which is not true.  If they offer options of other
bootloader than grub2 why bother them to maintain grub.cfg ?

>
>> I have test VM with Windows/Fedora/openSUSE. I installed openSUSE
>
>> after Fedora. Wanna guess if openSUSE kerenls are present in Fedora
>> grub.cfg?
>
> The lack of cooperation on inter-distribution multiboot experience is orthogonal to chain loading.
>
>>
>>> Name something you can only do via chainloading that you cannot do by keeping a singular
>>> primary boot loader up-to-date.

Some people who use standard mbr boot code to manage their booting,.
The reason they would like to keep that old practice is they don't
want to bet their destiny on any primary bootloader of any
distribution as it fails for whatever reasons would render your entire
system un-bootable. They could still booting to other distribution via
togging the active flag and perform the rescue of data.

In this case they require grub2 be chainloaded as secondary bootloader
not the master one.

Regards,
Michael

>>
>> This requires close cooperation between *all* installed OSes that is
>> simply not going to happen.
>
> Chainloading doesn't solve this problem. You still have a primary bootloader that doesn't know anything about the 2nd, 3rd, 4th bootloaders. You still have to rewrite some configuration file to make it aware of the distribution specific boot loader.
>
>>
>> Oh, and how to you add options for Windows loader to you primary grub2
>> bootloader?
>
> Windows on BIOS does necessitate chain loading, that's its legacy.
>
>>
>>> Chainloading is a relic of BIOS limitations. It's a relic of boot sectors. That's not how things
>>> work with UEFI. The way forward is precisely the end to chainloading.
>>
>> Huh? EFI has master bootloader which *chainloads* other bootladers. If
>> anything, this is "chainloading made right".
>
>
> OK I think that's a broad use of chain loading. UEFI defines a boot manager, which is used to choose a boot loader application, which loads a kernel. In that envisioned sequence there's no actual replacement of a block of instructions with another. The boot manager runs within UEFI, the OS loader application runs along side the boot manager as part of boot services, and the kernel is loaded by the OS loader into a separate area of memory too - it's not wholesale replaced. So I wouldn't call it chain loading unless you're going to significantly broaden the definition of chain loading.
>
> In the case of Fedora and Secure Boot, shim.efi loads grubx64.efi, and that might be chainloading if grubx64.efi actually replaces shim.efi. I don't know if it does, it seems they'd have to be independently located in memory because shim.efi needs to confirm/deny the signed status of grubx64.efi before it's executed.
>
> In the case of GRUB Legacy chain loading GRUB2 or winload.exe, yeah sure it's real mode so code in a 512KB is literally being replaced with read in code. That's chain loading.
>
> And in any case, UEFI doesn't rely on boot sectors, let alone block lists. The one and only boot loader you choose via the boot manager is expected to be capable of reading the file system that contains the kernel and initramfs.
>
>
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>