From: Peter Cordes <peter@cordes.ca>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux <util-linux@vger.kernel.org>
Subject: Re: sfdisk problem with a partition starting early on a GPT disk
Date: Mon, 02 Mar 2015 12:19:32 -0400 [thread overview]
Message-ID: <20150302161932.GX3933@cordes.ca> (raw)
In-Reply-To: <20150302100652.GI8046@ws.net.home>
[-- 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 --]
next prev parent reply other threads:[~2015-03-02 16:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-01 15:56 sfdisk problem with a partition starting early on a GPT disk Peter Cordes
2015-03-02 10:06 ` Karel Zak
2015-03-02 16:19 ` Peter Cordes [this message]
2015-03-02 20:13 ` Karel Zak
2015-03-02 22:31 ` Peter Cordes
2015-03-03 0:21 ` Karel Zak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150302161932.GX3933@cordes.ca \
--to=peter@cordes.ca \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox