Re: workaround install boot on btrfs with windows partition scheme

[Chris Murphy]

On Nov 2, 2014, at 10:36 PM, Andrei Borzenkov <address@hidden> wrote:

> В Sun, 2 Nov 2014 15:19:43 -0700
> Chris Murphy <address@hidden> пишет:
> 
>> 
>> On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov <address@hidden> 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