The symptoms:
I cannot boot anymore into my Xubuntu 22.04 Linux machine, and here's what happened:
At some point my home directory filesystem went into read-only (most likely as a protective measure, from what I can gather). I then rebooted, thinking it was a one-time glitch, but that is not the case: It failed to boot with journaling errors on my /dev/sdb disk (which is where I have stored my home directory, separate from the OS which is on /dev/sda).
I am able to reboot into my installation USB, and mount both /dev/sda and /dev/sdb. When running fsck, it errors out with:
# fsck /dev/sdb
fsck from util-linux 2.37.2
e2fsck 1.46.5 (30-Dec-2021)
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/sdb
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>
Found a gpt partition table in /dev/sdb
I've since backed up my home directory on that drive back to /dev/sda which seems to be working, although with errors transferring some files that I can recreate.
The question:
I'm thinking about trying to repair the /dev/sdb drive using these instructions:
https://askubuntu.com/a/1335193/340383
But it scared me away with this sentence which gave no explanation as to why:
Note: do NOT bad block a SSD
So, in that answer, they mentioned running:
sudo e2fsck -fccky /dev/sdXX # non-destructive read/write test (recommended)
where, in my case, I speculate would need to be:
sudo e2fsck -fccky /dev/sdb1
Is that going to harm my ability to repair this issue with /dev/sdb, or is it is harmless and a true non-destructive test?
Given the answer here:
https://askubuntu.com/a/1233241/340383
and the OP's question where they implied they succeeded in using e2fsck, I'm concluding it is safe to proceed. Is it?
Sub-question:
Also, I do not know what this part of the output of fsck
is trying to communicate:
Found a gpt partition table in /dev/sdb
Is that telling me that I'm running fsck
incorrectly? I don't want to follow that advice in the output by trying different superblocks until I confirm that this is not just my own user-error.
2023-07-02 09:08:57: Running sudo e2fsck -C0 -p -f -v /dev/sdb1
At comment, I followed the advice of Ubuntu 14.04 is not booting normaly after a manual hard boot via (this was after a unmounting of /dev/sda* and /dev/sdb* drives):
sudo e2fsck -C0 -p -f -v /dev/sdb1
And got:
Inode898044343 extent tree (at level 2) could be narrower. IGNORED.0.1%
DRIVE8: Inode 103942010 extent tree (at level 2) could be narrower. IGNORED.
DRIVE8: Inode 103942011 extent tree (at level 2) could be narrower. IGNORED.
... <snip mostly duplicate types of output lines here> ...
DRIVE8: Inode 103942324 extent tree (at level 1) could be narrower. IGNORED.
Inodes:that=were=part=of=a=corrupted=orphan linked list found. / 59.7%
DRIVE8: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)