[Top][All Lists]

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

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

From: Chris Murphy
Subject: Re: GRUB and the risk of block list corruption in extX
Date: Tue, 19 Feb 2013 11:54:59 -0700

On Feb 19, 2013, at 1:43 AM, Michael Chang <address@hidden> wrote:

> 2013/2/19 Chris Murphy <address@hidden>:
>> 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.

The context was GRUB, so yes I'm assuming GRUB configuration files in this 
case. But GRUB2 can still do what most other boot loaders can't which is read 
pretty much any common file system out there, and even find boot files on md 
raid and lvm. It can chain load the distribution's unique boot loader by 
reading the file system its on. Blocklists, VBR boot sectors, are still not 

>  If they offer options of other
> bootloader than grub2 why bother them to maintain grub.cfg ?

I'm not suggesting that distributions be required to play nice in the multiboot 
sandbox. But if they want to be cooperative, they might actually have to 
cooperate somehow. Doesn't seem totally surprising to me.

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

It meets my vague and loose requirements, but the failure is an edge case. And 
it's fine there are tools that help people with their edge cases. But this work 
around to regain bootability requires esoteric knowledge on the part of the 
user (in addition to being an edge case for it to occur). The probability of 
both happening at the same time, is low. I don't think this is a case of good 
design. There's also still a single point of failure, LBA0. It's not as if the 
risk of rewriting those 512 bytes is zero, just to change the active flag. I 
don't see how the probability of boot loader failure is meaningfully reduced.

Chris Murphy

reply via email to

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