[arch-projects] [mkinitcpio] [PATCH] Add sd-resume hook.
This depends on the systemd hook. It adds systemd-hibernate-resume@.service
and systemd-hibernate-resume-generator which perform userspace parsing of
resume= kernel parameter, allowing to specify the resume device by its
persistent path ("resume=/dev/disk/by-foo/bar") or fstab-like specifier
("resume=FOO=bar"), just like the root= parameter.
---
Given that relevant functionality has just landed in systemd git, it makes
sense to pipeline things a bit (even if actual applying will be delayed until
systemd-217).
Also, does this need to be a separate hook or can be merged into 'systemd'
hook itself?
install/sd-resume | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 install/sd-resume
diff --git a/install/sd-resume b/install/sd-resume
new file mode 100644
index 0000000..2995a8e
--- /dev/null
+++ b/install/sd-resume
@@ -0,0 +1,22 @@
+#!/bin/bash
+
+build() {
+ map add_binary \
+ /usr/lib/systemd/systemd-hibernate-resume \
+ /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator
+
+ map add_systemd_unit \
+ systemd-hibernate-resume@.service \
+ local-fs-pre.target
+}
+
+help() {
+ cat <
On Wed, Aug 27, 2014 at 12:47:10AM +0400, Ivan Shapovalov wrote:
This depends on the systemd hook. It adds systemd-hibernate-resume@.service and systemd-hibernate-resume-generator which perform userspace parsing of resume= kernel parameter, allowing to specify the resume device by its persistent path ("resume=/dev/disk/by-foo/bar") or fstab-like specifier ("resume=FOO=bar"), just like the root= parameter. ---
Given that relevant functionality has just landed in systemd git, it makes sense to pipeline things a bit (even if actual applying will be delayed until systemd-217).
Also, does this need to be a separate hook or can be merged into 'systemd' hook itself?
This belongs in mkinitcpio proper, along with the systemd hooks currently residing in the core/systemd package. You can blame me for the latter not yet happening. Given that, we should probably add this to the systemd package for now, as to not give people the idea that sd-resume can be used without the systemd hook. Thanks so much for pushing this work upstream!
install/sd-resume | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 install/sd-resume
diff --git a/install/sd-resume b/install/sd-resume new file mode 100644 index 0000000..2995a8e --- /dev/null +++ b/install/sd-resume @@ -0,0 +1,22 @@ +#!/bin/bash + +build() { + map add_binary \ + /usr/lib/systemd/systemd-hibernate-resume \ + /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator + + map add_systemd_unit \ + systemd-hibernate-resume@.service \ + local-fs-pre.target +} + +help() { + cat <
On Tuesday 26 August 2014 at 17:42:54, Dave Reisner wrote:
On Wed, Aug 27, 2014 at 12:47:10AM +0400, Ivan Shapovalov wrote:
This depends on the systemd hook. It adds systemd-hibernate-resume@.service and systemd-hibernate-resume-generator which perform userspace parsing of resume= kernel parameter, allowing to specify the resume device by its persistent path ("resume=/dev/disk/by-foo/bar") or fstab-like specifier ("resume=FOO=bar"), just like the root= parameter. ---
Given that relevant functionality has just landed in systemd git, it makes sense to pipeline things a bit (even if actual applying will be delayed until systemd-217).
Also, does this need to be a separate hook or can be merged into 'systemd' hook itself?
This belongs in mkinitcpio proper, along with the systemd hooks currently residing in the core/systemd package. You can blame me for the latter not yet happening. Given that, we should probably add this to the systemd package for now, as to not give people the idea that sd-resume can be used without the systemd hook.
Thanks so much for pushing this work upstream!
I'm confused a bit. Do you say that the 'systemd' hook currently in core/systemd shall be eventually moved to core/mkinitcpio? Either way, there are 'sd-vconsole' and 'sd-shutdown' already in core/mkinitcpio. I think that if 'sd-resume' will be a separate hook, then either it should be placed here, or all three sd-* hooks should be moved to core/systemd. (The global alternative -- viability unknown -- is not to make 'sd-resume' a separate hook but to add all this directly from 'systemd' hook.) -- Ivan Shapovalov / intelfx /
On Wed, Aug 27, 2014 at 02:05:41AM +0400, Ivan Shapovalov wrote:
On Tuesday 26 August 2014 at 17:42:54, Dave Reisner wrote:
On Wed, Aug 27, 2014 at 12:47:10AM +0400, Ivan Shapovalov wrote:
This depends on the systemd hook. It adds systemd-hibernate-resume@.service and systemd-hibernate-resume-generator which perform userspace parsing of resume= kernel parameter, allowing to specify the resume device by its persistent path ("resume=/dev/disk/by-foo/bar") or fstab-like specifier ("resume=FOO=bar"), just like the root= parameter. ---
Given that relevant functionality has just landed in systemd git, it makes sense to pipeline things a bit (even if actual applying will be delayed until systemd-217).
Also, does this need to be a separate hook or can be merged into 'systemd' hook itself?
This belongs in mkinitcpio proper, along with the systemd hooks currently residing in the core/systemd package. You can blame me for the latter not yet happening. Given that, we should probably add this to the systemd package for now, as to not give people the idea that sd-resume can be used without the systemd hook.
Thanks so much for pushing this work upstream!
I'm confused a bit.
Apparently, I am too. My brain is largely fried from being sick for a week (and then traveling/partying copiously this past weekend). Let's try this again -- this time with a bit more context/detail.
Do you say that the 'systemd' hook currently in core/systemd shall be eventually moved to core/mkinitcpio?
Actually, no. I'm incorrectly recalling my own plan. What I should have said is that the add_systemd_unit and add_udev_rule shell functions were to be matured in core/systemd before adding them to the "functions" file of mkinitcpio. I've not seen any bug reports since Tom Gundersen and I wrote those (maybe a year ago?) so perhaps it's time to just go ahead and do that. I'm actually against moving the whole systemd hook into core/mkinitcpio because it then puts mkinitcpio in a situation where it has to be reactionary to backwards incompatible changes to systemd. This kind of dependency has bitten me in the past (though offhand, I don't recall which hook this was relevant to). Maybe Thomas recalls.
Either way, there are 'sd-vconsole' and 'sd-shutdown' already in core/mkinitcpio. I think that if 'sd-resume' will be a separate hook, then either it should be placed here, or all three sd-* hooks should be moved to core/systemd.
Yes, you're right -- this contradicts my previous reply. Ultra long-term, mkinitcpio may lose its shell-based early userspace and only support systemd. That would mean that I ignore my paranoia about backwards incompatible changes just deal with mkinitcpio sometimes needing to move in lockstep with systemd.
(The global alternative -- viability unknown -- is not to make 'sd-resume' a separate hook but to add all this directly from 'systemd' hook.)
Certainly viable. The extra binaries are quite small, and it'd be nice if this "just worked" out of the box. Hope this makes things a bit clearer... d
Am 27.08.2014 um 01:02 schrieb Dave Reisner:
I'm actually against moving the whole systemd hook into core/mkinitcpio because it then puts mkinitcpio in a situation where it has to be reactionary to backwards incompatible changes to systemd. This kind of dependency has bitten me in the past (though offhand, I don't recall which hook this was relevant to). Maybe Thomas recalls.
$ LANG= pacman -Qo /usr/lib/initcpio/hooks/udev /usr/lib/initcpio/hooks/udev is owned by systemd 216-1 This stuff was changed so often, I can't recall the number of problems with it.
On Tuesday 26 August 2014 at 19:02:50, Dave Reisner wrote:
On Wed, Aug 27, 2014 at 02:05:41AM +0400, Ivan Shapovalov wrote:
On Tuesday 26 August 2014 at 17:42:54, Dave Reisner wrote:
On Wed, Aug 27, 2014 at 12:47:10AM +0400, Ivan Shapovalov wrote:
This depends on the systemd hook. It adds systemd-hibernate-resume@.service and systemd-hibernate-resume-generator which perform userspace parsing of resume= kernel parameter, allowing to specify the resume device by its persistent path ("resume=/dev/disk/by-foo/bar") or fstab-like specifier ("resume=FOO=bar"), just like the root= parameter. ---
Given that relevant functionality has just landed in systemd git, it makes sense to pipeline things a bit (even if actual applying will be delayed until systemd-217).
Also, does this need to be a separate hook or can be merged into 'systemd' hook itself?
This belongs in mkinitcpio proper, along with the systemd hooks currently residing in the core/systemd package. You can blame me for the latter not yet happening. Given that, we should probably add this to the systemd package for now, as to not give people the idea that sd-resume can be used without the systemd hook.
Thanks so much for pushing this work upstream!
I'm confused a bit.
Apparently, I am too. My brain is largely fried from being sick for a week (and then traveling/partying copiously this past weekend).
Let's try this again -- this time with a bit more context/detail.
Do you say that the 'systemd' hook currently in core/systemd shall be eventually moved to core/mkinitcpio?
Actually, no. I'm incorrectly recalling my own plan. What I should have said is that the add_systemd_unit and add_udev_rule shell functions were to be matured in core/systemd before adding them to the "functions" file of mkinitcpio. I've not seen any bug reports since Tom Gundersen and I wrote those (maybe a year ago?) so perhaps it's time to just go ahead and do that.
I'm actually against moving the whole systemd hook into core/mkinitcpio because it then puts mkinitcpio in a situation where it has to be reactionary to backwards incompatible changes to systemd. This kind of dependency has bitten me in the past (though offhand, I don't recall which hook this was relevant to). Maybe Thomas recalls.
Either way, there are 'sd-vconsole' and 'sd-shutdown' already in core/mkinitcpio. I think that if 'sd-resume' will be a separate hook, then either it should be placed here, or all three sd-* hooks should be moved to core/systemd.
Yes, you're right -- this contradicts my previous reply. Ultra long-term, mkinitcpio may lose its shell-based early userspace and only support systemd. That would mean that I ignore my paranoia about backwards incompatible changes just deal with mkinitcpio sometimes needing to move in lockstep with systemd.
(The global alternative -- viability unknown -- is not to make 'sd-resume' a separate hook but to add all this directly from 'systemd' hook.)
Certainly viable. The extra binaries are quite small, and it'd be nice if this "just worked" out of the box.
Hope this makes things a bit clearer...
Yep, I've largely understood the situation. So, what will we do? If putting this into 'systemd' is OK, then I'd prefer this way. -- Ivan Shapovalov / intelfx /
On Tuesday 26 August 2014 at 19:02:50, Dave Reisner wrote:
On Wed, Aug 27, 2014 at 02:05:41AM +0400, Ivan Shapovalov wrote:
On Tuesday 26 August 2014 at 17:42:54, Dave Reisner wrote:
On Wed, Aug 27, 2014 at 12:47:10AM +0400, Ivan Shapovalov wrote:
This depends on the systemd hook. It adds systemd-hibernate-resume@.service and systemd-hibernate-resume-generator which perform userspace parsing of resume= kernel parameter, allowing to specify the resume device by its persistent path ("resume=/dev/disk/by-foo/bar") or fstab-like specifier ("resume=FOO=bar"), just like the root= parameter. ---
Given that relevant functionality has just landed in systemd git, it makes sense to pipeline things a bit (even if actual applying will be delayed until systemd-217).
Also, does this need to be a separate hook or can be merged into 'systemd' hook itself?
This belongs in mkinitcpio proper, along with the systemd hooks currently residing in the core/systemd package. You can blame me for the latter not yet happening. Given that, we should probably add this to the systemd package for now, as to not give people the idea that sd-resume can be used without the systemd hook.
Thanks so much for pushing this work upstream!
I'm confused a bit.
Apparently, I am too. My brain is largely fried from being sick for a week (and then traveling/partying copiously this past weekend).
Let's try this again -- this time with a bit more context/detail.
Do you say that the 'systemd' hook currently in core/systemd shall be eventually moved to core/mkinitcpio?
Actually, no. I'm incorrectly recalling my own plan. What I should have said is that the add_systemd_unit and add_udev_rule shell functions were to be matured in core/systemd before adding them to the "functions" file of mkinitcpio. I've not seen any bug reports since Tom Gundersen and I wrote those (maybe a year ago?) so perhaps it's time to just go ahead and do that.
I'm actually against moving the whole systemd hook into core/mkinitcpio because it then puts mkinitcpio in a situation where it has to be reactionary to backwards incompatible changes to systemd. This kind of dependency has bitten me in the past (though offhand, I don't recall which hook this was relevant to). Maybe Thomas recalls.
Either way, there are 'sd-vconsole' and 'sd-shutdown' already in core/mkinitcpio. I think that if 'sd-resume' will be a separate hook, then either it should be placed here, or all three sd-* hooks should be moved to core/systemd.
Yes, you're right -- this contradicts my previous reply. Ultra long-term, mkinitcpio may lose its shell-based early userspace and only support systemd. That would mean that I ignore my paranoia about backwards incompatible changes just deal with mkinitcpio sometimes needing to move in lockstep with systemd.
(The global alternative -- viability unknown -- is not to make 'sd-resume' a separate hook but to add all this directly from 'systemd' hook.)
Certainly viable. The extra binaries are quite small, and it'd be nice if this "just worked" out of the box.
Hope this makes things a bit clearer...
d
Hello again, systemd 217 seems to be in testing now, so what's the status of this? We should either merge this hook to core/mkinitcpio or add the equivalent code to 'systemd' hook. (I'm for the second approach, actually...) -- Ivan Shapovalov / intelfx /
On Fri, Oct 31, 2014 at 05:08:55AM +0300, Ivan Shapovalov wrote:
Hello again,
systemd 217 seems to be in testing now, so what's the status of this? We should either merge this hook to core/mkinitcpio or add the equivalent code to 'systemd' hook.
(I'm for the second approach, actually...)
-- Ivan Shapovalov / intelfx /
Thanks for the reminder! I'm planning on a systemd 217-2 with some bug fixes in the next few days. I'll include your changes to systemd's install hook. dR
participants (3)
-
Dave Reisner
-
Ivan Shapovalov
-
Thomas Bächler