You are not logged in.

#1 2021-04-02 00:55:50

juancuyo
Member
Registered: 2017-11-17
Posts: 35

crash SO

Good evening, the PC has had a very serious problem, I installed Bleachbit and when cleaning the system it crashed, after a while I restarted it but it was impossible to access the system attached screenshots, enter with the dvd that I installed in 2020 no Access the home volume, if you access the live system and also access the 30 GB system where the operating system is with the current kernel. How do I recover the operating system.
/home/user/IMG_20210401_193315.jpg
/home/user/IMG_20210401_193330.jpg
/home/user/IMG_20210401_205637.jpg
/home/user/IMG_20210401_210048.jpg
/home/user/IMG_20210401_193741.jpg

Offline

#2 2021-04-02 01:11:59

juancuyo
Member
Registered: 2017-11-17
Posts: 35

Re: crash SO

59GvBcv.jpg

Offline

#3 2021-04-02 01:14:48

juancuyo
Member
Registered: 2017-11-17
Posts: 35

Re: crash SO

AF1Mtx3.jpg
pNd8zYT.jpg

Offline

#4 2021-04-02 01:16:08

juancuyo
Member
Registered: 2017-11-17
Posts: 35

Re: crash SO

rFnHTz3.jpg
3Ts1nUZ.jpg

Offline

#5 2021-04-02 01:24:09

juancuyo
Member
Registered: 2017-11-17
Posts: 35

Re: crash SO

ldOx0Ef.jpg
I hope that with the screenshots you can guide me, I have many applications installed and pending OSM tasks with josm

Offline

#6 2021-04-02 10:00:44

twoion
ほやほや
Registered: 2015-08-10
Posts: 3,133

Re: crash SO

I suppose the complete error message is "found ext4 filesystem with invalid superblock checksum". This error causes the system to not touch the filesystem in order to not cause further damage.

As the error message indicates, the superblock is corrupted.

The good news is that ext4 is a filesystem that is easy to recover, supposing not much else is wrong.

ext4 stores additional backups of the primary superblock at physically spaced offsets in the filesystem. We'll first try to make e2fsck fix the filesystem as is, but if it fails to do so, we'll be using the backup superblock(s) instead of the corrupted one to restor order to the filesystem.

Boot the live CD. Locate the broken filesystems as block devices in /dev. For example, run lsblk, it'll print you a pretty tree that should make it easy to determine ther target filesystem. Going by the error message in the screenshot, it could be /dev/sda6.

If the data is really really important, you should connect an appropriately sized backup disk first and copy the entire disk to a file or partition on the target disk using dd or ddrescue. The steps below will modify the original data, and maybe make things worse, however unlikely that is.

Lastly, after booting the live system, check `sudo dmesg` for anything that looks like "I/O errors" related to the physical drive the partition is on. If there are I/O errors, chances are that the drive itself is in the process of failing. In that case, your first priority should be not recovery but copying all the data to a new drive.

Run

sudo e2fsck -n /dev/sda6

first. Observe if the output says something interesting. This will not change the filesystem in any way.

sudo e2fsck -p /dev/sda6

will get serious and will attempt to fix the filesystem. Observe if the program fails or completes successfully. If the program reports the filesystem is fixed, run e2fsck -p again to make sure the results are consistent.

If the e2fsck fails to fix the file system, run

sudo mke2fs -n /dev/sda6

on the UNMOUNTED FILE SYSTEM. DO NOT FORGET -n. It'll act as if the program would create a new file system but not actually write anything (a prerequisite for this to output accurate information is that the general parameters (blocksize etc) of the underlying filesystem are the same that mke2fs assumes, otherwise you need to add additional information to the mke2fs command (see man page). In most cases the default parameters should work though unless you handcrafted your filesystems). It'll output the locations of the backup superblocks like so

Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Take the first number, and run

sudo e2fsck -p -b 32768 /dev/sda6

again and see if the program can fix the filesystem. If not, try the next superblock by taking the next number, and so on. The larger the filesystem, the more backup superblocks there will be and the better the chance to find one that works.

If no way worked, your next step is using testdisk https://www.redhat.com/sysadmin/recover … s-testdisk. If that didn't yield any results either, you will be using photorec, which is the most messy approach; photorec will scan through the data that's left and try to determine file boundaries from leftover filesystem information and well-known file headers.

Ideally, you would in any case always operate while having a backup of the original data left. Just in case.

Before attempting any of the steps, please make yourself familiar with the tools you'll be using, the man pages are easy to read:

http://manpages.ubuntu.com/manpages/bio … sck.8.html

http://manpages.ubuntu.com/manpages/bio … 2fs.8.html

Good luck.


Music makes us braver

Online

#7 2021-04-02 11:40:37

eight.bit.al
Member
From: Prison
Registered: 2015-10-01
Posts: 889

Re: crash SO

^ Nice. This should be a sticky somewhere.

8bit


If art is how we decorate space, music is how we decorate time.

Online

#8 2021-04-02 13:08:31

sleekmason
zoom
From: Ozarks
Registered: 2018-05-22
Posts: 570
Website

Re: crash SO

Wow! Really good info.  Bookmarked.  ^ +1 on the sticky.

Offline

#9 2021-04-02 17:13:27

rbh
Member
From: Sweden/Vasterbotten/Rusfors
Registered: 2016-08-11
Posts: 973

Re: crash SO

Nice Howto, but:

twoion wrote:

If the data is really really important, you should connect an appropriately sized backup disk first and copy the entire disk to a file or partition on the target disk using dd or ddrescue.

Dd, should never bu used to copy faulty block devices!
Ddrescue is mor iuntelligent, copy good sectors first and save a list of bad sectors for later.
Dd is good for working with healthy block devices.


// Regards rbh

Offline

Board footer

Powered by FluxBB