First of all, thanks everyone for the amazing help.
I tried to turn on my PC today but it fails.
The one thing that I did yesterday that was different from the usual was that I took an old USB drive, repartitioned it, and used it to back up some files. I shut down the system properly but without disconnecting both external drives.
The reason I think this has something to do with it is that when the system boots it hangs at some point waiting for sdd1, which doesn’t make sense because the system is sda.
After it times out it sends me to the command prompt.
I’m attaching pictures of the boot screen, the command prompt, and dmesg.
Recent BIOS tend to try to be smarter than they’re capable of being. This can result in sda becoming something else if and when a USB device is attached. Moreover, they can remember what they shouldn’t, so that once sda is recognized as something else, it is remembered as something else, and/or boot priority is rearranged.
Being at a login prompt isn’t necessarily such a bad thing. You can login as root, then do some checking to find out what failed without having to hunt for and boot from rescue media. Maybe something you did during repartitioning and backup isn’t what you thought you were doing. Start by finding out what failed to mount, what sdd1 is (if it even exists), and why systemd thinks it is needed. Does
findmnt
output appear as expected? What’s missing? Maybe
blkid
or
lsblk -a
will provide a needed clue. Do
parted -l
and/or
fdisk -l
produce expected output?
journalctl -e
and
dmesg | less
provide ways to scan for error messages that represent clues to whatever has changed or isn’t happening.
Does /etc/fstab have an old timestamp, or a fresh one?
It looks like whatever that needs to be mounted is mounted (sda is the system). Also, it looks to me like it’s looking for that external drive (ssd), and I don’t know why. dmesg complains at the end about improper unmounting even though that was not the case.
I tried to start the computer with the external drives plugged in in the same ports as before to no avail.
Those commands were meant to be either perused by you, and/or shared as text, by redirecting output to files, then copying and pasting here or to http://susepaste.org, not screenshots. In particular, dmesg (without | less) and journalctl (without -e) output are far too long to fit on any single screen, and of little value as only a first or last screen from otherwise voluminous output.
it looks to me like it’s looking for that external drive (ssd), and I don’t know why.
/etc/fstab or the pieces of journal and dmesg not displayed might provide clues to that. If there’s a line in fstab that includes sdd1, commenting or removing it might result in an improved or normal boot.
You’re using XFS, BTRFS, LVM and encryption, each something I don’t use, and so cannot help with.
The journalctl output has its washout over a found /dev/ line that might explain sdd1.
Maybe a boot to Windows would check the sda1 filesystem that dmesg claims is needed, and could possibly change how 15.0 is trying to boot.
Sorry, I’m posting from my laptop as I could not figure out how to post here (access the internet) from the troubled machine.
You guys were right, fstab was the problem. The external drive (sdd) was appended to the file at the bottom and I commented it out. Now it boots without a problem.
I’m curious, though. Two drives were connected at shutdown: Same brand, model, size… completely identical, but only one was added to fstab, the one I formatted yesterday. Why would the system add it to fstab? What is the criteria? Something to do with GPT?
It was probably mounted at some point where a new initrd was generated, we’ve seen this reported before, though not often. Shouldn’t happen though. But good to hear it’s fixed.