Getting hibernate to work on a clone of a centos workstation
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
Getting hibernate to work on a clone of a centos workstation
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.
Quote:
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.
Quote:
However,it does not have linu lines,
I count 4 in your attachment. Each is followed by an initrd line.
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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:
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
Code:
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.