I have an encrypted secondary drive for storage in my machine that I have been using in this setup for over a year without issue. I made an ownership change trying to fix a permissions issue for a NAS shared folder…
sudo chown -R myuser:myuser /mnt/SF
I then attempted to log off the user session but my machine got stuck so after waiting, I did a hard reboot.
I then encountered the following error that stopped my system from booting…
[FAILED] Failed to mount /media/ssd
[DEPEND] Dependency failed for Local File Systems.
I was able to login to the command line with my root password, and amend my fstab to comment out the line causing the error, the last line…
file system mount point type options dump pass
UUID=4824-2933 /boot/efi vfat umask=0077 0 2
/dev/mapper/luks-bc99384c-29c6-556d-9f19-97d92b0b883a / ext4 defaults,noatime 0 1
/dev/mapper/luks-4ea2cd3f-8824-23d9-a1a4-cb6b74c02144 /media/ssd ext4 rw,user,exec 0 0
I was then able to reboot and log into the KDE desktop. In the file explorer, Dolphin, the secondary drive appears under Devices but when I click it I get this error…
An error occurred while accessing ‘ssd’, the system responded: The requested operation has failed: Error mounting /dev/dm-1 at /run/media/myuser/ssd: can’t read superblock on /dev/mapper/luks-4ea2cd3f-8824-23d9-a1a4-cb6b74c02144
I didn’t knowingly make any changes to the encrypted drive so I don’t understand why it stopped mounting.
- Make a full copy as is of
sdd onto another drive to ensure that if anyone asks you to do anything you can still revert the change.
- What’s the output of the following commands running as
smartctrl --all /dev/sdd
(I’m on shaky waters here as I know a lot about disks and superblocks but don’t do full drive encryption. *I sincerely hope you have an unencrypted backup of your drive!)
Can you “manually” open the container?
to find out which disk and partition it is
this here is for my encrypted disk, which
lsblk shows as
/dev/sdb1 when I plug it in:
sudo cryptsetup open /dev/sdb1 mydisk
It should ask for the password and then open the container.
Then you should be able to run
e2fsck on the filesystem within it:
sudo e2fsck -v /dev/mapper/mydisk
afterwards, close the container:
sudo cryptsetup close mydisk
and if you then can mount it:
(first open the container again)
sudo mount /dev/mapper/mydisk /mnt
tune the filesystem, so it will be force checked every 10 mounts:
(this feature is disabled by default)
sudo tune2fs -c 10 /dev/mapper/mydisk
unmount and close the container
I forgot that before the issue started, I tried to log out of my user session which resulted in a black screen and seemed to be stuck. I waited a while and then did a hard reboot. I presume I interrupted a process that caused the issue. I have edited the original post accordingly.
To fix the issue, I went into the KDE Partition Manager GUI, selected the device, right clicked on the partition, and ran the Check process And that fixed the issue!
This is the output I received:
Check and repair partition ‘/dev/sda1’ (931.51 GiB, ext4)
Job: Check file system on partition ‘/dev/sda1’
Command: e2fsck -f -y -v /dev/mapper/luks-4ea2cd3f-8824-23d9-a1a4-cb6b74c02144
e2fsck 1.45.6 (20-Mar-2020)
SSD: recovering journal
JBD2: Invalid checksum recovering block 60293235 in log
Journal checksum error found in SSD
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: +26705922 +26705924 +(26705926--26705927) [... I have omitted a large amount of text here]
>SSD: ***** FILE SYSTEM WAS MODIFIED *****
102214 inodes used (0.17%, out of 61054976)
1303 non-contiguous files (1.3%)
70 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 101646/538
43977913 blocks used (18.01%, out of 244189696)
0 bad blocks
2 large files
80773 regular files
0 character device files
0 block device files
35 symbolic links (22 fast symbolic links)
Check file system on partition ‘/dev/sda1’: Success
Job: Maximise file system on ‘/dev/sda1’ to fill the partition
The file system on partition ‘/dev/sda1’ already has the requested length of 1,953,521,664 sectors.
Maximise file system on ‘/dev/sda1’ to fill the partition: Success
Check and repair partition ‘/dev/sda1’ (931.51 GiB, ext4): Success
The first command worked.
The second command…
smartctrl --all /dev/sdd
… did not work. I get a command not found message back.
It works now, no need to provide more information.
fsck is what i was going to have you run first anyway and it fixed the issue…
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.