0

Background

Had a Linux root ext4 partition that I needed more space; cleared it from my Windows install, and then modified the remaining stuff on KDE's partition manager on a live usb.

I'm not experienced at all in this partition management/fixing stuff, so there's a chance I may have done things I wasn't supposed to along the way.

Similar issue: Recovering ext4 superblocks

Partition structure before (what I remember)
|device|type              |
|------|------------------|
|sda1  | ESP Windows      |
|sda2  | MS Reserved      |
|sda3  | Win partition    | 
|sda4  | -(unallocated)-  |
|sda5  | ESP Linux        | *
|sda6  | Swap             | *
|sda7  | Solus Linux      | 
|sda8  | Win recovery env |

Steps before disaster

  • I deleted the partitions inbetween (represented by *) to enable the move, and got to extending Linux.
  • I moved part of the unallocated space to extend the partition
  • I made sure to leave no space left after the extended partition
  • It took a while and the resize was successful, but ended on an operation error from e2fsck: bad magic number[...]superblock invalid.

What I did

After the error, I searched and found through fdisk that somehow the partitions got misaligned, reporting "out of disk order" (sda7 appearing before sda4, that sort of thing); showing that some sectors were beginning and ending where they weren't supposed to.

  • Researched bad magic number and superblock error
  • Suggestion was to replace the magic number with the backups.
  • Tried all with e2fsck -b {number} /dev/sda7, but none worked.

I then shifted focus to try and realign the partitions, and found that fdisk itself does that, and it worked, placing the Linux partition in the correct place.

  • So the sectors are now correct. I checked the others before and after to make sure the realignment didn't affect anything else.

But I'm still stuck with a resized partition (linux root, ext4) that is not accessible (does not mount), showing up as an unknown filesystem type.

(Current outputs are at the bottom)

I'm guessing this all happened because resizing made the information about the partition (superblock) change and it didn't update correctly.



What can I do to recover?

  1. Can I rebuild the superblock information somehow?
  2. Backup the contents of the partition in any way before erasing to recreate it correctly? I've seen ddrescue in passing and it seems to be what I'm looking for
  3. What about testdisk? It looks promising, but too complex for me to understand atm. Some help here would be nice.

Any replies are very much appreciated.



Outputs

Partition structure after the realignment

# fdisk -l /dev/sda

Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors Disk model: ADATA SU650
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: 2268FBBE-207C-44A8-A784-28F30D837464

Device Start End Sectors Size Type /dev/sda1 2048 206847 204800 100M EFI System /dev/sda2 206848 239615 32768 16M Microsoft reserved /dev/sda3 239616 189430999 189191384 90.2G Microsoft basic data /dev/sda4 189431808 192237567 2805760 1.3G ## temporary fs to avoid mixing up /dev/sda5 192237568 233375743 41138176 19.6G Linux filesystem /dev/sda6 233375744 234438655 1062912 519M Windows recovery environment

(Yes I have very limited storage, no I don't currently have another option.)

Trying to mount the partition

# mount /dev/sda5 /target     
mount: /target: wrong fs type, bad option, bad superblock on /dev/sda5, missing codepage or helper program, or other error.

Bad magic number error:

# e2fsck -v /dev/sda5

e2fsck 1.45.6 (20-Mar-2020) ext2fs_open2: Bad magic number in super-block e2fsck: Superblock invalid, trying backup blocks... e2fsck: Bad magic number in super-block while trying to open /dev/sda5

The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device>

0 Answers0