[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
>
- Re: workaround install boot on btrfs with windows partition scheme, (continued)
Re: workaround install boot on btrfs with windows partition scheme, Chris Murphy, 2014/11/01
- Re: workaround install boot on btrfs with windows partition scheme, Andrei Borzenkov, 2014/11/02
- Re: workaround install boot on btrfs with windows partition scheme, Chris Murphy, 2014/11/02
- Re: workaround install boot on btrfs with windows partition scheme, Andrei Borzenkov, 2014/11/03
- Re: workaround install boot on btrfs with windows partition scheme, Chris Murphy, 2014/11/03
- Re: workaround install boot on btrfs with windows partition scheme, Andrei Borzenkov, 2014/11/03
- Re: workaround install boot on btrfs with windows partition scheme, Chris Murphy, 2014/11/03
- Re: workaround install boot on btrfs with windows partition scheme,
Andrei Borzenkov <=
- Re: workaround install boot on btrfs with windows partition scheme, Chris Murphy, 2014/11/04
Re: workaround install boot on btrfs with windows partition scheme, Michael Chang, 2014/11/02