Re: workaround install boot on btrfs with windows partition scheme

[Chris Murphy]

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

> В Sun, 2 Nov 2014 15:11:29 -0700
> Chris Murphy <address@hidden> пишет:
> 
>> 
>> On Nov 1, 2014, at 11:27 PM, Andrei Borzenkov <address@hidden> wrote:
>> 
>>> В Sat, 1 Nov 2014 14:35:57 -0600
>>> Chris Murphy <address@hidden> пишет:
>>>> 
>>>> Why not have a dedicated partition with MBR type code for core.img, 
>>>> equivalent to BIOSBoot currently used on GPT? freedesktop.org has a 
>>>> proposal to use type code 0xEA for this purpose (in part). The boot.img 
>>>> code in the MBR can arbitrarily jump to any LBA, so 0xEA doesn't need to 
>>>> be a primary partition does it?
>>>> 
>>> 
>>> It is rarely needed in simple cases; in complicated cases (btrfs or
>>> LVM) we already have space dedicated for core.img. It seems more
>>> logical to use this space.
>> 
>> Well actually it isn't rare in simple cases. The most common case on Linux 
>> is booting from ext which grub won't embed to either without 
>> --force.xz_dec_lzma2
> 
> We are discussing installation in MBR here, not in partition. 

The point is that GRUB has difficulty even in the simple case because it either 
can't fit in the MBR gap, or something else could just as legitimately use the 
MBR gap. Right now the fallback depends on a complex matrix depending on the 
file system being used rather than the primary use case rarely depending on 
fallback because it's a sure thing and consistent regardless of file system 
used.



> 
>> So we have to have core.img embedded somewhere else. UEFI it's a fixed
> location. BIOS+GPT it's a fixed location. Only on MBR is it in an
> unreserved location or forcibly embedded - that's really  where the
> problem is. It seems a lot simpler to constrain the MBR options down
> to only a reserved partition just like elsewhere where it's now much
> simpler because it can only properly go in one location.
>> 
>> 
>>> Also you still need to tell grub-setup to use this special partition at
>>> which point why not extend it to support arbitrary location for
>>> core.img? It could be made check partition type and not refuse to
>>> install on raw partition for special 0xEA type then as a bonus.
>> 
>> I never tell grub-setup to use BIOSboot partition type. It always just finds 
>> it automatically.
>> 
> 
> I do not really trust anyone respect partition types on MBR to be
> honest. So I would rather avoid blindly overwriting anything without
> explicit user's consent.

These two things are orthogonal. Relying on the user to know even basic things 
about how computers boot, is unreasonable. They don't understand such things, 
they never will, and expecting them to is simply out of scope.

If you don't trust others to respect partition types, then how do you trust 
them to respect non-partitioned regions like the MBR gap? The concept works 
quite well on UEFI and BIOS+GPT, I don't see why it should be any different on 
MBR, except for the small problem that we don't have as many type codes 
available. But certainly even that problem is more reliable than nothing at all.


Chris Murphy