The KDE problem from some time ago seems to have been solved,
but at least in my case I have a problem now:
I formatted and mounted a large drive (10tb, enterprise, info in following link) all thanks to the great guide and work the users of this forum provided me, and all future people who may need so.
My problem now is:
This drive, and this drive alone, doesn’t mount at boot anymore.
Another (the 4tb one you can see from the link) is Ext4 too and I followed the same exact guide after KDE_P_M started working again to mount it at boot without password. It just works.
Altho not only the 10tb drive doesn’t mount at boot anymore, it also gives this error if you try to mount it from the Drives List (error visible if done in Dolphin, just an [ X ] if done from the bottom-right of the screen):
.
Could someboy guide me into fixing this?
I can still mount from KDE_P_M, but you know… I want it on at boot…
That is a confusing error message. It mentions both /dev/sda1 and /dev/sdc1 at the same time.
I guess it is trying to mount multiple devices at once?
In any case, you will probably have to use the command line to get better details about what has gone wrong.
I’d start by leaving sudo journalctl -f running in a terminal window while attempting whatever is failing. It should print more information about what is failing. Hopefully there will be enough info in the error message to figure out what needs to be fixed.
I both cleaned my computer and upgraded the PSU (because I need to get more stuff in my PC).
I know for a fact that I changed the Sata Data ports to which my HDDs are connected (not the Nvme and not Fedora KDE’s boot SSD).
Could it just be that “it got confused” (you told me that sdX addresses are dynamic)?
Yes. If you used sdX addresses in /etc/fstab and that is what KDE Partition Manager is referencing, that might well cause that sort of confusion.
Personally, I like to set a custom label on my partitions and then use PARTLABEL="<my-custom-label>" in place of /dev/sdX in /etc/fstab. But most people use the UUID.
If you modify /etc/fstab, you’ll need to run sudo systemctl daemon-reload to get the OS to register the change (or reboot).
Ok, I’d say that PARTLABEL="<my-custom-label>" can wait another day, but what does sudo systemctl daemon-reload do?
[Additional context: I barely remember if I re-selected a mounting point for the 10tb (if I had to re-set it or if it wasn’t changed/deleted), but would it just be fixed if I were to create a new mounting point and put it there?]
sudo systemctl daemon-reload essentially tells the OS that you have changed some of the configuration files (e.g. /etc/fstab) and that it should now re-read them to get the updated settings. If you don’t change a config file like /etc/fstab, that command won’t do anything.
Maybe. It depends on what exactly you have in /etc/fstab that might be wrong. If you have “nofail” set as an option for the bad entry, then it might just ignore that bad entry and continue. If you don’t, your PC might hang the next time you boot the system because it cannot find the drive.
So:
I’ve first tried out sudo systemctl daemon-reload , which doesn’t seem to have done anything (even after reboot, the 10tb changed from what was sdc before to sda now even before using the command). I do not know what the computer was trying to do, but it seems that it was trying to address 10tb both with its old and new sdX address…
So, I’ve created a new mount point and addressed it as 10tb’s new Mount. After a system reboot it now just mounts.
.
I would have tried it on my own, but it’s good to first ask with more knowledgeable people.
How did the say go? “If you ask you are stupid for a minute, if you don’t ask you are stupid forever”?
Better to ask than to nuke my HDD.
.
.
.
As a closure, speaking about nuking data:
Sata (Data) drives are hotswappable, meaning that they can be plugged in and out dynamically, but when I did so with my Windows 10 Backupping Computer I first had the 2tb drive on “the Sata Data cable” (copying off its files in the backup) and then plugged in, on the same Sata Data, the 4tb one.
It seems that Windows 10 got confused, corrupted the 4tb’s data and tried to write upon it 2tb’s folders.
It’s all good, I already had MANY separate backups of all that was important (only lost some games from Steam, no biggie ) but it was still a bother as HDD average speeds are 120-140Mb/s.
Wanted to share it here, because it should be shared somewhere, and this seems like a pertinent place (now 4tb is an Ext4 drive, mounting on boot in Fedora KDE).
Linux is clever enough not to assign a device path “over” an existing device path that hasn’t been properly disconnected.
Yes, SATA ports should be hot-pluggable, but it might depend on the controller.
While the ext4 filesystem uses a journal, so that the files should not become corrupt in the event of a sudden loss of power/connectivity, it is still possible for some of the data/changes to be in RAM and not “flushed” to the disk when you yank the cord. Ergo, it is always advisable to unmount your filesystem before disconnecting your drive (even if it is a USB drive).
ext4 enables write barriers by default. It ensures that file system metadata is correctly written and ordered on disk, even when write caches lose power.
) but it was still a bother as HDD average speeds are 120-140Mb/s.