grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrey Borzenkov
Subject: Re: GRUB and the risk of block list corruption in extX
Date: Tue, 19 Feb 2013 09:02:10 +0400

On Tue, Feb 19, 2013 at 1:07 AM, Chris Murphy <address@hidden> wrote:
>
> Chainloading was never a good idea, it was the only idea for supporting 
> multiboot on hardware with a brain dead BIOS that was never designed with 
> multiboot in mind.
>

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 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. You do not go
and run os-prober in chroot on every other Linux you may have when you
install additional kernel.

I have test VM with Windows/Fedora/openSUSE. I installed openSUSE
after Fedora. Wanna guess if openSUSE kerenls are present in Fedora
grub.cfg?

> Name something you can only do via chainloading that you cannot do by keeping 
> a singular
> primary boot loader up-to-date.

This requires close cooperation between *all* installed OSes that is
simply not going to happen.

Oh, and how to you add options for Windows loader to you primary grub2
bootloader?

> 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".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]