В Mon, 3 Nov 2014 14:05:24 -0700 Chris Murphy <li...@colorremedies.com> пишет:
> > On Nov 3, 2014, at 1:29 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote: > > > В Mon, 3 Nov 2014 12:36:24 -0700 > > Chris Murphy <li...@colorremedies.com> пишет: > > > >> > >> On Nov 2, 2014, at 10:36 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote: > >> > >>> В Sun, 2 Nov 2014 15:19:43 -0700 > >>> Chris Murphy <li...@colorremedies.com> пишет: > >>> > >>>> > >>>> On Nov 1, 2014, at 11:37 PM, Andrei Borzenkov <arvidj...@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 > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
