On Thu, 03 Dec 2020 07:12:04 -0400 David Bremner <da...@tethera.net> wrote: > Anton Lundin <gla...@acc.umu.se> writes: > > > The generated postinst script in nullmailer has a section like: > > # Automatically added by dh_installinit/12 > > if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = > > "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then > > # In case this system is running systemd, we need to ensure that all > > # necessary tmpfiles (if any) are created before starting. > > if [ -d /run/systemd/system ] ; then > > systemd-tmpfiles --create nullmailer.conf >/dev/null || true > > fi > > fi > > # End automatically added section > > > > > > The problem with this is that fai doesn't use systemd during the > > install, but it's used when the machine reboots into the new install. > > > > Since this postinst section is generated by debhelper, this seems like a > bug in debhelper. It also suggests that most packages using systemd-tmpfiles > will be broken when installed via FAI. I'm CC'ing Thomas in case he's > encountered this before. > > > The sysvinit script shipped with nullmailer creates the pipe if it > > doesn't exist, and the nullmailer systemd service should do something > > equivalent. > > Although I think the right place to fix this is debhelper, I'm open to > concrete suggestions for a workaround. I'm not really interested in > handcrafting a postinst, but if there really is a one line fix for the > unit file, that could be reasonable to apply. I haven't investigated > deeply, but I suppose ExecStartPre might do the trick. >
I don't get it. If you don't use systemd during the bootstrapping of the system, you also don't/can't start the systemd .service. So adding anything to ExecStartPre= would achieve nothing. What exactly is the error here?
signature.asc
Description: This is a digitally signed message part
