sfdisk problem with a partition starting early on a GPT disk

sfdisk problem with a partition starting early on a GPT disk

[Peter Cordes]

[-- Attachment #1: Type: text/plain, Size: 5358 bytes --]

 I recently got 3 new disks, and am setting them up now that I've
figured out how I want to RAID them together, and what you can boot
from.  (for the record, turns out you can boot from almost anything,
even a RAID10,f2 of 2 disks, or a RAID10,n2 of 3 disks, with GRUB2.  I
tested on another machine before putting the disks into my main
machine, so I could do stuff without rebooting my main machine.)


 Anyway, seemed like a golden opportunity to test the new sfdisk.  I
partitioned one with parted, then created a BIOS boot partition (from
sector 40 to 2047), fixed the partition types and sorted the partition
table to be in disk order with gdisk.  Then I tried to copy the
partition table from that one to the other two.

I got an error from sfdisk on trying to apply the plan it printed.

# the disk I partitioned manually:
$ sudo /usr/local/src/util-linux/sfdisk -d /dev/sde | tee tosh-partitions.sfdisk
label: gpt
label-id: 7E471862-5089-4C54-A3BC-722ADD08808A
device: /dev/sde
unit: sectors

/dev/sde1 : start=          40, size=        2008, type=21686148-6449-6E6F-744E-656564454649, uuid=01F40706-97E6-43D1-80D3-0EA85BB5E8FD, name="BIOS boot partition"
/dev/sde2 : start=        2048, size=    30720000, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=9898E8B2-C930-4E6E-826A-4D7305793E6A
/dev/sde3 : start=    30722048, size=   122880000, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=C0CF3D7C-A170-4E1E-9169-9AB4A4FF3164
/dev/sde4 : start=   153602048, size=   820695040, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=F9258FDA-14A3-4B72-B367-F3B1B244C407
/dev/sde5 : start=   974297088, size=     2457600, type=0657FD6D-A4AB-43C4-84E5-0933C84B4F4F, uuid=8EF2E18C-8E3D-41A3-86AF-EE4FDA7B103D
/dev/sde6 : start=   976754688, size=  4883777536, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=265297FD-E7AA-484F-BEC2-D03C385E75DD


# one of the other two disks:
 $ sudo /usr/local/src/util-linux/sfdisk /dev/sdj < tosh-partitions.sfdisk
 Checking that no-one is using this disk right now ... OK
 
 Disk /dev/sdj: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 4096 bytes
 I/O size (minimum/optimal): 4096 bytes / 4096 bytes
 Disklabel type: gpt
 Disk identifier: 74559404-2E86-49E7-8B30-219F09264C1E
 
 Old situation:
 
 Device         Start       End   Sectors   Size Type
 /dev/sdj1       2048 572524543 572522496   273G Microsoft basic data
 /dev/sdj2  572524544 868653055 296128512 141.2G Linux filesystem
 /dev/sdj3  868653056 904501247  35848192  17.1G Linux filesystem
 /dev/sdj4         40      2047      2008  1004K BIOS boot
 /dev/sdj5  904501248 927029247  22528000  10.8G Linux filesystem
 /dev/sdj6  927029248 945461247  18432000   8.8G Linux filesystem
 
 Partition table entries are not in disk order.
 
 >>> Script header accepted.
 >>> Script header accepted.
 >>> Script header accepted.
 >>> Script header accepted.
 >>> Created a new GPT disklabel (GUID: 7E471862-5089-4C54-A3BC-722ADD08808A).
 Sector 40 already used.
 Failed to add partition: Numerical result out of range
 Leaving.



Removing the boot partition from the plan before feeding it to sfdisk
makes it work.  (4k aligned partition in the first 1MiB before the
first aligned-to-1MiB partition that gparted creates. See
https://en.wikipedia.org/wiki/BIOS_boot_partition).


Am I missing something?  Even -f didn't work.  I don't have sfdisk
from git HEAD (14160b7bd08f54f9...) installed; I'm just running it
from /usr/local/src on Ubuntu 14.10, in case that helps explain
anything.

Does sfdisk use more space for its GPT than other tools, like gdisk
or gparted?  After making a new GPT partition table with either of
those tools, I could make a new partition starting as early as sector
34 (according to gdisk).  I make my boot partition start at sector 40
just so it's 4k aligned.  (It's only written by grub-install, not the
usual update-grub on kernel updates, so it's not like it matters if
it's aligned anyway, but still.)

 Oh that's weird.  Running gdisk on the sfdisk-partitioned disk
doesn't let me create a partition before the one at 1MiB (sector
2048).  Does sfdisk make the partition table itself consume the full
first 1MiB of the disk?

 And BTW, yes I tested booting Linux with GRUB2 on disks with the
bios_grub partition from sector 40-2047.  I don't think I ever tried
having it anywhere else.  I never had a problem with it in my
experiments with GRUB reading md RAID devices.  (GRUB can read
basically anything except RAID0.  The machine hard resets when I try
that...  It has no trouble with RAID10,f2, or even RAID10 on 3 disks,
so it can read multiple disks.)

I'm not an expert, so IDK if there's some reason it's reasonable to
reject a config like this, but other tools have no problem creating
and using it (except gparted, with align to 1MiB or cyclinder as the
only options, but it doesn't even let you set the partition type
correctly for md on GPT.)

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 359 bytes --]

Re: sfdisk problem with a partition starting early on a GPT disk

[Karel Zak]

On Sun, Mar 01, 2015 at 11:56:10AM -0400, Peter Cordes wrote:
> # the disk I partitioned manually:
> $ sudo /usr/local/src/util-linux/sfdisk -d /dev/sde | tee tosh-partitions.sfdisk
> label: gpt
> label-id: 7E471862-5089-4C54-A3BC-722ADD08808A
> device: /dev/sde
> unit: sectors
> 
> /dev/sde1 : start=          40, size=        2008, type=21686148-6449-6E6F-744E-656564454649, uuid=01F40706-97E6-43D1-80D3-0EA85BB5E8FD, name="BIOS boot partition"
> /dev/sde2 : start=        2048, size=    30720000, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=9898E8B2-C930-4E6E-826A-4D7305793E6A
> /dev/sde3 : start=    30722048, size=   122880000, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=C0CF3D7C-A170-4E1E-9169-9AB4A4FF3164
> /dev/sde4 : start=   153602048, size=   820695040, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=F9258FDA-14A3-4B72-B367-F3B1B244C407
> /dev/sde5 : start=   974297088, size=     2457600, type=0657FD6D-A4AB-43C4-84E5-0933C84B4F4F, uuid=8EF2E18C-8E3D-41A3-86AF-EE4FDA7B103D
> /dev/sde6 : start=   976754688, size=  4883777536, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=265297FD-E7AA-484F-BEC2-D03C385E75DD
...
>  >>> Created a new GPT disklabel (GUID: 7E471862-5089-4C54-A3BC-722ADD08808A).
>  Sector 40 already used.
>  Failed to add partition: Numerical result out of range
>  Leaving.
...

> Does sfdisk use more space for its GPT than other tools, like gdisk
> or gparted?  After making a new GPT partition table with either of
> those tools, I could make a new partition starting as early as sector
> 34 (according to gdisk).  I make my boot partition start at sector 40
> just so it's 4k aligned.  (It's only written by grub-install, not the
> usual update-grub on kernel updates, so it's not like it matters if
> it's aligned anyway, but still.)

UEFI standard:

  "First Usable LBA must be greater than or equal to 34.."

so your setup correct, you have the first partition at LBA 40.

>  Oh that's weird.  Running gdisk on the sfdisk-partitioned disk
> doesn't let me create a partition before the one at 1MiB (sector
> 2048).  Does sfdisk make the partition table itself consume the full
> first 1MiB of the disk?

No, GPT header contains First and Last LBA offsets, it's area where
you can define partitions. The libfdisk uses 1MiB offset for the
First LBA to make sure that all partitions will be aligned. This
is generic for all our fdisks.   (1MiB is almost standard now.)

For MBR sfdisk is more benevolent and it allows to use smaller offsets
in scripts, maybe we need something like this for GPT too.

I don't want to offer such possibility for standard partitioning (in
cfdisk or fdisk), but for dumps or if you want to restore PT backups
the library should be ready to accept smaller offsets.

> I'm not an expert, so IDK if there's some reason it's reasonable to
> reject a config like this, but other tools have no problem creating
> and using it (except gparted, with align to 1MiB or cyclinder as the
> only options, but it doesn't even let you set the partition type
> correctly for md on GPT.)

Well, <1MiB for the first partition is like a black swan, it's
unusual, but it exists :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: sfdisk problem with a partition starting early on a GPT disk

[Peter Cordes]

[-- Attachment #1: Type: text/plain, Size: 4633 bytes --]

On Mon, Mar 02, 2015 at 11:06:52AM +0100, Karel Zak wrote:
> On Sun, Mar 01, 2015 at 11:56:10AM -0400, Peter Cordes wrote:
> > # the disk I partitioned manually:
> > $ sudo /usr/local/src/util-linux/sfdisk -d /dev/sde | tee tosh-partitions.sfdisk
> > label: gpt
> > label-id: 7E471862-5089-4C54-A3BC-722ADD08808A
> > device: /dev/sde
> > unit: sectors
> > 
> > /dev/sde1 : start=          40, size=        2008, type=21686148-6449-6E6F-744E-656564454649, uuid=01F40706-97E6-43D1-80D3-0EA85BB5E8FD, name="BIOS boot partition"
> > /dev/sde2 : start=        2048, size=    30720000, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=9898E8B2-C930-4E6E-826A-4D7305793E6A
> > /dev/sde3 : start=    30722048, size=   122880000, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=C0CF3D7C-A170-4E1E-9169-9AB4A4FF3164
> > /dev/sde4 : start=   153602048, size=   820695040, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=F9258FDA-14A3-4B72-B367-F3B1B244C407
> > /dev/sde5 : start=   974297088, size=     2457600, type=0657FD6D-A4AB-43C4-84E5-0933C84B4F4F, uuid=8EF2E18C-8E3D-41A3-86AF-EE4FDA7B103D
> > /dev/sde6 : start=   976754688, size=  4883777536, type=A19D880F-05FC-4D3B-A006-743F0F84911E, uuid=265297FD-E7AA-484F-BEC2-D03C385E75DD
> ...
> >  >>> Created a new GPT disklabel (GUID: 7E471862-5089-4C54-A3BC-722ADD08808A).
> >  Sector 40 already used.
> >  Failed to add partition: Numerical result out of range
> >  Leaving.
> ...
>
> UEFI standard:
> 
>   "First Usable LBA must be greater than or equal to 34.."
> 
> so your setup correct, you have the first partition at LBA 40.

 That wording sounds like the partition utilities are allowed to make
GPT partition tables with first-usable-sector as high as they want.  So
the UEFI standard doesn't require that tools support stuffing a
partition before the first 1MiB.

> The libfdisk uses 1MiB offset for the
> First LBA to make sure that all partitions will be aligned. This
> is generic for all our fdisks.   (1MiB is almost standard now.)

 Yeah, since alignment requirements for pretty much any hardware
(except a partitionable RAID5/6) are so much smaller than device
capacity, it makes sense to just go way overboard and align to 1MiB.
That still only wastes a tiny fraction (~1MiB / 1TiB < 10^-6).

 Thanks for clearing up that this is just a side effect of a
restriction imposed while designing libfdisk to ensure standard
alignment.

 If libfdisk doesn't actually store anything after sector 33, it would
be nice if it wrote a GPT to disk that that has sector 34 as the
first-usable.  That way, I could use gdisk to add a boot partition on
each disk after copying the layout of the other partitions with
sfdisk.  (That would be a minimal fix that isn't as nice as actually
supporting copying arbitrary valid GPT partition tables.  But it
should be easier).  As it is, gdisk tells me that the GPT it read from
the disk has the first-usable-sector as 2048.

 I ended up using sfdisk (instead of dd, since I needed different
UUIDs).  Then gdisk, and put my gdisk-EF02 boot partition in the
unused ~500k at the end of the disk.  (Hopefully GRUB2's boot sector
can load its next component from > 2TiB.  Otherwise I could make room
next to my swap partitions or something.  I've already started copying
data to the other partitions.)



> I don't want to offer such possibility for standard partitioning (in
> cfdisk or fdisk), but for dumps or if you want to restore PT backups
> the library should be ready to accept smaller offsets.

 gdisk supports it.  As long as it's maintained, people can use that.

> Well, <1MiB for the first partition is like a black swan, it's
> unusual, but it exists :-)

 My thinking was that I don't even need 1MiB for this, and it just
felt clunky to make the first real partition start at 2MiB.  IMO,
right after the the partition table should be the standard location
for "bios boot" partitions (gdisk EF02 type code).

 The other advantage is that it makes it slightly simpler to dd
everything needed for booting (other than the partition containing
/boot, which can be a RAID10,f2 or whatever).

 I haven't tried setting my BIOS to UEFI boot mode, but if the EFI
system partition (containing a FAT FS) can fit in 1000kiB, that still
seems like the ideal location for it.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 359 bytes --]

Re: sfdisk problem with a partition starting early on a GPT disk

[Karel Zak]

On Mon, Mar 02, 2015 at 12:19:32PM -0400, Peter Cordes wrote:
>  If libfdisk doesn't actually store anything after sector 33, it would
> be nice if it wrote a GPT to disk that that has sector 34 as the
> first-usable. 

 I'm not sure, the common consensus is to use 1MiB offset for the
 first partition -- then it does not make sense to define
 FirstUsableLBA smaller, because the extra space between the first
 partition may be interpreted as gap and later (inadvertently)
 partitioned.

 Note the I'm talking about default layout, your example with 
 --dump and restore is different -- sfdisk has to be able to 
 copy existing partition tables.
 
 BTW, the problem should be fixed in git tree, you have to --dump with
 new sfdisk and then it will add "first-lba" number to scrit header.
 You can also use 

  label: gpt
  first-lba: 34

 lines to manually create a GPT header by sfdisk.

> That way, I could use gdisk to add a boot partition on
> each disk after copying the layout of the other partitions with
> sfdisk.  (That would be a minimal fix that isn't as nice as actually
> supporting copying arbitrary valid GPT partition tables.  But it

 It would be better to learn partitioning tools to modify
 FirstUsableLBA in GPT header. I'll probably implement it for v2.27
 fdisk, so creative users like you will be able to tune up their
 partition tables :-)

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: sfdisk problem with a partition starting early on a GPT disk

[Peter Cordes]

[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]

On Mon, Mar 02, 2015 at 09:13:11PM +0100, Karel Zak wrote:
> On Mon, Mar 02, 2015 at 12:19:32PM -0400, Peter Cordes wrote:
> >  If libfdisk doesn't actually store anything after sector 33, it would
> > be nice if it wrote a GPT to disk that that has sector 34 as the
> > first-usable. 
> 
>  I'm not sure, the common consensus is to use 1MiB offset for the
>  first partition -- then it does not make sense to define
>  FirstUsableLBA smaller, because the extra space between the first
>  partition may be interpreted as gap and later (inadvertently)
>  partitioned.

 If libfdisk-based tools depend on this to avoid showing the user
there's partitionable space before the first partition, then they'll
behave differently when editting GPT partitions written by other tools.
(The widely-used parted sets FirstUsableLBA = 34, and I assume so do
most others.)

 If that's just for the benefit of "other tools", then parted doesn't
need this help.  gparted doesn't seem to offer a way to create
non-1MiB-aligned partitions even if you wanted to.  (IDK about the CLI).

 If a tool doesn't try to enforce alignment, the 2nd partition a user
creates could be un-aligned, if the first partition doesn't end on a
1MiB boundary.  Anyway, IDK how useful this theoretical benefit is to
anyone.

>  Note the I'm talking about default layout, your example with 
>  --dump and restore is different -- sfdisk has to be able to 
>  copy existing partition tables.
>  
>  BTW, the problem should be fixed in git tree, you have to --dump with
>  new sfdisk and then it will add "first-lba" number to scrit header.

 Ok, cool.  It might not be hard to detect scripted partitions
starting below 2048, but above 33, and set first-lba to the lowest
number found.  Or to 34, if a partition before 2048 is found at all.

 Requiring scripts to have a first-lba: 34 is a non-obvious extra step
that might take some debugging time for someone generating a script
from scratch in a program, rather than with sfdisk -d.

>  It would be better to learn partitioning tools to modify
         <englishlesson> teach </englishlesson>  :)
>  FirstUsableLBA in GPT header. I'll probably implement it for v2.27
>  fdisk, so creative users like you will be able to tune up their
>  partition tables :-)

 Yeah, neat.  That could be useful either way, for setting to 2048 in
other tables, as well.

 Thanks again for the quick response and getting a fix in.  I'll use
it to re-copy my partition tables now, before I'm booting from them.
So it should be easy to fix anything that happens because of different
UUIDs.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 359 bytes --]

Re: sfdisk problem with a partition starting early on a GPT disk

[Karel Zak]

On Mon, Mar 02, 2015 at 06:31:10PM -0400, Peter Cordes wrote:
>  Ok, cool.  It might not be hard to detect scripted partitions
> starting below 2048, but above 33, and set first-lba to the lowest
> number found.  Or to 34, if a partition before 2048 is found at all.

 Yes, I thought about... maybe I'll implement it.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com