此转储是在{2}上的2GiB硬盘（dd if=/dev/sda bs=512 | hexdump -C）上.vdi的输出，GUID Partition Table使用cfdisk写入LBA 1。这是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
（GPT标题逻辑块）的样子：
LBA 2此标头指出有80h（128d）分区条目，每个条目长度为128位，因此条目从LBA 02h开始，跨越16KiB或32个扇区（此磁盘中每个扇区512B），意味着来自{{ 1}}到LBA 21h。
为什么LBA 800h被报告为分区的第一个可用LBA而不是LBA 22h，下一个分区条目之后？ Aren的条目和实际分区是否在磁盘上连续存储？
答案 0 :(得分：0)
看起来这是cfdisk特定的行为。我删除了GPT并使用gdisk和parted将其写回两次，两者都按照我的预期放置了分区条目数组的起始点LEA 22h。但请注意，在磁盘中进一步启动实际分区是完全可以接受的，因为UEFI 2.6标准只规定它们不会在LEA 22h之前启动。