[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: workaround install boot on btrfs with windows partition scheme
From: |
Chris Murphy |
Subject: |
Re: workaround install boot on btrfs with windows partition scheme |
Date: |
Mon, 3 Nov 2014 14:05:24 -0700 |
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
- 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 <=
- Re: workaround install boot on btrfs with windows partition scheme, Andrei Borzenkov, 2014/11/04
- 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