Re: help requested for mdadm grow error

[antlists <antlists@youngman.org.uk>]

On 26/05/2020 00:31, Thomas Grawert wrote:
> ok, maybe it´s getting out of scope now. If so, please let me know...
> 
> md0 is clean and running. no active resync.  I just tried to mount the 
> filesystem to check if everything is fine and to proceed with growing... 
> thanks god, I did it this way because:
> 
> root@nas:~# mount /dev/md0 /mnt
> mount: /mnt: wrong fs type, bad option, bad superblock on /dev/md0, 
> missing codepage or helper program, or other error.
> 
> root@nas:~# df -h
> Filesystem    Größe Benutzt Verf. Verw% Eingehängt auf
> udev             16G       0   16G    0% /dev
> tmpfs           3,1G     11M  3,1G    1% /run
> /dev/sdg2       203G    7,2G  186G    4% /
> tmpfs            16G       0   16G    0% /dev/shm
> tmpfs           5,0M    4,0K  5,0M    1% /run/lock
> tmpfs            16G       0   16G    0% /sys/fs/cgroup
> /dev/sdg1       511M    5,2M  506M    1% /boot/efi
> tmpfs           3,1G       0  3,1G    0% /run/user/0
> root@nas:~# fsck /dev/md0
> fsck from util-linux 2.33.1
> e2fsck 1.44.5 (15-Dec-2018)
> ext2fs_open2: Ungültige magische Zahl im Superblock
> fsck.ext2: Superblock ungültig, Datensicherungs-Blöcke werden versucht ...
> fsck.ext2: Ungültige magische Zahl im Superblock beim Versuch, /dev/md0 
> zu öffnen
> 
> Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
> Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
> Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
> beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
> zu starten:
>      e2fsck -b 8193 <Gerät>
>   oder
>      e2fsck -b 32768 <Gerät>
> 
> In /dev/md0 wurde eine gpt-Partitionstabelle gefunden
> 
> =========================================
> 
> For those who not understand German:
> ext2fs_open2: Invalid magical number in superblock
> fsck.ext2: Superblock invalid. Backup-blocks are tried...
> fsck.ext2:  Invalid magical number in superblock when trying to open 
> /dev/md0
> 
> Found a gpt-partition-table at /dev/md0
> 
> =========================================
> 
> there should be a valid ext4 filesystem...
> 
Oh help ...

Hopefully all that's happened is that something has written a GPT and 
that's it. Unfortunately, that seems painfully common - rogue tools 
format disks when they shouldn't ... I just hope it's not the Debian 
upgrade that did it.

So we should hopefully just be able to recover the filesystem, except I 
don't know how.

Did you actually try the e2fsck with the alternate superblocks? That's 
the limit of what I can suggest. I don't think e2fsck will try them for 
you - you have to explicitly tell it.

Just test it by using the "don't write anything" option, whatever that 
is? If that then doesn't report many errors, it looks like we may have 
our filesystem back - cross fingers ...

Cheers,
Wol