kernel panic not syncing VFS unable to mount root fs on unknown-block(179,2)

Troubleshooting
#1

Hello guys,

After a recent up date and reboot, my system fails to boot up and I have been getting the following,

kernel panic not syncing vfs unable to mount root fs on unknown-block (179,2)

This is my File and VPN server that took me ages to setup and I have many active user, obviously reinstalling is not and option and therefor before I get my hands on it I’d like to get some advice here. I would be very grateful for any help and tips.

Please see the attached photo from the system on boot up. By the way the Dietpi is installed on a ASUS Tinker Board.

Thanks

IMG_3010.JPG
IMG_3010.JPG3024×4030 3.31 MB

#2

Hi,

I hope you have a backup done, before executing an update, if it is such an important system?

Do you have another Linux box where you could connect the SD card to perform some file system checks?

#3

Hi, I might have some backup done in past, cannot remember where they are thought! No backup done recently :roll_eyes:
Yes I do have another system in my network running Dietpi on it, if necessary I’l willing go further and install any OS on that system.

Thanks

#4

so I connected the SD to system to do some basic file system check and results are below,

root@DietPi:/mnt/sda1# sudo fsck.ext4 /dev/sda1
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks…
fsck.ext4: Bad magic number in super-block while trying to open /dev/sda1

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
or
e2fsck -b 32768

/dev/sda1 contains a vfat file system
root@DietPi:/mnt/sda1#

AND…


root@DietPi:/mnt/sda1# sudo fsck.ext4 /dev/sda2
e2fsck 1.44.5 (15-Dec-2018)
/dev/sda2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway? yes
fsck.ext4: Input/output error while recovering journal of /dev/sda2
fsck.ext4: unable to set superblock flags on /dev/sda2


/dev/sda2: ********** WARNING: Filesystem still has errors **********

root@DietPi:/mnt/sda1#

#5

I guess sda1 is a fat partition. Therefore can you try following

dosfsck /dev/sda1

MichaIng
Can you have a look. You are more the file system specialist

#6

Sorry my mistake, tried that, now I am able to mount sda1 its vfat but still unable to mount sda2 which is ext4

#7

The ext4 partition also still has errors. It seems like the superblock is damaged. Let’s see where the backup superblocks are:

mkfs.ext4 -n -m 0 /dev/sda2
#8

Hi,
Here is the results,

root@DietPi:~# mkfs.ext4 -n -m 0 /dev/sda2
mke2fs 1.44.5 (15-Dec-2018)
/dev/sda2 contains a ext4 file system
last mounted on / on Fri Jan 18 08:50:17 2013
Proceed anyway? (y,N) y
Creating filesystem with 7774336 4k blocks and 1945888 inodes
Filesystem UUID: e0773760-1e29-45df-859a-c6b8b9739694
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000

root@DietPi:~#

#9

Update!

0B4675DF-CA9A-4423-B5D5-A467AAD555D4.jpeg
0B4675DF-CA9A-4423-B5D5-A467AAD555D4.jpeg1242×1366 134 KB

#10

That command did nothing but printing what mkfs would have done (-n as noop), including especially the superblock backup locations, we wanted to know.

Let’s try to recover the superblock with the first backup:

fsck -b 32768 /dev/sda2

If this does not work, try with the second:

fsck -b 98304 /dev/sda2

etc, until one succeeded to allow fsck actually repairing the filesystem.