Re: workaround install boot on btrfs with windows partition scheme

[Chris Murphy]

On Oct 30, 2014, at 2: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.

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?


Chris Murphy