On Fri, Dec 16, 2022 at 03:48:00PM -0800, Ross Vandegrift wrote: > At a high level the issue is: firewalld.service forces network-pre.target > after > sysinit.target, but cloud-init.service forces the other way around. In > detail, > using < to represent Before, the imposed orderings look like: > > - from firewalld: > sysinit.target < dbus.service < firewalld.service < network-pre.target > - from cloud-init: > cloud-init-local.service < network-pre.target < > systemd-networkd-wait-online.service < cloud-init.service < sysinit.target > > There's a few approaches to resolving this. As far as I can tell, the only > immediately viable one (at the bottom) requires users to manually fix this > and accept some trade-offs. Anyone have any better ideas?
We discussed this issue on the recent cloud-team meeting and had some revised options. > Modify firewalld to run before sysinit.target > --------------------------------------------- [snip] This one still seems impossible. > Modify cloud-init to run after sysinit.target > --------------------------------------------- [snip] The main downside of this one, is that cloud-init will be running too late to configure block devices. But this feature didn't always work well. So maybe we'd affect a non-working feature. I've confirmed that cloud-init's block device setup is working well on AWS at least. So I think this will break working cloud-init features. IMO, that means it is not viable. > Locally override firewalld.service's order > ------------------------------------------ [snip] This remains unattractive since unsuspecting users will be left with broken images and no clear path to fix the problem. Modify dbus to run later ------------------------ We discussed a way improve things by shuffling dbus later, but I didn't take good enough notes, and I can't reconstruct the details. Sorry for forgetting - Bastian do you recall the details? Add Breaks or Conflicts to prevent coinstallation ------------------------------------------------- None of the alternatives seem reasonable and installing cloud-init and firewalld cannot produce a working Debian image. So we should prevent this state. We thought Conflicts might be required because once both are unpacked, the problematic cycle technically exists. Though it may not cause harm unless both services are (re-)started simultaneously. Ross