fdisk does not produce Protective MBR for GPT correctly #485
Comments
The PMBR partition record should be StartingCHS=0x002000 (0/0/2) and EndingCHS=0xFFFFFF (1023/255/63) Addresses: #485 Signed-off-by: Karel Zak <kzak@redhat.com>
|
Nice catch! Fixed. |
|
Commit 8ffa3b6 is not so correct as ** EndingCHS** needs to be calculated from C-H-S disk geometry and value 0xFFFFFF (1023/255/63) is used only if it is not possible to represent last logical block as C-H-S. |
|
Well, the same solution uses GNU Parted.. not sure if we have to care about this so much as nothing uses CHS. |
|
C-H-S is probably not used anymore... but UEFI/GPT specification clearly say what should be filled into structures. And tool which aim to support GPT should follow specification and do not invent its own rules. And at least gdisk has it implemented, so in case of problems, code can be reused. |
The PMBR partition record should be StartingCHS=0x002000 (0/0/2) and EndingCHS=0xFFFFFF (1023/255/63) Addresses: #485 Signed-off-by: Karel Zak <kzak@redhat.com>
|
Microsoft appears to not follow it too... |
|
We know that Microsoft notoriously does not follow industrial standards or implement them differently (E, E, E strategy). So it is not a surprise that Microsoft implements also GPT in non-compliant way. But it does not mean that other developers should do same thing. |
|
The problem is that for CHS you need device geometry and it's not always available (e.g. some logical volumes, non block device partitioning, etc.) and it's poorly portable between devices (dd(1) PT from one disk to another). The reason why we want to use GPT is to avoid dos-like junk :-) So from my point of view GNU Parted and MS solution makes sense and it improves things. IMHO it would be better to update the standard than force applications to care about absolutely obsolete CHS in year 2017. |
Yes, and in most cases C-H-S does not make sense for hdds and BIOS uses some values... Looking at wikipedia there is interesting transition table between LBA and C-H-S numbers. No idea what is the source of data...
GPT itself is not portable between devices (via dd) as it stores layout at beginning and also at the end of disk. Also GPT is addressed by logical sector size and now when usage of native 4K disks is increasing, more problems just come. Two identical disks should not have GPT problem, but probably would have also same C-H-S compatibility.
I fully agree with you. Problem is that standard is not updated yet and so compliant applications still need to care... |
Both the GPT table and ProtectiveMBR need to be updated or
re-written if the disk size changes. That is not a very common
event with real disks (disks don't magically get more bytes).
But, it is common for virtual disks to be "grown" (zeros added
to the end).
The GPT header at the beginning of a disk contains a reference
to the location of a copy (HeaderCopyStartLBA) which is typically
at the end of the disk. The ProtectiveMBR is supposed to span
the entire disk. So both of these things have to be updated
if the disk changes size.
The change here is just to make sure we update both whenever
we write a GPT partition table.
A simple 'diff' doesn't show it well, but what happened is:
a.) move writeProtectiveMBR from writeNewGPTTable to writeGPTTable
b.) pass a disk size into writeGPTTable so that it can pass it through
to writeProtectiveMBR when it needs it.
writeProtectiveMBR doesn't *actually* need the size, because most
partition table writers will just write a partition length of
0xFFFFFFFF independent of the size of the disk. But for now we
can't just do that because the MBR package will return error from
Check(). I've tried to get that fixed. See conversation on
https://github.com/rekby/mbr/pull/2/files
and
util-linux/util-linux#485
Both the GPT table and ProtectiveMBR need to be updated or
re-written if the disk size changes. That is not a very common
event with real disks (disks don't magically get more bytes).
But, it is common for virtual disks to be "grown" (zeros added
to the end).
The GPT header at the beginning of a disk contains a reference
to the location of a copy (HeaderCopyStartLBA) which is typically
at the end of the disk. The ProtectiveMBR is supposed to span
the entire disk. So both of these things have to be updated
if the disk changes size.
The change here is just to make sure we update both whenever
we write a GPT partition table.
A simple 'diff' doesn't show it well, but what happened is:
a.) move writeProtectiveMBR from writeNewGPTTable to writeGPTTable
b.) pass a disk size into writeGPTTable so that it can pass it through
to writeProtectiveMBR when it needs it.
writeProtectiveMBR doesn't *actually* need the size, because most
partition table writers will just write a partition length of
0xFFFFFFFF independent of the size of the disk. But for now we
can't just do that because the MBR package will return error from
Check(). I've tried to get that fixed. See conversation on
https://github.com/rekby/mbr/pull/2/files
and
util-linux/util-linux#485
Both the GPT table and ProtectiveMBR need to be updated or
re-written if the disk size changes. That is not a very common
event with real disks (disks don't magically get more bytes).
But, it is common for virtual disks to be "grown" (zeros added
to the end).
The GPT header at the beginning of a disk contains a reference
to the location of a copy (HeaderCopyStartLBA) which is typically
at the end of the disk. The ProtectiveMBR is supposed to span
the entire disk. So both of these things have to be updated
if the disk changes size.
The change here is just to make sure we update both whenever
we write a GPT partition table.
A simple 'diff' doesn't show it well, but what happened is:
a.) move writeProtectiveMBR from writeNewGPTTable to writeGPTTable
b.) pass a disk size into writeGPTTable so that it can pass it through
to writeProtectiveMBR when it needs it.
writeProtectiveMBR doesn't *actually* need the size, because most
partition table writers will just write a partition length of
0xFFFFFFFF independent of the size of the disk. But for now we
can't just do that because the MBR package will return error from
Check(). I've tried to get that fixed. See conversation on
https://github.com/rekby/mbr/pull/2/files
and
util-linux/util-linux#485
Both the GPT table and ProtectiveMBR need to be updated or
re-written if the disk size changes. That is not a very common
event with real disks (disks don't magically get more bytes).
But, it is common for virtual disks to be "grown" (zeros added
to the end).
The GPT header at the beginning of a disk contains a reference
to the location of a copy (HeaderCopyStartLBA) which is typically
at the end of the disk. The ProtectiveMBR is supposed to span
the entire disk. So both of these things have to be updated
if the disk changes size.
The change here is just to make sure we update both whenever
we write a GPT partition table.
A simple 'diff' doesn't show it well, but what happened is:
a.) move writeProtectiveMBR from writeNewGPTTable to writeGPTTable
b.) pass a disk size into writeGPTTable so that it can pass it through
to writeProtectiveMBR when it needs it.
writeProtectiveMBR doesn't *actually* need the size, because most
partition table writers will just write a partition length of
0xFFFFFFFF independent of the size of the disk. But for now we
can't just do that because the MBR package will return error from
Check(). I've tried to get that fixed. See conversation on
https://github.com/rekby/mbr/pull/2/files
and
util-linux/util-linux#485
Both the GPT table and ProtectiveMBR need to be updated or
re-written if the disk size changes. That is not a very common
event with real disks (disks don't magically get more bytes).
But, it is common for virtual disks to be "grown" (zeros added
to the end).
The GPT header at the beginning of a disk contains a reference
to the location of a copy (HeaderCopyStartLBA) which is typically
at the end of the disk. The ProtectiveMBR is supposed to span
the entire disk. So both of these things have to be updated
if the disk changes size.
The change here is just to make sure we update both whenever
we write a GPT partition table.
A simple 'diff' doesn't show it well, but what happened is:
a.) move writeProtectiveMBR from writeNewGPTTable to writeGPTTable
b.) pass a disk size into writeGPTTable so that it can pass it through
to writeProtectiveMBR when it needs it.
writeProtectiveMBR doesn't *actually* need the size, because most
partition table writers will just write a partition length of
0xFFFFFFFF independent of the size of the disk. But for now we
can't just do that because the MBR package will return error from
Check(). I've tried to get that fixed. See conversation on
https://github.com/rekby/mbr/pull/2/files
and
util-linux/util-linux#485
Reproduce:
According to UEFI Specification 2.6, section 5 GUID Partition Table (GPT) Disk Layout, subsection 5.2.3 Protective MBR, Table 17. Protective MBR Partition Record protecting the entire disk, StartingCHS is 0x000200 (0/0/2) and EndingCHS is 0xFFFFFF (1023/255/63) if it is not possible to represent last logical block as C-H-S.
Here is output when GPT disk was initialized by gdisk:
Protective MBR is there correct.
Please make fdisk compliant to UEFI/GPT specification.
The text was updated successfully, but these errors were encountered: