Am 08.07.2018 um 17:51 schrieb Michael Biebl: > Am 08.07.2018 um 17:42 schrieb Michael Biebl:
>> Any ideas how we can convince apt to upgrade the packages in the correct >> order, ie. make sure that udev's postinst is run after systemd's >> postinst without adding a versioned systemd Depends to udev? > > > Bringing David and Julian into the loop here. Maybe they have a clever idea. > > It's interesting to note, that apt does upgrade the packages in a proper > order for me, but doesn't for others. Atm, I see two options: 1/ We call systemctl daemon-reexec in udev.postinst before we restart udev. The existing versioned Breaks ensures that we have systemd 239 or newer unpacked. Triggering a daemon-reexec from udev is a bit icky but it should be reasonably safe. Atm we don't have any upgrade code in systemd.postinst which needs to run before we can re-exec PID 1 (which doesn't mean this might not change before buster is released. The daemon-reexec in udev.postinst would be a one-time only thing, guarded by dpkg --compare-versions "$1" lt 239-6 2/ We remove the sandboxing features which trip up older systemd versions. Specifically this is the commit which turns the seccomp filters from a black into a whitelist. Specifically this would mean removing SystemCallFilter=@system-service @module @raw-io SystemCallErrorNumber=EPERM from systemd-udevd.service. With that change, the service file should work with systemd v232 from stretch. That patch would be dropped in buster+1. Thoughts, preferences? [1] https://github.com/systemd/systemd/commit/ee8f26180d01e3ddd4e5f20b03b81e5e737657ae -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
