what is fdisk: "GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write."?
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives a rather cryptic message: GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write. Reading a lot of posts on this message, doesn't clarify at all what it means. The numbers the message contains don't correspond even remotely to anything output by fdisk. Secondly, what's to be "corrected" and why? Thanks.
On Mon, Apr 26, 2021 at 3:07 PM kf <gebser@mousecar.com> wrote:
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives a rather cryptic message: GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write.
rather noob here. isnt "modern" type of gpt partitioning rather be done with more specialized variants like gdisk and more. not fdisk in the classical means. see: <https://wiki.archlinux.org/index.php/GPT_fdisk> ty
On 2021-04-26 7:24 a.m., cagsm wrote:
On Mon, Apr 26, 2021 at 3:07 PM kf <gebser@mousecar.com> wrote:
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives a rather cryptic message: GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write.
rather noob here. isnt "modern" type of gpt partitioning rather be done with more specialized variants like gdisk and more. not fdisk in the classical means. see: <https://wiki.archlinux.org/index.php/GPT_fdisk> ty
fdisk doesn't interpret a GPT properly, so you really shouldn't be using it on that drive. Use parted/gparted instead.
cagsm, et al -- ...and then cagsm said... % % On Mon, Apr 26, 2021 at 3:07 PM kf <gebser@mousecar.com> wrote: % > Along with other (normal) output, running "fdisk -l /dev/blahblah" gives ... % % rather noob here. isnt "modern" type of gpt partitioning rather be % done with more specialized variants like gdisk and more. not fdisk in [snip] A good question, but the answer isn't always certain. It depends on the version of fdisk you have; if it's gpt-aware, then you're good to go. So we should probably ask the OP for fdisk -V as well as all of the usual other stuff. HTH & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
On 4/26/21 11:09 AM, David T-G wrote:
cagsm, et al --
...and then cagsm said... % % On Mon, Apr 26, 2021 at 3:07 PM kf <gebser@mousecar.com> wrote: % > Along with other (normal) output, running "fdisk -l /dev/blahblah" gives ... % % rather noob here. isnt "modern" type of gpt partitioning rather be % done with more specialized variants like gdisk and more. not fdisk in [snip]
A good question, but the answer isn't always certain. It depends on the version of fdisk you have; if it's gpt-aware, then you're good to go.
So we should probably ask the OP for
fdisk -V
as well as all of the usual other stuff.
HTH & HAND
:-D
$ fdisk --version fdisk from util-linux 2.36.1
On Mon, Apr 26, 2021 at 4:12 PM kf <gebser@mousecar.com> wrote:
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives a rather cryptic message:
GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write.
Reading a lot of posts on this message, doesn't clarify at all what it means. The numbers the message contains don't correspond even remotely to anything output by fdisk.
How are we supposed to guess what *is* output?
Secondly, what's to be "corrected" and why?
Start with showing full command and its output.
On Mon, Apr 26, 2021 at 3:52 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Mon, Apr 26, 2021 at 4:12 PM kf <gebser@mousecar.com> wrote:
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives
isnt this line exactly what the user posted as her command?
GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write.
and this being the error message as the output of that command? ty
On 26/04/2021 16.56, cagsm wrote:
On Mon, Apr 26, 2021 at 3:52 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Mon, Apr 26, 2021 at 4:12 PM kf <gebser@mousecar.com> wrote:
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives
isnt this line exactly what the user posted as her command?
GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write.
and this being the error message as the output of that command? ty
Usually it is better to have the whole command and whole output. Context helps the analysts. Just one single sweep of copy/paste mouse. Example: Telcontar:~ # fdisk -l /dev/blahblah fdisk: cannot open /dev/blahblah: No such file or directory Telcontar:~ # -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 4/26/21 9:52 AM, Andrei Borzenkov wrote:
On Mon, Apr 26, 2021 at 4:12 PM kf <gebser@mousecar.com> wrote:
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives a rather cryptic message:
GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write.
Reading a lot of posts on this message, doesn't clarify at all what it means. The numbers the message contains don't correspond even remotely to anything output by fdisk.
How are we supposed to guess what *is* output?
Secondly, what's to be "corrected" and why?
Start with showing full command and its output.
# fdisk -l /dev/nvme0n1 GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write. Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors Disk model: SAMSUNG MZVLB1T0HBLR-000L7 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 6D9DCF7C-5513-4390-904D-05449A0FC32C Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 3327999 2097152 1G Linux filesystem /dev/nvme0n1p3 3328000 500117503 496789504 236.9G Linux filesystem
Am Montag, 26. April 2021, 15:01:58 CEST schrieb kf:
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives a rather cryptic message:
GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write.
Reading a lot of posts on this message, doesn't clarify at all what it means. The numbers the message contains don't correspond even remotely to anything output by fdisk. Secondly, what's to be "corrected" and why?
PMBR = Protective MBR. This is a Fake MBR partition table as part of a GPT to make non GPT aware partitioning tools aware that there is allready something on that disk. It should fill the whole disk up to the MBR limit of 2TiB. But in your case it doesn't but only about 500GB of 2000 GB . Might it be that this disk was cloned from a smaller disk ?
On 4/26/21 1:37 PM, Markus Koßmann wrote:
Am Montag, 26. April 2021, 15:01:58 CEST schrieb kf:
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives a rather cryptic message:
GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write.
Reading a lot of posts on this message, doesn't clarify at all what it means. The numbers the message contains don't correspond even remotely to anything output by fdisk. Secondly, what's to be "corrected" and why?
PMBR = Protective MBR. This is a Fake MBR partition table as part of a GPT to make non GPT aware partitioning tools aware that there is allready something on that disk. It should fill the whole disk up to the MBR limit of 2TiB. But in your case it doesn't but only about 500GB of 2000 GB . Might it be that this disk was cloned from a smaller disk ?
No, it wasn't cloned from anywhere. In fact, the whole system setup was from the factory, so, one would think, quite standard. Or perhaps the factory-install was cloned.... But you're correct about the data in the PMBR not filling up the entire partition... (if the PMBR is what resides in /boot or /boot/efi : # fdisk -l /dev/nvme0n1 GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write. Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors Disk model: SAMSUNG MZVLB1T0HBLR-000L7 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 6D9DCF7C-5513-4390-904D-05B69A0FC32C Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 3327999 2097152 1G Linux filesystem /dev/nvme0n1p3 3328000 500117503 496789504 236.9G Linux filesystem # df -m /boot/efi /boot / Filesystem 1M-blocks Used Available Use% Mounted on /dev/nvme0n1p1 599 45 555 8% /boot/efi /dev/nvme0n1p2 976 252 658 28% /boot /dev/nvme0n1p3 242573 14728 227158 7% /
On 27/04/2021 02.40, kf wrote:
On 4/26/21 8:38 PM, kf wrote:
... (if the PMBR is what resides in /boot or /boot/efi
or does it, as with the legacy MBR, reside at the very begin of the disk?
Yes. It is exactly the very first sector of the disk. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 27.04.2021 03:38, kf wrote:
On 4/26/21 1:37 PM, Markus Koßmann wrote:
Am Montag, 26. April 2021, 15:01:58 CEST schrieb kf:
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives a rather cryptic message:
GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write.
Reading a lot of posts on this message, doesn't clarify at all what it means. The numbers the message contains don't correspond even remotely to anything output by fdisk. Secondly, what's to be "corrected" and why?
PMBR = Protective MBR. This is a Fake MBR partition table as part of a GPT to
There is nothing fake in it. It is normal MBR.
make non GPT aware partitioning tools aware that there is allready something on that disk. It should fill the whole disk up to the MBR limit of 2TiB. But in your case it doesn't but only about 500GB of 2000 GB . Might it be that this disk was cloned from a smaller disk ?
No, it wasn't cloned from anywhere. In fact, the whole system setup was from the factory, so, one would think, quite standard. Or perhaps the factory-install was cloned....
But you're correct about the data in the PMBR not filling up the entire partition... (if the PMBR is what resides in /boot or /boot/efi :
# fdisk -l /dev/nvme0n1 GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write. Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
So the last disk sector is 2000409263 which matches error message.
Disk model: SAMSUNG MZVLB1T0HBLR-000L7 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt
fdisk detects GPT and does not print MBR. Use sgdisk -Op /dev/nvme0n1 to print both partition tables.
Disk identifier: 6D9DCF7C-5513-4390-904D-05B69A0FC32C
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 3327999 2097152 1G Linux filesystem /dev/nvme0n1p3 3328000 500117503 496789504 236.9G Linux filesystem
Well, you have 1TB disk and your partition table is for 250TB (using marketing numbers :). The number 500118191 is close to 500117503, I also have some free space near disk end. So this partition table appears to be cloned from smaller disk.
On 27.04.2021 07:55, Andrei Borzenkov wrote:
Disk identifier: 6D9DCF7C-5513-4390-904D-05B69A0FC32C
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 3327999 2097152 1G Linux filesystem /dev/nvme0n1p3 3328000 500117503 496789504 236.9G Linux filesystem
Well, you have 1TB disk and your partition table is for 250TB (using marketing numbers :). The number 500118191 is close to 500117503, I also have some free space near disk end.
That is likely due to 1MiB default alignment. 500117504 == 244198MiB. So some space at the end (smaller than 1MiB) was lost.
On 27/04/2021 06.55, Andrei Borzenkov wrote:
On 27.04.2021 03:38, kf wrote:
...
# fdisk -l /dev/nvme0n1 GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write. Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
So the last disk sector is 2000409263 which matches error message.
Disk model: SAMSUNG MZVLB1T0HBLR-000L7 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt
fdisk detects GPT and does not print MBR. Use
sgdisk -Op /dev/nvme0n1
to print both partition tables.
Disk identifier: 6D9DCF7C-5513-4390-904D-05B69A0FC32C
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 3327999 2097152 1G Linux filesystem /dev/nvme0n1p3 3328000 500117503 496789504 236.9G Linux filesystem
Well, you have 1TB disk and your partition table is for 250TB (using marketing numbers :).
Huh, 250 GB, no? :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 4/27/21 12:55 AM, Andrei Borzenkov wrote:
On 27.04.2021 03:38, kf wrote:
On 4/26/21 1:37 PM, Markus Koßmann wrote:
Am Montag, 26. April 2021, 15:01:58 CEST schrieb kf:
Along with other (normal) output, running "fdisk -l /dev/blahblah" gives a rather cryptic message:
GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write.
Reading a lot of posts on this message, doesn't clarify at all what it means. The numbers the message contains don't correspond even remotely to anything output by fdisk. Secondly, what's to be "corrected" and why?
PMBR = Protective MBR. This is a Fake MBR partition table as part of a GPT to
There is nothing fake in it. It is normal MBR.
make non GPT aware partitioning tools aware that there is allready something on that disk. It should fill the whole disk up to the MBR limit of 2TiB. But in your case it doesn't but only about 500GB of 2000 GB . Might it be that this disk was cloned from a smaller disk ?
No, it wasn't cloned from anywhere. In fact, the whole system setup was from the factory, so, one would think, quite standard. Or perhaps the factory-install was cloned....
But you're correct about the data in the PMBR not filling up the entire partition... (if the PMBR is what resides in /boot or /boot/efi :
# fdisk -l /dev/nvme0n1 GPT PMBR size mismatch (500118191 != 2000409263) will be corrected by write. Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
So the last disk sector is 2000409263 which matches error message.
Disk model: SAMSUNG MZVLB1T0HBLR-000L7 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt
fdisk detects GPT and does not print MBR. Use
sgdisk -Op /dev/nvme0n1
to print both partition tables.
Disk identifier: 6D9DCF7C-5513-4390-904D-05B69A0FC32C
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 3327999 2097152 1G Linux filesystem /dev/nvme0n1p3 3328000 500117503 496789504 236.9G Linux filesystem
Well, you have 1TB disk and your partition table is for 250TB (using marketing numbers :). The number 500118191 is close to 500117503, I also have some free space near disk end. So this partition table appears to be cloned from smaller disk.
You're correct. Thanks for the explanation and advice. Mine is a factory-installed system, so, yes, I would imagine the entire install was cloned the same way onto every drive, regardless of size. I did have a lot of unused space on my drive. I was using fdisk to see how much in order to plan the partitions. And. after creating those partitions (used parted (for the first time) to do it), filling up the drive, that message went away in fdisk. BTW, parted gave no such error message about the PMBR.
participants (7)
-
Andrei Borzenkov -
cagsm -
Carlos E. R. -
Darryl Gregorash -
David T-G -
kf -
Markus Koßmann