Re: workaround install boot on btrfs with windows partition scheme

[Andrei Borzenkov <arvidjaar@gmail.com>]

В Mon, 3 Nov 2014 12:36:24 -0700
Chris Murphy <lists@colorremedies.com> пишет:

> 
> On Nov 2, 2014, at 10:36 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 
> > В Sun, 2 Nov 2014 15:19:43 -0700
> > Chris Murphy <lists@colorremedies.com> пишет:
> > 
> >> 
> >> On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov <arvidjaar@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.

Exactly. We have multiple core.img but single location for grub state
and configuration information. It does not matter which core.img is
loaded as long as they all refer to the same /boot/grub. How can
multiple core.img refer to the same 0xEA partition to be sure they read
(and write!) the same grubenv?

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

Please explain how grub should know when to access /boot/grub/grubenv
and when to access 0xEA partition.

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