Re: workaround install boot on btrfs with windows partition scheme

[Chris Murphy]

On Nov 3, 2014, at 1:29 PM, Andrei Borzenkov <address@hidden> wrote:

> В Mon, 3 Nov 2014 12:36:24 -0700
> Chris Murphy <address@hidden> пишет:
> 
>> 
>> 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.
> 
> 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.

Which is fragile, BTW, because if Linux /boot becomes corrupt, now I don't even 
get a GRUB menu and can't boot any other OS on the same system, e.g. Windows or 
a 2nd Linux instance. GRUB as installed to a device should be completely self 
contained, it means fewer single points of failure.


> How can
> multiple core.img refer to the same 0xEA partition to be sure they read
> (and write!) the same grubenv?

There's no assurance they do this now. Multiple core.img can have multiple 
roots on multiple devices, so each may point to different grubenv anyway. We 
can't be sure they all point to the same grubenv in any case.

HOWEVER, I understand the confusion, it's my fault. 0xEA proposed by 
Bootloaderspec is FAT32 to be used for Linux /boot and shared. That has all 
sorts of problems that aren't relevant in this thread, but it's not the 
equivalent of BIOSboot on GPT, which is an unformatted partition.

I'm suggesting an MBR partition type, equivalent to the BIOSboot partition, for 
embedding core.img instead of the MBR gap, so that there is always a reliable 
location for GRUB. If devs want it FAT32 like on UEFI, fine. If you want it 
unformatted like BIOSboot, fine. I have nothing to say about that. I just want 
to see the primary use case for installing GRUB on MBR partition drives to 
actually be the primary use case, rather than seemingly always having to 
fallback on special cases.

For example on Fedora, since the installer change, they no longer use 
grub-install --force to install GRUB to ext4 /boot and this has really made a 
lot of users angry and most of them refuse to learn how to install it manually 
instead they claim to have moved to different distributions that still use 
--force by default. 

For example, opensuse's GUI installer still uses --force by default, which by 
definition is a special case. Their *default* most common case, is now using a 
workflow explicitly not recommended by GRUB upstream. And the reason why is 
because the simple case, installing to MBR gap, is unreliable. It has been for 
a very long time.



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

Move core.img+grubenv+grub.cfg to the same partition. Do this for UEFI's ESP, 
and BIOSBoot, and a suitable explicit partition as replacement for MBR gap.

This is also easier to replicate across multiple disks, for raid1/5/6 booting.


Chris Murphy