grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: workaround install boot on btrfs with windows partition scheme


From: Andrei Borzenkov
Subject: Re: workaround install boot on btrfs with windows partition scheme
Date: Sun, 2 Nov 2014 08:27:07 +0300

В Sat, 1 Nov 2014 14:35:57 -0600
Chris Murphy <address@hidden> пишет:

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

It is rarely needed in simple cases; in complicated cases (btrfs or
LVM) we already have space dedicated for core.img. It seems more
logical to use this space.

Also you still need to tell grub-setup to use this special partition at
which point why not extend it to support arbitrary location for
core.img? It could be made check partition type and not refuse to
install on raw partition for special 0xEA type then as a bonus.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]