1
user@localhost:$ LC_ALL=C sudo fdisk -l

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! 
The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 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: 0xe4948bbb

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1  1953525167   976762583+  ee  GPT
Partition 1 does not start on physical sector boundary.

trying to dumpe2fs my /dev/sda1 :

sudo dumpe2fs /dev/sda1 | grep -i superblock

dumpe2fs: Ongeldig magisch getal in superblok tijdens openen van /dev/sda1

[ dumpe2fs: magic number not valid during opening /dev/sda1 ]

How can I repair my superblocks ?

pbhj
  • 3,231
Mokum
  • 336
  • I found this helpfull question;http://askubuntu.com/questions/760584/dumpe2fs-not-finding-any-superblock – Mokum Jul 08 '16 at 08:42
  • but after doing ~umount /dev/sda1 and ~ sudo mkfs.ext4 -n /dev/sda1 I dont know how to proceed. Any suggestions are welcome – Mokum Jul 08 '16 at 08:47

2 Answers2

3

List backup superblocks:

sudo dumpe2fs /dev/sda1 | grep -i backup

then use backup superblock, 32768 just an example, try several

sudo fsck -b 32768 /dev/sda1

One user could not get partition unmounted (may have needed swapoff), but used another live distro

Only the newer fdisk in 16.04 will correctly show gpt partitions. Use parted or gdisk.

sudo parted /dev/sda unit s print

sudo gdisk -l /dev/sda
oldfred
  • 12,100
  • sudo fsck -b 24577 /dev/sda1 : shows no result but the man page of 'fsck' – Mokum Jul 08 '16 at 18:22
  • Only if you have tried everything Else. http://ubuntuforums.org/showthread.php?t=1681972&p=10434656#post10434656 – oldfred Jul 08 '16 at 18:57
1

I had a somewhat similar problem where my Ubuntu system would not boot (under a multi-boot scenario) and couldn't be mounted from a different Linux system. In a live session gparted reported bad superblock.

I have followed this solution here, but the first step was enough for me.

In a live environment (or in another Linux system) I did something like:

sudo fsck.ext4 -v /dev/sda6

Which gave this:

e2fsck 1.43.7 (16-Oct-2017)
ext2fs_open2: Superblock checksum does not match superblock
fsck.ext4: Superblock invalid, trying backup blocks...
/dev/sda6 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -3014664 -(3014811--3014813) -(3014840--3014850) -(3014950--3014960) -(3014962--3014965) -3014970 -3014972 -(3014974--3014976) -(3014979--3014980) -(3014983--3014987) -3015043 -(3015053--3015055) -3015089 -(3015105--3015106) -3015121 -(3015179--3015183) -3015208 -3015258 -3015364 -3015392 -(3015470--3015475) -3015489 -(3015536--3015538)
...etc

at which point I have selected "a" for "fix all" and got a lot of lines like these:

Directories count wrong for group #272 (0, counted=1544).
Fix? yes

Free inodes count wrong (2362853, counted=2128687).
Fix? yes

and in the end this

Block bitmap differences: Group 0 block bitmap does not match checksum.
FIXED.

/dev/sda6: ***** FILE SYSTEM WAS MODIFIED *****

      234177 inodes used (9.91%, out of 2362864)
         897 non-contiguous files (0.4%)
         165 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 210228/56
     5915339 blocks used (62.60%, out of 9449951)
           0 bad blocks
           1 large file

      189841 regular files
       19796 directories
           7 character device files
           0 block device files
           0 fifos
           0 links
       24521 symbolic links (23875 fast symbolic links)
           3 sockets
------------
      234168 files

Everything worked after that. But after booting in Windows 7 again I had to re-do the procedure.

Oddly, only Ubuntu 18.04 was affected, Solus was not.

The culprit in my case was the Windows program ext2fsd - as said here - and removing that fixed the problem completely.

  • Microsoft even says to avoid things like ext2fsd: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/ – K7AAY Jul 11 '18 at 17:36
  • 1
    @K7AAY - After having used it, I advise against it too :) –  Jul 12 '18 at 14:45