Re: workaround install boot on btrfs with windows partition scheme

[Chris Murphy]

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.

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.

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


Chris Murphy