On Thu, Oct 30, 2014 at 03:42:29PM +0300, Andrei Borzenkov wrote: > On Thu, Oct 30, 2014 at 11:32 AM, Michael Chang <mch...@suse.com> 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 > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
