I was trying to resize my partition with parted and resize2fs.

I tried the following:

Partition Table: msdos
Number  Start   End     Size    Type     File system     Flags
 1      2097kB  21.0GB  21.0GB  primary  ext4            boot
 2      21.0GB  500GB   479GB   primary  ext4
 3      500GB   500GB   536MB   primary  linux-swap(v1)

(parted) rm 2
(parted) mkpart
Partition type?  primary/extended? primary
File system type?  [ext2]? ext4
Start? 41GB
End? 500GB
(parted) q
Information: You may need to update /etc/fstab.

#resize2fs /dev/sda2
resize2fs 1.42.5 (29-Jul-2012)
resize2fs: Bad magic number in super-block while trying to open /dev/sda2
Couldn't find valid filesystem superblock.

Unfortunately I can't understand why this doesn't work. It was an ext4 partition. I would like to resize the partition without loss of data.

fdisk list before operation:
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        4096    40962047    20478976   83  Linux
/dev/sda2        40962048   975718399   467378176   83  Linux
/dev/sda3       975718400   976764927      523264   82  Linux swap / Solaris

Now fdisk shows:
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        4096    40962047    20478976   83  Linux
/dev/sda2        80078848   975718399   447819776   83  Linux
/dev/sda3       975718400   976764927      523264   82  Linux swap / Solaris
  • 1
    excuse me didn't you forget to create the file system on the new partittion: mkfs.ext4 /dev/sda2 and then try resizing, i am sure it will work – Baroudi Safwen Jun 28 '15 at 19:50
  • Could you elaborate? Wouldnt running mkfs.ext4 destroy the current data? – Joel G Mathew Jun 29 '15 at 2:00
  • 1
    yeah but unfortunately you lost your data the minute you typed rm 2. it is not possible to resize a partition that has no filesystem like the partition you are trying to resize, you are getting the error bad magic number because resiserfx could not find the superblocks. – Baroudi Safwen Jun 29 '15 at 12:48

First, I'd like to be very clear on an important distinction:

  • Partitions are simply pointers to where filesystems begin and end. On modern disks, these start and end points are expressed as sector values.
  • Filesystems are complex data structures that reside within partitions (or other containers). Typically, filesystems are defined relative to the start point of the containing partition.

Your /dev/sda2 used to begin at sector 40,962,048. You changed it so that it now begins at sector 80,078,848. Thus, the critical early parts of the filesystem now begin outside the partition. An analogy might be if you somehow moved the front cover of a reference book, sitting flat on a table, a centimeter or so down without moving any of the pages of the book. When you opened the book, you'd find that the table of contents was missing, along with the first chapter or two. Those pages would now be floating freely, extracted from the book. You'd therefore be unable to find anything in the book except by reading the whole thing -- and even then, parts of it would be missing.

Generally speaking, any partitioning operation that involves moving or resizing the start of a partition is best done using GParted, which knows the proper order of operations for moving and resizing partition and filesystem data structures to keep everything working properly. Even GParted is not without its risks when resizing partitions, though -- especially not when the start point is involved, since this requires moving significant amounts of data, so a bug, power failure, hardware fault, or other problem can end up trashing the whole partition. If you must do it without GParted, you can, but you have to fully understand the distinction between a partition and a filesystem that I've outlined, and understand the implications of this distinction for the order in which you perform various operations (resize filesystem, move filesystem, change partition boundaries).

In your specific case, what I recommend is:

  1. Delete your new /dev/sda2.
  2. Re-create your /dev/sda2 using its original start and end sector values. Be sure these are exactly the same as they were before.
  3. Check that the re-created /dev/sda2 is accessible.
  4. Back up your important data from /dev/sda2.
  5. Re-evaluate whether you really need to move the start of the partition. I don't know what your ultimate goal is, so I can't do this for you. Perhaps moving the end point would work as well (and that would be safer); or maybe adding another disk would be a better option; or maybe you don't really need to repartition at all.
  6. If you must repartition the disk, use GParted to do the job.
  • The problem is that this is a lowend dedicated server, and running gparted gui is not possible (I wouldnt want to have to install Gnome and VNC just for the sake of partitioning.). Isn't "resizing" possible from the command line rescue mode? – Joel G Mathew Jun 29 '15 at 1:59
  • As I said, it is possible, but it's risky and requires expertise. If you're currently booted from the partition you want to move and resize, forget it; AFAIK, it can't be done safely. Since you pretty much must boot something else, then, you might as well boot a utility with a GUI and run GParted. If you're not booted from the partition you want to move, see this. In the future, LVM is much more flexible if you need to do such things. – Rod Smith Jun 29 '15 at 13:14
  • How about mounting the root read-only, dd'ing the whole disk over the network and then practice using loopback device using ` sudo losetup -Pf [imagefile]`? Then you could even try running the image as a virtual machine harddrive to see if all went well – twicejr Feb 12 '17 at 8:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.