Move systemd binaries to /sbin/systemd
cover Move systemd binaries to /sbin/systemd
Hi,
Following the example set by udev, move the binaries to /sbin/systemd and hardcode less paths in general. Tested on atom-pc with a .hddimg so the live boot/initrd paths were tested.
Ross
The following changes since commit 2ef72c3174c8c111678ac7e3cf3d866eaf2c8d77:
wayland: add necessary dependencies to fix build error (2013-04-11 16:41:13 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib ross/systemd
for you to fetch changes up to 0154334c32234d70dc064fb7dac6b499ca91cf3a:
initrdscripts: look for new systemd-udevd location (2013-04-11 17:18:19 +0100)
----------------------------------------------------------------
Ross Burton (2):
systemd: move the binaries to /sbin/systemd
initrdscripts: look for new systemd-udevd location
meta/recipes-core/initrdscripts/files/init-live.sh | 2 +- .../initrdscripts/initramfs-framework/udev | 2 +- meta/recipes-core/systemd/systemd/init | 14 +++--- meta/recipes-core/systemd/systemd_199.bb | 46 +++++++------------- 4 files changed, 25 insertions(+), 39 deletions(-)
Signature · 1 line
1.7.10.4
PATCH 1/2 systemd: move the binaries to /sbin/systemd
As with udev, placing binaries in /lib breaks our current multilib implementation. Change the rootlibexecdir to /sbin/systemd so that binaries don't move in multilib situations.
--- meta/recipes-core/systemd/systemd/init | 14 ++++----- meta/recipes-core/systemd/systemd_199.bb | 46 +++++++++++------------------- 2 files changed, 23 insertions(+), 37 deletions(-)
meta/recipes-core/systemd/systemd/init +7 -7
@@ -15,7 +15,7 @@ export TZ=/etc/localtime [ -d /sys/class ] || exit 1 [ -r /proc/mounts ] || exit 1 -[ -x /lib/systemd/systemd-udevd ] || exit 1 +[ -x @UDEVD@ ] || exit 1 [ -f /etc/default/udev-cache ] && . /etc/default/udev-cache [ -f /etc/udev/udev.conf ] && . /etc/udev/udev.conf
@@ -71,15 +71,15 @@ case "$1" in # trigger the sorted events echo -e '\000\000\000\000' > /proc/sys/kernel/hotplug - /lib/systemd/systemd-udevd -d + @UDEVD@ -d - /usr/bin/udevadm control --env=STARTUP=1 + udevadm control --env=STARTUP=1 if [ "$not_first_boot" != "" ];then - /usr/bin/udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux --subsystem-nomatch=platform - (/usr/bin/udevadm settle --timeout=3; /usr/bin/udevadm control --env=STARTUP=)& + udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux --subsystem-nomatch=platform + (udevadm settle --timeout=3; udevadm control --env=STARTUP=)& else - /usr/bin/udevadm trigger --action=add - /usr/bin/udevadm settle + udevadm trigger --action=add + udevadm settle fi ;; stop)
meta/recipes-core/systemd/systemd_199.bb +16 -30
113 lines not on this page · raw message
Signature · 1 line
1.7.10.4
PATCH 2/2 initrdscripts: look for new systemd-udevd location
In reply to Ross BurtonAs per the previous commit, systemd-udevd is now in /sbin/systemd/.
--- meta/recipes-core/initrdscripts/files/init-live.sh | 2 +- meta/recipes-core/initrdscripts/initramfs-framework/udev | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
meta/recipes-core/initrdscripts/files/init-live.sh +1 -1
@@ -12,7 +12,7 @@ UNIONFS="no" # Copied from initramfs-framework. The core of this script probably should be # turned into initramfs-framework modules to reduce duplication. udev_daemon() { - OPTIONS="/sbin/udev/udevd /sbin/udevd /lib/udev/udevd /lib/systemd/systemd-udevd" + OPTIONS="/sbin/udev/udevd /sbin/udevd /lib/udev/udevd /sbin/systemd/systemd-udevd /lib/systemd/systemd-udevd" for o in $OPTIONS; do if [ -x "$o" ]; then
meta/recipes-core/initrdscripts/initramfs-framework/udev +1 -1
@@ -11,7 +11,7 @@ udev_shutdown_hook_handler() { } udev_daemon() { - OPTIONS="/sbin/udev/udevd /sbin/udevd /lib/udev/udevd /lib/systemd/systemd-udevd" + OPTIONS="/sbin/udev/udevd /sbin/udevd /lib/udev/udevd /sbin/systemd/systemd-udevd /lib/systemd/systemd-udevd" for o in $OPTIONS; do if [ -x "$o" ]; then
Signature · 1 line
1.7.10.4
Ross Burton <[email protected]>
Quoted 3 lines · writes:
Following the example set by udev, move the binaries to
/sbin/systemdand hardcode less paths in general. Tested on atom-pc with a .hddimg so the live boot/initrd paths were tested.
At least the moving of udev breaks a lot of local recipes here which install e.g. local rules or keymaps in /lib/udev. This is a silent break which is detected at device runtime only. The global 'bitbake.conf' has not been updated for the new paths neither.
There should be:
1. added some QA checks which detect this broken packaging
2. added some global variables (e.g. 'udev_basedir') which can be used in the rules.
Enrico
Op 15 apr. 2013, om 13:00 heeft Enrico Scholz <[email protected]> het volgende geschreven:
Quoted 13 lines
Ross Burton <[email protected]>
Quoted 3 lines · writes:
Following the example set by udev, move the binaries to
/sbin/systemdand hardcode less paths in general. Tested on atom-pc with a .hddimg so the live boot/initrd paths were tested.At least the moving of udev breaks a lot of local recipes here which install e.g. local rules or keymaps in
/lib/udev. This is a silent break which is detected at device runtime only. The global 'bitbake.conf' has not been updated for the new paths neither.
Quoted 6 lines
There should be:
1. added some QA checks which detect this broken packaging
2. added some global variables (e.g. '
udev_basedir') which can be used in the rules.
These patches can get NAK'd all you want, but they will go in. I still say: NAK, this is a bad, bad idea. It diverges from upstream and introduces silent breakage as you point out due to that.
Quoted 17 lines · Koen Kooi
Op 15 apr. 2013, om 13:00 heeft Enrico Scholz <[email protected]> het volgende geschreven:
Quoted 15 lines
Ross Burton <[email protected]>
Quoted 3 lines · writes:
Following the example set by udev, move the binaries to
/sbin/systemdand hardcode less paths in general. Tested on atom-pc with a .hddimg so the live boot/initrd paths were tested.At least the moving of udev breaks a lot of local recipes here which install e.g. local rules or keymaps in
/lib/udev. This is a silent break which is detected at device runtime only. The global 'bitbake.conf' has not been updated for the new paths neither.There should be:
Quoted 8 lines
Quoted 4 lines
1. added some QA checks which detect this broken packaging
2. added some global variables (e.g. '
udev_basedir') which can be used in the rules.These patches can get NAK'd all you want, but they will go in. I still
say: NAK, this is a bad, bad idea. It diverges from upstream and introduces silent breakage as you point out due to that.
In the 1.5 timeframe I want to look at this again and see how we can better solve it as it may be we can do something to the multilib code to avoid the issues. We ran out of runway with this for 1.4 :(.
Cheers,
Richard
Quoted 17 lines · Richard Purdie
Quoted 17 lines
Quoted 16 lines
Quoted 3 lines
Following the example set by udev, move the binaries to
/sbin/systemdand hardcode less paths in general. Tested on atom-pc with a .hddimg so the live boot/initrd paths were tested.At least the moving of udev breaks a lot of local recipes here which install e.g. local rules or keymaps in
/lib/udev. This is a silent break which is detected at device runtime only. The global 'bitbake.conf' has not been updated for the new paths neither.There should be:
1. added some QA checks which detect this broken packaging
2. added some global variables (e.g. '
udev_basedir') which can be used in the rules.
Quoted 7 lines
Quoted 3 lines
These patches can get NAK'd all you want, but they will go in. I still
say: NAK, this is a bad, bad idea. It diverges from upstream and introduces silent breakage as you point out due to that.In the 1.5 timeframe I want to look at this again and see how we can better solve it as it may be we can do something to the multilib code to avoid the issues. We ran out of runway with this for 1.4 :(.
Does this mean, this last-minute and invasive patch gets reverted (--> it is already in oe). Or, that it stays and we have to live in 1.4 with bad surprises[1] because an undefined number of packages[2] uses still the upstream defaults?
Enrico
Footnotes:
[1] udev rules, keymaps and firmware at the wrong location
[2] surprisingly, 'systemd' itself where this change has been applied still refers to /lib/udev/rules.d