Re: workaround install boot on btrfs with windows partition scheme

[Chris Murphy]

On Nov 3, 2014, at 9:50 PM, Michael Chang <address@hidden> wrote:

> On Mon, Nov 03, 2014 at 01:04:33PM -0700, Chris Murphy wrote:
>> 
>> Well, Btrfs raid1 might make sense for some of them but opensuse will 
>> constrain people from multiple device btrfs. So you can just disallow them 
>> from /boot on Btrfs by default, and make /boot on ext bigger than 500MB so 
>> it can accumulate more kernels.
> 
> On the other hand we do not want to maintain the nightmare of proposing
> different disk partitioning for different bootloader/filesystem
> combinations. The most significant advantage of grub is it able to
> provide unified setups for as many file systems it supports as well as
> the cpu-firmware architectures.
> 
> The principle is grub can support booting btrfs directly, then separate
> /boot will not be considered. We don't want to revive it because of this
> particular case.

Yeah I understand and agree with this. It really needs to work for Btrfs. 

> 
>> 
>> When it comes to booting multiple tree OS's, I prefer the design and 
>> capabilities of OStree, even though it's not particularly Btrfs aware or 
>> optimized yet. At least it's very aware of both the tree states, and totally 
>> manages the bootloader configuration when changing trees (e.g. rollback) via 
>> bootloaderspec drop in scripts.
> 
> It sounds to me that OSTree is a general way to manage your versioned
> system binaries exported from build server. Out of my curious why it has
> anything to do with btrfs? Anyway many thanks for pointing me to this
> cool project. :)

There are now several ways of having snapshottable and bootable filesystems. Do 
we want to maintain the nightmare of proposing different ways for booting each 
of them, or come up with a common scheme?  OSTree could be a model for a common 
scheme, even if it's not a specific solution in every case.

I'm convinced though, without agreement, the distros will inevitably arrive at 
totally incompatible schemes far worse than what we've seen up to this point. 
They're not quite openly hostile to each other, but they're certainly not 
friendly when it comes to preserving bootability for multiple Linux 
installations. For example even without considering snapshots, Fedora and 
openSUSE use completely different ondisk layouts and fs assembly at boot time, 
and this necessarily affects how each OS is discovered and booted were they to 
both be on one system at the same time sharing one bootloader as on BIOS/MBR.

Meanwhile OSTree is agnostic to the underlying storage technology used, while 
desiring future leveraging of those technologies as optimizations (rather than 
as dependencies). It also now works on BIOS and UEFI systems. It uses 
Bootloaderspec [1] drop in scripts rather than modifying grub.cfg. And big 
bonus (although it's the project's raison d'être) is all software updates are 
always atomic: the tree being modified is not the currently active tree so 
libraries aren't being yanked out from under any process. So as a rather young 
project it's getting a lot of things right. Its philosophy is what I think 
makes it relevant to Btrfs booting even if not the present state of the code.


>> 
>> OK fine, but this just adds to the already complicated matrix of GRUB MBR 
>> installations, to have yet another fallback for yet another special case. 
>> This proves the primary case is broken that so many fallback methods are 
>> even necessary. Already the ESP and BIOSboot workflows are vastly more 
>> reliable, and completely consistent regardless of the filesystems being 
>> used. It's the MBR gap workflow that's busted. If the primary use case is 
>> fixed, most use cases will inherit the benefit with no additional work or 
>> testing.
> 
> We like BIOSboot on GPT, because we know it's value to the bootloader.
> But most people just don't realize it and complain grub will require
> additioanal partition to work, which is not for leagcy-grub.
> 
> The same thing on msdos could be even worse as there's no spec for it.
> The biggest challenge is even not any technical stuff but people has
> got used to it for years. Not always the good solution will win.

Sadly true. But I still think that change is completely fair game when it 
accommodates and streamlines the most common use cases, while permitting the 
edge cases.

And as for no spec:

a. Let's make one. Bootloaderspec is weak in this area, and is sorta begging 
for clarity.
b. There's no spec for BIOS+GPT either, yet in effect that combination requires 
BIOSboot or grub-install fails.

The reason we can get away without a spec for BIOS+GPT is because the 
constraint essentially requires one workaround where as on MBR it's very loosy 
goosy, there are 10 ways to solve one problem because of the lack of 
constraint. So what it takes to solve this on BIOS+MBR is commitment, so I'm 
perfectly OK with a written spec.


> That is I think BIOSboot for msdos makes sense, but better use it as a
> (yet another) fallback location for mbr gap not a replacement.

It's not a hill I'm willing to die on, but I don't agree. There's essentially 
no downside except some hypothetical vocal complainers. Default grub-install 
command should work on MBR disks with the most common layouts and certainly 
partition 1 beginning at LBA 63 is very common, yet it's treated as an 
exception requiring fallback. Only because many distributions use --force by 
default have users not complained a lot more about this. The right way to solve 
this for Btrfs is not a Btrfs exception, and an XFS exception, and an LVM 
exception. All three of those (common or increasingly so) cases are solved 
singularly with BIOSBoot. It's just a matter of committing to a broad solution 
rather than more fallbacks.



Chris Murphy