Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
On 2014-08-29 04:28, Andrei Borzenkov wrote: В Thu, 28 Aug 2014 19:36:53 +0200 Jan Janssen medhe...@web.de пишет: On Thursday 28 August 2014 11:33:44 Ivan Shapovalov wrote: On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote: Ivan Shapovalov intelfx100 at gmail.com writes: On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote: On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. What about swap files with the resume_offset= parameter? Are they still being used? I don't know if somebody uses that, but for now it's missing functionality. After a cursory search, I could not find a mechanism to initiate a resume with offset from userspace. In Arch, it was never implemented even if possible. I'm a heavy user of this myself. It's especially useful because you can just have a single luks encrypted ext4 without a lvm in between for a swap partition or (even more yuck) using a separate (encrypted) swap partition. Arch does support this, mostly because as far as I know, the resume_offset= is consumed by the kernel, while resume= has to refer to the (unencrypted) filesystem (/dev/mapper/root in my case). So, as long as this solution waits for the device to show up in /dev/ (and especially /dev/mapper/ for my case), this should work out. Here's information to set this up. Imho more people should be aware this is possible: https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file Jan Hmm, so is resume_offset= parsed independently of resume=? If that's the case, and resume_offset= can be parsed by kernel while resume= is parsed by userspace, then yes, I was wrong and this should work. Actually, it should work _just like before_, sans tuxonice support. I gave it a try and resume works for me with that sd-resume hook in arch. But I'm not too sure whether fsck is delayed properly: systemd[1]: Started Cryptography Setup for luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78. systemd[1]: Found device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78. systemd[1]: Starting File System Check on /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78... Hmm ... it is not systemd-fsck-root.service. Do you have local-fs-pre.target installed in initrd? What units are there at all? never mind, I failed to update the system-fsk@.service that had the new dependency. Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
Ivan Shapovalov intelfx100 at gmail.com writes: On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote: On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. What about swap files with the resume_offset= parameter? Are they still being used? I don't know if somebody uses that, but for now it's missing functionality. After a cursory search, I could not find a mechanism to initiate a resume with offset from userspace. In Arch, it was never implemented even if possible. I'm a heavy user of this myself. It's especially useful because you can just have a single luks encrypted ext4 without a lvm in between for a swap partition or (even more yuck) using a separate (encrypted) swap partition. Arch does support this, mostly because as far as I know, the resume_offset= is consumed by the kernel, while resume= has to refer to the (unencrypted) filesystem (/dev/mapper/root in my case). So, as long as this solution waits for the device to show up in /dev/ (and especially /dev/mapper/ for my case), this should work out. Here's information to set this up. Imho more people should be aware this is possible: https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote: Ivan Shapovalov intelfx100 at gmail.com writes: On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote: On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. What about swap files with the resume_offset= parameter? Are they still being used? I don't know if somebody uses that, but for now it's missing functionality. After a cursory search, I could not find a mechanism to initiate a resume with offset from userspace. In Arch, it was never implemented even if possible. I'm a heavy user of this myself. It's especially useful because you can just have a single luks encrypted ext4 without a lvm in between for a swap partition or (even more yuck) using a separate (encrypted) swap partition. Arch does support this, mostly because as far as I know, the resume_offset= is consumed by the kernel, while resume= has to refer to the (unencrypted) filesystem (/dev/mapper/root in my case). So, as long as this solution waits for the device to show up in /dev/ (and especially /dev/mapper/ for my case), this should work out. Here's information to set this up. Imho more people should be aware this is possible: https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file Jan Hmm, so is resume_offset= parsed independently of resume=? If that's the case, and resume_offset= can be parsed by kernel while resume= is parsed by userspace, then yes, I was wrong and this should work. Actually, it should work _just like before_, sans tuxonice support. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
On Thursday 28 August 2014 11:33:44 Ivan Shapovalov wrote: On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote: Ivan Shapovalov intelfx100 at gmail.com writes: On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote: On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. What about swap files with the resume_offset= parameter? Are they still being used? I don't know if somebody uses that, but for now it's missing functionality. After a cursory search, I could not find a mechanism to initiate a resume with offset from userspace. In Arch, it was never implemented even if possible. I'm a heavy user of this myself. It's especially useful because you can just have a single luks encrypted ext4 without a lvm in between for a swap partition or (even more yuck) using a separate (encrypted) swap partition. Arch does support this, mostly because as far as I know, the resume_offset= is consumed by the kernel, while resume= has to refer to the (unencrypted) filesystem (/dev/mapper/root in my case). So, as long as this solution waits for the device to show up in /dev/ (and especially /dev/mapper/ for my case), this should work out. Here's information to set this up. Imho more people should be aware this is possible: https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file Jan Hmm, so is resume_offset= parsed independently of resume=? If that's the case, and resume_offset= can be parsed by kernel while resume= is parsed by userspace, then yes, I was wrong and this should work. Actually, it should work _just like before_, sans tuxonice support. I gave it a try and resume works for me with that sd-resume hook in arch. But I'm not too sure whether fsck is delayed properly: systemd[1]: Started Cryptography Setup for luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78. systemd[1]: Found device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78. systemd[1]: Starting File System Check on /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78... systemd[1]: Starting Resume from hibernation using device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78... systemd-fsck[135]: fsck.ext4 doesn't exist, not checking file system on /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78 systemd[1]: Starting Encrypted Volumes. systemd[1]: Reached target Encrypted Volumes. systemd[1]: Starting System Initialization. systemd[1]: Reached target System Initialization. systemd[1]: Starting Basic System. systemd[1]: Reached target Basic System. systemd[1]: Started File System Check on /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78. kernel: PM: Starting manual resume from disk kernel: PM: Hibernation image partition 254:0 present kernel: PM: Looking for hibernation image. systemd-hibernate-resume[137]: Could not resume from '/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78' (254:0). systemd[1]: Started Resume from hibernation using device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78. If I read this correctly, the moment the plaintext device appears, the resume and fsck are racing each other. And in this case, fsck won (good thing my fsck binaries are not in the systemd initrd for now). Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
В Thu, 28 Aug 2014 19:36:53 +0200 Jan Janssen medhe...@web.de пишет: On Thursday 28 August 2014 11:33:44 Ivan Shapovalov wrote: On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote: Ivan Shapovalov intelfx100 at gmail.com writes: On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote: On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. What about swap files with the resume_offset= parameter? Are they still being used? I don't know if somebody uses that, but for now it's missing functionality. After a cursory search, I could not find a mechanism to initiate a resume with offset from userspace. In Arch, it was never implemented even if possible. I'm a heavy user of this myself. It's especially useful because you can just have a single luks encrypted ext4 without a lvm in between for a swap partition or (even more yuck) using a separate (encrypted) swap partition. Arch does support this, mostly because as far as I know, the resume_offset= is consumed by the kernel, while resume= has to refer to the (unencrypted) filesystem (/dev/mapper/root in my case). So, as long as this solution waits for the device to show up in /dev/ (and especially /dev/mapper/ for my case), this should work out. Here's information to set this up. Imho more people should be aware this is possible: https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file Jan Hmm, so is resume_offset= parsed independently of resume=? If that's the case, and resume_offset= can be parsed by kernel while resume= is parsed by userspace, then yes, I was wrong and this should work. Actually, it should work _just like before_, sans tuxonice support. I gave it a try and resume works for me with that sd-resume hook in arch. But I'm not too sure whether fsck is delayed properly: systemd[1]: Started Cryptography Setup for luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78. systemd[1]: Found device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78. systemd[1]: Starting File System Check on /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78... Hmm ... it is not systemd-fsck-root.service. Do you have local-fs-pre.target installed in initrd? What units are there at all? systemd[1]: Starting Resume from hibernation using device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78... systemd-fsck[135]: fsck.ext4 doesn't exist, not checking file system on /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78 systemd[1]: Starting Encrypted Volumes. systemd[1]: Reached target Encrypted Volumes. systemd[1]: Starting System Initialization. systemd[1]: Reached target System Initialization. systemd[1]: Starting Basic System. systemd[1]: Reached target Basic System. systemd[1]: Started File System Check on /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78. kernel: PM: Starting manual resume from disk kernel: PM: Hibernation image partition 254:0 present kernel: PM: Looking for hibernation image. systemd-hibernate-resume[137]: Could not resume from '/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78' (254:0). systemd[1]: Started Resume from hibernation using device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78. If I read this correctly, the moment the plaintext device appears, the resume and fsck are racing each other. And in this case, fsck won (good thing my fsck binaries are not in the systemd initrd for now). Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote: On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx...@gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. What about swap files with the resume_offset= parameter? Are they still being used? I don't know if somebody uses that, but for now it's missing functionality. After a cursory search, I could not find a mechanism to initiate a resume with offset from userspace. In Arch, it was never implemented even if possible. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
On Wed, 27.08.14 13:17, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote: On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx...@gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. What about swap files with the resume_offset= parameter? Are they still being used? I don't know if somebody uses that, but for now it's missing functionality. After a cursory search, I could not find a mechanism to initiate a resume with offset from userspace. In Arch, it was never implemented even if possible. I wouldn't bother until somebody actually really runs into this. And even then I'd be careful whether we really want to support that... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. It adds: - a 'systemd-hibernate-resume' tool which takes path to a device node and writes its major:minor to /sys/power/resume; - a corresponding 'systemd-hibernate-resume@.service' templated unit; - a 'systemd-hibernate-resume-generator' generator which parses the kernel command line and instantiates the unit as necessary. This functionality already exists in-kernel, but only for /dev/sdXY-style pathes. Implementing it in userspace allows to use arbitrary udev-created symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar) or fstab-like specifiers (FOO=bar). Userspace parsing of resume= kernel command line parameter has been traditionally done in initramfs via shell scripts (for Arch Linux, this is resume mkinitcpio hook), so I feel that this feature has its place within systemd. Due to the nature of hibernation, the resume unit must be activated before any modifications to filesystems take place. This can happen only in initramfs before mounting anything. So, first patch orders all non-root fsck after local-fs-pre.target, which in turn allows to order the resume unit before those fsck instances. Second and third patches add the tool, the unit and the generator. Thanks for reviewing! v2: fix issues pointed out by Andrei: - don't RemainAfterExit because it's useless - don't attempt to resume outside of initramfs because it's unsafe (reiserfs replays journal even if mounted RO) v3: fix mistakes spotted by Thomas: - return 0 in main path of resume.c:process_resume() - fix type and add missing cleanup attribute in resume-generator.c:main() v4: drop the [RFC] prefix as there are no more issues with this approach; incorporate feedback from Lennart: - fix indentation in resume-generator.c:parse_proc_cmdline_item() - remove overly aggressive 80-column line breaks - don't Before=usr.mount and After=systemd-udevd.service as the respective configurations are deemed broken - reword the Failed to resume message and downgrade it to log_info() v5: add the binaries and preprocessed unit to respective .gitignore files incorporate feedback from Lennart: - rename systemd-resume-* to systemd-hibernate-resume-* incorporate feedback from Dave: - use fstab_node_to_udev_node() in the generator to also handle fstab-like specifiers v6: rebase against master Ivan Shapovalov (3): units: order systemd-fsck@.service after local-fs-pre.target. hibernate-resume: add a tool to write a device node's major:minor to /sys/power/resume. hibernate-resume-generator: add a generator for instantiating the resume unit. .gitignore | 2 + Makefile-man.am| 9 +++ Makefile.am| 28 +++-- man/kernel-command-line.xml| 14 - man/systemd-hibernate-resume-generator.xml | 93 + man/systemd-hibernate-res...@.service.xml | 81 + src/hibernate-resume/Makefile | 1 + src/hibernate-resume/hibernate-resume.c| 81 + src/resume-generator/Makefile | 1 + src/resume-generator/resume-generator.c| 95 ++ units/.gitignore | 1 + units/systemd-f...@.service.in | 2 +- units/systemd-hibernate-res...@.service.in | 20 +++ 13 files changed, 422 insertions(+), 6 deletions(-) create mode 100644 man/systemd-hibernate-resume-generator.xml create mode 100644 man/systemd-hibernate-res...@.service.xml create mode 12 src/hibernate-resume/Makefile create mode 100644 src/hibernate-resume/hibernate-resume.c create mode 12 src/resume-generator/Makefile create mode 100644 src/resume-generator/resume-generator.c create mode 100644 units/systemd-hibernate-res...@.service.in -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx...@gmail.com) wrote: Applied all three! Thanks! This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. It adds: - a 'systemd-hibernate-resume' tool which takes path to a device node and writes its major:minor to /sys/power/resume; - a corresponding 'systemd-hibernate-resume@.service' templated unit; - a 'systemd-hibernate-resume-generator' generator which parses the kernel command line and instantiates the unit as necessary. This functionality already exists in-kernel, but only for /dev/sdXY-style pathes. Implementing it in userspace allows to use arbitrary udev-created symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar) or fstab-like specifiers (FOO=bar). Userspace parsing of resume= kernel command line parameter has been traditionally done in initramfs via shell scripts (for Arch Linux, this is resume mkinitcpio hook), so I feel that this feature has its place within systemd. Due to the nature of hibernation, the resume unit must be activated before any modifications to filesystems take place. This can happen only in initramfs before mounting anything. So, first patch orders all non-root fsck after local-fs-pre.target, which in turn allows to order the resume unit before those fsck instances. Second and third patches add the tool, the unit and the generator. Thanks for reviewing! v2: fix issues pointed out by Andrei: - don't RemainAfterExit because it's useless - don't attempt to resume outside of initramfs because it's unsafe (reiserfs replays journal even if mounted RO) v3: fix mistakes spotted by Thomas: - return 0 in main path of resume.c:process_resume() - fix type and add missing cleanup attribute in resume-generator.c:main() v4: drop the [RFC] prefix as there are no more issues with this approach; incorporate feedback from Lennart: - fix indentation in resume-generator.c:parse_proc_cmdline_item() - remove overly aggressive 80-column line breaks - don't Before=usr.mount and After=systemd-udevd.service as the respective configurations are deemed broken - reword the Failed to resume message and downgrade it to log_info() v5: add the binaries and preprocessed unit to respective .gitignore files incorporate feedback from Lennart: - rename systemd-resume-* to systemd-hibernate-resume-* incorporate feedback from Dave: - use fstab_node_to_udev_node() in the generator to also handle fstab-like specifiers v6: rebase against master Ivan Shapovalov (3): units: order systemd-fsck@.service after local-fs-pre.target. hibernate-resume: add a tool to write a device node's major:minor to /sys/power/resume. hibernate-resume-generator: add a generator for instantiating the resume unit. .gitignore | 2 + Makefile-man.am| 9 +++ Makefile.am| 28 +++-- man/kernel-command-line.xml| 14 - man/systemd-hibernate-resume-generator.xml | 93 + man/systemd-hibernate-res...@.service.xml | 81 + src/hibernate-resume/Makefile | 1 + src/hibernate-resume/hibernate-resume.c| 81 + src/resume-generator/Makefile | 1 + src/resume-generator/resume-generator.c| 95 ++ units/.gitignore | 1 + units/systemd-f...@.service.in | 2 +- units/systemd-hibernate-res...@.service.in | 20 +++ 13 files changed, 422 insertions(+), 6 deletions(-) create mode 100644 man/systemd-hibernate-resume-generator.xml create mode 100644 man/systemd-hibernate-res...@.service.xml create mode 12 src/hibernate-resume/Makefile create mode 100644 src/hibernate-resume/hibernate-resume.c create mode 12 src/resume-generator/Makefile create mode 100644 src/resume-generator/resume-generator.c create mode 100644 units/systemd-hibernate-res...@.service.in Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote: On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx...@gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. What about swap files with the resume_offset= parameter? Are they still being used? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
