Error: resume: hibernation device 'uuid=...' not found

Thank you, Petsam. I’ll copy files and remove them.
The question now is, what would cause hibernate to activate itself?

I commented out the resume parts of grub and grub.cfg, but I didn’t see resume in mkinitcpio.d. After executing grub-mkconfig -o /boot/grub/grub.cfg, on reboot the system was unbootable:

No device specified for hibernation
device 'UUID=uuid of boot disk' not found. Skipping fsck.
mount: /new root: can't find UUID=uuid of boot disk.
You are now being dropped into an emergency shell.
sh: can't access tty: job control turned off
[rootfs ]#

@lee, a suggestion.
Sometimes, it is just a simple fsck that’s needed.
fsck the partitions and try to boot.
caveat: sometimes it is, sometimes it is more serious.

Good luck.

Oh… removing ‘resume’ is in HOOKS line of /etc/mkinitcpio.conf
not mkinitcpio.d

4 Likes

Thank you gohlip.

Now the system does not boot at all, no hibernation device specified, and drops to an emergency shell.
I tried fsck from a Kubuntu install on the Manjaro ext4 drive, because of the scary waring of damage to the mounted file system, but no return value was shown.

fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
/dev/sdd4: clean, 831070/10903552 files, 16647391/43585280 blocks

Is there a way to root into the Manjaro install to rebuild grub again?

Check for a tutorial or manjaro wiki, you’ll find it.
If you are sure about you haven’t changed other than Xorg, then get prepared for disk rescue, backup your important data ASAP.
From another system check blkid lsblk and fstab again.
With chroot do an update, remove and reinstall video drivers with mhwd with the most successful choices (you can improve them after saving system stability) .
You may check previous boot logs from another system.
https://wiki.archlinux.org/index.php/Systemd#Specify_a_different_journal_to_view
Also check Xorg.0.log.old.

1 Like

Other than the chroot suggested by petsam above, you can try to boot using this method but instead of “grub> initrd /boot/initramfs-4.19-x86_64.img” in step 5. use fallback as in
“grub> initrd /boot/initramfs-4.19-x86_64-fallback.img” Oh use the right kernel that you have. and first boot to prompt (add ‘3’). I’ll rewrite step 5 below (use your right kernel, reminder).

grub> linux /boot/vmlinuz-4.19-x86_64 root=UUID=$abc rw 3
grub> initrd /boot/initramfs-4.19-x86_64-fallback.img
grub> boot

When/if booted to prompt, recheck your graphics (or undo your screen tearing).

Oh… you cannot fsck a mounted partition.
Good luck.

1 Like

Thank you for your suggestions.
I’ll deal with them one at a time. I just got the info for removing and installing graphics cards with mhwd.

For some reason after updating the system and grub via chroot (dealing with mhwd later), blkid now shows the Linux installations and swap on /dev/sdb_, but they were on /dev/sdd_. Maybe that is one reason why now grub cannot find the Manjaro partition at all on boot and drops to the useless shell. Maybe it’s not useless, but I can’t do anything with it.

I’ve just found another page on using mhwd-chroot and installing Grub rather than trying to just update it. I’ll give that a try before I mess with the graphics side of things.

I’m still confused as to why this whole hibernation thing appeared in the first place. Not only that, but why it only affected Xfce but not Lxde for the same user.

This is a clear sign that you have wrongfully edited appropriate system files!!
Please post

cat /etc/default/grub | grep CMDLINE
cat /etc/mkinitcpio.conf | grep -v ^#
2 Likes

Okay.
First of all, I uninstalled and reinstalled the graphics card with mhwd.

Requested outputs are:

[manjaro /]# cat /etc/default/grub | grep CMDLINE
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=fb45bd94-abdb-40be-a88a-0ca666ea48d9"
GRUB_CMDLINE_LINUX=""
[manjaro /]# cat /etc/mkinitcpio.conf | grep -v ^#
MODULES=""
BINARIES=""
FILES=""
HOOKS="base udev autodetect modconf block keyboard keymap resume filesystems fsck"
cat /etc/default/grub | grep UUID 
2 Likes

I always suggest this, even tho was argued to not be the case, to change to:

HOOKS="base udev resume autodetect modconf block keyboard keymap filesystems fsck"

then run:
sudo mkinitcpio -P
sudo update-grub

3 Likes

@lee
Is sdd a removable drive?
And it is msdos.
What is sda? Without os?
Any reason why sdd is not primary drive?
Also noted your windows 10 is uefi.
F8 to boot Windows or to boot Linux?
Lxde and xfce both in sdd?

Pretty creative set up.:grinning:

A suggestion, if we must have (not recommended) both uefi and bios-legacy boots, depending on the motherboard, have the default bootloader and booting default $esp on the first 2 internal sata drives, sata0 and sata1. Meaning not sdd or sdc but sda and sdb.
Even then the bios may not see the other external drives initially.
And swap be on these first 2 drives (sda or sdb) as well.

Having separate drives for separate OS’s is often recommended but IMO, I think that is a mistake.

ps: note you said sdd became sdc and vice versa.
Usually sda remains sda (not on old computers). The rest are interchangeable.

1 Like

Right! It’s working again.

Thank you for the further suggestions.

Working through things one step at a time, I tried fsck again, but it continued to do nothing to the filesystem. @gohlip, I wasn’t going to give up on that step. Further research revealed that Gparted has fsck built-in, so I ran that from LiveUSB, and it did make modifications. Hibernation errors stopped being returned, and I could then log into lxde but not Xfce.

The whole graphics card saga was the problem for Xfce. I unchecked ‘Force composition pipeline’ in the Nvidia-settings dialogue box, saved to the X config file, and rebooted, but the seemingly stalled log in persisted. I then opened /etc/X11/mhwd.d/nvidia.conf, which showed: Option "metamodes" "nvidia-auto-select +0+0 {ForceCompositionPipeline=On}". I commented that out and replaced it with the xorg.conf line, Option "metamodes" "nvidia-auto-select +0+0", rebooted and now everything is in order again.

Could the problem have been the difference between the xorg.conf and nvidia.conf files? Maybe Xfce only executes nvidia.conf, while lxde executes xorg.conf.

Blimey! I’ve learnt a lot of new procedures for fixing the system. Thank you very much.

Great! Good to hear!
I really don’t know if the xorg and nvidia files are the causes of the issue.
An I was wrong about sata0 and sata1 here too in your case.
(in my case, not being in sata0 and sata1 has issues for bios detecting booting drives)

Hope others here can explain more on the xorg and nvidia files for us.
Cheers.

1 Like
  • Yes, sdd is a USB external drive.

  • sda is another USB external drive that I use for data storage.

  • Yes, I F8 to boot. I wanted to keep Linux away from any Windows stuff. Previous experience led to Windows messing up grub or grub messing up MBR, so I avoided that. When I installed the system, there seemed to be a fair few more steps in set up to go through for UEFI, and I suppose then, I was afraid of it.

  • Yes, Lxde and Xfce on sdd. I did have them for separate users, but accidentally logged in to lxde as my main user once, so no I have it there as a fallback in case things go wrong, like a few days ago.

  • Windows 7 on sdb is only used for storage not Windows, any Windows system files were deleted a long time ago.

Again, unsure if it applies to your case - in my case, the bios has difficulty detecting a usb3 external drive (not to a usb2 usb stick) when starting up. Rebooting computer usually gets it to find the drive. So I have to check at grub prompt with ‘ls’; if drive not detected, I reboot for the bios to detect it. After any OS in system is booted up, all drives are detected by OS (not bios, to be clear) of course. I have seen the same behaviour in others (in forum) and I figured it may also apply to you.

In my uefi system having separate $esp’s keeps any ‘interference’ away. And having my own separate grub (with its own $esp) helps (boots everything regardless of OS bootloader issues - silent-boot, fedora-grub, no-grub, systemd-boot, refind) and still lets me test any OS bootloader without messing up itself.

2 Likes

This is not true. What could interfere on a user basis is possible commands entered in some dot file like .xinit or .config/openbox/* or .config/xfce4/* something. Also, saved xfce sessions could do. Anyways, only logs can reveal what’s breaking xfce session. Ie. .Xsession-errors, Xorg.0.log journal or other in combination.

2 Likes

Being as UEFI keeps systems separated, I’ll take a look into it. Thanks.

As I found out, users cause many errors. :disappointed_relieved:

After booting into the system a few times and not changing anything since getting it into a working state, the system has messed up again with not finding the uuid to boot up from. This time fsck via Gparted on live USB found zero file system errors. Updating GRUB had no effect.

I’ve just ran sudo pacman -Syyu. This time there is a bunch of kernel updates, some related to nvidia:

  • lib32-nvidia-utils-1:410.78-1
  • linux419-nvidia-1:410.78-3
  • mhwd-nvidia-1:410.78-1
  • nvidia-utils-1:410.78-1

Maybe they might solve the problem. Anyway, the Internet is so slow, so I’ll leave it to download overnight.