Parted deleted the wrong partition!

Using Rocky 8.5 parted in emergency mode, it somehow deleted the wrong partition.

I used grub menu edit to log in using single user emergency node to make sure nothing was mounted on any of the devices I was working on.

Connect to parted interactive and issue ‘print’ to ensure it’s the correct device, the only connected device which has an MBR partition table. This device is not used for booting or o/s.

parted /dev/sda

looks good, correct device
rm 3
p3 has gone, we see free space at end as expected
rm 2
p2 has gone, we see free space increase at end
looks good, still using /dev/sda
rm 1
it’s deleted p1 from /dev/sdb, instead of from /dev/sda!

I thought using interactive mode would be safer; the p1 partition deleted from /dev/sdb contained an LVM setup. It didn’t just delete the partition, it also trahsed the GPT partition table and started reporting it as MBR.

I tried to use parted rescue on /dev/sdb to recover the deleted p1 partition on sdb, but it didn’t work; it treated it as an MBR disk instead of a GPT disk.

In the end, I was able to recover the lost p1 partition on sdb using gdisk, which correctly found a backup copy of the GPT and restored it.

So I thought from the RHEL 8 docs that parted was the correct tool to use, even for GPT disks, but now I don’t know; I’ll probably switch to using gdisk…

I’ve used ‘fdisk’ for MBR and ‘gdisk’ for GPT. The fdisk might now support GPT, but I’m not that daring. Parted … I’ve seen that name, but probably skipped the docs.

This guide for RHEL is almost identical to what I did

and the following page covers deleting a partition.

This is tagged as RHEL7, but it’s very similar to RHEL8.

The device I was working on, /dev/sda was an MBR device

I’m curious why you wouldn’t use a graphical tool like gparted. It is available in the Rocky repos. My biggest fears when editing disks is the potential for typos. I’ve used the command line tools mostly for gathering information or backing up the mbr. I’ve used gdisk to convert a msdos disk to gpt and that worked without issue.

Hehehehe. Yea. I’ve been there… more than once… unfortunately. One of the best disk utilities EVERYONE should have in their kit is something called KNOPPIX (now version 9.1). It can be installed as a stand alone OS, or used to pull your @$$ out of the fire. It has quite a few disk utilities on it including GParted. If something goes south the first thing I do is pull out my handy dandy copy of KNOPPIX, as that will allow me to see if something like I have a missing partition, a missing file name, etc., It also allows me to scrub a drive to be entirely unallocated space to do a fresh install. Recently – as within the past week – I’ve added CLONEZILLA to my magic bag of tricks, and two CLI tricks run from Konsole under KNOPPIX:

smartctl -H /dev/[drive] which tests the health of a drive


badblocks -v /dev/[drive] to see if you have any bad blocks

I think now I am going to go looking for a copy of “gdisk” to add to my bag of tricks.


Linux Mint apparently has or had a utility called USB Stick Formatter, whose only purpose is to do just what it says. It will format a usb flash drive and that’s all it does.


I’ve never used it myself (never used Linux Mint either) but I’ve always thought that this would be a wonderful utility to have available on RHEL and (now) Rocky, since it apparently avoids any chance of screwing up and accidentally formatting the wrong thing. I use Gnome Disks for that task and I’m always terrified of unintentionally doing something that I didn’t really want to do.

1 Like

For this kind og accidents you should try systemrescuecd which comes in a bootable iso file you can burn on a cd or an USB stick.
It saved my life a lot of times.

Just to clarify, there were no accidents and no mistyping. The original post clearly shows the commands that were entered, and it was using parted interactive mode.

OK just let’s assume there were no pebcak. Just parted went wrong.

If it’s true that it went wrong and his isn’t an example of PIBKAC, then definitely it would be a good idea to get a bug report into the parted project Parted - GNU Project - Free Software Foundation which would get more knowledgable support to this.

What’s wanted is to get the same situation and try to get the same problem to happen again. If we had to reproduce the exact situation I’d suggest:

  • check the documents carefully and make sure we understand this
  • take a backup as normal to be sure
  • make an identical clone of the entire disk onto a second disk
  • boot from that second disk if possible (otherwise try reproducing elsewhere?)
  • use the same commands and see if the same problem happens

A good shortcut could be to try to create a virtual machine or a cloud machine which has a similar disk layout and try to get the same problem to happen there. Of course, with a different setup there’s no guarantee that the problem also occurs but it would make it easier for others to debug if it did.

Reproducing this in a meaningful way would require duplicate hardware, which isn’t practical. As parted is used over many years by thousands of people, it seems unlikely something this serious could be normal. The other considersation is the kernel, where it goes out-of-sync with parted, and may need ‘partx’ or ‘partprobe’.