Hello, Today, April 26, I did something stupid and updated my system, Suse tumbleweed. I generally put this off but there were 1800+ updates and I thought why not? When the update ended I rebooted the system and it hung over the boot process not finding "disk/by-uuid/f18fcf84-3787-4949-937c-b96a007ccdfc"
A quick search of my system revealed no such uuid
ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 Apr 26 18:16 1c97e950-d85c-42f6-95ae-4fc7b4d5f384 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Apr 26 18:16 58d63884-e53b-48cb-8691-6d2249000134 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Apr 26 18:16 65488b85-ac17-4c47-a6fc-57f7e944f19c -> ../../sda2
lrwxrwxrwx 1 root root 10 Apr 26 18:16 869640cb-e335-4de4-b91e-7c8dde6bbce3 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 26 18:16 88060e05-e0e8-46b1-b1a4-ab9a7b45b4f3 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Apr 26 18:16 fb3798b4-909c-44fe-bfd9-13056389ea6f -> ../../sda3

However searching in /boot/grub2 I FOUND 8 iterations of this line::
grub2/grub.cfg: linux /boot/vmlinuz-5.6.4-1-default root=UUID=65488b85-ac17-4c47-a6fc-57f7e944f19c ${extra_cmdline} splash=silent resume=/dev/disk/by-uuid/f18fcf84-3787-4949-937c-b96a007ccdfc mitigations=auto quiet

/boot/grub2/grub.cfg states
# DO NOT EDIT THIS FILE
3 #
4 # It is automatically generated by grub2-mkconfig using templates
5 # from /etc/grub.d and settings from /etc/default/grub

And apparently the initial error comes from:
grep ccdfc /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="splash=silent resume=/dev/disk/by-uuid/f18fcf84-3787-4949-937c-b96a007ccdfc mitigations=auto quiet"

which shows last being modified on: -rw-r--r-- 1 root root 1687 Mar 3 19:00 /etc/default/grub

So it would seem a simple modification of /etc/default/grub to correct the UUID and then running grub2-mkconfig would be a solution. But what is the resume function supposed to be pointing at? A disk of course but which one? The boot disk or something else?

Thanks for your consideration

From The Linux kernel user’s and administrator’s guide:
Usually, it's your swap partition.

2 members found this post helpful.

I've seen a couple of threads like this - pretty ugly if tumbleweed is issuing a mkswap during that update. Pure speculation on my part of course.

Apparently somewhere in the tumbleweed updates grub2-mkconfig is called to update the boot config files. Problem is that the update software doesn't take into consideration that there may have been changes in the disk configurations since last invocation. I assume that the resume=/dev/disk/by-uuid/f18fcf84-3787-4949-937c-b96a007ccdfc refers to a previous swap partition that was deleted. A hard drive started having issues and I removed it after relocating its contents. Presently waiting for a replacement drive but as my sdb drive is 1TB it was adequate to hold everything. I guess this is something you learn the hard way. "resume" apparently is in reference to laptop hibernation where closing the lid necessitates the system hibernating which means writing out a copy to swap space. Which basically is what I wanted to know. I changed the UUID to point at my current swap partition re-ran grub2-mkconfig and the system now boots appropriately. I've learned also that removing the "resume" arg and re-running grub2-mkconfig will also work as my system runs 24/7 and I'm not sure if it would ever be required to hibernate.
Thanks all.
And best regards.

BTW, anyone know the reason for SUSE using "grub2" instead of just "grub" as the directory name?? It's ok after you learn they are supposed to be the same but makes getting up on the documentation a bit more confusing.

Hey jjefferies44.

As you have surmised, the "resume" kernel boot option is indeed for telling the system the UUID of your swap partition to resume from hibernation. Not needed if you don't hibernate. You can also remove the hook from your mkconfig.conf if you don't hibernate (although leaving it there won't cause any problems). As you have also surmised, if ever you remove, modify, recreate your swap partition, and you *do* use hibernation, make sure to update the UUID information here.

Can't answer your SUSE-specific questions, I'm afraid.

Cheers.

1 members found this post helpful.

Because SUSE used to use grub 0.x (also called legacy-grub) in earlier releases.
grub 2 is the official name of this version:
(from the wikipedia page for the grub bootloader en.wikipedia.org/wiki/GNU_GRUB).

1 members found this post helpful.

Unlike in RHEL and Fedora, the appearance of Grub2 didn't result in Grub Legacy or support for it being dropped from SLE. Grub Legacy continued to be provided along with Grub2 in standard repos, and its /boot/grub/menu.lst automatically updated with each kernel installation if configured to do so. Since it stayed, and remains, in SLE, it stayed in openSUSE too. The installer will no longer configure it for you, but you can have it nevertheless if you know how, which is what I do to the full exclusion of Grub2 on hundreds of openSUSE installations on MBR disks. Both however could not and cannot use the same package naming, or directory in /boot/, so Grub2 was assigned /boot/grub2/, and thus it stays.

1 members found this post helpful.