On Feb 19, 2013, at 1:43 AM, Michael Chang <mch...@suse.com> wrote: > 2013/2/19 Chris Murphy <li...@colorremedies.com>: >> >> 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 needed. > 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
