[Top][All Lists]

[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 23:46:58 -0700

On Nov 3, 2014, at 10:50 PM, Andrei Borzenkov <address@hidden> wrote:

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

Sure but no distro actually does this, and we're all making an even worse 
mistake with /boot/efi being persistently mounted for no good reason also.

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

# It is automatically generated by grub2-mkconfig using templates

It's explicitly not user domain. Arguably 3rd party tools shouldn't be editing 
it either.

Instead there should be a simple drop in script format to inform GRUB how to 
boot other OS's, or trees, on the system. Then grub.cfg doesn't need to be 
edited by either user or distribution, let alone shared among multiple 
distributions (which is really quite an ugly mess). But still permits 
distributions to modify GRUB menu entries by creating/managing distro specific 
boot scripts. Very simple ones. This is probably the most useful aspect of 

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

Well in a perfect world they'd all be identical, made so at grub-install and 
mkconfig time, so it wouldn't matter. This envisions agreement to follow a 
spec, including shared space for bootloader configuration drop in scripts. No 
one is touching the grub.cfg, or anyone else's scripts. Each distro manages 
their own scripts.

In reality, each device could have a core.img and grubenv produced by a distro 
specific GRUB, in which case it's up to the BIOS and whether the grub.cfg it 
effectively causes to load was created to include awareness of other OS's on 
the system. It's no different than now except the grubenv is co-located with 
core.img so that it's ensured to be in a reliable read/write location. Plus 
grubenv isn't user domain either, we're supposed to use grub-editenv not 
directly edit the file.

Chris Murphy

reply via email to

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