I have Fedora 31 installed in VirtualBox, and I am trying to test out hibernation with a swap file, but no matter what I do I am unable to get Hibernation to work.
I am using a 6GB swap file with the RAM allocated to the VM is 5GB, so the file should be sufficient for a successful hibernate.
This is my /etc/fstab:
/dev/mapper/vgfedora-fedora / ext4 defaults 1 1 UUID=070a13c2-7c99-4703-bb7a-e408245316c4 /boot ext4 defaults 1 2 /fedora.swap none swap 0 0
This is my grub.cfg:
GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.lvm.lv=vgfedora/fedora rhgb quiet resume=/dev/vgfedora/fedora resume_offset=587776" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true
I have followed the instructions from the Arch wiki: https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#...
I am hibernating using the following command: sudo /usr/lib/systemd/systemd-sleep hibernate
Weirdly, there are no errors in the log that I get with journalctl -b : https://pastebin.com/9cfnRx8V
I have not added any hooks to the initramfs because if you see the tutorial it says that if you are using systemd then you don't need any additional hooks in the initramfs. Thus, I did not rebuild my initramfs.
Do I have to do that ? Fedora uses systemd by default right ?
I don't understand what I am doing wrong, I am only using LVM but no encryption.
This is my lsblk -f output:
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT sda
├─sda1 ext4 070a13c2-7c99-4703-bb7a-e408245316c4 739.3M 17% /boot └─sda2 LVM2_member m1OMiT-aeUG-9Fb1-pNSw-LmUn-rKJK-cHYASh └─vgfedora-fedora ext4 8cec892a-8da9-4ee2-95fe-bc2e0c4cd3aa 24G 34% / sr0
Let me know if there are any other logs I can include, I am unable to understand what is the root cause of the problem, there are no errors any where.
Even SELinux is not complaining.
Thanks.
On Fri, 2020-04-17 at 15:47 +0530, Sreyan Chakravarty wrote:
I have Fedora 31 installed in VirtualBox, and I am trying to test out hibernation with a swap file, but no matter what I do I am unable to get Hibernation to work.
As has already been explained when you asked before, you can't use a swap file for hibernation. It has to be a device or partition.
poc
Can that partition be encrypted ? Why can't I use a swap file ? I mean is the Arch wiki wrong ?
On Fri, Apr 17, 2020 at 4:36 PM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Fri, 2020-04-17 at 15:47 +0530, Sreyan Chakravarty wrote:
I have Fedora 31 installed in VirtualBox, and I am trying to test out hibernation with a swap file, but no matter what I do I am unable to get Hibernation to work.
As has already been explained when you asked before, you can't use a swap file for hibernation. It has to be a device or partition.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Ah! saw your message in the other thread, continuing over there.
Sorry for the confusion.
On Fri, Apr 17, 2020 at 4:36 PM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Fri, 2020-04-17 at 15:47 +0530, Sreyan Chakravarty wrote:
I have Fedora 31 installed in VirtualBox, and I am trying to test out hibernation with a swap file, but no matter what I do I am unable to get Hibernation to work.
As has already been explained when you asked before, you can't use a swap file for hibernation. It has to be a device or partition.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Fri, 17 Apr 2020 15:47:41 +0530 Sreyan Chakravarty sreyan32@gmail.com wrote:
This is my /etc/fstab:
/dev/mapper/vgfedora-fedora / ext4
^
GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.lvm.lv=vgfedora/fedora rhgb quiet
^
resume=/dev/vgfedora/fedora resume_offset=587776"
^
GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true
I know little about hibernation or volume groups. But is it possible the vgfedora/fedora should be vgfedora-fedora in grub?
For the vg/offset to work the file must be contiguous (only 1 section/extent in the file). I don't see that mentioned in archlinux.
What does filefrag show and what does du against the swap file show?
The hibernate restore is starting up the vg/lv and going to that offset and expecting it to all be there.
On Fri, Apr 17, 2020 at 3:15 PM stan via users users@lists.fedoraproject.org wrote:
On Fri, 17 Apr 2020 15:47:41 +0530 Sreyan Chakravarty sreyan32@gmail.com wrote:
This is my /etc/fstab:
/dev/mapper/vgfedora-fedora / ext4
^GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rd.lvm.lv=vgfedora/fedora rhgb quiet
^resume=/dev/vgfedora/fedora resume_offset=587776"
^GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true
I know little about hibernation or volume groups. But is it possible the vgfedora/fedora should be vgfedora-fedora in grub? _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 4/17/20 2:11 PM, Roger Heflin wrote:
For the vg/offset to work the file must be contiguous (only 1 section/extent in the file). I don't see that mentioned in archlinux.
I tried to find out the on-disk format for swap files, but wasn't able to. But from the doc at https://www.kernel.org/doc/html/latest/power/swsusp-and-swap-files.html, there's this: "swap files need not be contiguous" I assume the header has some sort of map of where to find all the other blocks, so you just need to provide the offset to the header.
On Fri, 2020-04-17 at 14:25 -0700, Samuel Sieb wrote:
On 4/17/20 2:11 PM, Roger Heflin wrote:
For the vg/offset to work the file must be contiguous (only 1 section/extent in the file). I don't see that mentioned in archlinux.
I tried to find out the on-disk format for swap files, but wasn't able to. But from the doc at https://www.kernel.org/doc/html/latest/power/swsusp-and-swap-files.html
That does give some interesting insights. In particular, it explains why the file has to be treated specially (because during resume, the filesystem may not be mounted, which is what I was trying to get at earlier). This clears up some confusion for me at least.
poc
On 4/17/20 2:42 PM, Patrick O'Callaghan wrote:
On Fri, 2020-04-17 at 14:25 -0700, Samuel Sieb wrote:
On 4/17/20 2:11 PM, Roger Heflin wrote:
For the vg/offset to work the file must be contiguous (only 1 section/extent in the file). I don't see that mentioned in archlinux.
I tried to find out the on-disk format for swap files, but wasn't able to. But from the doc at https://www.kernel.org/doc/html/latest/power/swsusp-and-swap-files.html
That does give some interesting insights. In particular, it explains why the file has to be treated specially (because during resume, the filesystem may not be mounted, which is what I was trying to get at earlier). This clears up some confusion for me at least.
During resume, the filesystem *can't* be mounted. All the filesystem state is in the hibernation image which you are trying to load. It's one of those fun chicken and egg challenges. That's why there has to be enough info in the swap file to locate the data without relying on anything else.
On Fri, 2020-04-17 at 15:03 -0700, Samuel Sieb wrote:
During resume, the filesystem *can't* be mounted. All the filesystem state is in the hibernation image which you are trying to load. It's one of those fun chicken and egg challenges. That's why there has to be enough info in the swap file to locate the data without relying on anything else.
To be able to do that, it has to be able to read within a filesystem by itself. There's probably only a small set of filesystems it can handle.
On 4/17/20 11:20 PM, Tim via users wrote:
On Fri, 2020-04-17 at 15:03 -0700, Samuel Sieb wrote:
During resume, the filesystem *can't* be mounted. All the filesystem state is in the hibernation image which you are trying to load. It's one of those fun chicken and egg challenges. That's why there has to be enough info in the swap file to locate the data without relying on anything else.
To be able to do that, it has to be able to read within a filesystem by itself. There's probably only a small set of filesystems it can handle.
No, you point the kernel at the offset of the header within the partition. The header contains pointers to the rest of the data. It doesn't have to know anything about the filesystem.
On Sat, 2020-04-18 at 00:44 -0700, Samuel Sieb wrote:
On 4/17/20 11:20 PM, Tim via users wrote:
On Fri, 2020-04-17 at 15:03 -0700, Samuel Sieb wrote:
During resume, the filesystem *can't* be mounted. All the filesystem state is in the hibernation image which you are trying to load. It's one of those fun chicken and egg challenges. That's why there has to be enough info in the swap file to locate the data without relying on anything else.
To be able to do that, it has to be able to read within a filesystem by itself. There's probably only a small set of filesystems it can handle.
No, you point the kernel at the offset of the header within the partition. The header contains pointers to the rest of the data. It doesn't have to know anything about the filesystem.
OK. I retract my previous answer.
poc
On 4/17/20 11:20 PM, Tim via users wrote:
No, you point the kernel at the offset of the header within the partition. The header contains pointers to the rest of the data. It doesn't have to know anything about the filesystem.
You know there are 2 things that struck me as odd:
1) Why does Hibernate with swap partition work out of the box and why does using a file need the resume module in dracut ?
2) After hibernating successfully a couple of times, I can SELinux back to enforcing and it doesn't cause any problems. I have no clue why ?
These are ofcourse observations from VirtualBox.
On 2020-04-18 18:46, Sreyan Chakravarty wrote:
- After hibernating successfully a couple of times, I can SELinux back to enforcing and it doesn't cause any problems. I have no clue why ?
Well, since selinux operates on file/directory contexts and no files or directories are involved as mentioned bySamuel: "The header contains pointers to the rest of the data. It doesn't have to know anything about the filesystem." And since selinux is implemented in the kernel and that isn't "running" yet. It stands to reason that you won't have problems.
At least that is my stab at explaining it. :-)
On 2020-04-18 18:46, Sreyan Chakravarty wrote:
Well, since selinux operates on file/directory contexts and no files or directories are involved as mentioned bySamuel: "The header contains pointers to the rest of the data. It doesn't have to know anything about the filesystem." And since selinux is implemented in the kernel and that isn't "running" yet. It stands to reason that you won't have problems.
At least that is my stab at explaining it. :-)
Thats interesting but then why did I get the problem in the first place then ? My other topic is labelled SELinux is blocking Hibernate, and SELinux was legitimately interfering with the hibernate process, specifically blocking systemd-sleep to read the hibernate file.
The weird thing is why did it stop me once and then didn't stop me once I set it back from permissive to enforcing ? Did SELinux "learn" somehow that it is ok to allow access to the swap file ?
This is all very confusing.
On 4/18/20 3:53 AM, Ed Greshko wrote:
On 2020-04-18 18:46, Sreyan Chakravarty wrote:
- After hibernating successfully a couple of times, I can SELinux back to enforcing and it doesn't cause any problems. I have no clue why ?
Well, since selinux operates on file/directory contexts and no files or directories are involved as mentioned bySamuel: "The header contains pointers to the rest of the data. It doesn't have to know anything about the filesystem." And since selinux is implemented in the kernel and that isn't "running" yet. It stands to reason that you won't have problems.
It's the hibernating process that was blocked by selinux, not the resume. I think that in the initial part of this thread, he ran the commands to create the selinux modules to fix the problem.
Tim:
To be able to do that, it has to be able to read within a filesystem by itself. There's probably only a small set of filesystems it can handle.
Samuel Sieb:
No, you point the kernel at the offset of the header within the partition. The header contains pointers to the rest of the data. It doesn't have to know anything about the filesystem.
Surely that'd be dependent on the entireity of the swap file being arranged on the drive in a predictable manner. What if a swap file was created on a system that didn't arrange all the bits so predictably?
e.g. A swap file on an encrypted partition.
On Sun, 2020-04-19 at 00:28 +0930, Tim via users wrote:
Tim:
To be able to do that, it has to be able to read within a filesystem by itself. There's probably only a small set of filesystems it can handle.
Samuel Sieb:
No, you point the kernel at the offset of the header within the partition. The header contains pointers to the rest of the data. It doesn't have to know anything about the filesystem.
Surely that'd be dependent on the entireity of the swap file being arranged on the drive in a predictable manner. What if a swap file was created on a system that didn't arrange all the bits so predictably?
e.g. A swap file on an encrypted partition.
Encryption of course is a possible impediment (I've no idea if this is handled as it's not of particular interest to me). However with that caveat, a header including direct pointers to each block of data in sequence would seem to be workable in theory without requiring knowledge of the filesystem's layout strategy, recalling that this data is being created by something that knows how it's going to be used. (I say that without having looked at the actual format.)
poc
e.g. A swap file on an encrypted partition.
I am already using it in an encrypted partition. It does not give any problems.
On Sat, Apr 18, 2020 at 8:29 PM Tim via users users@lists.fedoraproject.org wrote:
Tim:
To be able to do that, it has to be able to read within a filesystem by itself. There's probably only a small set of filesystems it can handle.
Samuel Sieb:
No, you point the kernel at the offset of the header within the partition. The header contains pointers to the rest of the data. It doesn't have to know anything about the filesystem.
Surely that'd be dependent on the entireity of the swap file being arranged on the drive in a predictable manner. What if a swap file was created on a system that didn't arrange all the bits so predictably?
e.g. A swap file on an encrypted partition.
--
uname -rsvp Linux 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Fri, 2020-04-17 at 15:03 -0700, Samuel Sieb wrote:
On 4/17/20 2:42 PM, Patrick O'Callaghan wrote:
On Fri, 2020-04-17 at 14:25 -0700, Samuel Sieb wrote:
On 4/17/20 2:11 PM, Roger Heflin wrote:
For the vg/offset to work the file must be contiguous (only 1 section/extent in the file). I don't see that mentioned in archlinux.
I tried to find out the on-disk format for swap files, but wasn't able to. But from the doc at https://www.kernel.org/doc/html/latest/power/swsusp-and-swap-files.html
That does give some interesting insights. In particular, it explains why the file has to be treated specially (because during resume, the filesystem may not be mounted, which is what I was trying to get at earlier). This clears up some confusion for me at least.
During resume, the filesystem *can't* be mounted. All the filesystem state is in the hibernation image which you are trying to load. It's one of those fun chicken and egg challenges. That's why there has to be enough info in the swap file to locate the data without relying on anything else.
Yes, that's exactly my point. However it does mean that the filesystem has to be one that the initial system understands.
poc
On Fri, 2020-04-17 at 15:03 -0700, Samuel Sieb wrote:
Yes, that's exactly my point. However it does mean that the filesystem has to be one that the initial system understands.
poc
Sorry but let me confuse you further.
If the initial ramdisk does not understand the filesystem, then how is it even locating my swapfile ?
Is it just using the offset to go the memory location directly ?
On Sat, 2020-04-18 at 11:04 +0000, Sreyan Chakravarty wrote:
On Fri, 2020-04-17 at 15:03 -0700, Samuel Sieb wrote:
Yes, that's exactly my point. However it does mean that the filesystem has to be one that the initial system understands.
poc
Sorry but let me confuse you further.
If the initial ramdisk does not understand the filesystem, then how is it even locating my swapfile ?
As Samuel has pointed out, the resume info points directly at the swap file header on the device (including an offset from the device origin), and the file header itself points directly at the data blocks.
poc
This whole thread is why this email list is a great example of how this thing called the net can actually be a great resource for weird tech stuff, and for helping others!
Does the list sometimes veer off to snarky stuff.. very rarely.
OJ to all!
On Sat, Apr 18, 2020 at 8:08 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Sat, 2020-04-18 at 11:04 +0000, Sreyan Chakravarty wrote:
On Fri, 2020-04-17 at 15:03 -0700, Samuel Sieb wrote:
Yes, that's exactly my point. However it does mean that the filesystem has to be one that the initial system understands.
poc
Sorry but let me confuse you further.
If the initial ramdisk does not understand the filesystem, then how is
it even locating my swapfile ?
As Samuel has pointed out, the resume info points directly at the swap file header on the device (including an offset from the device origin), and the file header itself points directly at the data blocks.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Am 18.04.2020 um 14:12 schrieb bruce:
This whole thread is why this email list is a great example of how this thing called the net can actually be a great resource for weird tech stuff, and for helping others!
Yes, this is a mailing list and covered by guidelines like the good old etiquette conventions.
https://fedoraproject.org/wiki/Mailing_list_guidelines?rd=Communicate/Mailin...
https://fedoraproject.org/wiki/Mailing_list_guidelines?rd=Communicate/Mailin...
So why are you always top-posting? Why don't you trim your quotation? As by the nature of a mailing list the postings can be threaded in almost any mail client and there is no good reason the keep the whole previous conversation in a current reply.
Just have a look at the messy thread of yours
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/...
And look at how Jonathan Billings replied to one of your posts in that thread. Quoation to the point, easy to follow to which part of yours he is giving an answer.
Regards Alexander
-
Alexander Dalloz -
bruce -
Ed Greshko -
Patrick O'Callaghan -
Roger Heflin -
Samuel Sieb -
Sreyan Chakravarty -
stan -
Tim