Re: workaround install boot on btrfs with windows partition scheme

[Michael Chang]

On Mon, Nov 03, 2014 at 01:04:33PM -0700, Chris Murphy wrote:
> 
> On Nov 2, 2014, at 9:17 PM, Michael Chang <address@hidden> wrote:
> 
> > On Thu, Oct 30, 2014 at 03:42:29PM +0300, Andrei Borzenkov wrote:
> >> On Thu, Oct 30, 2014 at 11:32 AM, Michael Chang <address@hidden> wrote:
> >>> Many shipped Windows created it's first partition aligned in 63
> >>> (cylinder) and therefore can't offer enough room for core.img. Even
> >>> worse the partitions has been created as logical.
> >>> 
> >>>> sudo /sbin/fdisk -l
> >>> Disk /dev/sda: 64.4 GB, 64424509440 bytes, 125829120 sectors
> >>> Units = sectors of 1 * 512 = 512 bytes
> >>> Sector size (logical/physical): 512 bytes / 512 bytes
> >>> I/O size (minimum/optimal): 512 bytes / 512 bytes
> >>> Disk label type: dos
> >>> Disk identifier: 0x0001c622
> >>> 
> >>>   Device Boot      Start         End      Blocks   Id  System
> >>>   /dev/sda1              63     2056319     1028128+   b  W95 FAT32
> >>>   /dev/sda2   *     2058240   125829119    61885440    f  W95 Ext'd
> >>>   (LBA)
> >>>   /dev/sda5         2060288     5302271     1620992   82  Linux swap /
> >>>   Solaris
> >>>   /dev/sda6         5304320    47247359    20971520   83  Linux
> >>>   /dev/sda7        47249408   125804543    39277568   83  Linux
> >>> 
> >>> This leaves us currently no option to succeed in installation if boot is
> >>> on btrfs, or any other filesystems that block lists can't be used and
> >>> core.img must be embedded in order to be reliably addressed.
> >>> 
> >>> The attached patch try to workaround this scenario by placing the core.img
> >>> in filesystem's (btrfs) bootloader embedding area if available to overcome
> >>> the too small MBR gap which gets loaded by boot.img placed in MBR.
> >>> 
> >>> Please kindly review the patch or suggests for how to fix this scenario
> >>> sanely.
> >>> 
> >> 
> >> Well, I suggested something similar a way back
> >> 
> >> http://marc.info/?t=139175229300004&r=1&w=2
> > 
> > Thanks.
> > 
> >> 
> >> I still believe this is more flexible; in particular, /boot/grub on
> >> btrfs has problems with unwritable grubenv (quite a few people are hit
> >> by this now, when openSUSE defaults to single btrfs partition) so
> >> having separate /boot as ext2 makes sense.
> > 
> > But we can't constrain people from creating this setup if it makes sense
> > to them. For example they want to manage important kernel updates via
> > btrfs snapshots, etc.
> 
> 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.

> 
> 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. :)

> 
> > 
> >> 
> >> Your approach looks too special cased for default (open)SUSE configuration.
> > 
> > The idea is basically treating the filesystem bootloader location as a
> > fallback install to the (preferred) mbr gaps, just like the blocklist
> > install will be used when embedding is not possible and core.img is
> > placed on filesystem.
> 
> 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.

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.

regards,
Michael