If the issue remains the same as at 1st post, then remove the swap partition entry from the fstab file.
The swap entry is optional in fstab, when the drive is GPT.
I removed the line.
Issue persists.
It is impossible. Review what you have done and post here.
If there is no entry for the UUID in the error message, there is no reason the message being the same and boot stalls.
One word answers is not adequate communication, when you ask for assistance for your own PC.
I could answer:
Cool! I am at beach, bro!
This is the message that stalls:
This is the fstab file and ls -l /dev/disk/by-uuid:
Strange isn’t it?
did you change something in your kernel parameters?
The following looks suspicious to me:
a6cd5bdce6df rw nowatchdog nvme_load=YES resume=UUID=4dc57a11-b514-46bc-8aca-d6137421c7a8 loglevel=3
Jul 06 22:48:52 vadym-swiftsf31442 kernel: Unknown kernel command line parameters "BOOT_IMAGE=/boot/vmlinuz-linux nvme_load=YES", will be passed to user space.
that’s from the boot logs and there you can find the uuid that you can’t assign.
3 Likes
I don’t think I touched anything I just restored the backup. How do I fix this?
best explain how you restored your backup and why. maybe it’s easier to undo than looking for a needle in a haystack 
Here is what happened:
I had a working system
Then I did a backup of the EFI and root partitions using Redo Rescue software
Then I restored a backup made by the Macrium Reflect software
Then I did a backup of the system in that state using the Clonezilla software
Then I restored the Redo Rescue backup
Now the issue appears
I don’t want to explain the reason why I did this because that would be a long story
Here are the details how I restored the Redo Rescue backup:
- I booted up Redo Rescue software
- I clicked restore
- I selected the source and the taget
- I confirmed that the data will be overwritten
- I waited
- The backup was restored
This might help:
On the boot menu screen, choose the boot entry and press e. Navigate to the where the following is:
resume=UUID=4dc57a11-b514-46bc-8aca-d6137421c7a8
and delete it. Press Ctrl-x (if you use Grub) or just Enter (if you use systemd-boot). See if the system boots up normally.
Once you are in you will need to fix the issue from there.
4 Likes
I’M IN! I’M IN! How do I make the fix persistent?
You would need to tell us:
- Are you using grub or systemd-boot?
ls /efi
- Are you using mkinitcpio or dracut?
pacman -Q | grep -E 'dracut|mkinitcpio'
1 Like
- I’m using grub
- When I do ls /boot/ there is the grub folder
- ls /boot/efi reveals one folder: EFI
- I’m using dracut because it says dracut when I boot
Also help me with secure boot, I have secure boot off but it would be nice if you helped me make it work withe secure boot on.
- update your system
sudo pacman -Syu
- Rebuild your initrds:
sudo dracut-rebuild
- Edit
/etc/default/gruband remove
resume=UUID=4dc57a11-b514-46bc-8aca-d6137421c7a8
- Regenerate grub.cfg:
sudo grub-mkconfig -o /boot/grub/grub.cfg
3 Likes
Issue fixed
Can you show me some topics about secure boot? I want to enable secure boot on my system but if I enable it in BIOS it says “Secure Boot Fail”
Secure Boot is not implemented by Arch Linux on which EnOS is based.
It is subjected to much heated debates that pop up once in while.
Here is one recent example: Why doesn't EndeavourOS support Secure Boot out of the box?
Users could however implement it on their Arch systems but it involves some serious command line acrobatic. I wouldn’t dare myself!
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
PS. I would give the solution to @pycrk since they spotted the cause.
After that it was a smooth ride
2 Likes
fits as it is, the main thing is that the problem is solved and another user can sleep peacefully 
3 Likes
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.