[SOLVED] Running fdisk -l misidentifies my hard disks as GPT
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Running fdisk -l misidentifies my hard disks as GPT
I have three 2 TB hard disks, with various Linux and Windows partitions on them in a multi-boot system.
When I run fdisk -l, on any one of the Linux distros I have installed, it always starts off its display of the partitions on my three hard drives with the message:
WARNING: GPT (GUID Partition Table) detected on '/dev/sd(a|b|c)'! The util fdisk doesn't support GPT. Use GNU Parted.
and then shows the partitions correctly. But all my hard disks are MBR, not GPT.
Does anybody know why fdisk misidentifies the hard disks as GPT partitioning as opposed to MBR partitioning, which they are ?
Before you tell me to run gparted or KDE partition manager, I had a recent experience where running gparted on one of my Linux OSs, without changing anything, wiped out the partition table of my second and third hard disks and set them to GPT disks, so I am loath to do that anymore. This may have been a bug in an older version of gparted.
The partition managers, Minitools, EaseUS, Acronis DD11, and Clonezilla all show my hard disks correctly as MBR when I boot from their live disks.
For clarity, could you please post the full output of:
Code:
parted -l
followed by,
Code:
fdisk -l
I am running a number of different Linux distros. In most of them 'parted -l' gives an error saying that my second and third disks ( sdb and sdc ) "contains GPT signatures, indicating that it has a GPT table." But in the latest version of 'parted' in Fedora 17, it correctly reads sdb and sdc as MBR disks.
Rather than give you 'parted -l' output for all 5 Linux distros I run, I will concentrate on Suse 11.4 and Fedora 17. Here is the output for 'parted' on each.
Code:
_________
Suse 11.4
_________
parted -v
parted (GNU parted) 2.3
Model: ATA Hitachi HDS72302 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.3kB 240GB 240GB primary ntfs hidden, type=17
2 240GB 593GB 353GB primary ntfs boot, hidden, type=17
3 593GB 599GB 5355MB extended type=05
5 593GB 595GB 1077MB logical ext3 type=83
6 595GB 596GB 1053MB logical ext3 type=bb
7 596GB 597GB 1077MB logical ext3 type=bb
8 597GB 598GB 1077MB logical ext3 type=bb
9 598GB 599GB 1069MB logical ext3 type=bb
4 1999GB 2000GB 1160MB primary fat32 hidden, lba, type=1c
Warning: /dev/sdb contains GPT signatures, indicating that it has a GPT table.
However, it does not have a valid fake msdos partition table, as it should.
Perhaps it was corrupted -- possibly by a program that doesn't understand GPT
partition tables. Or perhaps you deleted the GPT table, and are now using an
msdos partition table. Is this a GPT partition table?
Yes/No? No
Sector size (logical/physical): 512B/4096B
Warning: /dev/sdc contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was
corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT
partition table?
Yes/No? No
Sector size (logical/physical): 512B/512B
Warning: Unable to open /dev/fd0 read-write (Read-only file system). /dev/fd0 has been opened read-only.
Error: /dev/fd0: unrecognised disk label
Sector size (logical/physical): 512B/512B
As far as fdisk is concerned it always gives a "WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted" on all my distros but then goes on to show the partition tables for all 3 disks as MBR. Again I will give just the outputs for Suse 11.4 and Fedora 17.
Code:
_________
Suse 11.4
_________
fdisk -v
fdisk (util-linux 2.19)
fdisk -l
WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000001
Device Boot Start End Blocks Id System
/dev/sda1 63 469274714 234637326 17 Hidden HPFS/NTFS
/dev/sda2 * 469274715 1159025489 344875387+ 17 Hidden HPFS/NTFS
/dev/sda3 1159041555 1169499869 5229157+ 5 Extended
/dev/sda4 3904758900 3907024064 1132582+ 1c Hidden W95 FAT32 (LBA)
/dev/sda5 1159041618 1161146069 1052226 83 Linux
/dev/sda6 1161146133 1163202389 1028128+ bb Boot Wizard hidden
/dev/sda7 1163202453 1165306904 1052226 bb Boot Wizard hidden
/dev/sda8 1165306968 1167411419 1052226 bb Boot Wizard hidden
/dev/sda9 1167411483 1169499869 1044193+ bb Boot Wizard hidden
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xd5f572fe
Device Boot Start End Blocks Id System
/dev/sdb1 16065 1063711844 531847890 f W95 Ext'd (LBA)
Partition 1 does not start on physical sector boundary.
/dev/sdb2 * 3479646870 3907024064 213688597+ 17 Hidden HPFS/NTFS
Partition 2 does not start on physical sector boundary.
/dev/sdb5 16128 104872319 52428096 83 Linux
/dev/sdb6 104872383 209728574 52428096 bb Boot Wizard hidden
Partition 6 does not start on physical sector boundary.
/dev/sdb7 209728638 314584829 52428096 bb Boot Wizard hidden
Partition 7 does not start on physical sector boundary.
/dev/sdb8 314584893 419441084 52428096 bb Boot Wizard hidden
Partition 8 does not start on physical sector boundary.
/dev/sdb9 419441148 524297339 52428096 83 Linux
Partition 9 does not start on physical sector boundary.
/dev/sdb10 524297403 626695649 51199123+ bb Boot Wizard hidden
Partition 10 does not start on physical sector boundary.
/dev/sdb11 626695713 729110024 51207156 bb Boot Wizard hidden
Partition 11 does not start on physical sector boundary.
/dev/sdb12 729110088 831508334 51199123+ bb Boot Wizard hidden
/dev/sdb13 831508398 947851064 58171333+ 83 Linux
Partition 13 does not start on physical sector boundary.
/dev/sdb14 947851128 1055534759 53841816 b W95 FAT32
/dev/sdb15 1055534823 1063711844 4088511 82 Linux swap / Solaris
Partition 15 does not start on physical sector boundary.
WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x1aeffb21
Device Boot Start End Blocks Id System
/dev/sdc1 * 16065 207302759 103643347+ 5 Extended
/dev/sdc5 16128 102494699 51239286 bb Boot Wizard hidden
/dev/sdc6 102494763 207302759 52403998+ bb Boot Wizard hidden
Code:
_________
Fedora 17
_________
fdisk -v
fdisk (util-linux 2.21.2)
fdisk -l
WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000001
Device Boot Start End Blocks Id System
/dev/sda1 63 469274714 234637326 17 Hidden HPFS/NTFS
/dev/sda2 * 469274715 1159025489 344875387+ 17 Hidden HPFS/NTFS
/dev/sda3 1159041555 1169499869 5229157+ 5 Extended
/dev/sda4 3904758900 3907024064 1132582+ 1c Hidden W95 FAT32 (LBA)
/dev/sda5 1159041618 1161146069 1052226 bb Boot Wizard hidden
/dev/sda6 1161146133 1163202389 1028128+ bb Boot Wizard hidden
/dev/sda7 1163202453 1165306904 1052226 83 Linux
/dev/sda8 1165306968 1167411419 1052226 bb Boot Wizard hidden
/dev/sda9 1167411483 1169499869 1044193+ bb Boot Wizard hidden
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xd5f572fe
Device Boot Start End Blocks Id System
/dev/sdb1 16065 1063711844 531847890 f W95 Ext'd (LBA)
Partition 1 does not start on physical sector boundary.
/dev/sdb2 * 3479646870 3907024064 213688597+ 17 Hidden HPFS/NTFS
Partition 2 does not start on physical sector boundary.
/dev/sdb5 16128 104872319 52428096 bb Boot Wizard hidden
/dev/sdb6 104872383 209728574 52428096 bb Boot Wizard hidden
Partition 6 does not start on physical sector boundary.
/dev/sdb7 209728638 314584829 52428096 83 Linux
Partition 7 does not start on physical sector boundary.
/dev/sdb8 314584893 419441084 52428096 bb Boot Wizard hidden
Partition 8 does not start on physical sector boundary.
/dev/sdb9 419441148 524297339 52428096 bb Boot Wizard hidden
Partition 9 does not start on physical sector boundary.
/dev/sdb10 524297403 626695649 51199123+ bb Boot Wizard hidden
Partition 10 does not start on physical sector boundary.
/dev/sdb11 626695713 729110024 51207156 83 Linux
Partition 11 does not start on physical sector boundary.
/dev/sdb12 729110088 831508334 51199123+ bb Boot Wizard hidden
/dev/sdb13 831508398 947851064 58171333+ 83 Linux
Partition 13 does not start on physical sector boundary.
/dev/sdb14 947851128 1055534759 53841816 b W95 FAT32
/dev/sdb15 1055534823 1063711844 4088511 82 Linux swap / Solaris
Partition 15 does not start on physical sector boundary.
WARNING: GPT (GUID Partition Table) detected on '/dev/sdc'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x1aeffb21
Device Boot Start End Blocks Id System
/dev/sdc1 * 16065 207302759 103643347+ 5 Extended
/dev/sdc5 16128 102494699 51239286 bb Boot Wizard hidden
/dev/sdc6 102494763 207302759 52403998+ bb Boot Wizard hidden
I also run Mandriva 2010/2, CentOS 5.8, and CentOS 6.3 but basically there outputs are similar to Suse 11.4 in claiming that my MBR disks are GPT.
It appears that those disks were at one time partitioned with GPT and then someone used a non-GPT partitioning tool to delete the type EE partition that was in the conventional MBR and then define new partitions, all without overwriting the GPT that begins at LBA 1. You can confirm that by running
Code:
dd if=/dev/sdb skip=1 count=1 | hexdump -C
and looking for the words "EFI PART" at the beginning of the dump.
Since you're not using that GPT, you can zero it out with
Code:
dd if=/dev/zero count=1 seek=1 of=/dev/sdb
but please be very careful that you've typed that command correctly and don't do it unless you saw that "EFI PART" signature. Now fdisk will no longer complain about seeing a GPT header.
It appears that those disks were at one time partitioned with GPT and then someone used a non-GPT partitioning tool to delete the type EE partition that was in the conventional MBR and then define new partitions, all without overwriting the GPT that begins at LBA 1. You can confirm that by running
Code:
dd if=/dev/sdb skip=1 count=1 | hexdump -C
and looking for the words "EFI PART" at the beginning of the dump.
Since you're not using that GPT, you can zero it out with
Code:
dd if=/dev/zero count=1 seek=1 of=/dev/sdb
but please be very careful that you've typed that command correctly and don't do it unless you saw that "EFI PART" signature. Now fdisk will no longer complain about seeing a GPT header.
Bravo ! Your suppositions were correct about the "EFI PART" for sdb and sdc. After using your command to zero out the 512 bytes of LBA 1, 'parted -l' now understands my disks to all be MBR disks.
It is amusing that 'fdisk' still thinks the disks are GPT, even though it displays all the information for them. But that is less worrisome since I believe 'fdisk' has been superceded by 'parted' on nearly all modern Linux systems.
Thanks very much for your help in straightening out this problem.
It is amusing that 'fdisk' still thinks the disks are GPT, even though it displays all the information for them.
There is a backup GPT header in the very last LBA on the disk (num_sectors - 1). I just looked at the source, and fdisk also probes for that. To keep everything happy you should zero out that one too.
There is a backup GPT header in the very last LBA on the disk (num_sectors - 1). I just looked at the source, and fdisk also probes for that. To keep everything happy you should zero out that one too.
I can see the GPT signature on the last sector on all 3 of my hard drives. Is it guaranteed for an MBR drive that this last sector can not be used as part of a partition ?
I can see the GPT signature on the last sector on all 3 of my hard drives. Is it guaranteed for an MBR drive that this last sector can not be used as part of a partition ?
No, it certainly could be included in a partition, but if the disk is partitioned using "cylinder" units, then there is usually some unused space at the end since the space on the drive usually isn't an integral number of those fictitious cylinders. When partitioned using "sector" units, then that last sector would certainly be used unless some space were deliberately left unallocated.
Personally, I wouldn't hesitate to zero out a leftover GPT header that I found there.
No, it certainly could be included in a partition, but if the disk is partitioned using "cylinder" units, then there is usually some unused space at the end since the space on the drive usually isn't an integral number of those fictitious cylinders. When partitioned using "sector" units, then that last sector would certainly be used unless some space were deliberately left unallocated.
Personally, I wouldn't hesitate to zero out a leftover GPT header that I found there.
I checked where the last partition ended on my drives and none of them ended at the last sector. So I zeroed out the last sector and now 'fdisk' correctly sees the hard diska as MBR.
I do see two more anomalies:
1) The partition type of the extended partition on one of my hard drives is 0xf rather than 0x5. This does not seem to matter much, but I could not tell from my investigation of partition types if I will be adversely affected by it.
2) On one of my hard drives, the actual physical sector size is 4096, or 8 logical 512 byte sectors. On that drive fdisk reports that a number of partitions do not start at a physical sectory boundary.
1) The partition type of the extended partition on one of my hard drives is 0xf rather than 0x5. This does not seem to matter much, but I could not tell from my investigation of partition types if I will be adversely affected by it.
Shouldn't be a problem. Type 0xf ("W95 Extended LBA") vs. 0x5 ("Extended") won't make any difference to Linux. fdisk will allow you to change the type to 5 (or 85 "Linux extended") if you want to.
Quote:
Originally Posted by eldiener
2) On one of my hard drives, the actual physical sector size is 4096, or 8 logical 512 byte sectors. On that drive fdisk reports that a number of partitions do not start at a physical sectory boundary.
I wasn't aware that fdisk checked for that. Are you sure it wasn't complaining about cylinder boundary? Partitions that don't begin/end on cylinder boundaries are normal and pretty much necessary on drives with 4KB sector size (the default cylinder size is not a multiple of that sector size), but partitions that aren't aligned on physical sector boundaries are going to have a severe impact on write performance (possibly a factor of 10) and should be corrected.
Shouldn't be a problem. Type 0xf ("W95 Extended LBA") vs. 0x5 ("Extended") won't make any difference to Linux. fdisk will allow you to change the type to 5 (or 85 "Linux extended") if you want to.
I wasn't aware that fdisk checked for that. Are you sure it wasn't complaining about cylinder boundary? Partitions that don't begin/end on cylinder boundaries are normal and pretty much necessary on drives with 4KB sector size (the default cylinder size is not a multiple of that sector size), but partitions that aren't aligned on physical sector boundaries are going to have a severe impact on write performance (possibly a factor of 10) and should be corrected.
Good to know there is no difference in Linux between the extended partition types of 0x5 and 0xf.
fdisk says "Partition n(1,2,etc.) does not start on physical sector boundary."
I will look for a program that can move the partitions on physical sector boundaries without destroying the data in them. But first I will back up everything on the drive where this occurs, before I try to maneuver the boundaries.
I will look for a program that can move the partitions on physical sector boundaries without destroying the data in them. But first I will back up everything on the drive where this occurs, before I try to maneuver the boundaries.
Good luck on that. I doubt you'll find a tool that will attempt something as dangerous as an overlapping move of a partition, but do post back if you should find one.
Good luck on that. I doubt you'll find a tool that will attempt something as dangerous as an overlapping move of a partition, but do post back if you should find one.
I don't want to do an overlapping move of a partition. I just want to be able to move one partiton at a time from the beginning to the left or from the end to the right so that each partition starts on a physical sector boundary. I will try Clonezilla live, or GParted live, or Parted Magic live to see which one allows me to specify the exact starting logical sector to move a partition to, while preserving the data in the partition, and updating the partition's table accordingly. I could probably do this with 'dd' if I could work out exactly how to update the partition tables and extended partition tables, but I have to think one of the partitioning tools I mention above will do the trick for me. I could, of course, now that I have backed up all partitions to my external drives, also delete all partitions from the drive and recopy each backed up partition to a correct area starting on a physical sectory boundary.
Last edited by eldiener; 10-15-2012 at 10:22 PM.
Reason: Correct misspelling
An overlapping move is one where the source and destination share some of the same area on the disk, which is exactly the case when you are trying to slide a partition a few sectors to the left or right. There is no simple way to do that that does not leave you with a huge mess if the operation gets aborted part way through.
An overlapping move is one where the source and destination share some of the same area on the disk, which is exactly the case when you are trying to slide a partition a few sectors to the left or right. There is no simple way to do that that does not leave you with a huge mess if the operation gets aborted part way through.
I have used partition managers which did just such an overlapped move without any problems in the past. Even if the move got aborted somehow, which has never happened to me, at worst I just restore my backup and I am fine again.
Unfortunately none of the Linux live partition managers I tried, both gparted and KDE partition manager, would allow me move a partition by specifying a sector boundary. Curses ! Then I though I might use 'parted' from the command line, only to find out that the ability to even resize/move a partition was taken away from its command line functionality long ago. The only alternative, since I am an expert programmer, is to try to understand the API of libparted, and write my own program to do what I want.
So I am a bit stuck and will have to live with my partitions on my sdb drive, most of which do not start on a physical sector boundary, unless I write my own program.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
, but do post back if you should find one.
