[Touch-packages] [Bug 1873794] Re: Unattended upgrades fixes missing from security repo
If the fix is not in the security pocket, how does it get sorted if the updates pocket is turned off? I understood *-updates are only supposed to be recommended. As I mentioned if you build an image with a tool like 'mkosi' which utilises debootstrap and then cleans the cache, the partial directory is missing in the resulting image. Under the Debian file system layout /var is supposed to be volatile. You can't rely on anything being there. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1873794 Title: Unattended upgrades fixes missing from security repo Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Fix Released Status in unattended-upgrades source package in Bionic: Fix Released Status in unattended-upgrades source package in Eoan: Fix Released Bug description: Critical unattended upgrades fixes are missing from the bionic security repo, which means that if you are using an installation of Ubuntu using only 'bionic' and 'bionic-security' you can stop unattended-upgrades from working just by doing a 'rmdir /var/cache/apt/archives/partial'. This is because the 'rootdir' parameter on the main function is set to "" rather than "/" - which disables the required directories and files check. I'm presuming here that the *-updates pocket is still 'recommended' rather than 'required'. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: unattended-upgrades 1.1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-96.97-generic 4.15.18 Uname: Linux 4.15.0-96-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.14 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Apr 20 12:44:35 2020 InstallationDate: Installed on 2016-04-28 (1452 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) PackageArchitecture: all SourcePackage: unattended-upgrades UpgradeStatus: Upgraded to bionic on 2018-08-19 (610 days ago) modified.conffile..etc.apt.apt.conf.d.10periodic: [modified] mtime.conffile..etc.apt.apt.conf.d.10periodic: 2018-09-17T10:50:46.904847 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1873794/+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
[Touch-packages] [Bug 1866367] [NEW] NetworkManager can't disable IPv6 properly
Public bug reported: Clicking 'disable' on the IPv6 tag doesn't appear to remove auto- configured IPv6 addresses or turn off the IPv6 operations on the specified interface. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: network-manager 1.22.8-1ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 Uname: Linux 5.4.0-14-generic x86_64 ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Mar 6 15:24:21 2020 InstallationDate: Installed on 2020-03-06 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200304) IpRoute: default via 192.168.1.254 dev ens33 proto dhcp metric 100 169.254.0.0/16 dev ens33 scope link metric 1000 192.168.1.0/24 dev ens33 proto kernel scope link src 192.168.1.86 metric 100 IwConfig: lono wireless extensions. ens33 no wireless extensions. RfKill: 0: hci0: Bluetooth Soft blocked: no Hard blocked: no SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAMEUUID TYPE TIMESTAMP TIMESTAMP-REALAUTOCONNECT AUTOCONNECT-PRIORITY READONLY DBUS-PATH ACTIVE DEVICE STATE ACTIVE-PATH SLAVE FILENAME Wired connection 1 9f785e0c-8a0d-310a-8a14-c603fd38083c ethernet 1583508227 Fri 06 Mar 2020 15:23:47 GMT yes -999 no /org/freedesktop/NetworkManager/Settings/1 yes ens33 activated /org/freedesktop/NetworkManager/ActiveConnection/1 -- /etc/NetworkManager/system-connections/Wired connection 1.nmconnection nmcli-dev: DEVICE TYPE STATE IP4-CONNECTIVITY IP6-CONNECTIVITY DBUS-PATH CONNECTION CON-UUID CON-PATH ens33 ethernet connected full limited /org/freedesktop/NetworkManager/Devices/2 Wired connection 1 9f785e0c-8a0d-310a-8a14-c603fd38083c /org/freedesktop/NetworkManager/ActiveConnection/1 lo loopback unmanaged unknown unknown /org/freedesktop/NetworkManager/Devices/1 -- -- -- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.22.8 connected started full enabled enabled enabled enabled enabled ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1866367 Title: NetworkManager can't disable IPv6 properly Status in network-manager package in Ubuntu: New Bug description: Clicking 'disable' on the IPv6 tag doesn't appear to remove auto- configured IPv6 addresses or turn off the IPv6 operations on the specified interface. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: network-manager 1.22.8-1ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 Uname: Linux 5.4.0-14-generic x86_64 ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Mar 6 15:24:21 2020 InstallationDate: Installed on 2020-03-06 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200304) IpRoute: default via 192.168.1.254 dev ens33 proto dhcp metric 100 169.254.0.0/16 dev ens33 scope link metric 1000 192.168.1.0/24 dev ens33 proto kernel scope link src 192.168.1.86 metric 100 IwConfig: lono wireless extensions. ens33 no wireless extensions. RfKill: 0: hci0: Bluetooth Soft blocked: no Hard blocked: no SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAMEUUID TYPE TIMESTAMP TIMESTAMP-REALAUTOCONNECT AUTOCONNECT-PRIORITY READONLY DBUS-PATH ACTIVE DEVICE STATE ACTIVE-PATH SLAVE FILENAME Wired connection 1 9f785e0c-8a0d-310a-8a14-c603fd38083c ethernet 1583508227 Fri 06 Mar 2020 15:23:47 GMT yes -999 no /org/freedesktop/NetworkManager/Settings/1 yes ens33 activated /org/freedesktop/NetworkManager/ActiveConnection/1 -- /etc/NetworkManager/system-connections/Wired connection 1.nmconnection nmcli-dev: DEVICE TYPE STATE IP4-CONNECTIVITY IP6-CONNECTIVITY DBUS-PATH
[Touch-packages] [Bug 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial
"I think you're trying to start dhclient on an interface that's already setup." It just triggers a lease refresh on the existing interface, which has the same issue. Nov 15 14:17:10 srv-ywz63 systemd-logind[981]: New session 27 of user ubuntu. Nov 15 14:17:10 srv-ywz63 systemd[1]: Started Session 27 of user ubuntu. Nov 15 14:17:30 srv-ywz63 sudo[12484]: ubuntu : TTY=pts/2 ; PWD=/home/ubuntu ; USER=root ; COMMAND=/sbin/dhclient eth0 Nov 15 14:17:30 srv-ywz63 sudo[12484]: pam_unix(sudo:session): session opened for user root by ubuntu(uid=0) Nov 15 14:17:30 srv-ywz63 dhclient[12485]: DHCPREQUEST of 10.241.196.178 on eth0 to 255.255.255.255 port 67 (xid=0x511efd40) Nov 15 14:17:30 srv-ywz63 dhclient[12485]: DHCPACK of 10.241.196.178 from 10.241.196.177 Nov 15 14:17:30 srv-ywz63 dhclient[12485]: bound to 10.241.196.178 -- renewal in 1421 seconds. Nov 15 14:17:30 srv-ywz63 sudo[12484]: pam_unix(sudo:session): session closed for user root -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [other info] this fix was included in the initial release of systemd for eoan, but the fix required the additional change in bug 1849608. Both the original patch plus that change (to avoid using bash-specific &>) are included in the b/d patch for this bug. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25
[Touch-packages] [Bug 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial
LGTM on bionic ubuntu@srv-ywz63:~$ dpkg -l systemd | grep ii ii systemd237-3ubuntu10.32 i386 system and service manager ubuntu@srv-ywz63:~$ journalctl -b -u systemd-resolved | grep Started Nov 14 17:05:43 srv-ywz63 systemd[1]: Started Network Name Resolution. Nov 14 17:05:44 srv-ywz63 systemd[1]: Started Network Name Resolution. ubuntu@srv-ywz63:~$ sudo dhclient eth0 RTNETLINK answers: File exists ubuntu@srv-ywz63:~$ journalctl -b -u systemd-resolved | grep Started Nov 14 17:05:43 srv-ywz63 systemd[1]: Started Network Name Resolution. Nov 14 17:05:44 srv-ywz63 systemd[1]: Started Network Name Resolution. ubuntu@srv-ywz63:~$ ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [other info] this fix was included in the initial release of systemd for eoan, but the fix required the additional change in bug 1849608. Both the original patch plus that change (to avoid using bash-specific &>) are included in the b/d patch for this bug. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25 ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160 Uname: Linux 4.4.0-139-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CrashDB: ubuntu Date: Mon Nov 26 16:17:52 2018
[Touch-packages] [Bug 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial
I think just a delta change process would be fine. It's restarting when there is no change in lease details, and just clogging up the logs. btw I am not suggesting leaving dhclient there is a bug - hence the title of the bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Triaged Bug description: If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25 ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160 Uname: Linux 4.4.0-139-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CrashDB: ubuntu Date: Mon Nov 26 16:17:52 2018 PackageArchitecture: all SourcePackage: ubuntu-release-upgrader UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183/+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
[Touch-packages] [Bug 1649288] [NEW] Unified ping doesn't support IPv4-mapped IPv6 addresses
Public bug reported: ping to a mapped address ping :::216.58.213.68 sends an ICMPv6 packet out onto the Internet with the mapped address in the destination packet and the IPv6 address as the source. Mapped addresses shouldn't appear on the public internet according to the RFC. I would have expected this to use the IPv6 API to send an ICMP packet over the v4 Internet on a dual stack machine in accordance with RFC4038. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: iputils-ping 3:20150815-2ubuntu3 ProcVersionSignature: User Name 4.8.0-30.32-generic 4.8.6 Uname: Linux 4.8.0-30-generic x86_64 ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 Date: Mon Dec 12 14:27:34 2016 SourcePackage: iputils UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: iputils (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug uec-images zesty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iputils in Ubuntu. https://bugs.launchpad.net/bugs/1649288 Title: Unified ping doesn't support IPv4-mapped IPv6 addresses Status in iputils package in Ubuntu: New Bug description: ping to a mapped address ping :::216.58.213.68 sends an ICMPv6 packet out onto the Internet with the mapped address in the destination packet and the IPv6 address as the source. Mapped addresses shouldn't appear on the public internet according to the RFC. I would have expected this to use the IPv6 API to send an ICMP packet over the v4 Internet on a dual stack machine in accordance with RFC4038. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: iputils-ping 3:20150815-2ubuntu3 ProcVersionSignature: User Name 4.8.0-30.32-generic 4.8.6 Uname: Linux 4.8.0-30-generic x86_64 ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 Date: Mon Dec 12 14:27:34 2016 SourcePackage: iputils UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1649288/+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
[Touch-packages] [Bug 1576692] Re: fully support package installation in systemd
Added both cloud-ini t and init-system-helpers from proposed to the standard Xenial cloud image (com.ubuntu.cloud:released:download/com.ubuntu.cloud:server:16.04:amd64/20160907.1/disk1.img) on a suitably sized server. Reset the cloud init with rm -rf /var/lib/cloud/instances/*, shutdown the server and snapshotted the image. Rebuilt a new server from the snapshotted image using the previously failing postgresql user data and all is well. The new packages correct my problem - bug 1611973 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to init-system-helpers in Ubuntu. https://bugs.launchpad.net/bugs/1576692 Title: fully support package installation in systemd Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in init-system-helpers package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Committed Status in init-system-helpers source package in Xenial: Fix Committed Bug description: in cloud-init users can install packages via cloud-config: #cloud-config packages: [apache2] Due to some intricacies of systemd and service installation that doesn't work all that well. We fixed the issue for simple services that do not have any dependencies on other services, or at least don't check those dependencies well under bug 1575572. We'd like to have a way to fully support this in cloud-init. Related bugs: * bug 1575572: apache2 fails to start if installed via cloud config (on Xenial) * bug 1611973: postgresql@9.5-main service not started if postgres installed via cloud-init * bug 1621336: snapd.boot-ok.service hangs eternally on cloud image upgrades (snapd packaging bug, but this cloud-init fix will workaround it) * bug 1620780: dev-sda2.device job running and times out SRU INFORMATION === FIX for init-system-helpers: https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=1460d6a02 REGRESSION POTENTIAL for init-system-helpers: This changes invoke-rc.d and service, two very central pieces of packaging infrastructure. Errors in it will break installation/upgrades of packages or /etc/network/if-up.d/ hooks and the like. This changes the condition when systemd units get started without their dependencies, and the condition gets weakened. This means that behaviour in a booted system is unchanged, but during boot this could change the behaviour of if- up.d/ hooks (although they have never been defined well during boot anyway). However, I tested this change extensively in cloud images and desktop installations (particularly I recreated https://bugs.debian.org/777113 and confirmed that this approach also fixes it) and could not find any regression. TEST CASE (for both packages): Run lxc launch ubuntu-daily:x --config=user.user-data="$(printf "#cloud-config\npackages: [postgresql, samba, postfix]")" x1 This will install all three packages, but "systemctl status postgresql@9.5-main" will not be running. Now prepare a new image with the proposed cloud-init and init-system- helpers: lxc launch ubuntu-daily:x xprep lxc exec xprep bash # enable -proposed and dist-upgrade, then poweroff lxc publish xprep x-proposed Now run the initial lxc launch again, but against that new x-proposed image instead of the standard daily: lxc launch x-proposed --config=user.user-data="$(printf "#cloud- config\npackages: [postgresql, samba, postfix]")" x1 You should now have "systemctl status postgresql@9.5-main" running. Directly after rebooting the instance, check that there are no hanging jobs (systemctl list-jobs), particularly networking.service, to ensure that https://bugs.debian.org/777113 did not come back. Also test interactively installing a package that ships a service, like "apache2", and verify that it starts properly after installation. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1576692/+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
[Touch-packages] [Bug 1576692] Re: fully support package installation in systemd
Have we back ported the init-system-helpers changes to Xenial? I'm only seeing 1.29ubuntu2 this morning. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to init-system-helpers in Ubuntu. https://bugs.launchpad.net/bugs/1576692 Title: fully support package installation in systemd Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in init-system-helpers package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Committed Status in init-system-helpers source package in Xenial: In Progress Bug description: in cloud-init users can install packages via cloud-config: #cloud-config packages: [apache2] Due to some intricacies of systemd and service installation that doesn't work all that well. We fixed the issue for simple services that do not have any dependencies on other services, or at least don't check those dependencies well under bug 1575572. We'd like to have a way to fully support this in cloud-init. Related bugs: * bug 1575572: apache2 fails to start if installed via cloud config (on Xenial) * bug 1611973: postgresql@9.5-main service not started if postgres installed via cloud-init * bug 1621336: snapd.boot-ok.service hangs eternally on cloud image upgrades (snapd packaging bug, but this cloud-init fix will workaround it) * bug 1620780: dev-sda2.device job running and times out SRU INFORMATION === FIX for init-system-helpers: https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=1460d6a02 REGRESSION POTENTIAL for init-system-helpers: This changes invoke-rc.d and service, two very central pieces of packaging infrastructure. Errors in it will break installation/upgrades of packages or /etc/network/if-up.d/ hooks and the like. This changes the condition when systemd units get started without their dependencies, and the condition gets weakened. This means that behaviour in a booted system is unchanged, but during boot this could change the behaviour of if- up.d/ hooks (although they have never been defined well during boot anyway). However, I tested this change extensively in cloud images and desktop installations (particularly I recreated https://bugs.debian.org/777113 and confirmed that this approach also fixes it) and could not find any regression. TEST CASE (for both packages): Run lxc launch ubuntu-daily:x --config=user.user-data="$(printf "#cloud-config\npackages: [postgresql, samba, postfix]")" x1 This will install all three packages, but "systemctl status postgresql@9.5-main" will not be running. Now prepare a new image with the proposed cloud-init and init-system- helpers: lxc launch ubuntu-daily:x xprep lxc exec xprep bash # enable -proposed and dist-upgrade, then poweroff lxc publish xprep x-proposed Now run the initial lxc launch again, but against that new x-proposed image instead of the standard daily: lxc launch x-proposed --config=user.user-data="$(printf "#cloud- config\npackages: [postgresql, samba, postfix]")" x1 You should now have "systemctl status postgresql@9.5-main" running. Directly after rebooting the instance, check that there are no hanging jobs (systemctl list-jobs), particularly networking.service, to ensure that https://bugs.debian.org/777113 did not come back. Also test interactively installing a package that ships a service, like "apache2", and verify that it starts properly after installation. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1576692/+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
