IIUC the problem is the package split of sd-resolved, which was still part of the combined "systemd" binary package in Jammy. When people upgrade to Noble "systemd" gets unconfigured, dropping any cache/state about systemd-resolved.service, then the "systemd-resolved" binary package gets (force)installed either as a Recommends or by an update- manager quirk. But due to the lost state, debhelper will start & enable the systemd-resolved.service, even if it was masked or disabled before. Breaking people's custom setup.
If this assumption is correct, the problem should not happen when upgrading from Noble to Oracular (or above) because state about systemd- resolved.service is handled properly when upgrading the "systemd- resolved" binary package... (to be confirmed), so would only affect Jammy->Noble upgrades. I looked into https://manpages.debian.org/testing/debhelper/dh_installsystemd.1.en.html and https://manpages.debian.org/testing/init-system-helpers/deb-systemd- helper.1p.en.html but feel like those cannot really do what we need here (considering the package-split edge case). So we might need some hand- crafted .postinst to restore systemd-resolved.service state in deb- systemd-helper. The auto-generated systemd-resolved (DEBIAN/postinst of the binary package), might be a good starting point. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/2078555 Title: Upgrading from 22.04 to 24.04.01 breaks dnsmasq Status in Ubuntu: Triaged Status in dnsmasq package in Ubuntu: Triaged Status in systemd package in Ubuntu: Triaged Status in ubuntu-release-upgrader package in Ubuntu: Triaged Bug description: Was running Ubuntu 22.04 as home gateway/firewall with dnsmasq as dns/dhcp server. Previous upgrade from Ubuntu 20.04 to 22.04 had worked without issue. After the upgrade to 24.04.01, systemd-resovled was automatically enabled. The result was that after a reboot, dnsmasq failed to start, as systemd-resolved had already bound to the necessary port. This in turn meant that my entire home network lost connectivity as it was dependant on dnsmasq running to provide both correct dns and dhcp functionality. Ideally, during the upgrade process, a check should be made for if another dns/dhcp service is already enabled, and if so, not enable systemd-resolved. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2078555/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
