0

This dump is the output of a dd if=/dev/sda bs=512 | hexdump -C on a 2GiB hard disk (.vdi, on Virtual Box) onto which a GUID Partition Table was written using cfdisk. This is what LBA 1 (the GPT header logical block) looks like:

45 46 49 20 50 41 52 54 | EFI signature
00 00 01 00             | GPT version
5c 00 00 00             | GPT header size
f8 8f 25 0d             | CRC32 (header)
00 00 00 00             | reserved
01 00 00 00 00 00 00 00 | current LBA (this is LBA 1) 
ff ff 3f 00 00 00 00 00 | backup LBA (last LBA on disk)
00 08 00 00 00 00 00 00 | first LBA available for partitions
de ff 3f 00 00 00 00 00 | last LBA available for partitions
a1 4b 7c df ca 02 95 4c | disk's GUID [1/2]
98 16 bb f0 73 d3 c8 0c | disk's GUID [2/2]
02 00 00 00 00 00 00 00 | partition entries' first LBA
80 00 00 00             | total amount of partition entries
80 00 00 00             | size of a single partition entry
86 d2 54 ab             | CRC32 (entries)
00 ..                   | zeroed out until next LBA

This header states there are 80h (128d) partition entries, each being 128 bits long, so entries start from LBA 2 and span for 16KiB or 32 sectors (512B per sector in this disk), meaning from LBA 02h to LBA 21h.

Why is LBA 800h reported as the first available LBA for partitions instead of LBA 22h, the next after partition entries? Aren't entries and actual partitions stored contiguously on disk?

pr0gma
  • 577
  • 3
  • 8
  • 18

1 Answers1

0

Well it looks like this is a cfdisk-specific behavior. I wiped out the GPT and wrote it back twice using gdisk and parted, both of which placed the Partition Entry Array's starting point in LEA 22h, as I was expecting. Note however that having the actual partitions start further in the disk is perfectly acceptable, since the UEFI 2.6 standard only dictates they don't start any sooner than LEA 22h.

pr0gma
  • 577
  • 3
  • 8
  • 18