grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: workaround install boot on btrfs with windows partition scheme


From: Andrei Borzenkov
Subject: Re: workaround install boot on btrfs with windows partition scheme
Date: Tue, 4 Nov 2014 08:50:10 +0300

В Mon, 3 Nov 2014 14:05:24 -0700
Chris Murphy <address@hidden> пишет:

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

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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]