On Nov 2, 2014, at 10:36 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> В Sun, 2 Nov 2014 15:19:43 -0700 > Chris Murphy <li...@colorremedies.com> пишет: > >> >> On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote: >>> >>> So far nobody suggested solution for grubenv on unwritable location. >>> Not to mention implementation … >> >> Put grubenv on 0xEA/BIOSboot as well. > > Please provide scheme how grub can reliably identify which of multiple > grub partitions on multiple disks is *the* partition where grubenv is > located. Why would the policy be any different than it is now? This isn't a new problem, we already have multiple MBR gaps and hence multiple core.img instances. There is no real change other than explicitly defining a suitably sized partition for GRUB's things to go in, rather than depending on an unreliable location, i.e. the MBR gap which often is either too small or could just as likely be used by something else since it's not reserved space for anyone. > > And it still should work when embedding bootloader in partition. Both > with and without blocklists. I'm not asking for any one else's workflow to become broken. I'm saying the primary workflow should be, primary, as in, consistent regardless of the file system used. > >> It's GRUB's partition it can put anything it wants there, exactly where > it expects to always find it. No coordination with filesystem groups > required. I don't see any of the fundamental behaviors about Btrfs > you're referring to changing anytime soon because it's simply how the > fs works, they aren't bugs. So either GRUB gets its own partition with > exclusive domain, or it continues to be hobbled by filesystem > dependencies like needing to be forced installed on ext, can't be > installed at all to XFS, and barely fits in 64KB on the Btrfs pad. >> >> It's not like there's a shortage of partitions. > > There is in real life. Not really. There's a shortage of primary partitions on MBR but *if* GRUB boot.img is permitted on the MBR, which is the default use case, then primary partitions aren't needed for core.img+grubenv+grub.cfg, those can go on an extended partition. And then even if Linux /boot is corrupt, I could still get a working GRUB menu that will permit me to boot e.g. Windows on the same disk. Right now this fails. Chris Murphy _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
