Re: workaround install boot on btrfs with windows partition scheme

[Michael Chang]

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.

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

The users of grub-install/grub-bios-setup may get used to take only stage1
install location into account and let the tools to figure out most feasible
setups for them, they don't have to care about where core.img will be placed
as this is what grub tools would make the best decision for them.

But I'm also second to your approach as it offers more flexibilty to
default behavior and can allow custom cases. With your patch (Will it
eventually be megerd into mainline by the way ?) this patch may not be
necessary, although it helps in setting up the bootloader by
grub-install witj less hassle, as it always did imho.

regards,
Michael

> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel