Leap - Cannot partition drives - type MBR/GPT mismatch?


I attempted to install new (for me) Leap 42.1 and the installation got wrong at partitioning - I get errors like:Setting disk label of /dev/sdb to GPT
System error code was -1007
/usr/sbin/parted -s --align=optimal 'dev/sdbÄ unit cyl mkpart primary fat32 0 19:
Error: /dev/sdb: unrecognised disk label

Failure occurred during the following action:
Setting disk label of /dev/sdb to GPT
System error code was: -1008

(those were copied from a post I read, however mine are nearly identical).

The PC I was installing OpenSuse on has two drives:

  • new ADATA 64 GB SSD drive (/dev/sda)
  • old SATA 250 MG drive (/dev/sdb)

What I tried to do, was to go into “expert mode” and partition as following (I have same for years on my PC):

  • /dev/sda1 - 25GB as “/” (left suggested BtrFS)
  • /dev/sda2 - 32GB unmounted, FAT32
  • /dev/sdb1 - 80GB as “/home” (left suggested BtrFS)
  • /dev/sdb2 - 2GB as “Swap”
  • /dev/sdb3 - 0.5GB as “/var/log”
  • /dev/sdb4 - the rest, unounted, FAT32

There is no dual boot - user wants linux and VirtualBox with his windows in it for “users back compatibility”.

In addition to partitioning within Opensuse Leap instllation, I tried fdisk, cfdisk (looks best), some parted stuff etc. No luck. I.e. when I partition any disk with cfdisk, all looks great, I exit the program. I go back into the program and list created partions and none are found. This is same for MBR and GPT choises.

Based on my impression from other post with similar problems, I think MBR and GPT are missmatched. However I don’t know how to proceed to fix it, please help.



When using “expert mode” did you - as first step - read in the (current) partition tables (in order to get rid of the installers proposal)?

To do GPT partitioning i always use “gdisk”. You should be able to do a pre-installation partitioning with “gdisk” by booting the “rescue” option of the openSUSE 42.1 installation DVD.

For a better qualified advice it would be good to know whether you want to install in UEFI (probably plus secureboot) or in BIOS mode.

Best regards


Note if the drive has ever used DOS partitioning and GPT partition you may have two partition tables this confuses things a lot. Best to zero wipe first track and start afresh

I am not completely following what you are trying, but when you try to use a 25 GB for / with Btrfs, then I think that is not enough. The default/recommeneded size of a ext4 / partition in 20GB and for a Btrfs one it is 40GB (the installer then assumes you use snapper).

The suggested fs type for /home in Leap 42.1 is xfs not Btrfs.

So apart from the problems you seem to have, I suggest you re-think your grand design.
(Personaly I wonder about non-Linux file systems on a Linux only system, uit you may know a goal for this that elapses me).

I have seen similar errors.

In my case, it was an external hard drive, to which I had copied a DVD install iso (as if it were a flash drive). When I tried to use that disk for normal use, I saw similar errors. Apparently the iso9660 label was confusing “parted”. I solved the problem by writing 1M of zeros over the beginning of the disk – something like:

# dd if=/dev/zero of=/dev/sdX count=2048

For you that “sdX” might be “sdb” – but check that carefully before you try. If you zero the wrong disk, you will lose data.

Thank you for your advices.


  • yes, when I entered expert mode, it loaded the existing partitioning tables (as it always have done)
  • I’ve tried gdisk with no success and I did it again:
Number  Start (sector)   End (sector)  Size      Code  Name
   1           2048         8388127   40.0 GiB   8300  Linux filesystem
   2        8388128       117231374   15.9 GiB   0700  Microsoft basic data
... ...  ... ...
OK; Overwriting new GUID partition table (GPT) to /dev/sda
The operation has completed succesfully.

…and right after that, there’s no partitioning table:

# gdisk
Command (? for help): p
... drive info...

Number  Start (sector)   End (sector)  Size      Code  Name

Command (? for help): 

In last 16 years of Suse installations on my PCs I haven’t come across such an issue, so I have no idea at this stage, whether to choose UEFI o not. Will have to study this a bit


  • OK, I attempted the action with your recommended values (40GB for BrtFS)
  • suggested type: I wasn’t clear about it. I meant what the installer sets as default, when you choose the purpose of the drive. It is different for data (XFS) and system categories (BrtFS)
  • win filesystems - they’re not important at this stage can be changed to linux. If VirtualBox emulation will be at least as good as on my PC with the same setup, then they won’t be needed

Yes, I think of same reason. But I fail to carry out the theory (to wipe old partitions and make new)…

You should try what was already proposed by nrickert

dd if=/dev/zero of=/dev/sdX count=2048

In addition you might want to use “gdisk” with “x extra functionality (experts only)” and “z zap (destroy) GPT data structures and exit”. That will take care of any GPT backup partition tables (which are not located at the start of the disk).

Best regards


I think I can confirm, that there are two partition tables on the drive(s).

I created whole new GPT tables with gdisk (I got it working - there seems to be a little bug if you specify the drive after the commands starts and not as an option) and then the SUSE installer first loads a partition table, which has been done during previous installation instance. But when I press on reload partition table button, the new GPT partition table made by gdisk appears.
However, when I set mount point and formats and start installation, it fails on formatting the drives… I think, it looks into different partition table…

So next I did:

dd if=/dev/zero of=/dev/sdX count=2048

It helps a bit, I was able to store partition tables with i.e. gdisk, but it kept telling me, that the main table is different from backup.

So I used expert options and “z” command to wipe GPT.

But I have still the same problem - I cannot create GPT consistently. When I write with gdisk a table I create and start it after, it says no GPT was found and creates a new one. If I create only one line, then GPT is recorded, but I need more drives.

I think I may even succeed to format the disks with different command line tools in rescue mode (and then, the installation wouldn’t fail), but it wouldn’t resolve the root cause, isn’t it?

I attempted to install the system with partition tables made after clearing the master sector with dd command and wiping out GPT and creating a new GPT, but still same story:

  1. Any attempt to modify partition table, even setting type of a partition, leads to an error (such as DISK_SET_TYPE_PARTED_FAILED)
  2. Any attempt to format a partition will lead in errors like VOLUME_CANNOT_TMP_MOUNT and consequently VOLUME_FORMAT_FAILED

By “attempts” in the above post I meant installation instances.

I also tried to use only SSD drive (/dev/sda) for whole openSUSE, but it didn’t work either:
Creating /dev/sda1
System error code -1008
Ignore error and continue?

Do i understand that correctly:

  1. You wiped your disk (dd + gdisk x z)
  2. You created several new partitions with gdisk
  3. You wrote the new partition table to disk (before leaving gdisk)
  4. Then you left gdisk and started it again and it told you, that there were no partitions on your drive
  5. You wiped your disk (dd + gdisk x z) again
  6. You created ONE SINGLE new partition with gdisk
  7. You wrote the new partition table to disk (before leaving gdisk)
  8. Then you left gdisk and started it again and it told you, that there was JUST ONE partition on your drive.

If that is what you did, then - i have to admit - i do not know what else could help you. I assume you already did all the common things like

Checked your SATA cables
Set the drive(s) in your UEFI/BIOS to AHCI
Checked your installation media
Tried the drive with a LIVE system

I don’t think it really matters in your case, but it still would be good to know whether your machine has a BIOS or an UEFI (probably with some details like manufacturer and version) and - in case you have an UEFI - whether you have set it to UEFI or MBR booting. (The latter is sometimes called CSM or Legacy.)

Best regards


Where these errors generated by the openSUSE 42.1 installer or by some other tools?

When you prepare your disks in advance (with “gdisk” and “mkfs.ext4”) and just tell the installer to use those formatted partitions, what are the precise error messages given by the installer ?

Best regards


I tried to switch “UEFI and Legasy” to “Legacy Only” in BIOS, but it has no effect on the issue.

Yes, this is basically true. I tried gdisk (for GPT), cfdisk (for DOS and GPT), fdisk (DOS). At the moment I only try to continue with DOS partitions, so I use fdisk. I set “Legacy Only” (=DOS) Boot Mode in BIOS. Regardless the tools I used, 4 out of 5 times when I write changes and the program finishes, when after I go back and list partitions with “p” command, there are no partitions and no partition label and it tells me, that it creates a new label. When it saves the partitions, it persists. When I start suse installer and get to the partitions, it fails and after restart when I check in rescue system again, the partitions and disk labels are all gone (on both hard drives).

I think it’s unlikely that both SSD and HDD would be damaged, or that both SATA cables would be damaged.

Comments at the end of lines above.

Set to “Legacy Only”, but not from beginnig of the troubles.


I did not prepared the filesystem yet, only the partitions. This is a next step I will try (to prepare the disks in the way that installer will not have to modify partitions or filesystems).
The messages: Differ, depending on what exactly I tried with partitions. But it is always a first thing it tries to do with the partition - either setting a partition label, or creating a partition, or formatting a partition…

At the moment I’m trying to create following (gone into safe and tested DOS partitioning and Ext4 file system):

  • sda1, primary, 25GB, ext4, /
  • sda2, primary, 30GB, ext4, data
  • sdb1, primary, 230GB, ext4, /home
  • sdb2, primary, 2GB, swap
  • sdb3, primary, 750MB, ext4, /var/log (…to reduce number of writes into SSD)

I tried also a variant with extended partition on sdb (so sdb2 becomes sdb5 and sdb3 → sdb6), but it doesn’t seem to have any effect.

Thank you for trying to help me, it’s appreciated.



You are always welcome! But i’m afraid that i’m not much of a help.

There are only two more things i currently can think of:

  1. Could you use a second system to verify that your disk hardware is ok (and probably do a partition setup with that machine)?
  2. Is your SSD an M.2 type SSD?
    If so, does your motherboard have any restrictions, when using M.2 SSDs (e.g. one of my motherboards disables two of its normal SATA ports when an M.2 SATA SSD is plugged and with M.2 PCIe SSDs it will only allow UEFI booting)?

Best regards


Great idea! I’ll try. The SSD is new, but I had the other HDD co my PC for data recovery and it was working fine. I’ll post result, once I test it.

No. It’s Kingston SSDNow V300 60GB, 2.5", SATA.

I removed the SSD and connected it to my PC, partitioned & formatted the partitions - worked like a charm!!
I removed the HDD and connected it to my PC, partitioned & formatted the partitions - worked like a charm!!

My PC is OpenSUSE 13.2, I used Yast tool for partitioning. I used the same power and SATA cables.

Now I’m about to put the drives back into the incident PC and I will try to run OpenSuSE installer without modifiying partitions and filesystems…

Sounds great!

Did you connect the drives direct to the motherboard (drive - SATA cable - motherboard) or where there any converters (e.g. SATA/USB) involved? The latter could cause funny results as well. Lately i saw some related posts here in the forum.

Good luck and best regards


OK, so after I returned SSD and HDD back into the incident PC and started installation, it proceeded fine. With one exception - the SSD is not bootable, so system won’t start until I pick the drive in F12 boot menu. But I believe I will be able to fix it by removing the drive temporarilly again and setting a boot flag from within my PC.

At all times, only direct connection from MB to drives with a single SATA cable was used.

Thank you very much susejunky, I resolved the issue thanks to the great help you provided!