[Touch-packages] [Bug 2037281] Re: Shutdown when triggering daemon-reload eary in boot
** Description changed: In Ubuntu Core 20, and Ubuntu Core 22, we are encountering an issue where if a service, started earlier than devices are processed by udev, does `systemctl daemon-reload`, the system shuts down. This is due to devices for mounted filesystem temporarily taken dead, which pulls most units down. This was fixed by upstream in https://github.com/systemd/systemd/pull/23218. But this was not backported to the versions used by Ubuntu packages for focal and jammy. The needed commit from that PR is the one with message `core/device: ignore DEVICE_FOUND_UDEV bit on switching root`. This patch applies to 245.4-4ubuntu3.22 (focal) without rebasing needed. And I suppose it does also for jammy. I have manually tested the fix with Ubuntu Core 20, and this fixes our issue. We would like this patch to be backported to focal-updates and jammy- updates. Thank you in advance. + + + [ Impact ] + * An explanation of the effects of the bug on users and + * justification for backporting the fix to the stable release. + * In addition, it is helpful, but not required, to include an +explanation of how the upload fixes this bug. + + [ Test Plan ] + * detailed instructions how to reproduce the bug + * these should allow someone who is not familiar with the affected +package to reproduce the bug and verify that the updated package fixes +the problem. + * if other testing is appropriate to perform before landing this update, +this should also be described here. + + [ Where problems could occur ] + * Think about what the upload changes in the software. Imagine the change is +wrong or breaks something else: how would this show up? + * It is assumed that any SRU candidate patch is well-tested before +upload and has a low overall risk of regression, but it's important +to make the effort to think about what ''could'' happen in the +event of a regression. + * This must '''never''' be "None" or "Low", or entirely an argument as to why +your upload is low risk. + * This both shows the SRU team that the risks have been considered, +and provides guidance to testers in regression-testing the SRU. + + [ Other Info ] + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance -- 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/2037281 Title: Shutdown when triggering daemon-reload eary in boot Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Status in systemd source package in Jammy: New Bug description: In Ubuntu Core 20, and Ubuntu Core 22, we are encountering an issue where if a service, started earlier than devices are processed by udev, does `systemctl daemon-reload`, the system shuts down. This is due to devices for mounted filesystem temporarily taken dead, which pulls most units down. This was fixed by upstream in https://github.com/systemd/systemd/pull/23218. But this was not backported to the versions used by Ubuntu packages for focal and jammy. The needed commit from that PR is the one with message `core/device: ignore DEVICE_FOUND_UDEV bit on switching root`. This patch applies to 245.4-4ubuntu3.22 (focal) without rebasing needed. And I suppose it does also for jammy. I have manually tested the fix with Ubuntu Core 20, and this fixes our issue. We would like this patch to be backported to focal-updates and jammy- updates. Thank you in advance. [ Impact ] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [ Test Plan ] * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. * if other testing is appropriate to perform before landing this update, this should also be described here. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to
[Touch-packages] [Bug 1593407] Re: Guest session cannot run snaps
** Project changed: snappy => snapd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1593407 Title: Guest session cannot run snaps Status in Light Display Manager: Confirmed Status in snapd: Confirmed Status in Ubuntu MATE: Confirmed Status in Desktop: New Status in firefox package in Ubuntu: Confirmed Status in lightdm package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Confirmed Status in firefox source package in Xenial: Confirmed Status in lightdm source package in Xenial: Confirmed Status in snapd source package in Xenial: Confirmed Bug description: I'm using Ubuntu 16.04. The guest session cannot execute snaps, because of a permission error. The LightDM's guest session AppArmor profile is not allowing access to /snap and other needed files and folders. To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1593407/+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 1659719] Re: ssh can't call a binary from a snap without the full path
** Project changed: snappy => snapd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1659719 Title: ssh can't call a binary from a snap without the full path Status in snapd: Fix Committed Status in livecd-rootfs package in Ubuntu: Fix Released Status in openssh package in Ubuntu: Confirmed Status in pam package in Ubuntu: Fix Released Status in livecd-rootfs source package in Xenial: New Status in openssh source package in Xenial: Won't Fix Status in pam source package in Xenial: Fix Released Status in livecd-rootfs source package in Bionic: New Status in openssh source package in Bionic: Won't Fix Status in pam source package in Bionic: Fix Released Status in livecd-rootfs source package in Focal: New Status in openssh source package in Focal: Won't Fix Status in pam source package in Focal: Fix Released Status in livecd-rootfs source package in Groovy: Fix Released Status in openssh source package in Groovy: Won't Fix Status in pam source package in Groovy: Fix Released Status in openssh package in Debian: New Bug description: [impact] ssh can't call a binary from a snap, it will only work using the full path. [test case] Create a container. Install the go snap (and make sure golang-go is not installed). Run "ssh go version" and check the binary is found. [regression potential] It's a pam change an they are always a bit scary but the code follows the existing pattern for updating PATH in /etc/environment and has been tested in groovy. [original description] Let's say I have the hello snap installed in 192.168.122.24. Then: elopio@ubuntu-xenial:~/mosh$ ssh 192.168.122.24 hello elopio@192.168.122.24's password: bash: hello: command not found elopio@ubuntu-xenial:~/mosh$ ssh 192.168.122.24 /snap/bin/hello elopio@192.168.122.24's password: Hello, world! To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1659719/+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 1965328] Re: transient scope could not be started error in bionic lxd container
** Project changed: snappy => snapd -- 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/1965328 Title: transient scope could not be started error in bionic lxd container Status in snapd: New Status in systemd package in Ubuntu: Incomplete Bug description: On my impish development host machine I tend to use lxd containers to support snap building and other tasks targeting different releases. Today I came to use a bionic container as per usual and found that I could not invoke any snap applications. I installed hello-world as the most simple test of running a snap app: ``` ubuntu@b:~$ hello-world internal error, please report: running "hello-world" failed: transient scope could not be started, job /org/freedesktop/systemd1/job/44 finished with result failed ``` I made sure the container had up to date packages in it (apt & snaps) and rebooted it. But the problem persisted. I then created a second container and installed hello-world in it and again the problem was reproducible. At the time of producing the following attachments I had not attempted to reboot the host. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1965328/+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 1503680] Re: dhclient for eth0 does never exit and retries dhcp foerever
** Project changed: snappy => snapd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1503680 Title: dhclient for eth0 does never exit and retries dhcp foerever Status in snapd: Incomplete Status in isc-dhcp package in Ubuntu: Confirmed Bug description: When booting snappy without eth0 connected, dhclient runs forever trying to retrieve DHCP every 5 minutes. dhclient is run with the -1 parameter which is supposed to try only once and exit after trying. -1 Try to get a lease once. On failure exit with code 2. In DHCPv6 this sets the maximum duration of the initial exchange to timeout (from dhclient.conf(5) with a default of sixty seconds). Though dhclient keeps running / does not exit. If dhclient is changed to exit after failure, it must be insured that it will be restarted when the network interface gets a physical link. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1503680/+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 1650688] Re: timedatectl set-timezone fails on UC16
** Project changed: snappy => snapd -- 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/1650688 Title: timedatectl set-timezone fails on UC16 Status in snapd: Triaged Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Hirsute: Won't Fix Status in systemd source package in Impish: Won't Fix Status in systemd source package in Jammy: Fix Released Bug description: SRU === [Impact] * The bug prevents timedated from recognizing and correctly set the system's timezone when running Ubuntu Core 16, 18 and 20. * This causes by timedated fails to take Ubuntu Core's /etc/writable redirection into account. * The recognizing part is fixed by making the code take writable redirection into account. * The set part is fixed by making the code link to the absolute path instead of a relative one. * Currently core snaps worked around the set part by providing a wrapper script which re-create /etc/writable/localtime afterward. However this does not cover DBus users. [Test Plan] * On classics systems: ensure the proposed systemd package is installed. On Ubuntu Core systems: build a new core snap including proposed package, and install it. Replaces timedatectl with timedatectl.real to test skipping the wrapper. (Note that one can simulate core snap's /etc/writable redirection by running this image creation hook [1] on the system.) [1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu- core/hooks/08-etc-writable.chroot?h=ubuntu/focal * On freshly boot system: query the timezone using `timedatectl`. The timezone should corresponds to `readlink -f /etc/localtime` and does not show `n/a`. * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`. `readlink -f /etc/localtime` should points to an existing file. * Run `sudo systemctl restart systemd-timedated.service`. Then, query the timezone again: `timedatectl`. It should show the previously set timezone and not `n/a`. * Run `sudo systemctl status systemd-timedated.service`. This should show no sign of timedated crashing. [Where problems could occur] * It's possible that the redirection handling code will be sub-par and causes crash. However, it's not likely because the similar pieces of code is in the previous patch since Ubuntu 16.04. * If it does: the patched `get_timezone()` function is used in 2 places: the networkd's DHCP server [3] and the timedated itself. - Networkd is used primarily on servers where NetworkManage is absent. It's possible that this patch causes the user to loss access to the server due to networkd crash when setting up network interfaces, and requires physical access to fix. However, the code path is executed when DHCP is enabled only. I think it's not common for users to have networkd's DHCP server enabled: the feature seems to gear towards desktop users wanting to share internet connection, and in those cases they're more likely to use NetworkManager. - The timedated itself is likely used by the programs that involves in time-related functions. If a crash occur, in the worst case users won't be able to set time or timezone via timedated. However, users should still be able to e.g. set time using `date` or set timezone using /etc/localtime (assuming online guides still consider systems without systemd). Timedated is DBus-activated, and thus a crash should be self-healing. * The set part would also affects the clasic systems. However, I believe nothing else actually rely on /etc/localtime being a relative path, otherwise the /etc/writable redirection would causes even more problem, and would have been reported. [3] Yes, I'm surprised that there's a DHCP server inside systemd codebase. [Other Info] * This is also useful for UBports's Ubuntu Touch. We continue using system-image system where the rootfs is read-only, and thus is affected by this bug similarly to Ubuntu Core. I've tested the Focal version of the package on our (currently in development) Focal Ubuntu Touch image, and the fix works. [Original bug description] On a system running UC16, the file /etc/localtime is a link that points to /etc/writable/localtime. On a freshly installed system, /etc/writable/localtime is a fully- qualified link that points at /usr/share/zoneinfo/UTC. If timedatectl is used to set the timezone to something else, timedated updates the localtime symbolic link with a relative path to the zoneinfo directory, which results in an invalid link. $ sudo timedatectl set-timezone America/Detroit $ sudo timedatectl Local time: Fri 2016-12-16 18:18:49 EST
[Touch-packages] [Bug 1712312] Re: Cannot add secondary group to user
** Project changed: snappy => snapd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1712312 Title: Cannot add secondary group to user Status in snapd: Triaged Status in shadow package in Ubuntu: New Bug description: When I try and add 'docker' group as a secondary group to my user: sudo usermod -aG docker $USER usermod: /etc/group.2059: Read-only file system usermod: cannot lock /etc/group; try again later. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1712312/+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 1721223] Re: Networkd fail to set ip address between leases if ip address changes on UbuntuCore
** Project changed: snappy => snapd -- 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/1721223 Title: Networkd fail to set ip address between leases if ip address changes on UbuntuCore Status in snapd: Fix Committed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Released Status in systemd source package in Zesty: Won't Fix Status in systemd source package in Artful: Fix Released Bug description: [Impact] * networkd fails to renew a lease, specifically it fails to change IPv4 address via DHCP renew/rebind. * networkd relies on a kernel feature to promote secondary IPv4 address to primary, upon primary address lease expiry. * this sysctl tunable was not enabled by default in systemd. [Test Case] Add a device, and assign two IPv4 addresses. First one, with a short lease time. Second one, with a different ip and a longer lease time. Second one should be treated as secondary ip address, and upon expiry of the first one, should be promoted and become primary ip address. The below scripted instructions simulate this: sudo ip link add name testleases type dummy sudo ip address add 192.0.2.10/27 dev testleases \ valid_lft 5 preferred_lft 5 sudo ip address add 192.0.2.11/27 dev testleases \ valid_lft 11 preferred_lft 11 ip address list dev testleases | \ grep -q 'inet 192.0.2.10/27 scope global dynamic testleases' \ && echo ok || echo not ok ip address list dev testleases | \ grep -q 'inet 192.0.2.11/27 scope global secondary dynamic testleases' \ && echo ok || echo not ok sleep 6 ip address list dev testleases | \ grep -q 'inet 192.0.2.11/27 scope global dynamic testleases' \ && echo ok || echo not ok sudo ip link del dev testleases [Regression Potential] * This changes the default kernel behaviour, previously upon expiry of the primary address, secondary addresses were removed as well. Which is imho silly. * comparing networkd renewal with isc-dhcp renewal the semantics are quite different. Upon acquiring new ip address, isc-dhcp would instantly flush existing ip address, and add a new one. Networkd add the new address as secondary, and waits for old one to expire first before promoting / switching to using the new ip address. IMHO kernel should have an API to promote secondary ip address to a primary one. * This update also applies other safe-looking options, which are currently also already applied via sysctls shipped in other packages # Source route verification net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 # Do not accept source routing net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.all.accept_source_route = 0 # Enable hard and soft link protection fs.protected_hardlinks = 1 fs.protected_symlinks = 1 * This update also applies the following upstream/bufferbloat.net recommended setting # Fair Queue CoDel packet scheduler to fight bufferbloat net.core.default_qdisc = fq_codel * [~racb] There are complex network setups out there, such as HA with corosync/pacemaker, OpenStack Neutron, and that kind of thing. If this fix were SRU'd, will all of these things in the wild cope with this sysctl change? [Other Info] * Original bug report Hi there, we found a replicable issue that involves the Ubuntu Core networking and causes complete loss of connectivity. We run a custom board with ubuntu core: the architecure is amrhf. We replicated this issue with an official Ubuntu Core image on a Raspberry Pi: other platform was been tested. It shows that it is a snap core problem which interests networkd: we use the default network stack based on networkd + netplan. Below steps to replicate the issue. 1)Setup a dhcp server for lease of about some minutes (i.e 10 minutes). 2)Boot the board and wait for get an ip from dhcp server 3)Before the lease expires, set a reservation for a different ip address Depending on lease duration before the lease expires( for 10 minute we have 2 minutes before ), networkd configure the new address in addition to the previous one. When the lease expire both ip address ( the prevoius and the new one ) disappear from the interested network interface. Depending on lease duration before the second lease expires ( for 10 minure we have 2 minutes before ) networkd configure only the new ip address on the network interface and the ping toward an outside host work properly. During the test the dhcp server records correctly leases and their duration. We check directly from console the network interface setting with the tool ip, checking continuously the value for ip address and valid_lft fields for the interested network interface. Please note that if the ip address setting are the
[Touch-packages] [Bug 2012563] Re: unsupported mount options: 'nofail', 'nostrictatime', 'lazytime', and 'nolazytime'
This also affects "functionfs" that uses "uid=2000,gid=2000,no_disconnect=1,rmode=0550,fmode=0660 ". -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2012563 Title: unsupported mount options: 'nofail', 'nostrictatime', 'lazytime', and 'nolazytime' Status in apparmor package in Ubuntu: New Bug description: The following mount options are unsupported: 'nofail', 'nostrictatime', 'lazytime', and 'nolazytime'. Other mount options have mappings from options to bitflags in `parser/mount.cc`, and the bitflags themselves are defined in `parser/mount.h`. Should the aforementioned mount options be included as well, or is there a reason why they are excluded? snapd currently assumes that they are supported, resulting in an error from the apparmor parser when a snap is connected with those options. I'd be happy to file a PR to add these mappings if I knew what the new bitflags should be defined as, and if/how they should be used elsewhere. For completeness: 1) This is a question/bug regarding the source code from the 'ubuntu/devel' branch (and presumably other branches), not a particular release. 2) Same as 1). 3) I expected the apparmor parser to recognize the 'nofail', 'nostrictatime', 'laztime', and 'nolazytime' mount options. 4) The apparmor parser threw an error with message "unsupported mount options" (from within `parser/mount.cc`). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2012563/+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 1998001] Re: Missing tests from libdrm-tests
@Brian Once the archive is frozen this is not entirely trivial anymore as the command-not-found indexfile is stored in the now frozen archive mirror. It seems the easiest way to fix is: * uploading a higher version in the -updates pocket should fix the problem automatically, the database code (CommandNotFound/db/creator.py:_parse_single_commands_file()) should discard the content of older versions. There are some useful ways to control what commands are visible from the pkg, you could use "X-Cnf-Ignore-Commands: kms-universal-planes" on the "libdrm-tests" binary package stanza (see what-is-python for an example) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libdrm in Ubuntu. https://bugs.launchpad.net/bugs/1998001 Title: Missing tests from libdrm-tests Status in command-not-found: New Status in command-not-found package in Ubuntu: Confirmed Status in libdrm package in Ubuntu: Invalid Bug description: It is advertised by the OS that kms-universal-planes can be installed via libdrm-tests but this is false: $ kms-universal-planes Command 'kms-universal-planes' not found, but can be installed with: sudo apt install libdrm-tests $ sudo apt install libdrm-tests [sudo] password for stolk: Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: libdrm-tests 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 47.5 kB of archives. After this operation, 193 kB of additional disk space will be used. Get:1 http://ca.archive.ubuntu.com/ubuntu kinetic/universe amd64 libdrm-tests amd64 2.4.113-2 [47.5 kB] Fetched 47.5 kB in 0s (142 kB/s) Selecting previously unselected package libdrm-tests. (Reading database ... 308766 files and directories currently installed.) Preparing to unpack .../libdrm-tests_2.4.113-2_amd64.deb ... Unpacking libdrm-tests (2.4.113-2) ... Setting up libdrm-tests (2.4.113-2) ... $ kms-universal-planes Command 'kms-universal-planes' not found, but can be installed with: sudo apt install libdrm-tests OS: Ubuntu 22.10 To manage notifications about this bug go to: https://bugs.launchpad.net/command-not-found/+bug/1998001/+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 1994146] Re: [SRU] apparmor - Focal, Jammy
Fwiw, the code has landed in the upstream git repository in https://gitlab.com/apparmor/apparmor/-/merge_requests/858 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1994146 Title: [SRU] apparmor - Focal, Jammy Status in apparmor package in Ubuntu: Confirmed Status in apparmor source package in Focal: In Progress Status in apparmor source package in Jammy: Incomplete Bug description: [ Impact ] This is a SRU proposal for apparmor in Focal and Jammy. For focal, we want to SRU fixes for Bug 1964636 which introduces the capability upstream patches. We are also fixing Bug 1728130 and Bug 1993353 which are introducing full backport of abi from apparmor-3.0 and support for POSIX message queue rules, which are both a request from Honeywell. Note that specifically for message queue rules, we are overriding the abi behavior. Message queue mediation is not a part of the 2.13 abi we are pinning. Honeywell has a kernel that has message queue mediation, but their policy does not contain an abi specified, so when we pin the abi for a kernel that does not mediate message queue, it will break Honeywell's AppArmor policies. So we are making an exception: when abi is not specified in the policy, and the policy contain mqueue rules, we are enforcing mqueue rules. When the policy does not contain mqueue rules, then they are not being enforced. This is so we do not break Honeywell policies and we also are not breaking policies that were developed when there was no mqueue or abi support. For jammy, we are SRUing fixes for Bug 1993353 which adds message queue rules support. [ Test Plan ] This has been extensively tested by using QA Regression Tests[1] for AppArmor. All tests have passed and demonstrated AppArmor to be working as expected. We are also adding regression tests for message queue rules[2] which guarantees it is working as expected. [1] https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py [2] https://gitlab.com/apparmor/apparmor/-/merge_requests/858 [ Where problems could occur ] The message queue rules support could cause issues for AppArmor policies that were developed before there was support for mqueues, that's why we are also backporting abi support and pinning the abi on parser.conf on focal. Jammy already has the abi pinned for a kernel that does not have support for mqueue mediation. [ Other Info ] The patches for both focal and jammy can be found at: https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1994146/+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 1943077] Re: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s
** Changed in: snapd Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1943077 Title: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s Status in snapd: Fix Released Status in openssh package in Ubuntu: New Status in squashfs-tools package in Ubuntu: New Bug description: During current snapd autopkgtest, a failure can be observed: https://autopkgtest.ubuntu.com/results/autopkgtest- impish/impish/amd64/s/snapd/20210907_175258_5451b@/log.gz error: cannot pack "/home/gopath/src/github.com/snapcore/snapd/tests/smoke/sandbox/test-snapd-sandbox": mksquashfs call failed: - libgcc_s.so.1 must be installed for pthread_cancel to work Parallel mksquashfs: Using 1 processor Creating 4.0 filesystem on /home/gopath/src/github.com/snapcore/snapd/tests/smoke/sandbox/test-snapd-sandbox/test-snapd-sandbox_1.0_all.snap, block size 131072. - error: cannot read snap file: "/var/lib/snapd/snaps/.local-install-136125945" is not a snap or snapdir I traced the underlying call to the following: "/snap/snapd/current/lib/x86_64-linux-gnu/ld-2.23.so" "--library-path" "/snap/snapd/current/usr/local/lib:/snap/snapd/current/lib/x86_64-linux-gnu:/snap/snapd/current/usr/lib/x86_64-linux-gnu" "/snap/snapd/current/usr/bin/mksquashfs" asdf asdf.squashfs (the real call has more arguments, this is a simplified version that produces the failure) To observe this, one can create a VM based a cloud image from https://cloud-images.ubuntu.com/impish/current, then run the above command in the resulting environment. Doing so will test against snapd v2.51.4 (12883). Retesting with edge 2.52+git635.gada2d87 (13323) produces an equivalent result. Running a more bland `/snap/snapd/current/usr/bin/mksquashfs asdf asdf.squashfs` without messing with library paths has mksquashfs behaving as expected. Also, getting a v2.51.3 snapd seems to behave itself. Updating from 2.51.3 -> 2.51.4 also works. One can see a passing mksquashfs by taking libgcc_s.so.1 from hirsute and placing it in the library path for the above call. In the working scenario, it appears that libgcc_s is being obtained from outside of /snap (and also libz). In the failing scenario, this external copy of libgcc_s is not being loaded (per gdb info sharedlibrary), but libz still is. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1943077/+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 1959375] Re: [SRU] Please support group manipulation with "extrausers"
** Changed in: shadow (Ubuntu Bionic) Status: New => In Progress ** Changed in: shadow (Ubuntu Focal) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1959375 Title: [SRU] Please support group manipulation with "extrausers" Status in shadow package in Ubuntu: Fix Released Status in shadow source package in Bionic: In Progress Status in shadow source package in Focal: In Progress Status in shadow source package in Impish: Won't Fix Status in shadow source package in Jammy: Fix Released Bug description: [Impact] * In order to use the microk8s snap in Ubuntu Core, one currently needs to be root. This is far from optimal, since normally (on desktop and server installations) this is not necessary. * This make it hard to provide consistent documentation on microk8s across all supported device, if we have to take the "sudo" command into account, and how file permissions for generated files might be affected. [Test Plan] The issue can be reproduced on Ubuntu Core 18, 20 and 22. The steps are as following (replace "" with the actual path of your Ubuntu Core image file: qemu-system-x86_64 -enable-kvm -smp 2 -m 1500 \ -netdev user,id=mynet0,hostfwd=tcp::8022-:22,hostfwd=tcp::8090-:80 \ -device virtio-net-pci,netdev=mynet0 \ -drive file=,format=raw After configuring your account, connect to youd device via SSH: ssh @localhost -p 8022 And issue these commands sudo snap install microk8s --channel=latest/edge/stable # microk8s is going to eat up all your disk space, so stop it as soon # as the prompt comes back: sudo microk8s stop # Add your user to the microk8s group sudo usermod -G snap_microk8s $(whoami) The last command will fail unless this bug is fixed. If the bug is fixed, the command will succeed, and after logging out and in again, you can verify that you've been added to the snap_microk8s group by running the "groups" command. [Where problems could occur] * The patch only touches error code paths and adds a fallback mechanism in them. Therefore, "normal" operations, where these commands would have succeeded before, will not be affected at all. * In those cases when usermod fails because it failed to find or load the requested user/group, we reset the user/group database paths to our writable user/group databases, and retry the operation. Note that the path for our database is hardcoded in the program source, so the security risk seems contained. We do not add additional command-line parameters. [Other Info] Original bug description Currently doing something like: sudo usermod -a -G snap_microk8s dbeamonte on a Ubuntu Core system will fail with usermod: /etc/group.15965: Read-only file system This is because the existing usermod patches to detect the extrausers file do not cover this case. Attached a simple patch that enables it. I will give this patch a test run in our image PPA for jammy and if things look good I would like upload to 22.04 and SRU for 20.04 and 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1959375/+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 1959375] Re: [SRU] Please support group manipulation with "extrausers"
** Patch added: "debdiff for the PPA jammy test upload" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1959375/+attachment/5557912/+files/shadow_4.8.1-2ubuntu2~ppa1.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1959375 Title: [SRU] Please support group manipulation with "extrausers" Status in shadow package in Ubuntu: New Status in shadow source package in Bionic: New Status in shadow source package in Focal: New Status in shadow source package in Impish: New Status in shadow source package in Jammy: New Bug description: Currently doing something like: sudo usermod -a -G snap_microk8s dbeamonte on a Ubuntu Core system will fail with usermod: /etc/group.15965: Read-only file system This is because the existing usermod patches to detect the extrausers file do not cover this case. Attached a simple patch that enables it. I will give this patch a test run in our image PPA for jammy and if things look good I would like upload to 22.04 and SRU for 20.04 and 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1959375/+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 1959375] Re: [SRU] Please support group manipulation with "extrausers"
** Patch added: "Proposed (untested) patch" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1959375/+attachment/5557911/+files/shadow-lp1959375.diff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1959375 Title: [SRU] Please support group manipulation with "extrausers" Status in shadow package in Ubuntu: New Status in shadow source package in Bionic: New Status in shadow source package in Focal: New Status in shadow source package in Impish: New Status in shadow source package in Jammy: New Bug description: Currently doing something like: sudo usermod -a -G snap_microk8s dbeamonte on a Ubuntu Core system will fail with usermod: /etc/group.15965: Read-only file system This is because the existing usermod patches to detect the extrausers file do not cover this case. Attached a simple patch that enables it. I will give this patch a test run in our image PPA for jammy and if things look good I would like upload to 22.04 and SRU for 20.04 and 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1959375/+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 1959375] [NEW] [SRU] Please support group manipulation with "extrausers"
Public bug reported: Currently doing something like: sudo usermod -a -G snap_microk8s dbeamonte on a Ubuntu Core system will fail with usermod: /etc/group.15965: Read-only file system This is because the existing usermod patches to detect the extrausers file do not cover this case. Attached a simple patch that enables it. I will give this patch a test run in our image PPA for jammy and if things look good I would like upload to 22.04 and SRU for 20.04 and 18.04. ** Affects: shadow (Ubuntu) Importance: Undecided Status: New ** Affects: shadow (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: shadow (Ubuntu Focal) Importance: Undecided Status: New ** Affects: shadow (Ubuntu Impish) Importance: Undecided Status: New ** Affects: shadow (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1959375 Title: [SRU] Please support group manipulation with "extrausers" Status in shadow package in Ubuntu: New Status in shadow source package in Bionic: New Status in shadow source package in Focal: New Status in shadow source package in Impish: New Status in shadow source package in Jammy: New Bug description: Currently doing something like: sudo usermod -a -G snap_microk8s dbeamonte on a Ubuntu Core system will fail with usermod: /etc/group.15965: Read-only file system This is because the existing usermod patches to detect the extrausers file do not cover this case. Attached a simple patch that enables it. I will give this patch a test run in our image PPA for jammy and if things look good I would like upload to 22.04 and SRU for 20.04 and 18.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1959375/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
Fwiw, it looks like the latest core18 edge build that includes https://launchpad.net/ubuntu/+source/cloud-init/21.4-0ubuntu1~18.04.1 make the problem go away. It seems https://bugs.launchpad.net/cloud- init/+bug/1946003 is what caused it. The old code had a udev rule that would call into the cloud-init python code for each "net|block" device that got added that spiked the CPU when a block device was added which then made the race that seems to exist much more likely to appear. Given what Dan said above something deeper seems to be still lurking here that probably needs fixing (but will be harder to trigger now). -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
I attached the /run/cloud-init and /var/log/cloud-init logs of the good/bad run - I looked over the diff via "diff -u <(cut -f 4- -d: /tmp/cloud-init-good-core18-r2206/cloud-init.log) <(cut -f 4- -d: /tmp/cloud-init-bad-core18-r2208/cloud-init.log)" but couldn't see anything standing out there (but I'm really not a cloud-init guy). Alberto mentioned that latest cloud-init adds "hotplug" (https://github.com/canonical/cloud-init/pull/936) which might be related. -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
** Attachment added: "cloud-init logs for the "good" run" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+attachment/5542024/+files/cloud-init-good-core18-r2206.tar.gz -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
** Attachment added: "cloud-init logs for the "bad" run" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+attachment/5542025/+files/cloud-init-bad-core18-r2208.tar.gz -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
I spend a bit more time bisecting the various core18 snaps to see at
what revision the failure started to become reproducible. Interestingly
I found that it started with r2208 AFAICT. It's all a bit annoying
because it's a race so I don't trust it 100% but the previous r2206 got
2 good runs in a row but the r2208 failed also two times in a row. The
only change there is cloud-init
https://people.canonical.com/~mvo/core18-changes/html/edge/'20210928'r2206_'20210930'r2208.html
which might explain why we see the failure in our integration tests in
GCE but not inside QEMU. Unfortuantely the cloud-init diff is pretty
big.
For reference, here is what I ran:
"""
$ git status
On branch tests-use-core18-from-gce
Your branch is up to date with 'sergiocazzolato/tests-use-core18-from-gce'.
$ git describe
2.53.1-460-gd171d434ed
diff --git a/overlord/devicestate/devicestate.go
b/overlord/devicestate/devicestate.go
index d40b32bcbd..77ec3fc0a8 100644
--- a/overlord/devicestate/devicestate.go
+++ b/overlord/devicestate/devicestate.go
@@ -117,6 +117,8 @@ func canAutoRefresh(st *state.State) (bool, error) {
if !seeded {
return false, nil
}
+ // HACK
+ return false, nil
// Try to ensure we have an accurate time before doing any
// refreshy stuff. Note that this call will not block.
diff --git a/spread.yaml b/spread.yaml
index 0aef5dea7c..68cbdc09b7 100644
--- a/spread.yaml
+++ b/spread.yaml
@@ -37,7 +37,7 @@ environment:
MANAGED_DEVICE: "false"
# a global setting for LXD channel to use in the tests
LXD_SNAP_CHANNEL: "latest/edge"
-UBUNTU_IMAGE_SNAP_CHANNEL: "latest/candidate"
+UBUNTU_IMAGE_SNAP_CHANNEL: "beta/1.11"
CORE_CHANNEL: '$(HOST: echo "${SPREAD_CORE_CHANNEL:-edge}")'
BASE_CHANNEL: '$(HOST: echo "${SPREAD_BASE_CHANNEL:-edge}")'
KERNEL_CHANNEL: '$(HOST: echo "${SPREAD_KERNEL_CHANNEL:-edge}")'
diff --git a/tests/lib/prepare.sh b/tests/lib/prepare.sh
index e6b984c4d0..14b9608fb9 100755
--- a/tests/lib/prepare.sh
+++ b/tests/lib/prepare.sh
@@ -973,7 +973,26 @@ EOF
fi
if os.query is-core18; then
-curl -s -o core18.snap
https://storage.googleapis.com/snapd-spread-tests/snaps/core18_20211102_amd64.snap
+# GOOD
+#curl --insecure -o core18.snap
https://people.canonical.com/~mvo/tmp/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_2081.snap
+# GOOD
+#curl --insecure -o core18.snap
https://people.canonical.com/~mvo/tmp/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_2128.snap
+# BAD
+#curl --insecure -o core18.snap
https://people.canonical.com/~mvo/tmp/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_2239.snap
+# GOOD
+#curl --insecure -o core18.snap
https://people.canonical.com/~mvo/tmp/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_2141.snap
+# GOOD (3 good runs in a row)
+#curl --insecure -o core18.snap
https://people.canonical.com/~mvo/tmp/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_2191.snap
+# BAD
+#curl --insecure -o core18.snap
https://people.canonical.com/~mvo/tmp/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_2213.snap
+# BAD
+#curl --insecure -o core18.snap
https://people.canonical.com/~mvo/tmp/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_2228.snap
+# BAD
+#curl --insecure -o core18.snap
https://people.canonical.com/~mvo/tmp/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_2219.snap
+# BAD
+curl --insecure -o core18.snap
https://people.canonical.com/~mvo/tmp/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_2208.snap
+# GOOD (2 good run in a row)
+#curl --insecure -o core18.snap
https://people.canonical.com/~mvo/tmp/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_2206.snap
EXTRA_FUNDAMENTAL="$EXTRA_FUNDAMENTAL --snap $PWD/core18.snap"
fi
$ $GOPATH/bin/spread -repeat 2
google:ubuntu-core-18-64:tests/main/services-disabled-kept-happy
...
"""
Each run takes ~12min so it's a bit cumbersome.
--
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/1949089
Title:
systemd randomly fails to activate mount units in Ubuntu Core 18
Status in systemd package in Ubuntu:
New
Status in systemd source package in Bionic:
New
Bug description:
Since a month or so, we've been seeing random failures in our snapd
spread tests where systemd could not start the mount unit associated
with a snap because of a failed dependency.
The issue is described in the comments to PR
https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
here.
When starting a snap, snapd creates a mount unit to mount the snap's
squashfs (the template is
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
The snapd asks systemd to reload the configuration, and starts the
mount unit.
The failure we've observed is that sometimes systemd decides to stop
our mount unit (search for "Unmounting Mount unit for
[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
@Dan Thanks, this find about BindsTo is super interesting! It's not something that snapd writes out, it's curious where this comes from. -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
I spend a bit of quality time with this bug today and it seems there is (also?)
a kernel dimension to it. I ran the following:
"""
$ git status
On branch tests-use-core18-from-gce
Your branch is up to date with 'sergiocazzolato/tests-use-core18-from-gce'.
$ git diff
diff --git a/overlord/devicestate/devicestate.go
b/overlord/devicestate/devicestate.go
index d40b32bcbd..77ec3fc0a8 100644
--- a/overlord/devicestate/devicestate.go
+++ b/overlord/devicestate/devicestate.go
@@ -117,6 +117,8 @@ func canAutoRefresh(st *state.State) (bool, error) {
if !seeded {
return false, nil
}
+ // HACK
+ return false, nil
// Try to ensure we have an accurate time before doing any
// refreshy stuff. Note that this call will not block.
diff --git a/spread.yaml b/spread.yaml
index 0aef5dea7c..68cbdc09b7 100644
--- a/spread.yaml
+++ b/spread.yaml
@@ -37,7 +37,7 @@ environment:
MANAGED_DEVICE: "false"
# a global setting for LXD channel to use in the tests
LXD_SNAP_CHANNEL: "latest/edge"
-UBUNTU_IMAGE_SNAP_CHANNEL: "latest/candidate"
+UBUNTU_IMAGE_SNAP_CHANNEL: "beta/1.11"
CORE_CHANNEL: '$(HOST: echo "${SPREAD_CORE_CHANNEL:-edge}")'
BASE_CHANNEL: '$(HOST: echo "${SPREAD_BASE_CHANNEL:-edge}")'
KERNEL_CHANNEL: '$(HOST: echo "${SPREAD_KERNEL_CHANNEL:-edge}")'
diff --git a/tests/lib/prepare.sh b/tests/lib/prepare.sh
index e6b984c4d0..215d0611be 100755
--- a/tests/lib/prepare.sh
+++ b/tests/lib/prepare.sh
@@ -973,8 +973,8 @@ EOF
fi
if os.query is-core18; then
-curl -s -o core18.snap
https://storage.googleapis.com/snapd-spread-tests/snaps/core18_20211102_amd64.snap
-EXTRA_FUNDAMENTAL="$EXTRA_FUNDAMENTAL --snap $PWD/core18.snap"
+curl --insecure -o pc-kernel.snap
https://people.canonical.com/~mvo/tmp/pYVQrBcKmBa0mZ4CCN7ExT6jH8rY1hza_831.snap
+EXTRA_FUNDAMENTAL="$EXTRA_FUNDAMENTAL --snap $PWD/pc-kernel.snap"
fi
/snap/bin/ubuntu-image snap \
"""
which essentially moves the image to a 2 month older 4.14 kernel. With that I
could not reproduce the error for three subsequent runs of 2 repeats.
However when I disabled this code and use the current "18/edge" pc-
kernel (or stable, it's the same revision) then I can trigger the bug
right away.
--
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/1949089
Title:
systemd randomly fails to activate mount units in Ubuntu Core 18
Status in systemd package in Ubuntu:
New
Status in systemd source package in Bionic:
New
Bug description:
Since a month or so, we've been seeing random failures in our snapd
spread tests where systemd could not start the mount unit associated
with a snap because of a failed dependency.
The issue is described in the comments to PR
https://github.com/snapcore/snapd/pull/10935, but I'll summarize it
here.
When starting a snap, snapd creates a mount unit to mount the snap's
squashfs (the template is
https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205).
The snapd asks systemd to reload the configuration, and starts the
mount unit.
The failure we've observed is that sometimes systemd decides to stop
our mount unit (search for "Unmounting Mount unit for test-snapd-svc-
flip-flop" in the attached log), and then tries to reactivate it
again, and at that point it fails.
When I asked for help, Lukas pointed out that the latest update
contains a patch that is related to reload handling and mount units:
http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz
(the patch itself is better visible at
https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656).
When looking at the systemd git log, though, I noticed another patch
that was applied shortly after this one, which also seems related but
was not backported:
https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0
Since the stopping of our mount unit happens immediately after a
systemd reload, it actually seems very likely that the inclusion of
f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what
causes our woes (though, indeed, the issue is not reliably
reproducible, so we cannot be sure).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
About the question about Focal/hirsute/uc20 - we have not observed the issue there. -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Status in systemd source package in Jammy: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
Fwiw, the patch debian/lp1934147/0001-core-add-a-new-unit-method- catchup.patch is part of a fairly large patchset (https://github.com/systemd/systemd/pull/9200/commits) so maybe something is missing there? -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Status in systemd source package in Jammy: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
Just for the record, I also did another run with: https://storage.googleapis.com/snapd-spread- tests/snaps/core18_20211102_amd64.snap and that also fails right away: """ $ git status On branch tests-use-core18-from-gce Your branch is up to date with 'sergiocazzolato/tests-use-core18-from-gce'. $ git diff [empty] $ $GOPATH/bin/spread -repeat 100 google:ubuntu-core-18-64:tests/main/services-disabled-kept-happy ... 2021-11-08 12:13:57 Error executing google:ubuntu-core-18-64:tests/main/services-disabled-kept-happy (nov081101-381415) : - + . /home/gopath/src/github.com/snapcore/snapd/tests/lib/disabled-svcs.sh ++ SVC_MISSING_ERR_MSG='state.json is missing last-active-disabled-services in it:' + echo 'CASE 1' CASE 1 + echo 'Install the snap' Install the snap + snap install --dangerous disabled-svcs-kept_1.0_all.snap disabled-svcs-kept 1.0 installed + echo 'Check that state.json doesn'\''t contain last-active-disabled-services' Check that state.json doesn't contain last-active-disabled-services + check_state_json_no_disabled_svcs + /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/snapd-state check-state '.data.snaps."disabled-svcs-kept" | ."last-active-disabled-services"?' = null 'state.json has invalid last-active-disabled-services in it:' + echo 'CASE 2' CASE 2 + echo 'Disable a service in the snap' Disable a service in the snap + snap stop --disable disabled-svcs-kept.svc Stopped. + echo 'Check that it was actually disabled' Check that it was actually disabled + retry -n 10 --wait 1 sh -c 'snap services disabled-svcs-kept | MATCH "disabled-svcs-kept\\.svc\\s+disabled\\s+inactive"' + echo 'Check that state.json still doesn'\''t contain last-active-disabled-services' Check that state.json still doesn't contain last-active-disabled-services + check_state_json_no_disabled_svcs + /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/snapd-state check-state '.data.snaps."disabled-svcs-kept" | ."last-active-disabled-services"?' = null 'state.json has invalid last-active-disabled-services in it:' + echo 'Disable the whole snap' Disable the whole snap + snap disable disabled-svcs-kept disabled-svcs-kept disabled + echo 'Check that state.json DOES contain last-active-disabled-services' Check that state.json DOES contain last-active-disabled-services + check_state_json_yes_disabled_svcs + /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/snapd-state check-state '.data.snaps."disabled-svcs-kept" | ."last-active-disabled-services"?' '!=' null 'state.json has invalid last-active-disabled-services in it:' + echo 'Enable the whole snap' Enable the whole snap + snap enable disabled-svcs-kept disabled-svcs-kept enabled + echo 'Check that the service is still disabled' Check that the service is still disabled + MATCH 'disabled-svcs-kept\.svc\s+disabled\s+inactive' + snap services disabled-svcs-kept + echo 'Check that state.json still doesn'\''t contain last-active-disabled-services' Check that state.json still doesn't contain last-active-disabled-services + check_state_json_no_disabled_svcs + /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/snapd-state check-state '.data.snaps."disabled-svcs-kept" | ."last-active-disabled-services"?' = null 'state.json has invalid last-active-disabled-services in it:' + echo 'CASE 3' CASE 3 + echo 'Refresh the snap' Refresh the snap + snap install --dangerous disabled-svcs-kept_1.0_all.snap disabled-svcs-kept 1.0 installed + echo 'Check that the service is still disabled' Check that the service is still disabled + MATCH 'disabled-svcs-kept\.svc\s+disabled\s+inactive' + snap services disabled-svcs-kept + echo 'Check that state.json still doesn'\''t contain last-active-disabled-services' Check that state.json still doesn't contain last-active-disabled-services + check_state_json_no_disabled_svcs + /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/snapd-state check-state '.data.snaps."disabled-svcs-kept" | ."last-active-disabled-services"?' = null 'state.json has invalid last-active-disabled-services in it:' + echo 'CASE 4' CASE 4 + echo 'Revert the snap' Revert the snap + snap revert disabled-svcs-kept --revision=x1 disabled-svcs-kept reverted to 1.0 + echo 'Check that the service is still disabled' Check that the service is still disabled + MATCH 'disabled-svcs-kept\.svc\s+disabled\s+inactive' + snap services disabled-svcs-kept + echo 'Check that state.json still doesn'\''t contain last-active-disabled-services' Check that state.json still doesn't contain last-active-disabled-services + check_state_json_no_disabled_svcs + /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/snapd-state check-state '.data.snaps."disabled-svcs-kept" | ."last-active-disabled-services"?' = null 'state.json has invalid last-active-disabled-services in it:' + echo 'Refresh back to the new revision to unmark it as blacklisted' Refresh back to the new revision to unmark it as blacklisted + snap refresh disabled-svcs-kept --revision=x2
[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
Thanks Lukas for providing this revert of f0831ed2a03fcef582660be1c3b1a9f3e267e656. Using https://people.ubuntu.com/~slyon/uc18/core18_20211105_amd64.snap I can no longer reproduce the isue. To make it easier to reproduce what I did: """ $ git status On branch tests-use-core18-from-gce Your branch is up to date with 'sergiocazzolato/tests-use-core18-from-gce'. ... $ git diff diff --git a/tests/lib/prepare.sh b/tests/lib/prepare.sh index e6b984c4d0..5c58a55b2f 100755 --- a/tests/lib/prepare.sh +++ b/tests/lib/prepare.sh @@ -973,7 +973,7 @@ EOF fi if os.query is-core18; then -curl -s -o core18.snap https://storage.googleapis.com/snapd-spread-tests/snaps/core18_20211102_amd64.snap +curl -s -o core18.snap https://people.ubuntu.com/~slyon/uc18/core18_20211105_amd64.snap EXTRA_FUNDAMENTAL="$EXTRA_FUNDAMENTAL --snap $PWD/core18.snap" fi $ $GOPATH/bin/spread -repeat 100 google:ubuntu-core-18-64:tests/main/services-disabled-kept-happy ... 2021-11-08 11:39:41 Preparing google:ubuntu-core-18-64:tests/main/services-disabled-kept-happy (nov081028-580805)... 2021-11-08 11:39:53 Executing google:ubuntu-core-18-64:tests/main/services-disabled-kept-happy (nov081028-580805) (1/1)... 2021-11-08 11:40:49 Restoring google:ubuntu-core-18-64:tests/main/services-disabled-kept-happy (nov081028-580805)... 2021-11-08 11:41:00 Preparing google:ubuntu-core-18-64:tests/main/services-disabled-kept-happy (nov081028-580805)... ... """ To validate my findings I'm also running the same test against core18 in stable and it fails very quickly: """ $ git status HEAD detached at upstream/master $ git describe 2.53.1-480-g2c39794030 $ $GOPATH/bin/spread -repeat 100 google:ubuntu-core-18-64:tests/main/services-disabled-kept-happy 2021-11-08 11:58:46 Error executing google:ubuntu-core-18-64:tests/main/services-disabled-kept-happy (nov081048-716592) : - + . /home/gopath/src/github.com/snapcore/snapd/tests/lib/disabled-svcs.sh ++ SVC_MISSING_ERR_MSG='state.json is missing last-active-disabled-services in it:' + echo 'CASE 1' CASE 1 + echo 'Install the snap' Install the snap + snap install --dangerous disabled-svcs-kept_1.0_all.snap disabled-svcs-kept 1.0 installed + echo 'Check that state.json doesn'\''t contain last-active-disabled-services' Check that state.json doesn't contain last-active-disabled-services + check_state_json_no_disabled_svcs + /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/snapd-state check-state '.data.snaps."disabled-svcs-kept" | ."last-active-disabled-services"?' = null 'state.json has invalid last-active-disabled-services in it:' + echo 'CASE 2' CASE 2 + echo 'Disable a service in the snap' Disable a service in the snap + snap stop --disable disabled-svcs-kept.svc Stopped. + echo 'Check that it was actually disabled' Check that it was actually disabled + retry -n 10 --wait 1 sh -c 'snap services disabled-svcs-kept | MATCH "disabled-svcs-kept\\.svc\\s+disabled\\s+inactive"' + echo 'Check that state.json still doesn'\''t contain last-active-disabled-services' Check that state.json still doesn't contain last-active-disabled-services + check_state_json_no_disabled_svcs + /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/snapd-state check-state '.data.snaps."disabled-svcs-kept" | ."last-active-disabled-services"?' = null 'state.json has invalid last-active-disabled-services in it:' + echo 'Disable the whole snap' Disable the whole snap + snap disable disabled-svcs-kept disabled-svcs-kept disabled + echo 'Check that state.json DOES contain last-active-disabled-services' Check that state.json DOES contain last-active-disabled-services + check_state_json_yes_disabled_svcs + /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/snapd-state check-state '.data.snaps."disabled-svcs-kept" | ."last-active-disabled-services"?' '!=' null 'state.json has invalid last-active-disabled-services in it:' + echo 'Enable the whole snap' Enable the whole snap + snap enable disabled-svcs-kept disabled-svcs-kept enabled + echo 'Check that the service is still disabled' Check that the service is still disabled + MATCH 'disabled-svcs-kept\.svc\s+disabled\s+inactive' + snap services disabled-svcs-kept + echo 'Check that state.json still doesn'\''t contain last-active-disabled-services' Check that state.json still doesn't contain last-active-disabled-services + check_state_json_no_disabled_svcs + /home/gopath/src/github.com/snapcore/snapd/tests/lib/tools/snapd-state check-state '.data.snaps."disabled-svcs-kept" | ."last-active-disabled-services"?' = null 'state.json has invalid last-active-disabled-services in it:' + echo 'CASE 3' CASE 3 + echo 'Refresh the snap' Refresh the snap + snap install --dangerous disabled-svcs-kept_1.0_all.snap disabled-svcs-kept 1.0 installed + echo 'Check that the service is still disabled' Check that the service is still disabled + MATCH 'disabled-svcs-kept\.svc\s+disabled\s+inactive' + snap services
[Touch-packages] [Bug 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
We created a test PR that uses this core18 snap build in https://github.com/snapcore/snapd/pull/11015 - we are still running tests but it seems the error is still there :-( -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Jammy: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1505670] Re: "uncaptured python exception"
My apologizes that this totally was not on my radar. I applied the patch
(thank you!) and moved the code from bzr to git, added a gbp.conf and
pushed to GH for now (but maybe this really should go to salsa instead).
I hope I will be able to release a new .16 release with these changes
(and the most recent Debian NMU changes). Sorry again.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python2.7 in Ubuntu.
https://bugs.launchpad.net/bugs/1505670
Title:
"uncaptured python exception"
Status in python2.7 package in Ubuntu:
New
Status in squid-deb-proxy package in Ubuntu:
Confirmed
Status in python2.7 source package in Bionic:
New
Status in squid-deb-proxy source package in Bionic:
New
Status in python2.7 source package in Focal:
New
Status in squid-deb-proxy source package in Focal:
New
Bug description:
I get the following error when running the discovery script on the
command line.
$ /usr/share/squid-deb-proxy-client/apt-avahi-discover
error: uncaptured python exception, closing channel
('10.1.2.3', 3142): 2147483647 (:[Errno 111] Connection
refused [/usr/lib/python2.7/asyncore.py|read|83]
[/usr/lib/python2.7/asyncore.py|handle_read_event|446]
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
error: uncaptured python exception, closing channel
('10.0.3.1', 3142): 2147483647 (:[Errno 111] Connection
refused [/usr/lib/python2.7/asyncore.py|read|83]
[/usr/lib/python2.7/asyncore.py|handle_read_event|446]
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
error: uncaptured python exception, closing channel
('172.24.74.129', 3142): 2147483647 (:[Errno 111]
Connection refused [/usr/lib/python2.7/asyncore.py|read|83]
[/usr/lib/python2.7/asyncore.py|handle_read_event|446]
[/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
http://172.24.74.145:3142/
The last line still returns the proper proxy URI so as far as I can
tell things are still working. The IP 10.1.2.3 is for an n2n VPN.
This is on trusty with version 0.8.6ubuntu1.
To trigger the bug the environment setup needs to be in a specific way.
It seems for the problem to occur it need more than one host/IP discovered
via avahi. This can be probed via $ avahi-browse -kprtf _apt_proxy._tcp
and e.g. the common LXD setup of IPv4 + ipv6 is NOT enough to trigger it.
TODO: a sample output of the above command in an affected environment
could be helpful.
TODO: if possible outlining how the environment can be configured to
have this multi host/IP reply in avahi would be helpful as well.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1505670/+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 1920107] Re: Failed messages of sd-umoun show with reboot/shutdown
** Package changed: snapd (Ubuntu) => systemd (Ubuntu) -- 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/1920107 Title: Failed messages of sd-umoun show with reboot/shutdown Status in snapd: New Status in systemd package in Ubuntu: New Bug description: We were seeing the same sequence of errors heppened on KVM and ARM device running UC20: """ [12450.684692] sd-umoun[5922]: Failed to unmount /oldroot: Device or resource busy [12450.693515] sd-remou[5923]: Failed to remount '/oldroot/run/mnt/data' read-only: Device or resource busy [12450.704374] sd-umoun[5924]: Failed to unmount /oldroot/run/mnt/data: Device or resource busy [12450.714225] sd-umoun[5925]: Failed to unmount /oldroot/run: Device or resource busy [12450.726073] shutdown[1]: Could not detach loopback /dev/loop0: Device or resource busy [12450.735481] shutdown[1]: Failed to finalize file systems, loop devices, ignoring [12451.129165] reboot: Power down """ [Steps to reproduce] $ sudo poweroff or $ sudo reboot There are few issues may be relevant but the PR listed on below was not useful for this case. https://github.com/systemd/systemd/issues/14298 https://github.com/systemd/systemd/issues/14981 https://github.com/systemd/systemd/pull/15566 To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1920107/+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 1915250] Re: buildd file owner/group for shared libraries
Fwiw, mysql-8.0 is also affected: $ dpkg -c libmysqlclient21_8.0.23-3_amd64.deb|grep buildd drwxr-xr-x buildd/buildd 0 2021-02-11 10:32 ./ [many more] And some more: $ dpkg -c libqt5xdg3_3.6.0-1ubuntu2_amd64.deb |grep buildd -rw-r--r-- buildd/buildd 268440 2021-02-11 21:58 ./usr/lib/x86_64-linux-gnu/libQt5Xdg.so.3.6.0 But it seems to have stopped around Saturday, not sure if something was done on the buildds maybe? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1915250 Title: buildd file owner/group for shared libraries Status in binutils package in Ubuntu: Confirmed Status in debhelper package in Ubuntu: Confirmed Status in fakeroot package in Ubuntu: Confirmed Status in glibc package in Ubuntu: Confirmed Status in debhelper package in Debian: Unknown Bug description: the current state of -proposed creates deb packages with buildd file owner/group for shared libraries. reported at least for kwayland-integration. $ dpkg -c kwayland-integration_5.20.90-0ubuntu1_amd64.deb|grep \.so -rw-r--r-- doko/doko 18984 2021-01-21 23:44 ./usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kguiaddons/kmodifierkey/kmodifierkey_wayland.so -rw-r--r-- doko/doko 85392 2021-01-21 23:44 ./usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kwindowsystem/KF5WindowSystemKWaylandPlugin.so -rw-r--r-- doko/doko 35536 2021-01-21 23:44 ./usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/org.kde.kidletime.platforms/KF5IdleTimeKWaylandPlugin.so - in a release pocket, rebuild binutils from proposed. correctly restores the file ownership - in a release pocket, update glibc from proposed. then rebuild binutils from proposed. shows the wrong ownership To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1915250/+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 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
After discussing this we decided that we will leave cgroups v1 support for 21.04 because the snapd team will not be able to port all features to v2 in time. But early in the 21.10 cycle v1 is turned off and snapd needs to be ported to full v2 support. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in snapd: Confirmed Status in docker.io package in Ubuntu: Confirmed Status in lxc package in Ubuntu: Fix Released Status in lxcfs package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Fix Released Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1850667/+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 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
@rbalint Thanks for this heads up. Unfortunately we are not ready for cgroups v2. Snapd is working on v2 systems but a lot of the functionality is not ported. AIUI it requires quite a bit of work on our side and the two are quite different :/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in docker.io package in Ubuntu: New Status in lxc package in Ubuntu: Fix Released Status in lxcfs package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Fix Released Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1850667/+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 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
@rbalint Do you have a timeline when you plan this? The changes required make this most likely something we can only tackle during the 21.10 cycle :/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in docker.io package in Ubuntu: New Status in lxc package in Ubuntu: Fix Released Status in lxcfs package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Fix Released Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1850667/+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 1888575] Re: Split motd-news config into a new package
Just a quick observation about this update. If you have a minimal environment without the motd-news-config, e.g. a debootstrap chroot or the ubuntu core snap then there is now a new: /etc/default/motd-news.wasremoved after the first upgrade of base-files. The relevant base-files.postinst script has a comment like: ``` # special case of having /etc/default/motd-news removed by hand ... ``` which is slightly misleading because the file was not removed, it was never there :) Anyway, not a big deal, just something I noticed while looking at the core snap changes. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to base-files in Ubuntu. https://bugs.launchpad.net/bugs/1888575 Title: Split motd-news config into a new package Status in base-files package in Ubuntu: Fix Released Status in ubuntu-meta package in Ubuntu: Fix Released Status in base-files source package in Xenial: Fix Released Status in ubuntu-meta source package in Xenial: Fix Released Status in base-files source package in Bionic: Fix Released Status in ubuntu-meta source package in Bionic: Fix Released Status in base-files source package in Focal: Fix Released Status in ubuntu-meta source package in Focal: Fix Released Status in base-files source package in Groovy: Fix Released Status in ubuntu-meta source package in Groovy: Fix Released Bug description: [Impact] The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users. We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan: - move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files) - have ubuntu-server depend on motd-news-config - have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config- news package, ENABLED=0 must remain set. [Test Case] a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news apt install base-files - upgrades ubuntu-server - installs motd-news-config - /e/d/motd-news remains, motd-news remains enabled b) base-files installed, ubuntu-server installed, modified /e/d/motd-news apt install base-files - upgrades ubuntu-server - installs motd-news-config - /e/d/motd-news remains with the original modification c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news apt install base-files - upgrades base-files - removes /e/d/motd-news - motd-news is disabled d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news apt install base-files - upgrades base-files - /e/d/motd-news gets renamed to backup - motd-news is disabled e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends) f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file h) base-files installed, ubuntu-server installed, removed /e/d/motd-news - apt install base-files - upgrades base-files, upgrades ubuntu-server, installs motd-news-config - /e/d/motd-news is installed with ENABLED=0 i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news - apt install base-files - base-files is upgraded - no /e/d/motd-news is installed, motd-news remains disabled j) Perform a release upgrade from the previous ubuntu release to the one being tested while having ubuntu-server NOT installed (or use a desktop install). At the end, motd-news should be disabled. Verify with: $ sudo /etc/update-motd.d/50-motd-news --force $ (no output) [Regression Potential] This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here: a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case. b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package
[Touch-packages] [Bug 1776622] Re: snapd updates on focal never finish installing. Can't install any other updates.
This problem is triggered by incorrect "/var/lib/snapd/seed/seed.yaml" files. At various points during the development cycles they were incorrect and that has (almost) no effect on the live-cd or the installed system. However on the next snapd refresh it would trigger the hang people are experiencing. The hang is caused by services waiting for "snapd" to finish seeding but that never happens because the seed.yaml is incorrect. The best workaround is to $ sudo mv /var/lib/snapd/seed/seed.yaml /var/lib/snapd/seed/seed.yaml .disabled and re-run the upgrade. Versions of snapd from ~April 2020 will do this automatically for you if they detect a broken seed. So I will close this bug as fixed because there is an automatic workaround in snapd now. The tooling around the livecd got also improved AIUI so that incorrect seed.yaml should be much harder to create now. ** Changed in: snapd Status: Confirmed => Fix Released ** Changed in: snapd (Ubuntu) Status: Confirmed => Fix Released -- 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/1776622 Title: snapd updates on focal never finish installing. Can't install any other updates. Status in snapd: Fix Released Status in snapd package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Invalid Bug description: snapd (2.33+18.10ubuntu3) cosmic never finishes installing. Can't install any other updates. The first time I gave up waiting and killed it. Then... $ sudo apt full-upgrade E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem. $ sudo dpkg --configure -a Setting up snapd (2.33+18.10ubuntu3) ... snapd.snap-repair.service is a disabled or a static unit, not starting it. << never ends >> All the while the snap and snapd process use about 0.3% CPU (which is more than usual). WORKAROUND: sudo killall apt dpkg sudo dpkg -r snapd gnome-software-plugin-snap sudo apt update sudo apt full-upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1776622/+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 1875493] Re: [core] log rotation doesn't properly restart rsyslogd
Thanks for your bugreport. What happens is that rsyslog: - has a rsyslog.logrotate config file that has "postrotate" /usr/lib/rsyslog/rsyslog-rotate - the rsyslog-rotate has "systemctl kill -s HUP rsyslog.service" in it It looks like neither rsyslog.logrotate nor rsyslog-rotate have changed between both xenial (UC16) and focal (UC20). So this needs some deeper investigation, I don't think we can change the postrotate line for UC16 only without understanding if: a) does this affect ubuntu classic as well? b) if not, why is it only affecting core? We will also then SRU it (and maybe put in the ppa:snappy-dev/image to get testing in edge). But we need to stay in sync with xenial here. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1875493 Title: [core] log rotation doesn't properly restart rsyslogd Status in Snappy: New Status in rsyslog package in Ubuntu: New Bug description: One of our commercial partners is developing a device agent snap for UC16. One of their engineers just shared the following bug report: I wanted to give you a heads up on an issue that we encountered with one of our gateways (a Dell 3000) regarding a full disk (/writable). It seems as though rsyslog had a bad logrotate config and was holding on to deleted files as described here: - https://www.claudiokuenzler.com/blog/861/after-ubuntu-update-trusty-xenial-disk-filled-syslog-logrotate - https://bugzilla.redhat.com/show_bug.cgi?id=1713358 Both df and du where showing different results for the “/writable” path on the Dell gateway. We were able to copy the lsof binary over and found this: $ sudo /tmp/lsof | grep deleted ... rsyslogd 1765 syslog 5w REG 179,4 1993793536 130599 /var/log/syslog (deleted) rsyslogd 1765 syslog 6w REG 179,4 45056 130836 /var/log/auth.log (deleted) rsyslogd 1765 syslog 7w REG 179,4 211976192 130782 /var/log/kern.log (deleted) in:imuxso 1765 1776 syslog 5w REG 179,4 1993793536 130599 /var/log/syslog (deleted) in:imuxso 1765 1776 syslog 6w REG 179,4 45056 130836 /var/log/auth.log (deleted) in:imuxso 1765 1776 syslog 7w REG 179,4 211976192 130782 /var/log/kern.log (deleted) in:imklog 1765 1777 syslog 5w REG 179,4 1993793536 130599 /var/log/syslog (deleted) in:imklog 1765 1777 syslog 6w REG 179,4 45056 130836 /var/log/auth.log (deleted) in:imklog 1765 1777 syslog 7w REG 179,4 211976192 130782 /var/log/kern.log (deleted) rs:main 1765 1778 syslog 5w REG 179,4 1993793536 130599 /var/log/syslog (deleted) rs:main 1765 1778 syslog 6w REG 179,4 45056 130836 /var/log/auth.log (deleted) rs:main 1765 1778 syslog 7w REG 179,4 211976192 130782 /var/log/kern.log (deleted) ... Restarting the service freed up the deleted files / disk space: sudo service rsyslog restart The rsyslog config (/etc/logrotate.d/rsyslog) calls this script post rotate: /usr/lib/rsyslog/rsyslog-rotate Which does not actually kill the rsyslog process: admin@GR0GP42:~$ ps aux | grep rsyslog syslog 2305 0.7 0.1 262692 3432 ? Ssl 20:35 0:00 /usr/sbin/rsyslogd -n admin 2464 0.0 0.0 12984 932 pts/0 S+ 20:36 0:00 grep --color=auto rsyslog admin@GR0GP42:~$ sudo /usr/lib/rsyslog/rsyslog-rotate admin@GR0GP42:~$ ps aux | grep rsyslog syslog 2305 0.6 0.1 262692 3432 ? Ssl 20:35 0:00 /usr/sbin/rsyslogd -n admin 2469 0.0 0.0 12984 972 pts/0 S+ 20:36 0:00 grep --color=auto rsyslog The fix appears to be using the following command: sudo systemctl restart rsyslog >/dev/null 2>&1 || true admin@GR0GP42:~$ ps aux | grep rsyslog syslog 2305 0.6 0.1 262692 3432 ? Ssl 20:35 0:00 /usr/sbin/rsyslogd -n admin 2482 0.0 0.0 12984 972 pts/0 S+ 20:36 0:00 grep --color=auto rsyslog admin@GR0GP42:~$ sudo systemctl restart rsyslog >/dev/null 2>&1 || true admin@GR0GP42:~$ ps aux | grep rsyslog syslog 2487 1.0 0.1 262692 3432 ? Ssl 20:36 0:00 /usr/sbin/rsyslogd -n admin 2496 0.0 0.0 12984 980 pts/0 S+ 20:36 0:00 grep --color=auto rsyslog To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1875493/+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 1875493] Re: [core] log rotation doesn't properly restart rsyslogd
** Also affects: rsyslog (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1875493 Title: [core] log rotation doesn't properly restart rsyslogd Status in Snappy: New Status in rsyslog package in Ubuntu: New Bug description: One of our commercial partners is developing a device agent snap for UC16. One of their engineers just shared the following bug report: I wanted to give you a heads up on an issue that we encountered with one of our gateways (a Dell 3000) regarding a full disk (/writable). It seems as though rsyslog had a bad logrotate config and was holding on to deleted files as described here: - https://www.claudiokuenzler.com/blog/861/after-ubuntu-update-trusty-xenial-disk-filled-syslog-logrotate - https://bugzilla.redhat.com/show_bug.cgi?id=1713358 Both df and du where showing different results for the “/writable” path on the Dell gateway. We were able to copy the lsof binary over and found this: $ sudo /tmp/lsof | grep deleted ... rsyslogd 1765 syslog 5w REG 179,4 1993793536 130599 /var/log/syslog (deleted) rsyslogd 1765 syslog 6w REG 179,4 45056 130836 /var/log/auth.log (deleted) rsyslogd 1765 syslog 7w REG 179,4 211976192 130782 /var/log/kern.log (deleted) in:imuxso 1765 1776 syslog 5w REG 179,4 1993793536 130599 /var/log/syslog (deleted) in:imuxso 1765 1776 syslog 6w REG 179,4 45056 130836 /var/log/auth.log (deleted) in:imuxso 1765 1776 syslog 7w REG 179,4 211976192 130782 /var/log/kern.log (deleted) in:imklog 1765 1777 syslog 5w REG 179,4 1993793536 130599 /var/log/syslog (deleted) in:imklog 1765 1777 syslog 6w REG 179,4 45056 130836 /var/log/auth.log (deleted) in:imklog 1765 1777 syslog 7w REG 179,4 211976192 130782 /var/log/kern.log (deleted) rs:main 1765 1778 syslog 5w REG 179,4 1993793536 130599 /var/log/syslog (deleted) rs:main 1765 1778 syslog 6w REG 179,4 45056 130836 /var/log/auth.log (deleted) rs:main 1765 1778 syslog 7w REG 179,4 211976192 130782 /var/log/kern.log (deleted) ... Restarting the service freed up the deleted files / disk space: sudo service rsyslog restart The rsyslog config (/etc/logrotate.d/rsyslog) calls this script post rotate: /usr/lib/rsyslog/rsyslog-rotate Which does not actually kill the rsyslog process: admin@GR0GP42:~$ ps aux | grep rsyslog syslog 2305 0.7 0.1 262692 3432 ? Ssl 20:35 0:00 /usr/sbin/rsyslogd -n admin 2464 0.0 0.0 12984 932 pts/0 S+ 20:36 0:00 grep --color=auto rsyslog admin@GR0GP42:~$ sudo /usr/lib/rsyslog/rsyslog-rotate admin@GR0GP42:~$ ps aux | grep rsyslog syslog 2305 0.6 0.1 262692 3432 ? Ssl 20:35 0:00 /usr/sbin/rsyslogd -n admin 2469 0.0 0.0 12984 972 pts/0 S+ 20:36 0:00 grep --color=auto rsyslog The fix appears to be using the following command: sudo systemctl restart rsyslog >/dev/null 2>&1 || true admin@GR0GP42:~$ ps aux | grep rsyslog syslog 2305 0.6 0.1 262692 3432 ? Ssl 20:35 0:00 /usr/sbin/rsyslogd -n admin 2482 0.0 0.0 12984 972 pts/0 S+ 20:36 0:00 grep --color=auto rsyslog admin@GR0GP42:~$ sudo systemctl restart rsyslog >/dev/null 2>&1 || true admin@GR0GP42:~$ ps aux | grep rsyslog syslog 2487 1.0 0.1 262692 3432 ? Ssl 20:36 0:00 /usr/sbin/rsyslogd -n admin 2496 0.0 0.0 12984 980 pts/0 S+ 20:36 0:00 grep --color=auto rsyslog To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1875493/+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 1869629] Re: please add /etc/mdns.allow to /etc/apparmor.d/abstractions/mdns
** Changed in: snapd Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1869629 Title: please add /etc/mdns.allow to /etc/apparmor.d/abstractions/mdns Status in snapd: Triaged Status in apparmor package in Ubuntu: Fix Committed Status in chrony package in Ubuntu: Invalid Bug description: In focal users of mdns get denials in apparmor confined applications. An exampel can be found in the original bug below. It seems it is a common pattern, see https://github.com/lathiat/nss-mdns#etcmdnsallow Therefore I'm asking to add /etc/mdns.allow r, to the file /etc/apparmor.d/abstractions/mdns" by default. --- original bug --- Many repetitions of audit: type=1400 audit(1585517168.705:63): apparmor="DENIED" operation="open" profile="/usr/sbin/chronyd" name="/etc/mdns.allow" pid=1983815 comm="chronyd" requested_mask="r" denied_mask="r" fsuid=123 ouid=0 in log. I use libnss-mdns for .local name resolution, so /etc/nsswitch.conf contains hosts: files mdns [NOTFOUND=return] myhostname dns and /etc/mnds.allow contains the domains to resolve with mDNS (in may case, "local." and "local"; see /usr/share/doc/libnss- mdns/README.html.) Presumably cronyd calls a gethostbyX() somewhere, thus eventually trickling down through the name service switch and opening /etc/mdns.allow, which the AppArmor profile in the chrony package does not allow. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: chrony 3.5-6ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24 Uname: Linux 5.4.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu21 Architecture: amd64 Date: Sun Mar 29 15:02:39 2020 InstallationDate: Installed on 2020-03-26 (3 days ago) InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200326) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: chrony UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1869629/+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 1869661] [NEW] lxc 3.23 (?) breaks nested lxd with snaps
Public bug reported: It looks like the latest release of lxd broke our snapd lxd test. The failure looks like it's lxd itself that can no longer run a nested lxd. The full log is available on e.g. https://api.travis-ci.org/v3/job/668138958/log.txt, search for """ Starting my-inner-ubuntu + MATCH from-the-INSIDE-inside + lxd.lxc exec my-nesting-ubuntu -- lxd.lxc exec my-inner-ubuntu -- echo from-the-INSIDE-inside Error: EOF grep error: pattern not found, got: """ The relevant part of the test is: https://github.com/snapcore/snapd/blob/master/tests/main/lxd/task.yaml#L153 I.e. this test creates an lxd container and sets up lxd inside this container. Happy to help with debugging (if needed), it really easy to reproduce with the above spread script. ** Affects: lxc (Ubuntu) Importance: Undecided Status: New ** Summary changed: - lxc 3.23 breaks nested lxd with snaps + lxc 3.23 (?) breaks nested lxd with snaps -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1869661 Title: lxc 3.23 (?) breaks nested lxd with snaps Status in lxc package in Ubuntu: New Bug description: It looks like the latest release of lxd broke our snapd lxd test. The failure looks like it's lxd itself that can no longer run a nested lxd. The full log is available on e.g. https://api.travis-ci.org/v3/job/668138958/log.txt, search for """ Starting my-inner-ubuntu + MATCH from-the-INSIDE-inside + lxd.lxc exec my-nesting-ubuntu -- lxd.lxc exec my-inner-ubuntu -- echo from-the-INSIDE-inside Error: EOF grep error: pattern not found, got: """ The relevant part of the test is: https://github.com/snapcore/snapd/blob/master/tests/main/lxd/task.yaml#L153 I.e. this test creates an lxd container and sets up lxd inside this container. Happy to help with debugging (if needed), it really easy to reproduce with the above spread script. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1869661/+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 1869330] [NEW] Hangs after eoan -> focal release upgrade on shutdown
Public bug reported: Hi, I upgraded one of my machines from eoan to focal today and the reboot after the upgrade hang with: ``` A stop job s running for Service for snap application lxd.daemon (xxx / 10min) ``` Attached is the output of "sudo journalctl -u snap.lxd.daemon.service" This machines does not use lxd heavily but it does have a running snapcraft-core20-test container ** Affects: lxc (Ubuntu) Importance: Undecided Status: New ** Attachment added: "journalctl.lxd.daemon.service" https://bugs.launchpad.net/bugs/1869330/+attachment/5342064/+files/journalctl.lxd.daemon.service -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1869330 Title: Hangs after eoan -> focal release upgrade on shutdown Status in lxc package in Ubuntu: New Bug description: Hi, I upgraded one of my machines from eoan to focal today and the reboot after the upgrade hang with: ``` A stop job s running for Service for snap application lxd.daemon (xxx / 10min) ``` Attached is the output of "sudo journalctl -u snap.lxd.daemon.service" This machines does not use lxd heavily but it does have a running snapcraft-core20-test container To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1869330/+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 1865055] Re: package libip4tc-dev 1.8.3-2ubuntu5 failed to install/upgrade: trying to overwrite '/usr/include/libiptc/ipt_kernel_headers.h', which is also in package libiptc-dev:
** Tags added: champagne ** Changed in: iptables (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1865055 Title: package libip4tc-dev 1.8.3-2ubuntu5 failed to install/upgrade: trying to overwrite '/usr/include/libiptc/ipt_kernel_headers.h', which is also in package libiptc-dev:amd64 1.8.3-2ubuntu5 Status in iptables package in Ubuntu: Confirmed Bug description: Running standard upgrades in focal. Unpacking libip4tc-dev:amd64 (1.8.4-3ubuntu1) over (1.8.3-2ubuntu5) ... dpkg: error processing archive /tmp/apt-dpkg-install-vyGukq/07-libip4tc-dev_1.8.4-3ubuntu1_amd64.deb (--unpack): trying to overwrite '/usr/include/libiptc/ipt_kernel_headers.h', which is also in package libiptc-dev:amd64 1.8.3-2ubuntu5 dpkg: considering deconfiguration of libip4tc-dev:amd64, which would be broken by installation of libiptc-dev:amd64 ... dpkg: yes, will deconfigure libip4tc-dev:amd64 (broken by libiptc-dev:amd64) Preparing to unpack .../08-libiptc-dev_1.8.4-3ubuntu1_amd64.deb ... De-configuring libip4tc-dev:amd64 (1.8.3-2ubuntu5) ... Left my system in this state... $ sudo apt dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: gobject-introspection : Depends: libgirepository-1.0-1 (= 1.63.2-1) but 1.62.0-4ubuntu2 is installed hplip : Depends: hplip-data (= 3.19.12+dfsg0-4ubuntu1) but 3.19.12+dfsg0-3 is installed Depends: libhpmud0 (= 3.19.12+dfsg0-4ubuntu1) but 3.19.12+dfsg0-3 is installed Depends: printer-driver-hpcups (= 3.19.12+dfsg0-4ubuntu1) but 3.19.12+dfsg0-3 is installed libcryptsetup-dev : Depends: libcryptsetup12 (= 2:2.2.2-3ubuntu1) but 2:2.2.2-2ubuntu1 is installed libgirepository1.0-dev : Depends: libgirepository-1.0-1 (= 1.63.2-1) but 1.62.0-4ubuntu2 is installed Depends: gir1.2-glib-2.0 (= 1.63.2-1) but 1.62.0-4ubuntu2 is installed Depends: gir1.2-freedesktop (= 1.63.2-1) but 1.62.0-4ubuntu2 is installed libip4tc-dev : Depends: libip4tc2 (= 1.8.3-2ubuntu5) but 1.8.4-3ubuntu1 is installed libiptc-dev : Depends: libip4tc-dev (= 1.8.4-3ubuntu1) but 1.8.3-2ubuntu5 is installed Breaks: libip4tc-dev (< 1.8.4-2) but 1.8.3-2ubuntu5 is installed libnss-systemd : Depends: systemd (= 244.3-1ubuntu1) libpam-systemd : Depends: systemd (= 244.3-1ubuntu1) libsmbclient : Depends: samba-libs (= 2:4.11.5+dfsg-1ubuntu2) but 2:4.11.1+dfsg-3ubuntu2 is installed Depends: libwbclient0 (= 2:4.11.5+dfsg-1ubuntu2) but 2:4.11.1+dfsg-3ubuntu2 is installed libsystemd-dev : Depends: libsystemd0 (= 244.3-1ubuntu1) but 244.1-0ubuntu2 is installed libudev-dev : Depends: libudev1 (= 244.3-1ubuntu1) but 244.1-0ubuntu2 is installed python3-ldb : Depends: libldb2 (= 2:2.0.8-1ubuntu1) but 2:2.0.7-4 is installed python3-samba : Depends: samba-libs (= 2:4.11.5+dfsg-1ubuntu2) but 2:4.11.1+dfsg-3ubuntu2 is installed Depends: libldb2 (>= 2:2.0.8~) but 2:2.0.7-4 is installed Depends: libwbclient0 (= 2:4.11.5+dfsg-1ubuntu2) but 2:4.11.1+dfsg-3ubuntu2 is installed samba-common-bin : Depends: samba-libs (= 2:4.11.5+dfsg-1ubuntu2) but 2:4.11.1+dfsg-3ubuntu2 is installed Depends: libwbclient0 (= 2:4.11.5+dfsg-1ubuntu2) but 2:4.11.1+dfsg-3ubuntu2 is installed systemd-sysv : Depends: systemd (= 244.3-1ubuntu1) ProblemType: Package DistroRelease: Ubuntu 20.04 Package: libip4tc-dev 1.8.3-2ubuntu5 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Thu Feb 27 10:28:46 2020 ErrorMessage: trying to overwrite '/usr/include/libiptc/ipt_kernel_headers.h', which is also in package libiptc-dev:amd64 1.8.3-2ubuntu5 InstallationDate: Installed on 2019-04-05 (327 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190405) Python3Details: /usr/bin/python3.8, Python 3.8.2rc1, python3-minimal, 3.8.0-3ubuntu1 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu2 apt 1.9.8 SourcePackage: iptables Title: package libip4tc-dev 1.8.3-2ubuntu5 failed to install/upgrade: trying to overwrite '/usr/include/libiptc/ipt_kernel_headers.h', which is also in package libiptc-dev:amd64 1.8.3-2ubuntu5 UpgradeStatus: Upgraded to focal on 2019-11-21 (97 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1865055/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe :
[Touch-packages] [Bug 1840375] Re: groupdel doesn't support extrausers
** Description changed:
snapd needs the ability to call 'groupdel --extrausers foo' to clean up
after itself, but --extrausers is currently unsupported.
[Impact]
On ubuntu-core systems we want to be able to manage "extrausers" in the same
way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
This is an important feature for Ubuntu Core
[Test Case]
0. upgrade the "passwd" to the version in {xenial,bionic}-proposed
1. install the libnss-extrausers and configure it (see
/usr/share/doc/libnss-extrausers/README for the modifications in sswitch.conf)
- 2. run "groupadd --extrausers foo"
+ 2. run "groupadd --extrausers foo" and verify "grep foo
/var/lib/extrausers/group"
3 check /var/lib/extrausers/group for the new "foo" group
4. run "groupdel --extrausers foo"
5. check /var/lib/extrausers/group and ensure the "foo" group is removed
[Regression Potential]
* low: this adds a new (optional) option which is off by default
** Description changed:
snapd needs the ability to call 'groupdel --extrausers foo' to clean up
after itself, but --extrausers is currently unsupported.
[Impact]
On ubuntu-core systems we want to be able to manage "extrausers" in the same
way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
This is an important feature for Ubuntu Core
[Test Case]
0. upgrade the "passwd" to the version in {xenial,bionic}-proposed
- 1. install the libnss-extrausers and configure it (see
/usr/share/doc/libnss-extrausers/README for the modifications in sswitch.conf)
+ 1. install the libnss-extrausers and add "extrauers" to the passwd and shadow
line (see /usr/share/doc/libnss-extrausers/README for the modifications in
sswitch.conf)
2. run "groupadd --extrausers foo" and verify "grep foo
/var/lib/extrausers/group"
3 check /var/lib/extrausers/group for the new "foo" group
4. run "groupdel --extrausers foo"
5. check /var/lib/extrausers/group and ensure the "foo" group is removed
[Regression Potential]
* low: this adds a new (optional) option which is off by default
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1840375
Title:
groupdel doesn't support extrausers
Status in snapd:
Triaged
Status in shadow package in Ubuntu:
Fix Released
Status in shadow source package in Xenial:
Fix Committed
Status in shadow source package in Bionic:
Fix Committed
Status in shadow source package in Disco:
Fix Committed
Bug description:
snapd needs the ability to call 'groupdel --extrausers foo' to clean
up after itself, but --extrausers is currently unsupported.
[Impact]
On ubuntu-core systems we want to be able to manage "extrausers" in the same
way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
This is an important feature for Ubuntu Core
[Test Case]
0. upgrade the "passwd" to the version in {xenial,bionic}-proposed
1. install the libnss-extrausers and add "extrauers" to the passwd and shadow
line (see /usr/share/doc/libnss-extrausers/README for the modifications in
sswitch.conf)
2. run "groupadd --extrausers foo" and verify "grep foo
/var/lib/extrausers/group"
3 check /var/lib/extrausers/group for the new "foo" group
4. run "groupdel --extrausers foo"
5. check /var/lib/extrausers/group and ensure the "foo" group is removed
[Regression Potential]
* low: this adds a new (optional) option which is off by default
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1840375/+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 1840375] Re: groupdel doesn't support extrausers
** Description changed:
snapd needs the ability to call 'groupdel --extrausers foo' to clean up
after itself, but --extrausers is currently unsupported.
- [Impact]
+ [Impact]
On ubuntu-core systems we want to be able to manage "extrausers" in the same
way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
This is an important feature for Ubuntu Core
[Test Case]
+ 0. upgrade the "passwd" to the version in {xenial,bionic}-proposed
1. install the libnss-extrausers and configure it
2. run "groupadd --extrausers foo"
3 check /var/lib/extrausers/group for the new "foo" group
4. run "groupdel --extrausers foo"
5. check /var/lib/extrausers/group and ensure the "foo" group is removed
[Regression Potential]
- * low: this adds a new (optional) option which is off by default
+ * low: this adds a new (optional) option which is off by default
** Description changed:
snapd needs the ability to call 'groupdel --extrausers foo' to clean up
after itself, but --extrausers is currently unsupported.
[Impact]
On ubuntu-core systems we want to be able to manage "extrausers" in the same
way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
This is an important feature for Ubuntu Core
[Test Case]
0. upgrade the "passwd" to the version in {xenial,bionic}-proposed
- 1. install the libnss-extrausers and configure it
+ 1. install the libnss-extrausers and configure it (see
/usr/share/doc/libnss-extrausers/README for the modifications in sswitch.conf)
2. run "groupadd --extrausers foo"
3 check /var/lib/extrausers/group for the new "foo" group
4. run "groupdel --extrausers foo"
5. check /var/lib/extrausers/group and ensure the "foo" group is removed
[Regression Potential]
* low: this adds a new (optional) option which is off by default
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1840375
Title:
groupdel doesn't support extrausers
Status in snapd:
Triaged
Status in shadow package in Ubuntu:
Fix Released
Status in shadow source package in Xenial:
Fix Committed
Status in shadow source package in Bionic:
Fix Committed
Status in shadow source package in Disco:
Fix Committed
Bug description:
snapd needs the ability to call 'groupdel --extrausers foo' to clean
up after itself, but --extrausers is currently unsupported.
[Impact]
On ubuntu-core systems we want to be able to manage "extrausers" in the same
way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
This is an important feature for Ubuntu Core
[Test Case]
0. upgrade the "passwd" to the version in {xenial,bionic}-proposed
1. install the libnss-extrausers and configure it (see
/usr/share/doc/libnss-extrausers/README for the modifications in sswitch.conf)
2. run "groupadd --extrausers foo"
3 check /var/lib/extrausers/group for the new "foo" group
4. run "groupdel --extrausers foo"
5. check /var/lib/extrausers/group and ensure the "foo" group is removed
[Regression Potential]
* low: this adds a new (optional) option which is off by default
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1840375/+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 1659534] Re: userdel doesn't supports extrausers
** Changed in: shadow (Ubuntu Cosmic) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1659534 Title: userdel doesn't supports extrausers Status in Snappy: Fix Released Status in shadow package in Ubuntu: Fix Released Status in shadow source package in Xenial: Fix Released Status in shadow source package in Bionic: Fix Released Status in shadow source package in Cosmic: Won't Fix Bug description: TEST CASE: - run userdel --extrausers foo on a ubuntu core system REGRESSION POTENTIAL: - low, this option will only take effect when "userdel --extrauser" is used. On an Ubuntu Core system is impossible to delete an user from the extrausers db: root@localhost:/# userdel --extrausers alice userdel: unrecognized option '--extrausers' To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1659534/+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 1861177] Re: seccomp_rule_add is very slow
** Changed in: snapd Status: New => Triaged ** Changed in: snapd Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Triaged Status in libseccomp package in Ubuntu: Triaged Bug description: There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1778936] Re: please re-add Support-system-image-read-only-etc.patch
** Changed in: systemd (Ubuntu Focal) Importance: Critical => High ** Patch added: "debdiff for 20.04 with the proposed fix" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936/+attachment/5318599/+files/systemd_244-3ubuntu2.debdiff -- 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/1778936 Title: please re-add Support-system-image-read-only-etc.patch Status in systemd package in Ubuntu: Triaged Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Focal: Triaged Bug description: [Impact] * core18 systems fail to update hostname * this happens due to /etc/hostname actually being a symlink to a file under /etc/writable/, adjust hostnamed to take that into account when trying to update /etc/hostname [Test Case] * run a core18 system, check that dhcp acquire hostname is correctly updated in /etc/writable/hostname [Regression Potential] * This is cherrypick of code that has gone missing since xenial. * There is no change of behaviour for the classic systems. * Currently, core18 systems simply fail to update hostname/machine-info files, thus the worst case is that they will still fail to do so. [Other Info] * original bug report The 16.04 version of systemd had a patch to support the read-only etc. For core18 we will also need this change because core18 is still not on a fully writable etc. I will attach a debdiff against the current bionic version of systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936/+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 1778936] Re: please re-add Support-system-image-read-only-etc.patch
** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: Fix Released ** Changed in: systemd (Ubuntu Focal) Status: Fix Released => Triaged ** Changed in: systemd (Ubuntu Focal) Importance: Undecided => Critical -- 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/1778936 Title: please re-add Support-system-image-read-only-etc.patch Status in systemd package in Ubuntu: Triaged Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Focal: Triaged Bug description: [Impact] * core18 systems fail to update hostname * this happens due to /etc/hostname actually being a symlink to a file under /etc/writable/, adjust hostnamed to take that into account when trying to update /etc/hostname [Test Case] * run a core18 system, check that dhcp acquire hostname is correctly updated in /etc/writable/hostname [Regression Potential] * This is cherrypick of code that has gone missing since xenial. * There is no change of behaviour for the classic systems. * Currently, core18 systems simply fail to update hostname/machine-info files, thus the worst case is that they will still fail to do so. [Other Info] * original bug report The 16.04 version of systemd had a patch to support the read-only etc. For core18 we will also need this change because core18 is still not on a fully writable etc. I will attach a debdiff against the current bionic version of systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936/+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 1826473] Re: package ubuntu-core-launcher 2.38 failed to install/upgrade: problemas de dependencias - se deja sin configurar
The real issue is: """ Configurando udev (229-4ubuntu21.21) ... addgroup: El grupo `input' ya existe como grupo del sistema. Saliendo. update-initramfs: deferring update (trigger activated) insserv: warning: script 'K07smfpd' missing LSB tags and overrides insserv: warning: script 'smfpd' missing LSB tags and overrides insserv: There is a loop at service plymouth if started insserv: There is a loop between service plymouth and procps if started insserv: loop involving service procps at depth 2 insserv: loop involving service udev at depth 1 insserv: There is a loop at service smfpd if started insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on plymouth and therefore on system facility
[Touch-packages] [Bug 1847570] Re: PulseAudio automatically switches to HDMI sound output on login
** Bug watch added: PulseAudio #749 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/749 ** Also affects: pulseaudio via https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/749 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1847570 Title: PulseAudio automatically switches to HDMI sound output on login Status in PulseAudio: Unknown Status in pulseaudio package in Ubuntu: Confirmed Bug description: On my freshly installed eoan system I have two output devices: - HDMI/DisplayPort 2 - GK208 ... - Line Out - Family 17h ... When I login into the system pulseaudio always select the "wrong" one (HDMI) and I need to go to gnome-settings/Sound/Output Device and switch to "line out". This applies to every login/logout not just reboots. I would be good if it would remember this choice so that I have to do it only once. Or maybe (if that is technically possible) just output on both output devices by default - this would be even more user friendly for newbies who will have a hard time finding the right place to change this (or maybe have UI in the volume slider to select outputs if there are more than one? But anyway, my immediate concern is that it should just remember my choice :) Please let me know if I can provide more information. Happy to dig into code if needed but I will need some pointers. To manage notifications about this bug go to: https://bugs.launchpad.net/pulseaudio/+bug/1847570/+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 1631161] Re: Preferred output device is not remembered between logins
Enabling "module-switch-on-connect" makes the problem appear again. So it seems like its this module. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1631161 Title: Preferred output device is not remembered between logins Status in pulseaudio package in Ubuntu: Confirmed Bug description: Whenever I reboot anew, pulseaudio has forgotten the correct audio port which I have set using the kde pulseaudio tool. I use line out, but it defaults to headphones, which is incorrect for my current setup. I expect it to remember that I wanted line out every time. Once selected, everything runs fine for that session, but it doesn't get saved and defaults back to the wrong output every time. Guessing this is pulseaudio as it happens with the gnome tool also. Tested not working in 16.04, 16.10 and Mint 18 (packages from 16.04). Policy installed: 1:8.0-0ubuntu3 Cheers --- ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0c: kvd1577 F...m pulseaudio /dev/snd/pcmC0D0p: kvd1577 F...m pulseaudio /dev/snd/controlC0: kvd1577 F pulseaudio CurrentDesktop: KDE DistroRelease: Linux 18 InstallationDate: Installed on 2016-10-02 (5 days ago) InstallationMedia: Linux Mint 18 "Sarah" - Release amd64 20160904 NonfreeKernelModules: nvidia_uvm nvidia Package: pulseaudio 1:8.0-0ubuntu3 [origin: Ubuntu] PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Tags: sarah third-party-packages Uname: Linux 4.4.0-38-generic x86_64 UnreportableReason: This is not an official Linux package. Please remove any third party package and try again. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 09/24/2013 dmi.bios.vendor: Award Software International, Inc. dmi.bios.version: F5f dmi.board.name: GA-770T-USB3 dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.type: 3 dmi.chassis.vendor: Gigabyte Technology Co., Ltd. dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF5f:bd09/24/2013:svnGigabyteTechnologyCo.,Ltd.:pnGA-770T-USB3:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-770T-USB3:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr: dmi.product.name: GA-770T-USB3 dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1631161/+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 1631161] Re: Preferred output device is not remembered between logins
Fwiw, commenting out load-module module-switch-on-port-available load-module module-switch-on-connect makes the problem go away for me. I now get "line out" consistently. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1631161 Title: Preferred output device is not remembered between logins Status in pulseaudio package in Ubuntu: Confirmed Bug description: Whenever I reboot anew, pulseaudio has forgotten the correct audio port which I have set using the kde pulseaudio tool. I use line out, but it defaults to headphones, which is incorrect for my current setup. I expect it to remember that I wanted line out every time. Once selected, everything runs fine for that session, but it doesn't get saved and defaults back to the wrong output every time. Guessing this is pulseaudio as it happens with the gnome tool also. Tested not working in 16.04, 16.10 and Mint 18 (packages from 16.04). Policy installed: 1:8.0-0ubuntu3 Cheers --- ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0c: kvd1577 F...m pulseaudio /dev/snd/pcmC0D0p: kvd1577 F...m pulseaudio /dev/snd/controlC0: kvd1577 F pulseaudio CurrentDesktop: KDE DistroRelease: Linux 18 InstallationDate: Installed on 2016-10-02 (5 days ago) InstallationMedia: Linux Mint 18 "Sarah" - Release amd64 20160904 NonfreeKernelModules: nvidia_uvm nvidia Package: pulseaudio 1:8.0-0ubuntu3 [origin: Ubuntu] PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Tags: sarah third-party-packages Uname: Linux 4.4.0-38-generic x86_64 UnreportableReason: This is not an official Linux package. Please remove any third party package and try again. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 09/24/2013 dmi.bios.vendor: Award Software International, Inc. dmi.bios.version: F5f dmi.board.name: GA-770T-USB3 dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.type: 3 dmi.chassis.vendor: Gigabyte Technology Co., Ltd. dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF5f:bd09/24/2013:svnGigabyteTechnologyCo.,Ltd.:pnGA-770T-USB3:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-770T-USB3:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr: dmi.product.name: GA-770T-USB3 dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1631161/+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 1631161] Re: Preferred output device is not remembered between logins
@vanvugt issue 494 seems similar but not close enough, I also tried the "comment out module-x11-publish" in /usr/bin/start-pulseaudio-x11 but it had no effect for me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1631161 Title: Preferred output device is not remembered between logins Status in pulseaudio package in Ubuntu: Confirmed Bug description: Whenever I reboot anew, pulseaudio has forgotten the correct audio port which I have set using the kde pulseaudio tool. I use line out, but it defaults to headphones, which is incorrect for my current setup. I expect it to remember that I wanted line out every time. Once selected, everything runs fine for that session, but it doesn't get saved and defaults back to the wrong output every time. Guessing this is pulseaudio as it happens with the gnome tool also. Tested not working in 16.04, 16.10 and Mint 18 (packages from 16.04). Policy installed: 1:8.0-0ubuntu3 Cheers --- ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0c: kvd1577 F...m pulseaudio /dev/snd/pcmC0D0p: kvd1577 F...m pulseaudio /dev/snd/controlC0: kvd1577 F pulseaudio CurrentDesktop: KDE DistroRelease: Linux 18 InstallationDate: Installed on 2016-10-02 (5 days ago) InstallationMedia: Linux Mint 18 "Sarah" - Release amd64 20160904 NonfreeKernelModules: nvidia_uvm nvidia Package: pulseaudio 1:8.0-0ubuntu3 [origin: Ubuntu] PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Tags: sarah third-party-packages Uname: Linux 4.4.0-38-generic x86_64 UnreportableReason: This is not an official Linux package. Please remove any third party package and try again. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 09/24/2013 dmi.bios.vendor: Award Software International, Inc. dmi.bios.version: F5f dmi.board.name: GA-770T-USB3 dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.type: 3 dmi.chassis.vendor: Gigabyte Technology Co., Ltd. dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF5f:bd09/24/2013:svnGigabyteTechnologyCo.,Ltd.:pnGA-770T-USB3:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-770T-USB3:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr: dmi.product.name: GA-770T-USB3 dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1631161/+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 1847570] [NEW] Preferred output device is not remembered between logins
*** This bug is a duplicate of bug 1631161 *** https://bugs.launchpad.net/bugs/1631161 Public bug reported: On my freshly installed eoan system I have two output devices: - HDMI/DisplayPort 2 - GK208 ... - Line Out - Family 17h ... When I login into the system pulseaudio always select the "wrong" one (HDMI) and I need to go to gnome-settings/Sound/Output Device and switch to "line out". This applies to every login/logout not just reboots. I would be good if it would remember this choice so that I have to do it only once. Or maybe (if that is technically possible) just output on both output devices by default - this would be even more user friendly for newbies who will have a hard time finding the right place to change this (or maybe have UI in the volume slider to select outputs if there are more than one? But anyway, my immediate concern is that it should just remember my choice :) Please let me know if I can provide more information. Happy to dig into code if needed but I will need some pointers. ** Affects: pulseaudio (Ubuntu) Importance: High Status: Confirmed ** Tags: eoan ** Summary changed: - Correct output device needs to be set again on each reboot + Correct output device needs to be set again on each login ** Description changed: On my freshly installed eoan system I have two output devices: - HDMI/DisplayPort 2 - GK208 ... - Line Out - Family 17h ... When I login into the system pulseaudio always select the "wrong" one (HDMI) and I need to go to gnome-settings/Sound/Output Device - and switch to "line out". + and switch to "line out". This applies to every login/logout not + just reboots. I would be good if it would remember this choice so that I have - to do it only once. + to do it only once. Or maybe (if that is technically possible) just output on both output devices by default - this would be even more user friendly for newbies who will have a hard time finding the right place to change this (or maybe have UI in the volume slider to select outputs if there are more than one? But anyway, my immediate concern is that it should just remember my choice :) Please let me know if I can provide more information. Happy to dig into code if needed but I will need some pointers. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1847570 Title: Preferred output device is not remembered between logins Status in pulseaudio package in Ubuntu: Confirmed Bug description: On my freshly installed eoan system I have two output devices: - HDMI/DisplayPort 2 - GK208 ... - Line Out - Family 17h ... When I login into the system pulseaudio always select the "wrong" one (HDMI) and I need to go to gnome-settings/Sound/Output Device and switch to "line out". This applies to every login/logout not just reboots. I would be good if it would remember this choice so that I have to do it only once. Or maybe (if that is technically possible) just output on both output devices by default - this would be even more user friendly for newbies who will have a hard time finding the right place to change this (or maybe have UI in the volume slider to select outputs if there are more than one? But anyway, my immediate concern is that it should just remember my choice :) Please let me know if I can provide more information. Happy to dig into code if needed but I will need some pointers. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1847570/+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 1840375] Re: groupdel doesn't support extrausers
I uploaded SRUs for xenial,bionic,disco now.
** Description changed:
snapd needs the ability to call 'groupdel --extrausers foo' to clean up
after itself, but --extrausers is currently unsupported.
+
+ [Impact]
+ On ubuntu-core systems we want to be able to manage "extrausers" in the same
+ way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
+
+ This is an important feature for Ubuntu Core
+
+ [Test Case]
+ 1. install the libnss-extrausers and configure it
+ 2. run "groupadd --extrausers foo"
+ 3 check /var/lib/extrausers/group for the new "foo" group
+ 4. run "groupdel --extrausers foo"
+ 5. check /var/lib/extrausers/group and ensure the "foo" group is removed
+
+ [Regression Potential]
+
+ * low: this adds a new (optional) option which is off by default
** Changed in: shadow (Ubuntu)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1840375
Title:
groupdel doesn't support extrausers
Status in snapd:
New
Status in shadow package in Ubuntu:
In Progress
Status in shadow source package in Xenial:
New
Status in shadow source package in Bionic:
New
Status in shadow source package in Disco:
New
Bug description:
snapd needs the ability to call 'groupdel --extrausers foo' to clean
up after itself, but --extrausers is currently unsupported.
[Impact]
On ubuntu-core systems we want to be able to manage "extrausers" in the same
way as regular users. This requires updates to the various
{user,group}{add,del} tools. Right now "groupdel" cannot handle extrausers.
This is an important feature for Ubuntu Core
[Test Case]
1. install the libnss-extrausers and configure it
2. run "groupadd --extrausers foo"
3 check /var/lib/extrausers/group for the new "foo" group
4. run "groupdel --extrausers foo"
5. check /var/lib/extrausers/group and ensure the "foo" group is removed
[Regression Potential]
* low: this adds a new (optional) option which is off by default
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1840375/+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 1840375] Re: groupdel doesn't support extrausers
** Also affects: shadow (Ubuntu Disco) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1840375 Title: groupdel doesn't support extrausers Status in snapd: New Status in shadow package in Ubuntu: Triaged Status in shadow source package in Xenial: New Status in shadow source package in Bionic: New Status in shadow source package in Disco: New Bug description: snapd needs the ability to call 'groupdel --extrausers foo' to clean up after itself, but --extrausers is currently unsupported. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1840375/+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 1840375] Re: groupdel doesn't support extrausers
I uploaded shadow_4.5-1.1ubuntu3_source.changes to eoan. We need to SRU this to xenial/bionic to have it in UC16/UC18. ** Also affects: shadow (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1840375 Title: groupdel doesn't support extrausers Status in snapd: New Status in shadow package in Ubuntu: Triaged Status in shadow source package in Xenial: New Status in shadow source package in Bionic: New Bug description: snapd needs the ability to call 'groupdel --extrausers foo' to clean up after itself, but --extrausers is currently unsupported. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1840375/+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 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH
The PR to re-enable the generator: https://github.com/snapcore/snapd/pull/7031 and updates the test. -- 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/1771858 Title: /snap/bin not in default PATH for units, snapd should ship system- environment-generators to inject /snap/bin into $PATH Status in snapd package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Released Status in snapd source package in Xenial: Confirmed Status in systemd source package in Xenial: Confirmed Status in snapd source package in Bionic: Confirmed Status in systemd source package in Bionic: Fix Committed Status in snapd source package in Cosmic: Fix Released Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] * This means that software installed via snap isn't transparently available for units to use. As snaps are first-class citizens in Ubuntu, we should update the PATH. * When a generator started to be provided by systemd, it was recognized that $PATH is not correctly set, nonetheless, due to an environment bug that systemd generators run in. [Testcase] # make snapd-env-generator executable if it is not $ sudo chmod +x /usr/lib/systemd/system-environment-generators/snapd-env-generator # reboot, then test the effect of the fix $ systemd-run /usr/bin/env $ journalctl -e | grep PATH Output should contain /snap/bin Output should contain a complete and a valid PATH, i.e. PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" or similar. [Regression Potential] * snapd generator was already fixed separately to cause no harm, when running under a broken systemd. With the corrected environment, generators will now run with a correct PATH out of the box. A slight change of PATH will be observed by all generators, when running in containers/initramfs-less boots. However most generators will not be affected as they typically do not execute external binaries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1771858/+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 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH
When we disabled the generator in snapd we added a regression test (tests/main/snap-system-env): https://github.com/snapcore/snapd/pull/6470/files With the current systemd (not the one in -proposed) I get: ``` grep error: pattern not found, got: LANG=C.UTF-8 PATH=/sbin:/usr/sbin:/bin:/usr/bin:/snap/bin ``` which is expected and shows that the generator is broken. When running the same regression test with the systemd in -proposed I get no error so the update looks fine (as far as our test case goes). I heard some concerns from xnox about systems with initrd that need to be explored too. -- 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/1771858 Title: /snap/bin not in default PATH for units, snapd should ship system- environment-generators to inject /snap/bin into $PATH Status in snapd package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Released Status in snapd source package in Xenial: Confirmed Status in systemd source package in Xenial: Confirmed Status in snapd source package in Bionic: Confirmed Status in systemd source package in Bionic: Fix Committed Status in snapd source package in Cosmic: Fix Released Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] * This means that software installed via snap isn't transparently available for units to use. As snaps are first-class citizens in Ubuntu, we should update the PATH. * When a generator started to be provided by systemd, it was recognized that $PATH is not correctly set, nonetheless, due to an environment bug that systemd generators run in. [Testcase] # make snapd-env-generator executable if it is not $ sudo chmod +x /usr/lib/systemd/system-environment-generators/snapd-env-generator # reboot, then test the effect of the fix $ systemd-run /usr/bin/env $ journalctl -e | grep PATH Output should contain /snap/bin Output should contain a complete and a valid PATH, i.e. PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" or similar. [Regression Potential] * snapd generator was already fixed separately to cause no harm, when running under a broken systemd. With the corrected environment, generators will now run with a correct PATH out of the box. A slight change of PATH will be observed by all generators, when running in containers/initramfs-less boots. However most generators will not be affected as they typically do not execute external binaries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1771858/+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 1659534] Re: userdel doesn't supports extrausers
** Tags removed: verification-done verification-needed-done ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1659534 Title: userdel doesn't supports extrausers Status in Snappy: In Progress Status in shadow package in Ubuntu: Fix Released Status in shadow source package in Xenial: Fix Committed Status in shadow source package in Bionic: Fix Committed Bug description: TEST CASE: - run userdel --extrausers foo on a ubuntu core system REGRESSION POTENTIAL: - low, this option will only take effect when "userdel --extrauser" is used. On an Ubuntu Core system is impossible to delete an user from the extrausers db: root@localhost:/# userdel --extrausers alice userdel: unrecognized option '--extrausers' To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1659534/+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 984390] Re: $PATH is taken from login.defs not /etc/environment
** Description changed: + TEST CASE: + $PATH isn't sourced from /etc/environment, instead the version in /etc/login.defs is used. (The example below comes from a precise install.) | james@panlong:~$ echo $PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ cat /etc/environment | PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" | buildd@panlong:~$ grep PATH /etc/login.defs | # Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH. | # *REQUIRED* The default PATH settings, for superuser and normal users. | ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | #CRACKLIB_DICTPATH | buildd@panlong:~$ sudo sed -i -e "s#^ENV_PATH.*#ENV_PATH PATH=/wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games#" /etc/login.defs | buildd@panlong:~$ logout | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ REGRESSION POTENTIAL: - medium: it changes (incorrect) existing behaviour so https://xkcd.com/1172/ may apply -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/984390 Title: $PATH is taken from login.defs not /etc/environment Status in shadow package in Ubuntu: Fix Released Status in shadow source package in Precise: Won't Fix Status in shadow source package in Xenial: Fix Committed Status in shadow source package in Bionic: Fix Committed Bug description: TEST CASE: $PATH isn't sourced from /etc/environment, instead the version in /etc/login.defs is used. (The example below comes from a precise install.) | james@panlong:~$ echo $PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ cat /etc/environment | PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" | buildd@panlong:~$ grep PATH /etc/login.defs | # Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH. | # *REQUIRED* The default PATH settings, for superuser and normal users. | ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | #CRACKLIB_DICTPATH | buildd@panlong:~$ sudo sed -i -e "s#^ENV_PATH.*#ENV_PATH PATH=/wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games#" /etc/login.defs | buildd@panlong:~$ logout | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ REGRESSION POTENTIAL: - medium: it changes (incorrect) existing behaviour so https://xkcd.com/1172/ may apply To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/984390/+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 1778936] Re: please re-add Support-system-image-read-only-etc.patch
This is tested via spread in https://github.com/snapcore/snapd/pull/6667 -- 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/1778936 Title: please re-add Support-system-image-read-only-etc.patch Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] * core18 systems fail to update hostname * this happens due to /etc/hostname actually being a symlink to a file under /etc/writable/, adjust hostnamed to take that into account when trying to update /etc/hostname [Test Case] * run a core18 system, check that dhcp acquire hostname is correctly updated in /etc/writable/hostname [Regression Potential] * This is cherrypick of code that has gone missing since xenial. * There is no change of behaviour for the classic systems. * Currently, core18 systems simply fail to update hostname/machine-info files, thus the worst case is that they will still fail to do so. [Other Info] * original bug report The 16.04 version of systemd had a patch to support the read-only etc. For core18 we will also need this change because core18 is still not on a fully writable etc. I will attach a debdiff against the current bionic version of systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
We validated the fix via spread in https://github.com/snapcore/snapd/pull/6595 (both xenial and 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803" and a subsequent fix in "PR#11121". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Medium/High, this change is already in the systemd upstream and in use disco and later but the backport required some manual resolving of conflicts the code because changed between 229,237 and the fixed code in 240. Its also not fully clear if the fix relies on the new systemd "coldplug" functionality that was added in more recent git revisions. The upstream fix is https://github.com/systemd/systemd/pull/8803 and https://github.com/systemd/systemd/pull/11121 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
This is now uploaded (together with #1816753) to xenial-proposed and is currently in the UNAPPROVED queue). -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803" and a subsequent fix in "PR#11121". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Medium/High, this change is already in the systemd upstream and in use disco and later but the backport required some manual resolving of conflicts the code because changed between 229,237 and the fixed code in 240. Its also not fully clear if the fix relies on the new systemd "coldplug" functionality that was added in more recent git revisions. The upstream fix is https://github.com/systemd/systemd/pull/8803 and https://github.com/systemd/systemd/pull/11121 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
The xenial version was also run on i386 with the full snapd testsuite without issues. -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803" and a subsequent fix in "PR#11121". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Medium/High, this change is already in the systemd upstream and in use disco and later but the backport required some manual resolving of conflicts the code because changed between 229,237 and the fixed code in 240. Its also not fully clear if the fix relies on the new systemd "coldplug" functionality that was added in more recent git revisions. The upstream fix is https://github.com/systemd/systemd/pull/8803 and https://github.com/systemd/systemd/pull/11121 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
This updated debdiff for xenial ran a full autopkgtest run of snapd on 16.04 without errors. ** Patch added: "Slightly more updated debdiff for xenial with PR#11121" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+attachment/5249168/+files/systemd_229-4ubuntu21.19.debdiff -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803" and a subsequent fix in "PR#11121". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Medium/High, this change is already in the systemd upstream and in use disco and later but the backport required some manual resolving of conflicts the code because changed between 229,237 and the fixed code in 240. Its also not fully clear if the fix relies on the new systemd "coldplug" functionality that was added in more recent git revisions. The upstream fix is https://github.com/systemd/systemd/pull/8803 and https://github.com/systemd/systemd/pull/11121 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
The bionic version of this systemd update was used on an Ubuntu 18.04 system that ran the full spread test suite (>300 tests). There are hundreds of mount units created, started, stopped and a bunch of system services created and removed and tons of daemon-reloads. No systemd related issues where found. -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803" and a subsequent fix in "PR#11121". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Medium/High, this change is already in the systemd upstream and in use disco and later but the backport required some manual resolving of conflicts the code because changed between 229,237 and the fixed code in 240. Its also not fully clear if the fix relies on the new systemd "coldplug" functionality that was added in more recent git revisions. The upstream fix is https://github.com/systemd/systemd/pull/8803 and https://github.com/systemd/systemd/pull/11121 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1495580] Re: chfn needs to learn about the --extrausers argument and use libnss-extrausers files when set
** Also affects: shadow (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: shadow (Ubuntu Bionic) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1495580 Title: chfn needs to learn about the --extrausers argument and use libnss- extrausers files when set Status in Snappy: Fix Released Status in shadow package in Ubuntu: Fix Released Status in shadow source package in Xenial: Confirmed Status in shadow source package in Bionic: Fix Released Bug description: as seen in bug 1492327, adduser now works for creating users in the extrausers db but when it tries to update the GECOS field at the end of adding a user (interactively and noninteractively) chfn falls over ... chfn needs similar patches to the other shadow binaries that recently got extrausers support. TEST CASE: - create a user "foo" on an Ubuntu Core system - run "chfn --extrausers -f some-name foo" on an Ubuntu Core system REGRESSION POTENTIAL: - low: this requires the new (and optional) --extrausers switch to change anything. To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1495580/+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 1495580] Re: chfn needs to learn about the --extrausers argument and use libnss-extrausers files when set
** Description changed: as seen in bug 1492327, adduser now works for creating users in the extrausers db but when it tries to update the GECOS field at the end of adding a user (interactively and noninteractively) chfn falls over ... chfn needs similar patches to the other shadow binaries that recently got extrausers support. + + REGRESSION POTENTIAL: + - low: this requires the new (and optional) --extrausers switch to change anything. ** Description changed: as seen in bug 1492327, adduser now works for creating users in the extrausers db but when it tries to update the GECOS field at the end of adding a user (interactively and noninteractively) chfn falls over ... chfn needs similar patches to the other shadow binaries that recently got extrausers support. + TEST CASE: + - create a user "foo" on an Ubuntu Core system + - run "chfn --extrausers -f some-name foo" on an Ubuntu Core system + REGRESSION POTENTIAL: - low: this requires the new (and optional) --extrausers switch to change anything. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1495580 Title: chfn needs to learn about the --extrausers argument and use libnss- extrausers files when set Status in Snappy: Fix Released Status in shadow package in Ubuntu: Fix Released Status in shadow source package in Xenial: Confirmed Status in shadow source package in Bionic: Fix Released Bug description: as seen in bug 1492327, adduser now works for creating users in the extrausers db but when it tries to update the GECOS field at the end of adding a user (interactively and noninteractively) chfn falls over ... chfn needs similar patches to the other shadow binaries that recently got extrausers support. TEST CASE: - create a user "foo" on an Ubuntu Core system - run "chfn --extrausers -f some-name foo" on an Ubuntu Core system REGRESSION POTENTIAL: - low: this requires the new (and optional) --extrausers switch to change anything. To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1495580/+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 984390] Re: $PATH is taken from login.defs not /etc/environment
This is "fixed" in disco - the "su" binary does no longer comes from "shadow" here but from util-linux. And there this bug does not exist. ** Changed in: shadow (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/984390 Title: $PATH is taken from login.defs not /etc/environment Status in shadow package in Ubuntu: Fix Released Status in shadow source package in Precise: Won't Fix Status in shadow source package in Xenial: New Status in shadow source package in Bionic: New Bug description: $PATH isn't sourced from /etc/environment, instead the version in /etc/login.defs is used. (The example below comes from a precise install.) | james@panlong:~$ echo $PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ cat /etc/environment | PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" | buildd@panlong:~$ grep PATH /etc/login.defs | # Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH. | # *REQUIRED* The default PATH settings, for superuser and normal users. | ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | #CRACKLIB_DICTPATH | buildd@panlong:~$ sudo sed -i -e "s#^ENV_PATH.*#ENV_PATH PATH=/wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games#" /etc/login.defs | buildd@panlong:~$ logout | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ REGRESSION POTENTIAL: - medium: it changes (incorrect) existing behaviour so https://xkcd.com/1172/ may apply To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/984390/+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 984390] Re: $PATH is taken from login.defs not /etc/environment
** Description changed: $PATH isn't sourced from /etc/environment, instead the version in /etc/login.defs is used. (The example below comes from a precise install.) | james@panlong:~$ echo $PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games - | buildd@panlong:~$ cat /etc/environment + | buildd@panlong:~$ cat /etc/environment | PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" - | buildd@panlong:~$ grep PATH /etc/login.defs + | buildd@panlong:~$ grep PATH /etc/login.defs | # Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH. | # *REQUIRED* The default PATH settings, for superuser and normal users. | ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | #CRACKLIB_DICTPATH - | buildd@panlong:~$ sudo sed -i -e "s#^ENV_PATH.*#ENV_PATH PATH=/wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games#" /etc/login.defs + | buildd@panlong:~$ sudo sed -i -e "s#^ENV_PATH.*#ENV_PATH PATH=/wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games#" /etc/login.defs | buildd@panlong:~$ logout | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ + + REGRESSION POTENTIAL: + - medium: it changes (incorrect) existing behaviour so https://xkcd.com/1172/ may apply -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/984390 Title: $PATH is taken from login.defs not /etc/environment Status in shadow package in Ubuntu: Triaged Status in shadow source package in Precise: Won't Fix Status in shadow source package in Xenial: New Status in shadow source package in Bionic: New Bug description: $PATH isn't sourced from /etc/environment, instead the version in /etc/login.defs is used. (The example below comes from a precise install.) | james@panlong:~$ echo $PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ cat /etc/environment | PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" | buildd@panlong:~$ grep PATH /etc/login.defs | # Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH. | # *REQUIRED* The default PATH settings, for superuser and normal users. | ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | #CRACKLIB_DICTPATH | buildd@panlong:~$ sudo sed -i -e "s#^ENV_PATH.*#ENV_PATH PATH=/wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games#" /etc/login.defs | buildd@panlong:~$ logout | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ REGRESSION POTENTIAL: - medium: it changes (incorrect) existing behaviour so https://xkcd.com/1172/ may apply To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/984390/+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 984390] Re: $PATH is taken from login.defs not /etc/environment
** Also affects: shadow (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: shadow (Ubuntu Precise) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/984390 Title: $PATH is taken from login.defs not /etc/environment Status in shadow package in Ubuntu: Triaged Status in shadow source package in Precise: Won't Fix Status in shadow source package in Xenial: New Status in shadow source package in Bionic: New Bug description: $PATH isn't sourced from /etc/environment, instead the version in /etc/login.defs is used. (The example below comes from a precise install.) | james@panlong:~$ echo $PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ cat /etc/environment | PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" | buildd@panlong:~$ grep PATH /etc/login.defs | # Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH. | # *REQUIRED* The default PATH settings, for superuser and normal users. | ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | #CRACKLIB_DICTPATH | buildd@panlong:~$ sudo sed -i -e "s#^ENV_PATH.*#ENV_PATH PATH=/wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games#" /etc/login.defs | buildd@panlong:~$ logout | james@panlong:~$ sudo su - buildd | buildd@panlong:~$ echo $PATH | /wtf:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games | buildd@panlong:~$ REGRESSION POTENTIAL: - medium: it changes (incorrect) existing behaviour so https://xkcd.com/1172/ may apply To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/984390/+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 1659534] Re: userdel doesn't supports extrausers
SRUs for xenial,bionic are uploaded and in the unapproved queue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1659534 Title: userdel doesn't supports extrausers Status in Snappy: In Progress Status in shadow package in Ubuntu: In Progress Status in shadow source package in Xenial: In Progress Status in shadow source package in Bionic: In Progress Bug description: TEST CASE: - run userdel --extrausers foo on a ubuntu core system REGRESSION POTENTIAL: - low, this option will only take effect when "userdel --extrauser" is used. On an Ubuntu Core system is impossible to delete an user from the extrausers db: root@localhost:/# userdel --extrausers alice userdel: unrecognized option '--extrausers' To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1659534/+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 1659534] Re: userdel doesn't supports extrausers
** Patch added: "debdiff for bionic" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1659534/+attachment/5248606/+files/shadow_4.5-1ubuntu1.debdiff ** Changed in: shadow (Ubuntu Xenial) Status: New => In Progress ** Changed in: shadow (Ubuntu Bionic) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1659534 Title: userdel doesn't supports extrausers Status in Snappy: In Progress Status in shadow package in Ubuntu: In Progress Status in shadow source package in Xenial: In Progress Status in shadow source package in Bionic: In Progress Bug description: TEST CASE: - run userdel --extrausers foo on a ubuntu core system REGRESSION POTENTIAL: - low, this option will only take effect when "userdel --extrauser" is used. On an Ubuntu Core system is impossible to delete an user from the extrausers db: root@localhost:/# userdel --extrausers alice userdel: unrecognized option '--extrausers' To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1659534/+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 1659534] Re: userdel doesn't supports extrausers
** Patch added: "debdiff for xenial" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1659534/+attachment/5248605/+files/shadow_4.2-3.1ubuntu5.4.debdiff ** Description changed: + TEST CASE: + - run userdel --extrausers foo on a ubuntu core system + + REGRESSION POTENTIAL: + - low, this option will only take effect when "userdel --extrauser" is used. + On an Ubuntu Core system is impossible to delete an user from the extrausers db: root@localhost:/# userdel --extrausers alice userdel: unrecognized option '--extrausers' -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1659534 Title: userdel doesn't supports extrausers Status in Snappy: In Progress Status in shadow package in Ubuntu: In Progress Status in shadow source package in Xenial: New Status in shadow source package in Bionic: New Bug description: TEST CASE: - run userdel --extrausers foo on a ubuntu core system REGRESSION POTENTIAL: - low, this option will only take effect when "userdel --extrauser" is used. On an Ubuntu Core system is impossible to delete an user from the extrausers db: root@localhost:/# userdel --extrausers alice userdel: unrecognized option '--extrausers' To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1659534/+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 1659534] Re: userdel doesn't supports extrausers
This is the fix for disco ** Patch added: "debdiff for disco" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1659534/+attachment/5248602/+files/shadow_4.5-1.1ubuntu2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1659534 Title: userdel doesn't supports extrausers Status in Snappy: In Progress Status in shadow package in Ubuntu: In Progress Status in shadow source package in Xenial: New Status in shadow source package in Bionic: New Bug description: On an Ubuntu Core system is impossible to delete an user from the extrausers db: root@localhost:/# userdel --extrausers alice userdel: unrecognized option '--extrausers' To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1659534/+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 1659534] Re: userdel doesn't supports extrausers
** Patch added: "debdiff for disco" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1659534/+attachment/5248603/+files/shadow_4.5-1.1ubuntu2.debdiff ** Patch removed: "debdiff for disco" https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1659534/+attachment/5248602/+files/shadow_4.5-1.1ubuntu2.debdiff ** Also affects: shadow (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: snappy Status: Confirmed => In Progress ** Changed in: shadow (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1659534 Title: userdel doesn't supports extrausers Status in Snappy: In Progress Status in shadow package in Ubuntu: In Progress Status in shadow source package in Xenial: New Status in shadow source package in Bionic: New Bug description: On an Ubuntu Core system is impossible to delete an user from the extrausers db: root@localhost:/# userdel --extrausers alice userdel: unrecognized option '--extrausers' To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1659534/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
** Patch added: "updated debdiff with updated PR#11121" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+attachment/5247198/+files/systemd_237-3ubuntu10.17.debdiff ** Tags removed: verification-needed-bionic ** Tags added: verification-failed-bionic ** Description changed: [Impact] - On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". + On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803" and a subsequent fix in "PR#11121". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] - Low, this change is already in the systemd upstream and in use cosmic and later. + Medium/High, this change is already in the systemd upstream and in use disco and later but the backport required some manual resolving of conflicts the code because changed between 229,237 and the fixed code in 240. Its also + not fully clear if the fix relies on the new systemd "coldplug" functionality that was added in more recent git revisions. - The upstream fix is https://github.com/systemd/systemd/pull/8803 - Full spread run with the fixed systemd in the "core" snap and a regression test: https://github.com/snapcore/snapd/pull/6595 + The upstream fix is https://github.com/systemd/systemd/pull/8803 and + https://github.com/systemd/systemd/pull/11121 -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803" and a subsequent fix in "PR#11121". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Medium/High, this change is already in the systemd upstream and in use disco and later but the backport required some manual resolving of conflicts the code because changed between 229,237 and the fixed code in 240. Its also not fully clear if the fix relies on the new systemd "coldplug" functionality that was added in more recent git revisions. The upstream fix is https://github.com/systemd/systemd/pull/8803 and https://github.com/systemd/systemd/pull/11121 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
** Patch added: "Slightly more updated debdiff for xenial" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+attachment/5246548/+files/fix-race-daemon-reload-8803.patch -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 Full spread run with the fixed systemd in the "core" snap and a regression test: https://github.com/snapcore/snapd/pull/6595 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
** Patch added: "debdiff with a port of the fix in PR#11121 to xenial" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+attachment/5246546/+files/systemd_229-4ubuntu21.19.debdiff -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 Full spread run with the fixed systemd in the "core" snap and a regression test: https://github.com/snapcore/snapd/pull/6595 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
The xenial crash turns out to be https://github.com/systemd/systemd/issues/10716 - there is a fix in git, I will look into backport this. We will also need a binoic update with that and a cosmic update. ** Bug watch added: github.com/systemd/systemd/issues #10716 https://github.com/systemd/systemd/issues/10716 -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 Full spread run with the fixed systemd in the "core" snap and a regression test: https://github.com/snapcore/snapd/pull/6595 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
I managed to capture the crash in xenial while running the ADT tests for python-systemd. ** Attachment added: "Crashfile" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+attachment/5246417/+files/systemd-229-4ubuntu21.18.crash.retraced -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 Full spread run with the fixed systemd in the "core" snap and a regression test: https://github.com/snapcore/snapd/pull/6595 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
I can reproduce the autopkgtest failure with: autopkgtest -sU --apt-pocket proposed python-systemd_234-2build1.dsc -- qemu ~/VM/ubuntu-16.04-32.img on a local qemu. When it pulls in the systemd from -proposed I see: ... Failed to execute operation: Failed to activate service 'org.freedesktop.systemd1': timed out ... Trying to debugnow. -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 Full spread run with the fixed systemd in the "core" snap and a regression test: https://github.com/snapcore/snapd/pull/6595 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
Unfortunately we need to pull the xenial update. We see failure like this: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-xenial/xenial/i386/p/python- systemd/20190314_173156_e1077@/log.gz on various autopkgtest runs. E.g. for http://autopkgtest.ubuntu.com/packages/p/python-systemd It is also very inconsistent, i.e. not all arches are affected, for the python-systemd just i386,ppc64el,s390x. But its also visible in the docker.io xenial amd64 test so its not arch specific. ** Changed in: systemd (Ubuntu Xenial) Status: Fix Committed => Triaged ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 Full spread run with the fixed systemd in the "core" snap and a regression test: https://github.com/snapcore/snapd/pull/6595 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
** Tags removed: verification-needed-xenial ** Tags added: verification-failed-xenial -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: Fix Committed Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 Full spread run with the fixed systemd in the "core" snap and a regression test: https://github.com/snapcore/snapd/pull/6595 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1778936] Re: please re-add Support-system-image-read-only-etc.patch
This is now uploaded again into the unapproved queue. -- 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/1778936 Title: please re-add Support-system-image-read-only-etc.patch Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] * core18 systems fail to update hostname * this happens due to /etc/hostname actually being a symlink to a file under /etc/writable/, adjust hostnamed to take that into account when trying to update /etc/hostname [Test Case] * run a core18 system, check that dhcp acquire hostname is correctly updated in /etc/writable/hostname [Regression Potential] * This is cherrypick of code that has gone missing since xenial. * There is no change of behaviour for the classic systems. * Currently, core18 systems simply fail to update hostname/machine-info files, thus the worst case is that they will still fail to do so. [Other Info] * original bug report The 16.04 version of systemd had a patch to support the read-only etc. For core18 we will also need this change because core18 is still not on a fully writable etc. I will attach a debdiff against the current bionic version of systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936/+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 1778936] Re: please re-add Support-system-image-read-only-etc.patch
The previous upload was superseded by a security upload so it never made it into the archive. ** Patch added: "Updated debdiff with the current SRU upload" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936/+attachment/5246027/+files/systemd_237-3ubuntu10.16.debdiff -- 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/1778936 Title: please re-add Support-system-image-read-only-etc.patch Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] * core18 systems fail to update hostname * this happens due to /etc/hostname actually being a symlink to a file under /etc/writable/, adjust hostnamed to take that into account when trying to update /etc/hostname [Test Case] * run a core18 system, check that dhcp acquire hostname is correctly updated in /etc/writable/hostname [Regression Potential] * This is cherrypick of code that has gone missing since xenial. * There is no change of behaviour for the classic systems. * Currently, core18 systems simply fail to update hostname/machine-info files, thus the worst case is that they will still fail to do so. [Other Info] * original bug report The 16.04 version of systemd had a patch to support the read-only etc. For core18 we will also need this change because core18 is still not on a fully writable etc. I will attach a debdiff against the current bionic version of systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
** Description changed: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". + + Note that this is a general problem in systemd with daemon-reload and + systemctl commands, we just happen to hit it more often on Ubuntu Core + but the test-case below explodes just fine on a normal Ubuntu release + like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 + Full spread run with the fixed systemd in the "core" snap and a regression test: https://github.com/snapcore/snapd/pull/6595 -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". Note that this is a general problem in systemd with daemon-reload and systemctl commands, we just happen to hit it more often on Ubuntu Core but the test-case below explodes just fine on a normal Ubuntu release like 16.04 or 18.04 (not on 18.10+ as its fixed there). [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 Full spread run with the fixed systemd in the "core" snap and a regression test: https://github.com/snapcore/snapd/pull/6595 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
I uploaded both the xenial and bionic version to -proposed now. -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
The version for xenial link in comment #9 did successfully run a full spread run with UC16. This includes the regression test that systemctl start is not hanging. -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
This version fixes a subtle bug added by me when de-conflicting the diff. ** Patch removed: "Full debdiff for xenial systemd SRU (with correct changelog)" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+attachment/5245818/+files/systemd_229-4ubuntu21.18.debdiff ** Patch added: "debdiff with a port of the fix in PR#8803 to trusty (test ppa upload)" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+attachment/5245851/+files/systemd_229-4ubuntu21.18~ppa2.debdiff -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
The xenial version of this is NOT ready yet, a second run produced a CRASH at startup on UC16 with the updated systemd. ** Patch removed: "debdiff with a port of the fix in PR#8803 for xenial" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+attachment/5245665/+files/fix-systemctl-race-8803.debdiff -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
The xenial build of the updated systemd was tested using a full spread run with no regressions and a new test was added in https://github.com/snapcore/snapd/pull/6595 to test that the regression is fixed This test shows that core/edge is fixed but core/beta which does not yet has the fix is hanging (as expected). -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
** Description changed: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. + + The upstream fix is https://github.com/systemd/systemd/pull/8803 -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. The upstream fix is https://github.com/systemd/systemd/pull/8803 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
** Patch added: "Full debdiff for xenial systemd SRU (with correct changelog)" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+attachment/5245818/+files/systemd_229-4ubuntu21.18.debdiff -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
This is now uploaded to the ppa:snappy-dev/edge -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
** Description changed: - On Ubuntu Core we recently hit the a race in daemon-reload and systemctl - twice. This race is fixed in systemd upstream: "fix race between daemon- - reload and other commands #8803". + [Impact] + On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". + [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. - This change is already in the systemd in cosmic+ + [REGRESSION POTENTIAL] + Low, this change is already in the systemd upstream and in use cosmic and later. -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: [Impact] On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". [TEST CASE] To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. [REGRESSION POTENTIAL] Low, this change is already in the systemd upstream and in use cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18)
I ran the snapd autopkgtest against a bionic systemd deb build with this and noticed no regressions. -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. This change is already in the systemd in cosmic+ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16)
** Patch added: "debdiff with a port of the fix in PR#8803 for bionic" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+attachment/5245782/+files/systemd_237-3ubuntu10.15.1.debdiff ** Summary changed: - Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) + Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) and 18.04 (for UC18) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. This change is already in the systemd in cosmic+ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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 1819728] Re: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16)
** Description changed: On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon- reload and other commands #8803". To reproduce its enough to run: for i in $(seq 50); do - systemctl daemon-reload & - systemctl start ssh & + systemctl daemon-reload & + systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. + + This change is already in the systemd in cosmic+ -- 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/1819728 Title: Please backport "fix race between daemon-reload and other commands #8803" to 16.04 (for UC16) Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Bug description: On Ubuntu Core we recently hit the a race in daemon-reload and systemctl twice. This race is fixed in systemd upstream: "fix race between daemon-reload and other commands #8803". To reproduce its enough to run: for i in $(seq 50); do systemctl daemon-reload & systemctl start ssh & done This will result in "systemctl start ssh" hanging in ppoll. With the patch applied the hangs go away. This change is already in the systemd in cosmic+ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819728/+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
