Good to hear of some progress.
It may be worth considering doing a file check which can correct errors in the filesystem. The
fsck command can be used as root or sudo, but it must be run on filesystems that are unmounted. A safe means of doing this is to run a live disk which normally won't have mounted any disks unless you instruct it. For such file checking here, we do it from live disks because it's safe. From the live disk run the following command to check whether the
fsck command can see any errors on the disk's partitions. It can be run for each ext4 partition on which there is data:
Code:
fsck -n /dev/<device-name-of-root-partition>
The partition device names can be discerned from the output of
lsblk as shown in post #10.
If errors are reported in the output of the above command, then to correct everything non-interactively, run as root or sudo for each partition that is shown to have errors:
Code:
fsck -y /dev/<device-name-of-any-partition>
As for the BIOS not seeing the SSD, that is unusual to say the least. The BIOS has to see the disk to hand it over to the bootloader. Perhaps check the manufacturer to see if there's a BIOS update.
Edit: In post #12 in the output of smartctl, there is a statistic of 80 unsafe shutdowns. An unsafe shutdown is like when the power goes off and the computer goes off suddenly with it, and the programs that are running don't have time to gracefully shutdown. Users can cause an unsafe shutdown by similar powering off without closing apps as they were intended to close. That sudden stoppage can affect the filesystem causing corruption, hence
fsck is worth running. Some systems will automatically run
fsck after an unsafe shutdown, but I can't say how your system runs.