Re: workaround install boot on btrfs with windows partition scheme

[Andrei Borzenkov <arvidjaar@gmail.com>]

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

> 
> On Nov 3, 2014, at 1:29 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 
> > В 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.
> 
> 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.

It is self contained if you treat /boot/grub as bootloader partition.
You are free to create separate filesystem for it and keep it unmounted
by default.

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

How do you edit grub.cfg which is now in raw partition?

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

Which of replica across multiple disks holds *the* authoritative copy
of grubenv and grub.cfg?

> 
> Chris Murphy
>