When I searched the internet for solutions to the error mentioned above, the solution was always to do something with the fstab file. However, when I ran the command cat /etc/fstab nothing was displayed.
just to make sure, you are running this command in a terminal / console ? Right ?
yes, from the emergency shell
If it is the emergency shell then likely you are still only in the very limited environment that the initrd (the initial ramdisk) provides.
The /etc/fstab there is empty and that is normal.
You need to mount the disk where your / filesystem resides to get to your /etc/fstab
Or:
boot a live system and access the /etc/fstab of your system that way - it’s probably easier.
So your actual issue is that you can’t boot.
Well this is concerning. One should usually at least have the default mounts in there put at installation.
And since it is a blocking error, preventing you from booting, that mount configuration is likely not a systemd mount, but indeed a fstab one.
I would rather question whether you are checking the right place…
1 Like
Well, the whole story behind this is that I had an error screen (“Oh no… Something has gone wrong”) and reinstalled manjaro. The new system worked but I wanted to restore all of my data etc. from a backup (2 Days old) on an external drive using timeshift. After I did that, the OS was not even recognized by my UEFI any more. I reinstalled grub from a live system. But this completely messed up everything. In this GRUB config file you can access from the GRUB menu, I needed to change hd0,msdos1 to hd0,gpt2 And the UUID in the file is probably wrong too…
The command I used for the GRUB install was:
sudo grub-install --efi-directory=/mnt/temp/efi --root-directory=/mnt/temp/root /dev/sda
I created the efi and root directory before and mounted /dev/sda1 to the efi directory and /dev/sda2 to the root directory which seems fine (I checked before which was the efi and which was the root partition)
From what you describe and from how I understand it,
it’s best to reinstall once again.
And after that, restore just your personal data to your $HOME directory
if you have this in your timeshift backup.
What I know of timeshift is:
it is intended to backup your system files - so you could restore a defunct system
to a previous working state.
Not so much your personal files - but this might work too.
What likely happened is:
when you restored your timeshift backup to the freshly installed system
critical things got overwritten with what was essentially the old system - and the mix of old and new didn’t function.
Back up your personal data
and after the reinstall
make sure the system works
then restore just that, your personal data - don’t replace the freshly installed system files with older ones from a timeshift backup.
That depends on the partition type uuids.
Using EFI it is possible to boot a system without any mounts in fstab.
The error of UUID not found can be caused by changing the partition layout e.g. splitting or merging partitions.
Such action - behind the scenes - is deleting one or more partitions and recreate a new layout which will change the partition uuid.
1 Like