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)
You do not run fsck on a drive like sdb, but on a partition that is ext4 formatted like sdb1
From working live Flash drive, so everything is un mounted,swap off if necessary, change example shown with partition sdb1 to your partition(s) To see all the ext4 partitions
sudo parted -l
e2fsck is used to check the ext2/ext3/ext4 family of file systems. -p trys fixes where response not required Run both commands as different parameters used. New NVMe drives will be like /dev/nvme0n1pY where pY is partition. Both SATA & NVMe shown as an example, mostly for others:
if errors: -y auto answers yes for fixes needing response, also see man e2fsck