Getting hibernate to work on a clone of a centos workstation

I am running a workstation with centos release 7.6.1810
I have tried to clone my workstation so that others in our group can upgrade from fedora 20 which has been obsolete for ages.
What I did was
1. write a script to copy ssh details for a workstation to a common server,
2. cloned my workstation to the same server with clonezilla.
3. I then used clonezilla to use the cloned file to build the cloned workstation onto another workstation of the same specs with the idea of
4. using another script I have written to restore the workstation hostname, passwords and ssh details for each user (2 users not including root).

I have completed the first three steps and checked it out against the original. At this stage the workstation has worked for each process I have attempted except for hibernate.
When I attempt to hibernate, using the hibernate button in the Mate terminal we use, or the command line command "systemctl hibernate" from root, it closes down as expected, but when I bring up the system again it acts as if I had shutdown rather than hibernated and comes up with a password request for the user and then is in the Mate GUI with none of the mate terminal sessions I had been in before attempting the hibernate.
Suspend seems to work, although I do not normally use that.

Any idea how I can make hibernate work, and why that changed with cloning which is supposed to produce an identical copy of the original?

Your process may be ignoring the presence of resume= on the linu lines in grub.cfg, and its presence in the initrd. Try ensuring these two's UUIDs match each other, and match the actual UUID of the actual swap partition. That could be as simple as regenerating grub.cfg on each cloned system.

Thanks,mrmazda, for your prompt reply. Sorry I have been so long in replying.
My knowledge of the basic workings of linux is very rudimentary (but I learn quickly), so please excuse apparently stupid questions.

As I mentioned, I am using centos release 7.6.1810, which is one of the red hat set of linux builds.

I have found grub.cfg in /boot/grub2 and in /etc/grub2. I assume the one in /boot/grub2 is the relevant one.
However,it does not have linu lines, and there is no resume= in the file (either file).

You mentioned regenerating the grub.cfg file. How do I regenerate the cfg file?

Where is the initrd file?

Why should any of this be necessary? I would have thought that the clone made by clonezilla would be identical to the original, which works OK.

attached is the grub2.cfg file, renamed to grub2.txt if looking at it might help.

The only time I ever used CentOS was before Grub2, so I can only provide generic information.

Originally Posted by WarwickWr I have found grub.cfg in /boot/grub2 and in /etc/grub2. I assume the one in /boot/grub2 is the relevant one.

It is.

However,it does not have linu lines,

I count 4 in your attachment. Each is followed by an initrd line.

and there is no resume= in the file (either file).

This is the first time I've seen a live grub.cfg file without resume= anywhere. I do know it's an optional parameter however. When used, it overrides any resume= parameter built into, or generated by, the initrd. Resume= is a necessary part of the hibernation process, so this almost certainly is where your problem lies. You may need to add one, via /etc/default/grub, and regenerating grub.cfg.

You mentioned regenerating the grub.cfg file. How do I regenerate the cfg file?

This is explained at the top of the file you attached.

Where is the initrd file?

On a running system, it's in /boot. Since you've configured using LVM and a separate filesystem that gets mounted to /boot, Grub sees it in / on the separate filesystem. Its name on openSUSE is initrd-<version>, with a symlink to initrd. On Fedora, it's initramfs-<version>.img, with no symlink. On Debians, it's initrd.img-<version>, with a symlink to /initrd.img on the running system.

Why should any of this be necessary? I would have thought that the clone made by clonezilla would be identical to the original, which works OK.

I don't use Clonezilla, or CentOS, or LVM. As I use LABEL everywhere instead of UUID, I'm not sure whether the UUID Grub uses is the filesystem UUID, or a partition's PARTUUID, but I'm sure the problem must lie in a mismatch between the actual UUID of the swap partition from which resume must reload, and the resume= in the initrd. I expected you could use lsinitrd or lsinitramfs, whichever CentOS provides, with grep to find the UUID it contains to compare with the actual swap partition UUID. However, doing so with Fedora 34 I obtained an unexpected result, and in Debian 11, I found:

conf/conf.d/zz-resume-auto
scripts/local-premount/resume
usr/lib/x86_64-linux-gnu/libuuid.so.1
usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0
usr/bin/resume

which is also not what I expected. openSUSE also produced surprise:

# lsinitrd initrd | egrep -i 'uuid|resume'
resume
-rw-r--r--   1 root     root           50 May 13 12:12 etc/cmdline.d/95resume.conf
-rwxr-xr-x   1 root     root        10320 May 13 12:12 usr/lib/systemd/system-generators/systemd-hibernate-resume-generator
-rw-r--r--   1 root     root          635 May 13 12:12 usr/lib/systemd/system/systemd-hibernate-resume@.service
-rwxr-xr-x   1 root     root        10296 May 13 12:12 usr/lib/systemd/systemd-hibernate-resume
lrwxrwxrwx   1 root     root           16 May 13 12:12 usr/lib64/libuuid.so.1 -> libuuid.so.1.3.0
-rwxr-xr-x   1 root     root        30848 Dec 16  2020 usr/lib64/libuuid.so.1.3.0

So, it looks like resume is under control of the systemd monolith, and an examination of its service files should turn up a source for the UUID that resume is looking for.

All that said, it seems like if your step 4 included rebuilding of the initrd, the problem might be solved - might, because it's unclear whether the new swap partitions are clones of the original, or newly created, with unique UUIDs.

Are your fstabs true clones of the originals, with swap partitions mounted by UUID? If so, I suppose this could also be the failure point. If your swap partitions were given LABELs used for mounting and resume, your cloning process might work better.

It's also possible that resume is done by-id, that is /dev/disk/by-id/<disk-id><part#>, which will definitely differ for each physical HDD or SSD, not under control of admin, user, Grub or Clonezilla.

Phew! That's a lot to absorb. I will have to work on this.

I did not realise that you meant lines with linu at the start.

My problem is that I took over on this when the original developer died 3 or 4 years ago (very inconvenient). At that stage I knew C (but had not used it for about 20 years), did not even have all the passwords, so I have been struggling since, while keeping the programming side going with the help of one, sometimes two, other programmers. The originator did pretty well to get a system with well over a million lines of code running with very few errors, but documentation was not his strong suit. I have since documented everything I have learnt about the system.

Would the first step be to try putting a resume line in somewhere? Where and what value?

To learn the UUID of the swap partition, use the blkid command.

When Grub is the bootloader, anything can be added to a linu line when the Grub menu appears by striking the E key, which puts Grub into edit mode. Your addition of a resume= parameter at boot time would be an addition to an existing linu line. Linu lines typically wrap. This works only for one boot, normally to test whether a parameter produces a desired effect. Given the effect resume= is intended to produce, the long length of a UUID, and the inability to copy and paste during Grub's edit mode, I suggest to skip testing this way.

The persisting way to add manually is via the file /etc/default/grub, adding the resume=yada...yada parameter to the GRUB_CMDLINE_LINUX_DEFAULT= line, followed by running

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

to regenerate /boot/grub2/grub.cfg with the addition included. This way it becomes possible to use copy & paste for the correct UUID value.