[Touch-packages] [Bug 1704929] Re: Repeating "can't open /dev/ttyX: No such device or address" messages during installation
Since this only seems to happen with xenial, and not with any other Ubuntu release (Y to E) and since it only happens during install time, and even then only with using the console for the entire installation (and not using the 2nd stage via ssh), I closing this as Won't Fix. ** Changed in: ubuntu-z-systems Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to console-setup in Ubuntu. https://bugs.launchpad.net/bugs/1704929 Title: Repeating "can't open /dev/ttyX: No such device or address" messages during installation Status in Ubuntu on IBM z Systems: Won't Fix Status in console-setup package in Ubuntu: Incomplete Bug description: [Impact] console-setup continuously tries to open /dev/tty[1-6] on s390x, when such consoles do not exist on s390x. This can be seen on boot in the output from the initramfs, and during the installer. [Cause] It seems to me that the postinst of the console-setup is incorrect for s390, since on s390 Linux tty[1-6] do not exist in any modes (LPAR, z/VM, KVM) [Solution] I do not know what ACTIVE_CONSOLES should be set as, my guess is to set it to... "guess". Usually it should be slcp, but that depends on which consoles are configured/activated in the given KVM. [Testcase] On boot, scroll all the messages and makesure there are no error messages about inability to open /dev/tty* [Original Bug Report] During the installation (z/VM guest and KVM virtual machine) of Ubuntu Server 16.04.1 (and 16.04.2) repeating messages of the form: " Select and install software ... 10% can't open /dev/tty4: No such device or address can't open /dev/tty2: No such device or address can't open /dev/tty3: No such device or address can't open /dev/tty4: No such device or address can't open /dev/tty2: No such device or address can't open /dev/tty3: No such device or address can't open /dev/tty2: No such device or address can't open /dev/tty4: No such device or address can't open /dev/tty4: No such device or address can't open /dev/tty3: No such device or address can't open /dev/tty2: No such device or address can't open /dev/tty2: No such device or address can't open /dev/tty3: No such device or address ... 20% can't open /dev/tty4: No such device or address can't open /dev/tty2: No such device or address can't open /dev/tty3: No such device or address ... 30%... 40% can't open /dev/tty3: No such device or address can't open /dev/tty4: No such device or address can't open /dev/tty2: No such device or address ... 50% can't open /dev/tty3: No such device or address can't open /dev/tty4: No such device or address can't open /dev/tty2: No such device or address ... 60% can't open /dev/tty2: No such device or address can't open /dev/tty3: No such device or address can't open /dev/tty4: No such device or address can't open /dev/tty2: No such device or address ... Finishing the installation ... 13%... 22%... 31% can't open /dev/tty3: No such device or address can't open /dev/tty2: No such device or address can't open /dev/tty4: No such device or address ... 40%... 50%... 63%... 72%... 81% can't open /dev/tty4: No such device or address can't open /dev/tty2: No such device or address can't open /dev/tty3: No such device or address ... 90% The system is going down NOW Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system reboot 01: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop CPU 00. 02: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop CPU 00. 03: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop CPU 00. 00 Storage cleared - system reset. 00 zIPL .. " They start to occur when the software gets installed: "Select and install software ... 10% can't open /dev/tty4: No such device or address" And only stop with the final system reboot at the end of the installation. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1704929/+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 1830501] Re: su bash-completion isn't working since 19.04
Thanks for the updates! I'll open an issue on the repo. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1830501 Title: su bash-completion isn't working since 19.04 Status in util-linux package in Ubuntu: New Bug description: The su bash-completiton isn't working in 19.04 or 19.10. There is 2 files related to su bash completion in 19.10: /usr/share/bash-completion/completions/_su /usr/share/bash-completion/completions/su However, I had to get the file /usr/share/bash- completion/completions/su in Ubuntu 16.04 and put it in /etc/bash_completion.d/ su USER+TAB now complete the username. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: bash-completion 1:2.8-6ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Uname: Linux 5.0.0-15-generic x86_64 ApportVersion: 2.20.11-0ubuntu2 Architecture: amd64 Date: Sat May 25 17:51:25 2019 Dependencies: PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: bash-completion UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1830501/+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 1817097] Comment bridged from LTC Bugzilla
--- Comment From heinz-werner_se...@de.ibm.com 2019-05-29 03:51 EDT--- IBM bugzilla status -> closed, Fix Released by Canonical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1817097 Title: pvmove causes file system corruption without notice upon move from 512 -> 4096 logical block size devices Status in lvm2: Confirmed Status in Ubuntu on IBM z Systems: Fix Released Status in e2fsprogs package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in lvm2 package in Ubuntu: Invalid Bug description: Problem Description--- Summary === Environment: IBM Z13 LPAR and z/VM Guest IBM Type: 2964 Model: 701 NC9 OS: Ubuntu 18.10 (GNU/Linux 4.18.0-13-generic s390x) Package: lvm2 version 2.02.176-4.1ubuntu3 LVM: pvmove operation corrupts file system when using 4096 (4k) logical block size and default block size being 512 bytes in the underlying devices The problem is immediately reproducible. We see a real usability issue with data destruction as consequence - which is not acceptable. We expect 'pvmove' to fail with error in such situations to prevent fs destruction, which might possibly be overridden by a force flag. Details === After a 'pvmove' operation is run to move a physical volume onto an ecrypted device with 4096 bytes logical block size we experience a file system corruption. There is no need for the file system to be mounted, but the problem surfaces differently if so. Either, the 'pvs' command after the pvmove shows /dev/LOOP_VG/LV: read failed after 0 of 1024 at 0: Invalid argument /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314507264: Invalid argument /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314564608: Invalid argument /dev/LOOP_VG/LV: read failed after 0 of 1024 at 4096: Invalid argument or a subsequent mount shows (after umount if the fs had previously been mounted as in our setup) mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/LOOP_VG-LV, missing codepage or helper program, or other error. A minimal setup of LVM using one volume group with one logical volume defined, based on one physical volume is sufficient to raise the problem. One more physical volume of the same size is needed to run the pvmove operation to. LV | VG: LOOP_VG [ ] | PV: /dev/loop0 --> /dev/mapper/enc-loop ( backed by /dev/mapper/enc-loop ) The physical volumes are backed by loopback devices (losetup) to base the problem report on, but we have seen the error on real SCSI multipath volumes also, with and without cryptsetup mapper devices in use. Further discussion == https://www.saout.de/pipermail/dm-crypt/2019-February/006078.html The problem does not occur on block devices with native size of 4k. E.g. DASDs, or file systems with mkfs -b 4096 option. Terminal output === See attached file pvmove-error.txt Debug data == pvmove was run with -dd (maximum debug level) See attached journal file. Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 4.18.0-13-generic #14-Ubuntu SMP Wed Dec 5 09:00:35 UTC 2018 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 2964 Model: 701 NC9 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Create two image files of 500MB in size and set up two loopback devices with 'losetup -fP FILE' 2.) Create one physical volume and one volume group 'LOOP_VG', and one logical volume 'VG' Run: pvcreate /dev/loop0 vgcreate LOOP_VG /dev/loop0 lvcreate -L 300MB LOOP_VG -n LV /dev/loop0 3.) Create a file system on the logical volume device: mkfs.ext4 /dev/mapper/LOOP_VG-LV 4.) mount the file system created in the previous step to some empty available directory: mount /dev/mapper/LOOP_VG-LV /mnt 5.) Set up a second physical volume, this time encrypted with LUKS2, and open the volume to make it available: cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/loop1 cryptsetup luksOpen /dev/loop1 enc-loop 6.) Create the second physical volume, and add it to the LOOP_VG pvcreate /dev/mapper/enc-loop vgextend LOOP_VG /dev/mapper/enc-loop 7.) Ensure the new physical volume is part of the volume group: pvs 8.) Move the /dev/loop0 volume onto the encrypted volume with maximum debug option: pvmove -dd /dev/loop0 /dev/mapper/enc-loop 9.) The previous step succeeds, but corrupts the file system on the logical volume We expect an error here. There might be a command line flag to override used because corruption does not cause a d
[Touch-packages] [Bug 768264] [NEW] Unable to copy first quote
You have been subscribed to a public bug: Upstream URL: https://gitlab.gnome.org/GNOME/evince/issues/248 Binary package hint: evince 1) lsb_release -rd Description:Ubuntu Vivid Vervet (development branch) Release:15.04 2) apt-cache policy evince evince: Installed: 3.14.1-0ubuntu1 Candidate: 3.14.1-0ubuntu1 Version table: *** 3.14.1-0ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages 100 /var/lib/dpkg/status 3) What is expected to happen when one copies the first paragraph of the second page of https://bugs.launchpad.net/ubuntu/+source/evince/+bug/768264/+attachment/4282570/+files/1311004.pdf it does so verbatim, just like Adobe Reader. 4) What happens instead is the first comma is not highlightable. ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: evince 2.32.0-0ubuntu12 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic i686 Architecture: i386 Date: Thu Apr 21 13:18:34 2011 InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Release Candidate i386 (20100419.1) ProcEnviron: LANGUAGE=de_DE:en LANG=de_DE.utf8 SHELL=/bin/bash ProcVersionSignature_: Ubuntu 2.6.38-8.42-generic 2.6.38.2 SourcePackage: evince UpgradeStatus: Upgraded to natty on 2011-04-11 (9 days ago) ** Affects: evince Importance: Unknown Status: Fix Released ** Affects: poppler (Ubuntu) Importance: Medium Status: Triaged ** Tags: apport-bug bionic i386 natty raring running-unity vivid -- Unable to copy first quote https://bugs.launchpad.net/bugs/768264 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to poppler in Ubuntu. -- 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 1830859] [NEW] new libseccomp 2.4 (in proposed) makes rebuilds need but not generate a dependency to 2.4
Public bug reported:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
I realized it works on X/B/C/E but not in a D container
It worked ~4 weeks ago.
This test can be simplified to one command:
$ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
With strace I found different behavior:
Good:
[pid 3487] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.11>
[pid 3487] 0.003136 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL
(Invalid argument) <0.44>
[pid 3487] 0.000250 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x55f2b7a5e2d0}) = 0 <0.000251>
Bad:
[pid 484] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.17>
[pid 484] 0.002680 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.14>
[pid 484] 0.88 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL
(Invalid argument) <0.13>
The difference seems to come from being built against seccomp as in
Disco (2.3.3-3ubuntu2 = good) or Disco-proposed ( = bad).
The dependency on the built package stayed
libseccomp2 (>= 2.3.0)
It did not pick up 2.4 via e.g. shlibs.
If I install libseccomp2 2.4 from -proposed the issue is gone.
Strace now looks like:
[pid 1788] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.15>
[pid 1788] 0.004167 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.13>
[pid 1788] 0.98 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL
(Invalid argument) <0.13>
[pid 1788] 0.54 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.22>
[pid 1788] 0.61 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.17>
[pid 1788] 0.001477 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x564de3852560}) = 0 <0.000288>
This is in all releases proposed to fix CVE-2019-9893
I was just ?lucky? to pick it up with my qemu build in the PPA that has
proposed enabled.
Now there might be some toolchain detail to this as well.
As I built qemu for B/C as well and they built against the proposed 2.4
versions as well.
But in B/C things work with new qemu builds and old libseccomp2 installed.
Eoan on the other hand works by having libseccomp2 2.4.1-0ubuntu0.19.10.3
already migrated.
But that "luck" of B/C working might be specific to Qemus code, other
rebuilds against the new libseccomp2 might fail as well in B/C and
further. Shlibs detection is based on these symbols but my new qemu
build is not calling these so it dependency stays at 2.3.
Until a simpler testcase is found, the qemu in PPA [1] built for Disco will
trigger it.
=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+packages
### some related Build logs ###
Cosmic rebuild against 2.4, not affected by the issue
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+build/16858331/+files/buildlog_ubuntu-cosmic-amd64.qemu_1%3A2.12+dfsg-3ubuntu8.9~ppa1_BUILDING.txt.gz
Disco rebuild against 2.4, affected by the issue
https://launchpadlibrarian.net/425689546/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.2~ppa1_BUILDING.txt.gz
Disco build against 2.3 (working)
https://launchpadlibrarian.net/422884897/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.1_BUILDING.txt.gz
** Affects: libseccomp (Ubuntu)
Importance: Critical
Assignee: Ubuntu Security Team (ubuntu-security)
Status: New
** Changed in: ubuntu
Importance: Undecided => Critical
** Changed in: ubuntu
Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)
** Also affects: libseccomp (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: ubuntu
** Changed in: libseccomp (Ubuntu)
Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)
** Changed in: libseccomp (Ubuntu)
Importance: Undecided => Critical
--
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/1830859
Title:
new libseccomp 2.4 (in proposed) makes rebuilds need but not generate
a dependency to 2.4
Status in libseccomp package in Ubuntu:
New
Bug description:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
[Touch-packages] [Bug 1830859] Re: new libseccomp 2.4 (in proposed) makes rebuilds need but not generate a dependency to 2.4
Task for now is:
- Critical (for the chance of breaking a potentially arbitrary amount of SRUs
that were built against it in proposed)
- Assigned to ubuntu-security as they are driving the libseccomp update
We need to understand it more to then re-triage severity and potential
actions.
--
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/1830859
Title:
new libseccomp 2.4 (in proposed) makes rebuilds need but not generate
a dependency to 2.4
Status in libseccomp package in Ubuntu:
New
Bug description:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
I realized it works on X/B/C/E but not in a D container
It worked ~4 weeks ago.
This test can be simplified to one command:
$ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
With strace I found different behavior:
Good:
[pid 3487] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.11>
[pid 3487] 0.003136 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.44>
[pid 3487] 0.000250 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x55f2b7a5e2d0}) = 0 <0.000251>
Bad:
[pid 484] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.17>
[pid 484] 0.002680 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.14>
[pid 484] 0.88 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
The difference seems to come from being built against seccomp as in
Disco (2.3.3-3ubuntu2 = good) or Disco-proposed ( = bad).
The dependency on the built package stayed
libseccomp2 (>= 2.3.0)
It did not pick up 2.4 via e.g. shlibs.
If I install libseccomp2 2.4 from -proposed the issue is gone.
Strace now looks like:
[pid 1788] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.15>
[pid 1788] 0.004167 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.13>
[pid 1788] 0.98 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
[pid 1788] 0.54 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.22>
[pid 1788] 0.61 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.17>
[pid 1788] 0.001477 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x564de3852560}) = 0 <0.000288>
This is in all releases proposed to fix CVE-2019-9893
I was just ?lucky? to pick it up with my qemu build in the PPA that has
proposed enabled.
Now there might be some toolchain detail to this as well.
As I built qemu for B/C as well and they built against the proposed 2.4
versions as well.
But in B/C things work with new qemu builds and old libseccomp2 installed.
Eoan on the other hand works by having libseccomp2 2.4.1-0ubuntu0.19.10.3
already migrated.
But that "luck" of B/C working might be specific to Qemus code, other
rebuilds against the new libseccomp2 might fail as well in B/C and
further. Shlibs detection is based on these symbols but my new qemu
build is not calling these so it dependency stays at 2.3.
Until a simpler testcase is found, the qemu in PPA [1] built for Disco will
trigger it.
=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+packages
### some related Build logs ###
Cosmic rebuild against 2.4, not affected by the issue
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+build/16858331/+files/buildlog_ubuntu-cosmic-amd64.qemu_1%3A2.12+dfsg-3ubuntu8.9~ppa1_BUILDING.txt.gz
Disco rebuild against 2.4, affected by the issue
https://launchpadlibrarian.net/425689546/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.2~ppa1_BUILDING.txt.gz
Disco build against 2.3 (working)
https://launchpadlibrarian.net/422884897/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.1_BUILDING.txt.gz
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1830859/+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 1830501] Re: su bash-completion isn't working since 19.04
Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1830501 Title: su bash-completion isn't working since 19.04 Status in util-linux package in Ubuntu: New Bug description: The su bash-completiton isn't working in 19.04 or 19.10. There is 2 files related to su bash completion in 19.10: /usr/share/bash-completion/completions/_su /usr/share/bash-completion/completions/su However, I had to get the file /usr/share/bash- completion/completions/su in Ubuntu 16.04 and put it in /etc/bash_completion.d/ su USER+TAB now complete the username. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: bash-completion 1:2.8-6ubuntu1 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Uname: Linux 5.0.0-15-generic x86_64 ApportVersion: 2.20.11-0ubuntu2 Architecture: amd64 Date: Sat May 25 17:51:25 2019 Dependencies: PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: bash-completion UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1830501/+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 1824111] Re: Backport packages for 18.04.3 HWE stack
** Also affects: xserver-xorg-video-nouveau-hwe-18.04 (Ubuntu) Importance: Undecided Status: New ** Changed in: xserver-xorg-video-nouveau-hwe-18.04 (Ubuntu Bionic) Assignee: (unassigned) => Timo Aaltonen (tjaalton) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1824111 Title: Backport packages for 18.04.3 HWE stack Status in libclc package in Ubuntu: Invalid Status in libdrm package in Ubuntu: Invalid Status in llvm-toolchain-8 package in Ubuntu: Invalid Status in mesa package in Ubuntu: Invalid Status in xorg-server-hwe-18.04 package in Ubuntu: Invalid Status in xserver-xorg-video-amdgpu-hwe-18.04 package in Ubuntu: Invalid Status in xserver-xorg-video-ati-hwe-18.04 package in Ubuntu: Invalid Status in xserver-xorg-video-nouveau-hwe-18.04 package in Ubuntu: New Status in libclc source package in Bionic: Fix Committed Status in libdrm source package in Bionic: Fix Committed Status in llvm-toolchain-8 source package in Bionic: Fix Committed Status in mesa source package in Bionic: Fix Committed Status in xorg-server-hwe-18.04 source package in Bionic: New Status in xserver-xorg-video-amdgpu-hwe-18.04 source package in Bionic: New Status in xserver-xorg-video-ati-hwe-18.04 source package in Bionic: New Status in xserver-xorg-video-nouveau-hwe-18.04 source package in Bionic: New Bug description: [Impact] These are needed for 18.04.3 images. [Test case] Boot a daily image, see that it still has the necessary stack installed and working. Check upgrade from stock bionic. [Regression potential] libdrm: very minimal chance for regressions llvm-8: a new package, no regression potential on it's own libclc: more or less just adds support for new llvm mesa: a new major release, but we'll pull the final stable release of 19.0.x series, so there shouldn't be any regressions left at that point xserver: a new minor release xorg drivers: modest updates, mainly just new ati/amdgpu [Other info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libclc/+bug/1824111/+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 1830859] Re: new libseccomp 2.4 (in proposed) makes rebuilds need but not generate a dependency to 2.4
Until a simpler testcase is found, the qemu in PPA [1] built for Disco will
trigger it.
=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+packages
** Description changed:
It started with some of my usual KVM checks and found them failing on Disco
with:
- error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
-
+ error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
I realized it works on X/B/C/E but not in a D container
It worked ~4 weeks ago.
This test can be simplified to one command:
$ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
With strace I found different behavior:
Good:
[pid 3487] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.11>
[pid 3487] 0.003136 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.44>
[pid 3487] 0.000250 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x55f2b7a5e2d0}) = 0 <0.000251>
Bad:
[pid 484] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.17>
[pid 484] 0.002680 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.14>
[pid 484] 0.88 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
The difference seems to come from being built against seccomp as in
Disco (2.3.3-3ubuntu2 = good) or Disco-proposed ( = bad).
- The dependency on the built package stayed
- libseccomp2 (>= 2.3.0)
+ The dependency on the built package stayed
+ libseccomp2 (>= 2.3.0)
It did not pick up 2.4 via e.g. shlibs.
If I install libseccomp2 2.4 from -proposed the issue is gone.
Strace now looks like:
[pid 1788] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.15>
[pid 1788] 0.004167 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.13>
[pid 1788] 0.98 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
[pid 1788] 0.54 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.22>
[pid 1788] 0.61 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.17>
[pid 1788] 0.001477 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x564de3852560}) = 0 <0.000288>
This is in all releases proposed to fix CVE-2019-9893
I was just ?lucky? to pick it up with my qemu build in the PPA that has
proposed enabled.
Now there might be some toolchain detail to this as well.
As I built qemu for B/C as well and they built against the proposed 2.4
versions as well.
But in B/C things work with new qemu builds and old libseccomp2 installed.
Eoan on the other hand works by having libseccomp2 2.4.1-0ubuntu0.19.10.3
already migrated.
But that "luck" of B/C working might be specific to Qemus code, other
rebuilds against the new libseccomp2 might fail as well in B/C and
further. Shlibs detection is based on these symbols but my new qemu
build is not calling these so it dependency stays at 2.3.
+ Until a simpler testcase is found, the qemu in PPA [1] built for Disco will
trigger it.
+ => https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+packages
### some related Build logs ###
Cosmic rebuild against 2.4, not affected by the issue
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+build/16858331/+files/buildlog_ubuntu-cosmic-amd64.qemu_1%3A2.12+dfsg-3ubuntu8.9~ppa1_BUILDING.txt.gz
Disco rebuild against 2.4, affected by the issue
https://launchpadlibrarian.net/425689546/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.2~ppa1_BUILDING.txt.gz
Disco build against 2.3 (working)
https://launchpadlibrarian.net/422884897/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.1_BUILDING.txt.gz
--
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/1830859
Title:
new libseccomp 2.4 (in proposed) makes rebuilds need but not generate
a dependency to 2.4
Status in libseccomp package in Ubuntu:
New
Bug description:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal
[Touch-packages] [Bug 1830859] Re: new libseccomp 2.4 (in proposed) makes rebuilds need but not generate a dependency to 2.4
To be clear - this will likely resolve over time when people upgrade to seccomp
2.4.
But right now SRUs could release things built in -proposed against it and then
end up broken until 2.4 is released as well.
Furthermore without a strict dependency it might stay broken as nothing
enforces 2.4 to be installed.
--
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/1830859
Title:
new libseccomp 2.4 (in proposed) makes rebuilds need but not generate
a dependency to 2.4
Status in libseccomp package in Ubuntu:
New
Bug description:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
I realized it works on X/B/C/E but not in a D container
It worked ~4 weeks ago.
This test can be simplified to one command:
$ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
With strace I found different behavior:
Good:
[pid 3487] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.11>
[pid 3487] 0.003136 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.44>
[pid 3487] 0.000250 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x55f2b7a5e2d0}) = 0 <0.000251>
Bad:
[pid 484] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.17>
[pid 484] 0.002680 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.14>
[pid 484] 0.88 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
The difference seems to come from being built against seccomp as in
Disco (2.3.3-3ubuntu2 = good) or Disco-proposed ( = bad).
The dependency on the built package stayed
libseccomp2 (>= 2.3.0)
It did not pick up 2.4 via e.g. shlibs.
If I install libseccomp2 2.4 from -proposed the issue is gone.
Strace now looks like:
[pid 1788] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.15>
[pid 1788] 0.004167 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.13>
[pid 1788] 0.98 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
[pid 1788] 0.54 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.22>
[pid 1788] 0.61 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.17>
[pid 1788] 0.001477 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x564de3852560}) = 0 <0.000288>
This is in all releases proposed to fix CVE-2019-9893
I was just ?lucky? to pick it up with my qemu build in the PPA that has
proposed enabled.
Now there might be some toolchain detail to this as well.
As I built qemu for B/C as well and they built against the proposed 2.4
versions as well.
But in B/C things work with new qemu builds and old libseccomp2 installed.
Eoan on the other hand works by having libseccomp2 2.4.1-0ubuntu0.19.10.3
already migrated.
But that "luck" of B/C working might be specific to Qemus code, other
rebuilds against the new libseccomp2 might fail as well in B/C and
further. Shlibs detection is based on these symbols but my new qemu
build is not calling these so it dependency stays at 2.3.
Until a simpler testcase is found, the qemu in PPA [1] built for Disco will
trigger it.
=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+packages
### some related Build logs ###
Cosmic rebuild against 2.4, not affected by the issue
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+build/16858331/+files/buildlog_ubuntu-cosmic-amd64.qemu_1%3A2.12+dfsg-3ubuntu8.9~ppa1_BUILDING.txt.gz
Disco rebuild against 2.4, affected by the issue
https://launchpadlibrarian.net/425689546/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.2~ppa1_BUILDING.txt.gz
Disco build against 2.3 (working)
https://launchpadlibrarian.net/422884897/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.1_BUILDING.txt.gz
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1830859/+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 768264] Re: Unable to copy first quote
It's a poppler issue, upstream report https://gitlab.freedesktop.org/poppler/poppler/issues/310 ** Bug watch added: gitlab.freedesktop.org/poppler/poppler/issues #310 https://gitlab.freedesktop.org/poppler/poppler/issues/310 ** Package changed: evince (Ubuntu) => poppler (Ubuntu) ** Also affects: poppler via https://gitlab.freedesktop.org/poppler/poppler/issues/310 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/768264 Title: Unable to copy first quote Status in Evince: Fix Released Status in Poppler: New Status in poppler package in Ubuntu: Triaged Bug description: Upstream URL: https://gitlab.gnome.org/GNOME/evince/issues/248 Binary package hint: evince 1) lsb_release -rd Description: Ubuntu Vivid Vervet (development branch) Release: 15.04 2) apt-cache policy evince evince: Installed: 3.14.1-0ubuntu1 Candidate: 3.14.1-0ubuntu1 Version table: *** 3.14.1-0ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages 100 /var/lib/dpkg/status 3) What is expected to happen when one copies the first paragraph of the second page of https://bugs.launchpad.net/ubuntu/+source/evince/+bug/768264/+attachment/4282570/+files/1311004.pdf it does so verbatim, just like Adobe Reader. 4) What happens instead is the first comma is not highlightable. ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: evince 2.32.0-0ubuntu12 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic i686 Architecture: i386 Date: Thu Apr 21 13:18:34 2011 InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Release Candidate i386 (20100419.1) ProcEnviron: LANGUAGE=de_DE:en LANG=de_DE.utf8 SHELL=/bin/bash ProcVersionSignature_: Ubuntu 2.6.38-8.42-generic 2.6.38.2 SourcePackage: evince UpgradeStatus: Upgraded to natty on 2011-04-11 (9 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/evince/+bug/768264/+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 768264] Re: Unable to copy first quote
** Changed in: poppler Status: Unknown => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/768264 Title: Unable to copy first quote Status in Evince: Fix Released Status in Poppler: New Status in poppler package in Ubuntu: Triaged Bug description: Upstream URL: https://gitlab.gnome.org/GNOME/evince/issues/248 Binary package hint: evince 1) lsb_release -rd Description: Ubuntu Vivid Vervet (development branch) Release: 15.04 2) apt-cache policy evince evince: Installed: 3.14.1-0ubuntu1 Candidate: 3.14.1-0ubuntu1 Version table: *** 3.14.1-0ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages 100 /var/lib/dpkg/status 3) What is expected to happen when one copies the first paragraph of the second page of https://bugs.launchpad.net/ubuntu/+source/evince/+bug/768264/+attachment/4282570/+files/1311004.pdf it does so verbatim, just like Adobe Reader. 4) What happens instead is the first comma is not highlightable. ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: evince 2.32.0-0ubuntu12 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic i686 Architecture: i386 Date: Thu Apr 21 13:18:34 2011 InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Release Candidate i386 (20100419.1) ProcEnviron: LANGUAGE=de_DE:en LANG=de_DE.utf8 SHELL=/bin/bash ProcVersionSignature_: Ubuntu 2.6.38-8.42-generic 2.6.38.2 SourcePackage: evince UpgradeStatus: Upgraded to natty on 2011-04-11 (9 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/evince/+bug/768264/+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 1830867] [NEW] Crackling sound with HDMI
Public bug reported: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New ** Attachment added: "My Recording#1.mp4" https://bugs.launchpad.net/bugs/1830867/+attachment/5267314/+files/My%20Recording%231.mp4 -- 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/1830867 Title: Crackling sound with HDMI Status in pulseaudio package in Ubuntu: New Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1830867/+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 1735160] Re: [SRU] Please backport python3-macaroonbakery 0.0.6-1 [universe] from bionic
Ok, let's forget about that SRU, it's a priority anymore and it would need work, deleting the protobuf buggy upload from xenial-proposed ** Changed in: protobuf (Ubuntu Xenial) Status: Fix Committed => Won't Fix ** Changed in: pymacaroons (Ubuntu Xenial) Status: Fix Committed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to protobuf in Ubuntu. https://bugs.launchpad.net/bugs/1735160 Title: [SRU] Please backport python3-macaroonbakery 0.0.6-1 [universe] from bionic Status in httmock package in Ubuntu: Fix Released Status in protobuf package in Ubuntu: Fix Released Status in py-macaroon-bakery package in Ubuntu: Fix Released Status in pymacaroons package in Ubuntu: Fix Released Status in httmock source package in Xenial: Won't Fix Status in protobuf source package in Xenial: Won't Fix Status in py-macaroon-bakery source package in Xenial: Won't Fix Status in pymacaroons source package in Xenial: Won't Fix Status in httmock source package in Artful: Fix Released Status in protobuf source package in Artful: Fix Released Status in py-macaroon-bakery source package in Artful: Won't Fix Status in pymacaroons source package in Artful: Won't Fix Bug description: [Impact] As part of allowing Ubuntu users to enable canonical-livepatch from software-properties GUI (https://wiki.ubuntu.com/SoftwareUpdates#Update_settings) we need to backport python3-macaroonbakery 0.0.6-1 [universe] from bionic. This will requires quite few changes: - backport httmock 1.2.6-1 [universe] from bionic - no httmock in xenial - backport pymacaroons 0.12.0-1 [universe] from bionic - xenial has 0.9.2-0ubuntu1 - SRU some changes in google-apputils-python - https://bugs.launchpad.net/ubuntu/+source/google-apputils-python/+bug/1735162 - add python3-protobuf to python-protobuf 2.6.1-1.3 - Right now the python3 package is not built. [Test case] - for protobuf: $ python3 -c "import google.protobuf" - for protobuf: $ python2 -c "import google.protobuf" - for python3-macaroonbakery: make sure all the tests pass - make sure "snapcraft login" works properly [Regression Potential] - httmock, none has it's not in xenial - protobuf, reduced considering that the code has been backported from master (small changes to make it compatabile py3 compatabile) - pymacaroons, none has 0.12 is backward compatible with 0.9.2 - py-macaroon-bakery, none has it's not in xenial. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/httmock/+bug/1735160/+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 1735160] Re: [SRU] Please backport python3-macaroonbakery 0.0.6-1 [universe] from bionic
httmock was in xenial/NEW but I'm going to reject it, the livepatch UI work changed since that bug was started and we are not targetting Xenial anymore at this point, the SRU has been sitting there for over a year so I'm just going to wontfix for now and delete the uploads from xenial- proposed ** Changed in: httmock (Ubuntu Xenial) Status: In Progress => Won't Fix ** Changed in: py-macaroon-bakery (Ubuntu Xenial) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to protobuf in Ubuntu. https://bugs.launchpad.net/bugs/1735160 Title: [SRU] Please backport python3-macaroonbakery 0.0.6-1 [universe] from bionic Status in httmock package in Ubuntu: Fix Released Status in protobuf package in Ubuntu: Fix Released Status in py-macaroon-bakery package in Ubuntu: Fix Released Status in pymacaroons package in Ubuntu: Fix Released Status in httmock source package in Xenial: Won't Fix Status in protobuf source package in Xenial: Won't Fix Status in py-macaroon-bakery source package in Xenial: Won't Fix Status in pymacaroons source package in Xenial: Won't Fix Status in httmock source package in Artful: Fix Released Status in protobuf source package in Artful: Fix Released Status in py-macaroon-bakery source package in Artful: Won't Fix Status in pymacaroons source package in Artful: Won't Fix Bug description: [Impact] As part of allowing Ubuntu users to enable canonical-livepatch from software-properties GUI (https://wiki.ubuntu.com/SoftwareUpdates#Update_settings) we need to backport python3-macaroonbakery 0.0.6-1 [universe] from bionic. This will requires quite few changes: - backport httmock 1.2.6-1 [universe] from bionic - no httmock in xenial - backport pymacaroons 0.12.0-1 [universe] from bionic - xenial has 0.9.2-0ubuntu1 - SRU some changes in google-apputils-python - https://bugs.launchpad.net/ubuntu/+source/google-apputils-python/+bug/1735162 - add python3-protobuf to python-protobuf 2.6.1-1.3 - Right now the python3 package is not built. [Test case] - for protobuf: $ python3 -c "import google.protobuf" - for protobuf: $ python2 -c "import google.protobuf" - for python3-macaroonbakery: make sure all the tests pass - make sure "snapcraft login" works properly [Regression Potential] - httmock, none has it's not in xenial - protobuf, reduced considering that the code has been backported from master (small changes to make it compatabile py3 compatabile) - pymacaroons, none has 0.12 is backward compatible with 0.9.2 - py-macaroon-bakery, none has it's not in xenial. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/httmock/+bug/1735160/+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 1830353] Re: /usr/bin/software-properties-gtk:AttributeError:_update_availability::get_status:_get_raw_snap
Using 0.96.24.32.9 shows no problem, the fix makes sense and e.u.c has no report, marking as verified ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1830353 Title: /usr/bin/software-properties- gtk:AttributeError:_update_availability::get_status:_get_raw_snap Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Bionic: Fix Committed Bug description: * Impact The livepatch tab hits an error when an old gir1.2-snapd-glib is installed * Test case The software-properties -> livepatch tab should load without error * Regression potential The change is only in the Debian packaging to ensure a recent enough version of the snapd-glib binding are installed, just check that the package is installable/that the depends is available - The Ubuntu Error Tracker has been receiving reports about a problem regarding software-properties. This problem was most recently seen with package version 0.96.24.32.8, the problem page at https://errors.ubuntu.com/problem/063a6452979ec2e97686c6136f1447b4e5442f42 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1830353/+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 1830348] Re: /usr/bin/software-properties-gtk:TypeError:msg_reply_handler:_enabled_reply_handler:__call__:call_async
Using 0.96.24.32.9 shows no problem, the fix makes sense and e.u.c has no report, marking as verified ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1830348 Title: /usr/bin/software-properties- gtk:TypeError:msg_reply_handler:_enabled_reply_handler:__call__:call_async Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Bionic: Fix Committed Bug description: * Impact Some livepatch errors case are not handling correctly and leading to having an error report rather than a error message * Test case Unsure how to trigger that livepatch error state, but that can be tested by hacking the source and set the 'token' parameter to the calls to SetLivePatchEnabled() to None Also check that the error reports stop for the new version * Regression potential The change is to use an empty string instead of None on error, since the type was incorrect and that case not working it should regress (it could keep not working if the other type was still not valid though, but that shouldn't be the case) - The Ubuntu Error Tracker has been receiving reports about a problem regarding software-properties. This problem was most recently seen with package version 0.96.24.32.8, the problem page at https://errors.ubuntu.com/problem/ca90da51d0612253e93b8547563a5d9c7c900104 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1830348/+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 1815882] Re: Update evolution-data-server to 3.30.5
3.30.5-0ubuntu0.18.10.1 seems to work fine, no report of regression, marking as verified ** Tags removed: removal-candidate verification-needed verification-needed-cosmic ** Tags added: verification-done verification-done-cosmic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to evolution-data-server in Ubuntu. https://bugs.launchpad.net/bugs/1815882 Title: Update evolution-data-server to 3.30.5 Status in evolution-data-server package in Ubuntu: Fix Released Status in evolution-data-server source package in Cosmic: Fix Committed Bug description: * Impact That's a new bug-fix only update from GNOME There is a micro-release exception for GNOME: https://wiki.ubuntu.com/StableReleaseUpdates#GNOME https://gitlab.gnome.org/GNOME/evolution-data-server/blob/gnome-3-30/NEWS https://gitlab.gnome.org/GNOME/evolution-data-server/commits/gnome-3-30 * Test Case After installing the update, restart your computer. Run several eds-using apps like Evolution, GNOME Calendar and verify that they continue to run at least as well as before this update. * Regression Potential It's a new version with a bug of changes and fixes including in imap, calendar and gpg signing code so those features need to be well tested. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1815882/+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 1830867] Re: Crackling sound with HDMI
Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal: apport-collect 1830867 When reporting bugs in the future please use apport by using 'ubuntu- bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs. ** Changed in: pulseaudio (Ubuntu) Status: New => Incomplete -- 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/1830867 Title: Crackling sound with HDMI Status in pulseaudio package in Ubuntu: Incomplete Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1830867/+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 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
** Also affects: libwww-perl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in libwww-perl package in Ubuntu: New Status in openssl package in Ubuntu: Fix Released Status in python-tornado package in Ubuntu: Confirmed Status in libio-socket-ssl-perl source package in Bionic: Incomplete Status in libnet-ssleay-perl source package in Bionic: Incomplete Status in openssl source package in Bionic: Fix Committed Status in python-cryptography source package in Bionic: Fix Committed Status in python2.7 source package in Bionic: Fix Committed Status in python3.6 source package in Bionic: Fix Committed Status in python3.7 source package in Bionic: Fix Committed Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: Fix Committed Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Test cases for the python updates] python3.7 is a preview in bionic as a non-supported/non-default version of python3. Passing it's own autopkgtests is sufficient validation for python3.7. It includes a point release update, with OpenSSL 1.1.1 compat and features. python3.6 not only has OpenSSL 1.1.1 compat and features patches, but also includes a point release update to 3.6.8. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python3.6 and python3-defaults with regressions already fixed in the individual packages as appropriate. python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1 compat only. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python2.7 and python-defaults with regressions already fixed in the individual packages as appropriate. The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1 and python point releases as seen in: http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html And analyzed in https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652 [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. - non-application data records. TLSv1.3 sends more of these, when compared with previous versions, and some applications may not handle this correctly. Resulting in application data not being available, when previously expected. Mitigation around these involve disabling/enabling SSL_MODE_AUTO_RETRY or setting max protocol version to TLSv1.2. For example see discussion identified in the perl stack https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034 Similar hangs are possible with prior versions of TLS as well, it is however easier to trigger this with TLSv1.3. * Deprecated npn extenstion does not exist in TLSv1.3 implementation. * This update bundles python 3.6 and 3.7 point releases [Other Info] * Previous FFe for OpenSSL in 18.10 i
[Touch-packages] [Bug 1830867] Re: Crackling sound with HDMI
apport information ** Tags added: apport-collected disco ** Description changed: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard + --- + ProblemType: Bug + ApportVersion: 2.20.10-0ubuntu27 + Architecture: amd64 + AudioDevicesInUse: + USERPID ACCESS COMMAND + /dev/snd/controlC0: edouard1677 F pulseaudio + CurrentDesktop: ubuntu:GNOME + DistroRelease: Ubuntu 19.04 + InstallationDate: Installed on 2019-05-28 (0 days ago) + InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) + Package: pulseaudio 1:12.2-2ubuntu3 + PackageArchitecture: amd64 + ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 + Tags: disco + Uname: Linux 5.0.0-15-generic x86_64 + UpgradeStatus: No upgrade log present (probably fresh install) + UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo + _MarkForUpload: True + dmi.bios.date: 04/20/2019 + dmi.bios.vendor: LENOVO + dmi.bios.version: N23ET63W (1.38 ) + dmi.board.asset.tag: Not Available + dmi.board.name: 20KHCTO1WW + dmi.board.vendor: LENOVO + dmi.board.version: SDK0J40709 WIN + dmi.chassis.asset.tag: No Asset Information + dmi.chassis.type: 10 + dmi.chassis.vendor: LENOVO + dmi.chassis.version: None + dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KHCTO1WW:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KHCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: + dmi.product.family: ThinkPad X1 Carbon 6th + dmi.product.name: 20KHCTO1WW + dmi.product.sku: LENOVO_MT_20KH_BU_Think_FM_ThinkPad X1 Carbon 6th + dmi.product.version: ThinkPad X1 Carbon 6th + dmi.sys.vendor: LENOVO + modified.conffile..etc.pulse.default.pa: [modified] + mtime.conffile..etc.pulse.default.pa: 2019-05-28T23:16:01.413832 ** Attachment added: "AlsaInfo.txt" https://bugs.launchpad.net/bugs/1830867/+attachment/5267327/+files/AlsaInfo.txt -- 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/1830867 Title: Crackling sound with HDMI Status in pulseaudio package in Ubuntu: Incomplete Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edouard1677 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.04 InstallationDate: Installed on 2019-05-28 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Package: pulseaudio 1:12.2-2ubuntu3 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Tags: disco Uname: Linux 5.0.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KHCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.as
[Touch-packages] [Bug 1830867] CurrentDmesg.txt
apport information ** Attachment added: "CurrentDmesg.txt" https://bugs.launchpad.net/bugs/1830867/+attachment/5267328/+files/CurrentDmesg.txt -- 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/1830867 Title: Crackling sound with HDMI Status in pulseaudio package in Ubuntu: Incomplete Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edouard1677 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.04 InstallationDate: Installed on 2019-05-28 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Package: pulseaudio 1:12.2-2ubuntu3 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Tags: disco Uname: Linux 5.0.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KHCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KHCTO1WW:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KHCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KHCTO1WW dmi.product.sku: LENOVO_MT_20KH_BU_Think_FM_ThinkPad X1 Carbon 6th dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO modified.conffile..etc.pulse.default.pa: [modified] mtime.conffile..etc.pulse.default.pa: 2019-05-28T23:16:01.413832 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1830867/+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 1830867] ProcEnviron.txt
apport information ** Attachment added: "ProcEnviron.txt" https://bugs.launchpad.net/bugs/1830867/+attachment/5267331/+files/ProcEnviron.txt -- 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/1830867 Title: Crackling sound with HDMI Status in pulseaudio package in Ubuntu: Incomplete Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edouard1677 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.04 InstallationDate: Installed on 2019-05-28 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Package: pulseaudio 1:12.2-2ubuntu3 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Tags: disco Uname: Linux 5.0.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KHCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KHCTO1WW:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KHCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KHCTO1WW dmi.product.sku: LENOVO_MT_20KH_BU_Think_FM_ThinkPad X1 Carbon 6th dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO modified.conffile..etc.pulse.default.pa: [modified] mtime.conffile..etc.pulse.default.pa: 2019-05-28T23:16:01.413832 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1830867/+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 1830859] Re: new libseccomp 2.4 (in proposed) makes rebuilds need but not generate a dependency to 2.4
I have set up two new PPAs
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-with-proposed-seccomp
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-without-proposed-seccomp
They both build amd64 qemu with/without proposed for Disco.
Including debug symbols for further debugging.
This decouples this from my other PPA to allow me going on there with a
temporary workaround.
--
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/1830859
Title:
new libseccomp 2.4 (in proposed) makes rebuilds need but not generate
a dependency to 2.4
Status in libseccomp package in Ubuntu:
New
Bug description:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
I realized it works on X/B/C/E but not in a D container
It worked ~4 weeks ago.
This test can be simplified to one command:
$ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
With strace I found different behavior:
Good:
[pid 3487] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.11>
[pid 3487] 0.003136 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.44>
[pid 3487] 0.000250 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x55f2b7a5e2d0}) = 0 <0.000251>
Bad:
[pid 484] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.17>
[pid 484] 0.002680 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.14>
[pid 484] 0.88 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
The difference seems to come from being built against seccomp as in
Disco (2.3.3-3ubuntu2 = good) or Disco-proposed ( = bad).
The dependency on the built package stayed
libseccomp2 (>= 2.3.0)
It did not pick up 2.4 via e.g. shlibs.
If I install libseccomp2 2.4 from -proposed the issue is gone.
Strace now looks like:
[pid 1788] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.15>
[pid 1788] 0.004167 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.13>
[pid 1788] 0.98 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
[pid 1788] 0.54 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.22>
[pid 1788] 0.61 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.17>
[pid 1788] 0.001477 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x564de3852560}) = 0 <0.000288>
This is in all releases proposed to fix CVE-2019-9893
I was just ?lucky? to pick it up with my qemu build in the PPA that has
proposed enabled.
Now there might be some toolchain detail to this as well.
As I built qemu for B/C as well and they built against the proposed 2.4
versions as well.
But in B/C things work with new qemu builds and old libseccomp2 installed.
Eoan on the other hand works by having libseccomp2 2.4.1-0ubuntu0.19.10.3
already migrated.
But that "luck" of B/C working might be specific to Qemus code, other
rebuilds against the new libseccomp2 might fail as well in B/C and
further. Shlibs detection is based on these symbols but my new qemu
build is not calling these so it dependency stays at 2.3.
Until a simpler testcase is found, I have set up two new PPAs:
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-with-proposed-seccomp
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-without-proposed-seccomp
### some related Build logs ###
Cosmic rebuild against 2.4, not affected by the issue
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+build/16858331/+files/buildlog_ubuntu-cosmic-amd64.qemu_1%3A2.12+dfsg-3ubuntu8.9~ppa1_BUILDING.txt.gz
Disco rebuild against 2.4, affected by the issue
https://launchpadlibrarian.net/425689546/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.2~ppa1_BUILDING.txt.gz
Disco build against 2.3 (working)
https://launchpadlibrarian.net/422884897/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.1_BUILDING.txt.gz
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1830859/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to
[Touch-packages] [Bug 1830867] PulseList.txt
apport information ** Attachment added: "PulseList.txt" https://bugs.launchpad.net/bugs/1830867/+attachment/5267332/+files/PulseList.txt -- 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/1830867 Title: Crackling sound with HDMI Status in pulseaudio package in Ubuntu: Incomplete Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edouard1677 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.04 InstallationDate: Installed on 2019-05-28 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Package: pulseaudio 1:12.2-2ubuntu3 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Tags: disco Uname: Linux 5.0.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KHCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KHCTO1WW:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KHCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KHCTO1WW dmi.product.sku: LENOVO_MT_20KH_BU_Think_FM_ThinkPad X1 Carbon 6th dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO modified.conffile..etc.pulse.default.pa: [modified] mtime.conffile..etc.pulse.default.pa: 2019-05-28T23:16:01.413832 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1830867/+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 1830867] Dependencies.txt
apport information ** Attachment added: "Dependencies.txt" https://bugs.launchpad.net/bugs/1830867/+attachment/5267329/+files/Dependencies.txt -- 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/1830867 Title: Crackling sound with HDMI Status in pulseaudio package in Ubuntu: Incomplete Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edouard1677 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.04 InstallationDate: Installed on 2019-05-28 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Package: pulseaudio 1:12.2-2ubuntu3 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Tags: disco Uname: Linux 5.0.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KHCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KHCTO1WW:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KHCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KHCTO1WW dmi.product.sku: LENOVO_MT_20KH_BU_Think_FM_ThinkPad X1 Carbon 6th dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO modified.conffile..etc.pulse.default.pa: [modified] mtime.conffile..etc.pulse.default.pa: 2019-05-28T23:16:01.413832 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1830867/+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 1830867] ProcCpuinfoMinimal.txt
apport information ** Attachment added: "ProcCpuinfoMinimal.txt" https://bugs.launchpad.net/bugs/1830867/+attachment/5267330/+files/ProcCpuinfoMinimal.txt -- 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/1830867 Title: Crackling sound with HDMI Status in pulseaudio package in Ubuntu: Incomplete Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edouard1677 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.04 InstallationDate: Installed on 2019-05-28 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Package: pulseaudio 1:12.2-2ubuntu3 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Tags: disco Uname: Linux 5.0.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KHCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KHCTO1WW:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KHCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KHCTO1WW dmi.product.sku: LENOVO_MT_20KH_BU_Think_FM_ThinkPad X1 Carbon 6th dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO modified.conffile..etc.pulse.default.pa: [modified] mtime.conffile..etc.pulse.default.pa: 2019-05-28T23:16:01.413832 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1830867/+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 1830859] Re: new libseccomp 2.4 (in proposed) makes rebuilds need but not generate a dependency to 2.4
** Description changed:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
I realized it works on X/B/C/E but not in a D container
It worked ~4 weeks ago.
This test can be simplified to one command:
$ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
With strace I found different behavior:
Good:
[pid 3487] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.11>
[pid 3487] 0.003136 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.44>
[pid 3487] 0.000250 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x55f2b7a5e2d0}) = 0 <0.000251>
Bad:
[pid 484] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.17>
[pid 484] 0.002680 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.14>
[pid 484] 0.88 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
The difference seems to come from being built against seccomp as in
Disco (2.3.3-3ubuntu2 = good) or Disco-proposed ( = bad).
The dependency on the built package stayed
libseccomp2 (>= 2.3.0)
It did not pick up 2.4 via e.g. shlibs.
If I install libseccomp2 2.4 from -proposed the issue is gone.
Strace now looks like:
[pid 1788] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.15>
[pid 1788] 0.004167 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.13>
[pid 1788] 0.98 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
[pid 1788] 0.54 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.22>
[pid 1788] 0.61 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.17>
[pid 1788] 0.001477 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x564de3852560}) = 0 <0.000288>
This is in all releases proposed to fix CVE-2019-9893
I was just ?lucky? to pick it up with my qemu build in the PPA that has
proposed enabled.
Now there might be some toolchain detail to this as well.
As I built qemu for B/C as well and they built against the proposed 2.4
versions as well.
But in B/C things work with new qemu builds and old libseccomp2 installed.
Eoan on the other hand works by having libseccomp2 2.4.1-0ubuntu0.19.10.3
already migrated.
But that "luck" of B/C working might be specific to Qemus code, other
rebuilds against the new libseccomp2 might fail as well in B/C and
further. Shlibs detection is based on these symbols but my new qemu
build is not calling these so it dependency stays at 2.3.
- Until a simpler testcase is found, the qemu in PPA [1] built for Disco will
trigger it.
- => https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+packages
+ Until a simpler testcase is found, I have set up two new PPAs:
+
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-with-proposed-seccomp
+
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-without-proposed-seccomp
+
### some related Build logs ###
Cosmic rebuild against 2.4, not affected by the issue
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+build/16858331/+files/buildlog_ubuntu-cosmic-amd64.qemu_1%3A2.12+dfsg-3ubuntu8.9~ppa1_BUILDING.txt.gz
Disco rebuild against 2.4, affected by the issue
https://launchpadlibrarian.net/425689546/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.2~ppa1_BUILDING.txt.gz
Disco build against 2.3 (working)
https://launchpadlibrarian.net/422884897/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.1_BUILDING.txt.gz
--
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/1830859
Title:
new libseccomp 2.4 (in proposed) makes rebuilds need but not generate
a dependency to 2.4
Status in libseccomp package in Ubuntu:
New
Bug description:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
I realized it works o
[Touch-packages] [Bug 1542734] Re: [20A8003UFR, Realtek ALC3232, Black Headphone Out, Left] Background noise
Thank you for reporting this bug to Ubuntu. Ubuntu 15.10 (wily) reached end-of-life on July 28, 2016. See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed. ** Changed in: alsa-driver (Ubuntu) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1542734 Title: [20A8003UFR, Realtek ALC3232, Black Headphone Out, Left] Background noise Status in alsa-driver package in Ubuntu: Won't Fix Bug description: I've a big problem of noise in my headphone (we can hear it particulary when there's no sound in it and it makes a "ploc" when I plug my headphone) . This problem does not appear on Windows and from my search it wasn't present on Ubuntu 14.04. Thanks you if you can help me with this ! ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 4.2.0-27.32-generic 4.2.8-ckt1 Uname: Linux 4.2.0-27-generic x86_64 ApportVersion: 2.19.1-0ubuntu5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: adrien 1828 F pulseaudio /dev/snd/controlC1: adrien 1828 F pulseaudio CurrentDesktop: XFCE Date: Sat Feb 6 23:16:49 2016 InstallationDate: Installed on 2016-02-01 (5 days ago) InstallationMedia: Xubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful Symptom_Card: Audio interne - HDA Intel PCH Symptom_Jack: Black Headphone Out, Left Symptom_PulsePlaybackTest: PulseAudio playback test successful Symptom_Type: High background noise, or volume is too low Title: [20A8003UFR, Realtek ALC3232, Black Headphone Out, Left] Background noise or low volume UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/19/2015 dmi.bios.vendor: LENOVO dmi.bios.version: GRET44WW (1.21 ) dmi.board.asset.tag: Not Available dmi.board.name: 20A8003UFR dmi.board.vendor: LENOVO dmi.board.version: SDK0E50510 Pro dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrGRET44WW(1.21):bd03/19/2015:svnLENOVO:pn20A8003UFR:pvrThinkPadX1Carbon2nd:rvnLENOVO:rn20A8003UFR:rvrSDK0E50510Pro:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 20A8003UFR dmi.product.version: ThinkPad X1 Carbon 2nd dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1542734/+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 1830867] Re: [ThinkPad X1 Carbon 6th] Crackling sound with HDMI
Thanks. This may be related to bug 1827440, which is the same hardware but sounds like a slightly different problem. ** Summary changed: - Crackling sound with HDMI + [ThinkPad X1 Carbon 6th] Crackling sound with HDMI ** Changed in: pulseaudio (Ubuntu) Status: Incomplete => New ** Also affects: linux (Ubuntu) Importance: Undecided Status: New -- 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/1830867 Title: [ThinkPad X1 Carbon 6th] Crackling sound with HDMI Status in linux package in Ubuntu: New Status in pulseaudio package in Ubuntu: New Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edouard1677 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.04 InstallationDate: Installed on 2019-05-28 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Package: pulseaudio 1:12.2-2ubuntu3 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Tags: disco Uname: Linux 5.0.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KHCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KHCTO1WW:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KHCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KHCTO1WW dmi.product.sku: LENOVO_MT_20KH_BU_Think_FM_ThinkPad X1 Carbon 6th dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO modified.conffile..etc.pulse.default.pa: [modified] mtime.conffile..etc.pulse.default.pa: 2019-05-28T23:16:01.413832 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830867/+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 1093227] Re: Crackling sound (now no sound) after waking ThinkPad X1 Carbon from suspend
Thank you for reporting this bug to Ubuntu. Ubuntu 12.10 (quantal) reached end-of-life on May 16, 2014. See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed. ** Changed in: alsa-driver (Ubuntu) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1093227 Title: Crackling sound (now no sound) after waking ThinkPad X1 Carbon from suspend Status in alsa-driver package in Ubuntu: Won't Fix Bug description: This other bug that I filed on post-suspend problems may also be of relevance: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1090608 ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: alsa-base 1.0.25+dfsg-0ubuntu3 Uname: Linux 3.7.0-030700-generic x86_64 ApportVersion: 2.6.1-0ubuntu9 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: srunni 2134 F xfce4-volumed srunni 4398 F pulseaudio /dev/snd/controlC29: srunni 2134 F xfce4-volumed Date: Sat Dec 22 22:06:41 2012 EcryptfsInUse: Yes InstallationDate: Installed on 2012-11-28 (25 days ago) InstallationMedia: Xubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.1) MarkForUpload: True PackageArchitecture: all ProcEnviron: TERM=rxvt-unicode PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed Symptom_AlsaPlaybackTestStderr: W r i t e e r r o r : - 5 , I n p u t / o u t p u t e r r o r x r u n _ r e c o v e r y f a i l e d : - 5 , I n p u t / o u t p u t e r r o r T r a n s f e r f a i l e d : O p e r a t i o n n o t p e r m i t t e d Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Speaker, Internal Symptom_Type: Underruns, dropouts, or "crackling" sound Title: [3443CTO, Realtek ALC269VC, Speaker, Internal] Underruns, dropouts or crackling sound UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/11/2012 dmi.bios.vendor: LENOVO dmi.bios.version: G6ET59WW (2.03 ) dmi.board.asset.tag: Not Available dmi.board.name: 3443CTO dmi.board.vendor: LENOVO dmi.board.version: Win8 STD DPK TPG dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrG6ET59WW(2.03):bd09/11/2012:svnLENOVO:pn3443CTO:pvrThinkPadX1Carbon:rvnLENOVO:rn3443CTO:rvrWin8STDDPKTPG:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 3443CTO dmi.product.version: ThinkPad X1 Carbon dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1093227/+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 1803203] Re: Support preferred_lft for IPv6 addresses
Currently, addresses is a "sequence of scalars" (aka a list). Here is
the example from the Netplan reference you quoted:
addresses: [192.168.14.2/24, "2001:1::1/64"]
This can, currently, also be written in this form (quotes optional):
addresses:
- 192.168.14.2/24
- "2001:1::1/64"
I actually prefer the latter form, so that's what I use today.
In YAML generally (not necessarily Netplan specifically), I think the
obvious extension would be to support dictionaries in addition to
scalars, for the addresses. That would allow for this type of extension:
addresses:
- 192.168.14.2/24
- "2001:1::1/64":
lifetime: 0
other: x
future: y
parameters: z
If you really want the flattened form, it would be:
addresses: [192.168.14.2/24, "2001:1::1/64": {lifetime: 0}]
This is a clean extension from the current syntax and supports other
future parameters.
Whether Netplan's YAML parser currently supports dictionaries is another
question. But this is all normal YAML. See, for example, Ansible:
https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html
--
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/1803203
Title:
Support preferred_lft for IPv6 addresses
Status in netplan:
New
Status in netplan.io package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
Fix Released
Bug description:
There doesn't currently seem to be any way to set the preferred_lft of
an IPv6 address.
With the "ip" command it might be, for example:
# ip address add 2001:db8::2/32 dev eth0 preferred_lft 0
In a systemd unit file it might be:
[Match]
Name=eth0
[Network]
Address=2001:db8::2/32
Gateway=2001:db8::1/32
PreferredLifetime=0
but I can't find any way to express this with netplan.
This is commonly used for per-service IP addresses that should never
be used as source addresses for outgoing traffic.
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1803203/+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 1830867] Missing required logs.
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window: apport-collect 1830867 and then change the status of the bug to 'Confirmed'. If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. This change has been made by an automated script, maintained by the Ubuntu Kernel Team. ** Changed in: linux (Ubuntu) Status: New => Incomplete -- 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/1830867 Title: [ThinkPad X1 Carbon 6th] Crackling sound with HDMI Status in linux package in Ubuntu: Incomplete Status in pulseaudio package in Ubuntu: New Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edouard1677 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.04 InstallationDate: Installed on 2019-05-28 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Package: pulseaudio 1:12.2-2ubuntu3 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Tags: disco Uname: Linux 5.0.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KHCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KHCTO1WW:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KHCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KHCTO1WW dmi.product.sku: LENOVO_MT_20KH_BU_Think_FM_ThinkPad X1 Carbon 6th dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO modified.conffile..etc.pulse.default.pa: [modified] mtime.conffile..etc.pulse.default.pa: 2019-05-28T23:16:01.413832 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830867/+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 1830502] Re: apparmor fails to start with no parser errors
We can get a diff of loaded vs. expected profiles
for a straight list of loaded profiles names, you can do
$ sudo cat /sys/kernel/security/apparmor/profiles
/snap/core/6964/usr/lib/snapd/snap-confine (enforce)
/snap/core/6964/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
(enforce)
firefox (enforce)
firefox//sanitized_helper (enforce)
firefox//lsb_release (enforce)
...
we can then get a list of profile names from apparmor_parser without doing a
compile using
$ sudo apparmor_parser -N /etc/apparmor.d/ /var/lib/snapd/apparmor/profiles/
udm-extractor
ubuntu-printing-app
/usr/sbin/tcpdump
...
so a quick and dirty script to get the diff
$ sudo cat /sys/kernel/security/apparmor/profiles | awk '{ print $1 }' >
/tmp/foo ; sudo apparmor_parser -N /etc/apparmor.d/
/var/lib/snapd/apparmor/profiles/ >> /tmp/foo ; sort /tmp/foo | uniq -c | grep
-e ' 1 '
Skipping profile in /etc/apparmor.d/disable:
usr.lib.libreoffice.program.oosplash
Ignoring: 'usr.bin.firefox~'
1 /etc/apparmor.d/usr.bin.firefox
1 libvirt-79eb4c35-23a7-44bb-8894-aa97ca616850
...
basically anything with that doesn't show up in both gets a count of 1.
We can further distinguish profiles that have been loaded based on time if we
need to with
$ ls -l /sys/kernel/security/apparmor/policy/profiles/
total 0
drwxr-xr-x 2 root root 0 May 21 23:16 content-hub-clipboard.1
drwxr-xr-x 2 root root 0 May 21 23:16 content-hub-peer-picker.2
drwxr-xr-x 2 root root 0 May 21 23:16 default.0
drwxr-xr-x 2 root root 0 May 21 23:16 etc.apparmor.d.skype.6
...
and we can try to load any of the profiles we find that failed to load
individually with
$ apparmor_parser -r $profile
or if need be one by one via shell scripting (sadly the parser is
missing a direct way to dump which profile is being worked on when it is
processing multiple dirs) and it can't do it when killed from the oom
killer either.
with this we should be able to track down which profile is failing
--
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/1830502
Title:
apparmor fails to start with no parser errors
Status in apparmor package in Ubuntu:
New
Bug description:
On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk,
my system was unable to finish booting and I had to go into recovery
mode and remove a number of files before the system would boot. After
doing so I discovered that now the apparmor.service systemd unit
always fails to start. I see this in dmesg:
[ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796
or sacrifice child
[ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB,
anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB
[ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Whenever apparmor.service is attempted to be started by systemd, i.e.
either on boot, or later with `systemctl start apparmor`.
The log from journalctl doesn't show any actual issues with any
profiles just this:
-- Reboot --
May 25 17:00:58 systemd[1]: Starting AppArmor initialization...
May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles
May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable:
usr.bin.firefox
May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable:
usr.sbin.rsyslogd
May 25 17:01:40 apparmor[1521]:...fail!
May 25 17:01:40 systemd[1]: apparmor.service: Main process exited,
code=exited, status=123/n/a
May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'.
May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization.
May 25 17:04:53 systemd[1]: Starting AppArmor initialization...
May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles
May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable:
usr.bin.firefox
May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable:
usr.sbin.rsyslogd
May 25 17:05:25 apparmor[4747]:...fail!
May 25 17:05:25 systemd[1]: apparmor.service: Main process exited,
code=exited, status=123/n/a
May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'.
May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization.
I can see that apparmor profiles are active after doing this (using
aa-status), but it's still troubling that apparmor runs into an issue
without actually saying what the error is.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1830867] Re: [ThinkPad X1 Carbon 6th] Crackling sound with HDMI
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- 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/1830867 Title: [ThinkPad X1 Carbon 6th] Crackling sound with HDMI Status in linux package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: New Bug description: Hello, I have a new laptop and I cannot manage to have a clean and stable sound with HDMI. It happens every time I play a track on Spotify (desktop and web), sometimes from a VLC radio or a youtube video, never from a video with VLC yet. I'm attaching a record of what I hear when I play a track from Spotify. I created two reports. One during a Spotify playing, when it is crackling and after the sound started to crackle everywhere: http://alsa-project.org/db/?f=4e7d724718a48179fa2f3740d5f3e634ad75def9 Another after a fresh reboot, where the sound is correct with at least YouTube: http://alsa-project.org/db/?f=2ec68f888bb93a0de648d48fd720f54cee644564 Just after this last report, the sound is still crackling with Spotify and VLC radio. Not with Youtube. A diff on theses files gives some differences I find suspect. Are there expected ? Do you have an idea where the problem comes from ? Thank you for your support ! Edouard --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: edouard1677 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 19.04 InstallationDate: Installed on 2019-05-28 (0 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) Package: pulseaudio 1:12.2-2ubuntu3 PackageArchitecture: amd64 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Tags: disco Uname: Linux 5.0.0-15-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 04/20/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N23ET63W (1.38 ) dmi.board.asset.tag: Not Available dmi.board.name: 20KHCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN23ET63W(1.38):bd04/20/2019:svnLENOVO:pn20KHCTO1WW:pvrThinkPadX1Carbon6th:rvnLENOVO:rn20KHCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X1 Carbon 6th dmi.product.name: 20KHCTO1WW dmi.product.sku: LENOVO_MT_20KH_BU_Think_FM_ThinkPad X1 Carbon 6th dmi.product.version: ThinkPad X1 Carbon 6th dmi.sys.vendor: LENOVO modified.conffile..etc.pulse.default.pa: [modified] mtime.conffile..etc.pulse.default.pa: 2019-05-28T23:16:01.413832 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1830867/+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 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
** Changed in: python-tornado (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in libwww-perl package in Ubuntu: New Status in openssl package in Ubuntu: Fix Released Status in python-tornado package in Ubuntu: In Progress Status in libio-socket-ssl-perl source package in Bionic: Incomplete Status in libnet-ssleay-perl source package in Bionic: Incomplete Status in openssl source package in Bionic: Fix Committed Status in python-cryptography source package in Bionic: Fix Committed Status in python2.7 source package in Bionic: Fix Committed Status in python3.6 source package in Bionic: Fix Committed Status in python3.7 source package in Bionic: Fix Committed Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: Fix Committed Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Test cases for the python updates] python3.7 is a preview in bionic as a non-supported/non-default version of python3. Passing it's own autopkgtests is sufficient validation for python3.7. It includes a point release update, with OpenSSL 1.1.1 compat and features. python3.6 not only has OpenSSL 1.1.1 compat and features patches, but also includes a point release update to 3.6.8. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python3.6 and python3-defaults with regressions already fixed in the individual packages as appropriate. python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1 compat only. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python2.7 and python-defaults with regressions already fixed in the individual packages as appropriate. The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1 and python point releases as seen in: http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html And analyzed in https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652 [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. - non-application data records. TLSv1.3 sends more of these, when compared with previous versions, and some applications may not handle this correctly. Resulting in application data not being available, when previously expected. Mitigation around these involve disabling/enabling SSL_MODE_AUTO_RETRY or setting max protocol version to TLSv1.2. For example see discussion identified in the perl stack https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034 Similar hangs are possible with prior versions of TLS as well, it is however easier to trigger this with TLSv1.3. * Deprecated npn extenstion does not exist in TLSv1.3 implementation. * This update bundles python 3.6 and 3.7 point releases [Other Info] * Previous FFe for OpenSSL in 18.10 is
[Touch-packages] [Bug 1830859] Re: new libseccomp 2.4 (in proposed) makes rebuilds need but not generate a dependency to 2.4
Two Disco containers (one per PPA)
$ sudo add-apt-repository ppa:paelzer/bug-1830859-with-proposed-seccomp
or
$ sudo add-apt-repository ppa:paelzer/bug-1830859-without-proposed-seccomp
# add main/debug and enable the deb-src in the PPA sources
$ sudo apt install gdb qemu-system-x86 qemu-system-x86-dbgsym dpkg-dev
$ apt source qemu
$ cd qemu-3.1+dfsg/
break on qemu_seccomp
Hrm ??
equal qemu source
Good:
Breakpoint 1 at 0x4d63f4: file ./qemu-seccomp.c, line 293.
Bad:
Breakpoint 1 at 0x4d63f4: qemu_seccomp. (2 location
(gdb) info b
Num Type Disp Enb AddressWhat
1 breakpoint keep y
1.1 y 0x004d63f4 in qemu_seccomp at
./qemu-seccomp.c:293
1.2 y 0x004d656e in qemu_seccomp at
./qemu-seccomp.c:244
Now the second hit isn't an actual qemu_seccomp call, but it is very
close to the error that we get reported.
(gdb) l qemu-seccomp.c:293
288
289 #if defined(SECCOMP_FILTER_FLAG_TSYNC)
290 int check;
291
292 /* check host TSYNC capability, it returns errno == ENOSYS if
unavailable */
293 check = qemu_seccomp(SECCOMP_SET_MODE_FILTER,
294 SECCOMP_FILTER_FLAG_TSYNC, NULL);
295 if (check < 0 && errno == EFAULT) {
296 add = true;
297 }
(gdb) l qemu-seccomp.c:244
239 error_setg(errp, "invalid argument for
resourcecontrol");
240 return -1;
241 }
242 }
243
244 if (seccomp_start(seccomp_opts) < 0) {
245 error_setg(errp, "failed to install seccomp syscall filter "
246"in the kernel");
247 return -1;
248 }
Well maybe with seccomp 2.4 development headers something changed and this now
gets inlined?
That is not an error, but suspicious.
qemu_seccomp should ALWAYS be inlined
static inline __attribute__((unused)) int
qemu_seccomp(unsigned int operation, unsigned int flags, void *args)
The one at line 293 is at seccomp_register and depends on #if
defined(SECCOMP_FILTER_FLAG_TSYNC).
This one is active in both cases.
But the one at line 244 is part of qemu_seccomp_get_kill_action
That has some checks as well being:
#if defined(SECCOMP_GET_ACTION_AVAIL) && \
defined(SCMP_ACT_KILL_PROCESS) && \
defined(SECCOMP_RET_KILL_PROCESS)
There is no other way to "avoid" the path of
parse_sandbox -> seccomp_start -> qemu_seccomp_get_kill_action ->
qemu_seccomp
in terms of precompiler.
Both have CONFIG_SECCOMP set, so it might really come down to the three checks
above.
Reading the commit [1] that added this to qemu seems to match the
current theories.
Lets see what happens when it tries to use things buildt with 2.4 but
without 2.4 being installed at runtime.
The returned value for action is matching expected /usr/include/seccomp.h
numbers:
- good case => 196608 ==> SCMP_ACT_TRAP = 0x0003U
- bad case => 2147483648 ==> SCMP_ACT_KILL_PROCESS = 0x8000U
As a summary:
- the libseccomp-dev 2.4 headers being installed at build time
- code can detect now the availability of SCMP_ACT_KILL_PROCESS
- code might decide to use SCMP_ACT_KILL_PROCESS
- if code runs without libseccomp2 2.4 installed it breaks
For qemu I could patch out the usage of SCMP_ACT_KILL_PROCESS, but:
- that is stupid as it is preferred if available
- the question is either
- how can we make such rebuilds pick up the dependency correctly
- could we runtime (instead of compile time) detect if SCMP_ACT_KILL_PROCESS
is available
[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=bda08a5764d
** Description changed:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
I realized it works on X/B/C/E but not in a D container
It worked ~4 weeks ago.
This test can be simplified to one command:
$ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
With strace I found different behavior:
Good:
[pid 3487] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.11>
[pid 3487] 0.003136 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.44>
[pid 3487] 0.000250 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x55f2b7a5e2d0}) = 0 <0.000251>
Bad:
[pid 484] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.17>
[pid 484] 0.002680 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SEC
[Touch-packages] [Bug 1830859] Re: new libseccomp 2.4 (in proposed) makes rebuilds need but not generate a dependency to 2.4
[13:09] cpaelzer: oh, we knew about that one :(
[13:09] well
[13:09] then had you a plan how we should resolve that
[13:10] either in general (magic great code I haven't thought of) or
in particular (how I should resolve it for qemu) ?
[13:10] and good morning mdeslaur sorry to start with such issues :-/
[13:10] cpaelzer: good morning! :)
[13:11] <-- lborda-eod (lbo...@173-246-24-26.qc.cable.ebox.net) has left this
server (Quit: Ex-Chat).
[13:11] cpaelzer: the plan is to publish the libseccomp update ;)
[13:11] --> lborda (lbo...@173-246-24-26.qc.cable.ebox.net) has joined this
channel.
[13:11] cpaelzer: we searched the archive, and qemu was the only
problematic package that used those new apis
[13:12] jdstrand: are we ready to publish the seccomp updates?
[13:12] mdeslaur: ok then should I add an explicit dependency for
Disco
[13:12] only there the "transition" might occur
[13:13] that we rebuild with the new version around but the old
might be installed
[13:13] hey mdeslaur
[13:13] I'm prepping an SRU anyway and that would avoid the "rebuilt
to 2.4 but not installed"
[13:13] if qemu really is the only one I'm ok to carry this
[13:13] cpaelzer: yeah, you can add an explicit dependency, or you
can wait until we publish seccomp...we may publish it today or monday
[13:13] and in Eoan things are fine as that will release with >=2.4
[13:14] mdeslaur: well, my point is even if you publish it there are
no guarantees
[13:14] people might update qemu but not libseccomp
[13:14] and they would be screwed
[13:14] so the first rebuild of qemu in disco (=now) will need to
add the dependency
[13:14] mdeslaur: ^^
[13:15] yes, selective installing of security updates is an untested
and probably broken configuration
[13:15] if you add the explicit dependency, you'll need to wait
until we do publish seccomp too
[13:15] yes, but I'll need a few days anyway
[13:15] and you seem close
[13:16] ok
[13:16] and for testing interim wise I can throw a no change rebuild
of libseccomp 2.4 in my ppa
[13:16] I'll try and remember to add the explicit dependency to the
next round of qemu updates
[13:16] Hmm, you have some in the pipe as well?
[13:16] I don't currently, no
[13:16] I have
[13:16] I'll add them right away
[13:17] if testing goes well those should hit -unapproved early next
week
[13:17] sorry our timezones don't overlap and you had to spend time
debugging this
[13:17] we spotted this issue when we prepared the emergency qemu
update last week
TL;DR
we will make is a qemu fix in Disco, by adding an explicit dependency.
All others don't need the change.
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: libseccomp (Ubuntu)
Status: New => Won't Fix
** Changed in: qemu (Ubuntu)
Status: New => Triaged
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** Changed in: libseccomp (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
** Changed in: qemu (Ubuntu)
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/1830859
Title:
new libseccomp 2.4 (in proposed) makes rebuilds need but not generate
a dependency to 2.4
Status in libseccomp package in Ubuntu:
Won't Fix
Status in qemu package in Ubuntu:
Triaged
Bug description:
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
I realized it works on X/B/C/E but not in a D container
It worked ~4 weeks ago.
This test can be simplified to one command:
$ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
With strace I found different behavior:
Good:
[pid 3487] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.11>
[pid 3487] 0.003136 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.44>
[pid 3487] 0.000250 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x55f2b7a5e2d0}) = 0 <0.000251>
Bad:
[pid 484] 0.00 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.17>
[pid 484] 0.002680 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.14>
[pid 484] 0.88 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.13>
The difference seems to come from being built against seccomp as in
Disco (2.3.3-3ubu
[Touch-packages] [Bug 1828617] Re: Hosts randomly 'losing' disks, breaking ceph-osd service enumeration
Thanks for all the details. I need to confirm this but I think the block.db and block.wal symlinks are created as a result of 'ceph-volume lvm prepare --bluestore --data --block.wal --block.db '. That's coded in the ceph-osd charm around here: https://opendev.org/openstack/charm-ceph- osd/src/branch/master/lib/ceph/utils.py#L1558 Can you confirm that the symlinks are ok prior to reboot? I'd like to figure out if they are correctly set up by the charm initially. -- 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/1828617 Title: Hosts randomly 'losing' disks, breaking ceph-osd service enumeration Status in systemd package in Ubuntu: New Bug description: Ubuntu 18.04.2 Ceph deployment. Ceph OSD devices utilizing LVM volumes pointing to udev-based physical devices. LVM module is supposed to create PVs from devices using the links in /dev/disk/by-dname/ folder that are created by udev. However on reboot it happens (not always, rather like race condition) that Ceph services cannot start, and pvdisplay doesn't show any volumes created. The folder /dev/disk/by-dname/ however has all necessary device created by the end of boot process. The behaviour can be fixed manually by running "#/sbin/lvm pvscan --cache --activate ay /dev/nvme0n1" command for re-activating the LVM components and then the services can be started. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828617/+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 1803993] Re: Password appears on the VT1 screen
@rbalint, this is still in eoan-proposed, can you get it pushed out to eoan-updates (or revert it)? -- 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/1803993 Title: Password appears on the VT1 screen Status in gdm3 package in Ubuntu: Invalid Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: In Progress Bug description: [Impact] * The keyboard on the graphical login screen started on VT1 may stop working and or keypresses including passwords are leaked to the terminal console running 'behind' the graphical login screen or environment. [Test Case] * Reboot after installing the fixed systemd package. * Install sysdig * Start sysdig on a remote connection or on a terminal console: $ sudo sysdig evt.type=ioctl | grep request=4B4 * While sysdig is running log in and out 3 times in GDM and press a few keys in the graphical session to see if keyboard still works * Log in and out on an other terminal console, too, running a few commands while being logged in to ensure that keyboard is working. * Observe that on terminal consoles the monitored keyboard setter ioctl is called with argument=3, but where the graphical screen is active only argument=4 is used, unlike with the buggy version observed in https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/comments/14 [Regression Potential] * The fix checks the current keyboard mode of the VT and allows only safe mode switches. The potential regression could be not allowing a valid mode switch keeping a keyboard in a non-operational mode. Testing covers that by typing the keyboard. (continued from bug 1767918) This was found when an administrative error made /home directory inaccessible. Any users that tried to login after that, were not able to (which is expected) but their password appears on the VT1 screen. Under normal circumstances, VT1 is not visible. But once the system was sent into this compromised mode, one can press ctrl+alt+F1 and then ctrl+alt+F2 and get a momentary glance at VT1. One can keep toggling between these key combinations in order to make out the password(s) on VT1. As a further test, I wanted to see if a non-super user could cause this condition, and it is in fact possible. As a regular user, I made their own home directory not writable and then removed ~/.config and logged out. Then logged in as that user again, and although that user can't login the system does go into that mode where passwords appear on VT1 and are viewable with the key combinations mentioned herein. Further, any other users that login will see no problem, but when they logon their passwords also appear on VT1 and are viewable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.3 Uname: Linux 4.19.2-041902-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Nov 19 08:32:59 2018 InstallationDate: Installed on 2018-08-25 (85 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/+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 1825997] Re: boot-smoke fails due to running jobs
** Description changed: [impact] boot-smoke test reboots 5 times and verifies systemd is fully started up after each boot, including checking if there are any running jobs (with list-jobs). However, this test makes the assumption that no further jobs will be started after systemd reaches 'running' (or 'degraded') state, which is a false assumption. [test case] see various boot-smoke failures in autopkgtest.ubuntu.com [regression potential] possible false-positive or false-negative autopkgtest results. [other info] - The problem appears to be that systemd reaches 'running' (or 'degraded') - state, and then other systemd services are started. This confuses the - boot-smoke test, because it sees that 'is-system-running' is done, but - then it sees running jobs, which fails the test. + Note: This patch is not required for debian, because debian's boot-smoke + does not include the wait for systemctl is-system-running. + + + The problem appears to be that systemd reaches 'running' (or 'degraded') state, and then other systemd services are started. This confuses the boot-smoke test, because it sees that 'is-system-running' is done, but then it sees running jobs, which fails the test. What is starting jobs after systemd reaches running state appears to be X inside the test system. There are various services started by gnome- session and dbus-daemon. Additionally, from the artifacts of one example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- bionic/bionic/i386/s/systemd/20190416_171327_478f6@/artifacts.tar.gz the artifacts/journal.txt shows that after the boot-smoke test causes the reboot and then re-ssh into the system after the reboot, it only gives the test system 9 seconds before deciding it has failed, and only 4 seconds after ssh'ing into the rebooted test system. Another wait is needed when checking for remaining running jobs. Or, the running jobs check could be removed entirely, and we can just trust that systemd correctly knows when it has reached running|degraded state. -- 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/1825997 Title: boot-smoke fails due to running jobs Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: In Progress Bug description: [impact] boot-smoke test reboots 5 times and verifies systemd is fully started up after each boot, including checking if there are any running jobs (with list-jobs). However, this test makes the assumption that no further jobs will be started after systemd reaches 'running' (or 'degraded') state, which is a false assumption. [test case] see various boot-smoke failures in autopkgtest.ubuntu.com [regression potential] possible false-positive or false-negative autopkgtest results. [other info] Note: This patch is not required for debian, because debian's boot- smoke does not include the wait for systemctl is-system-running. The problem appears to be that systemd reaches 'running' (or 'degraded') state, and then other systemd services are started. This confuses the boot-smoke test, because it sees that 'is-system-running' is done, but then it sees running jobs, which fails the test. What is starting jobs after systemd reaches running state appears to be X inside the test system. There are various services started by gnome-session and dbus-daemon. Additionally, from the artifacts of one example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- bionic/bionic/i386/s/systemd/20190416_171327_478f6@/artifacts.tar.gz the artifacts/journal.txt shows that after the boot-smoke test causes the reboot and then re-ssh into the system after the reboot, it only gives the test system 9 seconds before deciding it has failed, and only 4 seconds after ssh'ing into the rebooted test system. Another wait is needed when checking for remaining running jobs. Or, the running jobs check could be removed entirely, and we can just trust that systemd correctly knows when it has reached running|degraded state. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825997/+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 1830914] [NEW] software-properties-gtk does not run at all!
Public bug reported:
software-properties-gtk does not even start!
$ software-properties-gtk --debug
ENABLED COMPS: {'universe', 'main'}
INTERNET COMPS: {'universe', 'main'}
MAIN SOURCES
URI: http://archive.ubuntu.com/ubuntu
Comps: ['main']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu
BaseURI: http://archive.ubuntu.com/ubuntu
URI: http://archive.ubuntu.com/ubuntu
Comps: ['universe']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu
BaseURI: http://archive.ubuntu.com/ubuntu
CHILD SOURCES
URI: http://archive.ubuntu.com/ubuntu
Comps: ['main']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu
BaseURI: None
URI: http://archive.ubuntu.com/ubuntu
Comps: ['universe']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu
BaseURI: None
URI: http://archive.ubuntu.com/ubuntu
Comps: ['main']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu|security.ubuntu.com
BaseURI: http://security.ubuntu.com/ubuntu/
URI: http://archive.ubuntu.com/ubuntu
Comps: ['universe']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu|security.ubuntu.com
BaseURI: http://security.ubuntu.com/ubuntu/
URI: http://archive.ubuntu.com/ubuntu
Comps: ['universe', 'main']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu
BaseURI: None
CDROM SOURCES
SOURCE CODE SOURCES
DISABLED SOURCES
ISV
Traceback (most recent call last):
File "/usr/bin/software-properties-gtk", line 100, in
app = SoftwarePropertiesGtk(datadir=options.data_dir, options=options,
file=file)
File
"/usr/lib/python3/dist-packages/softwareproperties/gtk/SoftwarePropertiesGtk.py",
line 200, in __init__
self.init_livepatch()
File
"/usr/lib/python3/dist-packages/softwareproperties/gtk/SoftwarePropertiesGtk.py",
line 1482, in init_livepatch
self.livepatch_page = LivepatchPage(self)
File
"/usr/lib/python3/dist-packages/softwareproperties/gtk/LivepatchPage.py", line
51, in __init__
self._lps = LivepatchService()
File "/usr/lib/python3/dist-packages/softwareproperties/LivepatchService.py",
line 93, in __init__
self._session = requests_unixsocket.Session()
NameError: name 'requests_unixsocket' is not defined
{Exited with code 1.}
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 19.04
Release:19.04
Codename: disco
$ dpkg-query -l software-properties-gtk python3-requests-unixsocket
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion Architecture Description
+++-===---===
ii python3-requests-unixsocket 0.1.5-3 all Use requests to talk
HTTP via a UNIX domain socket - Python 3.x
ii software-properties-gtk 0.97.11 all manage the
repositories that you install software from (gtk)
$ sudo apt-get update
{Works.}
$ sudo apt-get dist-upgrade
{Works.}
** Affects: software-properties (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1830914
Title:
software-properties-gtk does not run at all!
Status in software-properties package in Ubuntu:
New
Bug description:
software-properties-gtk does not even start!
$ software-properties-gtk --debug
ENABLED COMPS: {'universe', 'main'}
INTERNET COMPS: {'universe', 'main'}
MAIN SOURCES
URI: http://archive.ubuntu.com/ubuntu
Comps: ['main']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu
BaseURI: http://archive.ubuntu.com/ubuntu
URI: http://archive.ubuntu.com/ubuntu
Comps: ['universe']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu
BaseURI: http://archive.ubuntu.com/ubuntu
CHILD SOURCES
URI: http://archive.ubuntu.com/ubuntu
Comps: ['main']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu
BaseURI: None
URI: http://archive.ubuntu.com/ubuntu
Comps: ['universe']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu
BaseURI: None
URI: http://archive.ubuntu.com/ubuntu
Comps: ['main']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu|security.ubuntu.com
BaseURI: http://security.ubuntu.com/ubuntu/
URI: http://archive.ubuntu.com/ubuntu
Comps: ['universe']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu|security.ubuntu.com
BaseURI: http://security.ubuntu.com/ubuntu/
URI: http://archive.ubuntu.com/ubuntu
Comps: ['universe', 'main']
Enabled: True
Valid: True
MatchURI: archive.ubuntu.com/ubuntu
BaseURI:
[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
** Tags added: bitesize server-next ** Changed in: bash (Ubuntu) Assignee: (unassigned) => Bryce Harrington (bryce) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: New Bug description: Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. Edit as per the SRU procedure: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. [Test Case] Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. [Regression Potential] Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Other Info] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+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 1828171] Re: New toolchain updates need to be rebuilt against -security only
** Also affects: ggcov (Ubuntu) Importance: Undecided Status: New -- 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/1828171 Title: New toolchain updates need to be rebuilt against -security only Status in binutils package in Ubuntu: New Status in eclipse-titan package in Ubuntu: New Status in gcc-7 package in Ubuntu: New Status in gcc-7-cross package in Ubuntu: New Status in gcc-7-cross-ports package in Ubuntu: New Status in gcc-8 package in Ubuntu: New Status in gcc-8-cross package in Ubuntu: New Status in gcc-8-cross-ports package in Ubuntu: New Status in gcc-defaults package in Ubuntu: New Status in gcc-defaults-ports package in Ubuntu: New Status in ggcov package in Ubuntu: New Status in binutils source package in Bionic: New Status in eclipse-titan source package in Bionic: New Status in gcc-7 source package in Bionic: New Status in gcc-7-cross source package in Bionic: New Status in gcc-7-cross-ports source package in Bionic: New Status in gcc-8 source package in Bionic: New Status in gcc-8-cross source package in Bionic: New Status in gcc-8-cross-ports source package in Bionic: New Status in gcc-defaults source package in Bionic: New Status in gcc-defaults-ports source package in Bionic: New Status in ggcov source package in Bionic: New Status in binutils source package in Cosmic: New Status in eclipse-titan source package in Cosmic: New Status in gcc-7 source package in Cosmic: New Status in gcc-7-cross source package in Cosmic: New Status in gcc-7-cross-ports source package in Cosmic: New Status in gcc-8 source package in Cosmic: New Status in gcc-8-cross source package in Cosmic: New Status in gcc-8-cross-ports source package in Cosmic: New Status in gcc-defaults source package in Cosmic: New Status in gcc-defaults-ports source package in Cosmic: New Status in ggcov source package in Cosmic: New Bug description: [Impact] With LP: #1814369, the toolchain packages have been updated in both cosmic and bionic, but due to an error those packages were built in -proposed as any regular SRU. For toolchain updates there exists a policy that those should be always built against -security *only*, and then released to both -security and -updates. Since this is not the case with the current toolchain update, we need to no-change rebuild all of the previously released toolchain packages in a -security enabled devirt PPA, sync them to -proposed with binaries and then release into the archives. [Regression Potential] As these are toolchain packages, there is always some regression potential. These will be no-change rebuilds so in theory the risk should be low, but the current versions of the packages have not been built against -security only before. It is hard to say how any regressions could manifest themselves. [Test Case] Making sure there are no reported regressions in the GCC and binutils test suites. Hopefully this will be sufficient. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1828171/+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 1803993] Re: Password appears on the VT1 screen
> can you get it pushed out to eoan-updates (or revert it)? sorry i meant eoan-release also, see discussion in #ubuntu-devel, I'll revert this patch in my upload to eoan, so that the regression can be figured out. -- 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/1803993 Title: Password appears on the VT1 screen Status in gdm3 package in Ubuntu: Invalid Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: In Progress Bug description: [Impact] * The keyboard on the graphical login screen started on VT1 may stop working and or keypresses including passwords are leaked to the terminal console running 'behind' the graphical login screen or environment. [Test Case] * Reboot after installing the fixed systemd package. * Install sysdig * Start sysdig on a remote connection or on a terminal console: $ sudo sysdig evt.type=ioctl | grep request=4B4 * While sysdig is running log in and out 3 times in GDM and press a few keys in the graphical session to see if keyboard still works * Log in and out on an other terminal console, too, running a few commands while being logged in to ensure that keyboard is working. * Observe that on terminal consoles the monitored keyboard setter ioctl is called with argument=3, but where the graphical screen is active only argument=4 is used, unlike with the buggy version observed in https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/comments/14 [Regression Potential] * The fix checks the current keyboard mode of the VT and allows only safe mode switches. The potential regression could be not allowing a valid mode switch keeping a keyboard in a non-operational mode. Testing covers that by typing the keyboard. (continued from bug 1767918) This was found when an administrative error made /home directory inaccessible. Any users that tried to login after that, were not able to (which is expected) but their password appears on the VT1 screen. Under normal circumstances, VT1 is not visible. But once the system was sent into this compromised mode, one can press ctrl+alt+F1 and then ctrl+alt+F2 and get a momentary glance at VT1. One can keep toggling between these key combinations in order to make out the password(s) on VT1. As a further test, I wanted to see if a non-super user could cause this condition, and it is in fact possible. As a regular user, I made their own home directory not writable and then removed ~/.config and logged out. Then logged in as that user again, and although that user can't login the system does go into that mode where passwords appear on VT1 and are viewable with the key combinations mentioned herein. Further, any other users that login will see no problem, but when they logon their passwords also appear on VT1 and are viewable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.3 Uname: Linux 4.19.2-041902-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Nov 19 08:32:59 2018 InstallationDate: Installed on 2018-08-25 (85 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Bug watch added: Debian Bug tracker #929726 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929726 ** Also affects: systemd (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929726 Importance: Unknown Status: Unknown -- 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: In Progress Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: In Progress Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Status in udisks2 source package in Cosmic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: In Progress Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: In Progress Status in udisks2 source package in Eoan: Invalid Status in systemd package in Debian: Unknown Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1829347] Re: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
** Bug watch added: Debian Bug tracker #929728
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929728
** Also affects: systemd (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929728
Importance: Unknown
Status: Unknown
--
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/1829347
Title:
systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Cosmic:
In Progress
Status in systemd source package in Disco:
In Progress
Status in systemd source package in Eoan:
In Progress
Status in systemd package in Debian:
Unknown
Bug description:
[impact]
systemd autopkgtest fails
[test case]
run systemd autopkgtest, check for output like:
LUKS device with "tmp" option ... rmmod: ERROR: Module scsi_debug is in use
FAIL
==
FAIL: test_luks_tmp (__main__.CryptsetupTest)
LUKS device with "tmp" option
--
Traceback (most recent call last):
File "/tmp/autopkgtest.It858Q/build.e7O/src/debian/tests/storage", line 59,
in setUp
self.fail('%s exists already' % self.plaintext_dev)
AssertionError: /dev/mapper/testcrypt1 exists already
or for older releases something like:
autopkgtest [19:27:26]: test storage: [---
modprobe: FATAL: Module scsi_debug not found in directory
/lib/modules/4.18.0-1011-kvm
ERROR
==
ERROR: setUpClass (__main__.CryptsetupTest)
--
Traceback (most recent call last):
File "/tmp/autopkgtest.azsL0q/build.Hbd/src/debian/tests/storage", line 21,
in setUpClass
subprocess.check_call(['modprobe', 'scsi_debug'])
File "/usr/lib/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['modprobe', 'scsi_debug']' returned
non-zero exit status 1.
this has attempted to be fixed in disco/eoan so the output is a bit different
across different releases, but all of them have the common point of failing to
modprobe or rmmod the scsi_debug module, which by itself doesn't indicate a
failure.
[regression potential]
low; this is fixing a testcase only.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829347/+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 1830936] [NEW] Wayland freeze 18.04 using VLC
Public bug reported: I tried Wayland while logging in and it works fine until I try to play some local video file using VLC. Ubuntu freezes completely and I have to power off by pressing the power button. It works fine in the default Xorg Ubuntu session. I have the latest version of VLC that comes with the update which 3.0.6 and Ubuntu 18.04 fully updated. ** Affects: wayland (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1830936 Title: Wayland freeze 18.04 using VLC Status in wayland package in Ubuntu: New Bug description: I tried Wayland while logging in and it works fine until I try to play some local video file using VLC. Ubuntu freezes completely and I have to power off by pressing the power button. It works fine in the default Xorg Ubuntu session. I have the latest version of VLC that comes with the update which 3.0.6 and Ubuntu 18.04 fully updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/1830936/+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 1554715] Re: rmt and rmt-tar should not be autoinstalled
** Bug watch added: Debian Bug tracker #653045 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653045 ** Also affects: tar (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653045 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1554715 Title: rmt and rmt-tar should not be autoinstalled Status in tar package in Ubuntu: Triaged Status in tar package in Debian: Unknown Bug description: A "remote magtape protocol module? On PCs? In 2016? The are potential users for this thing, maybe, on Z-series mainframes, but having it be autoinstalled on vanilla desktop machines, or even ordinary servers, is deeply silly. Recommendation: split the package. Yes, tar is essential; rmt is not. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: tar 1.27.1-2 ProcVersionSignature: Ubuntu 4.2.0-25.30-generic 4.2.6 Uname: Linux 4.2.0-25-generic x86_64 ApportVersion: 2.19.1-0ubuntu5 Architecture: amd64 CurrentDesktop: i3 Date: Tue Mar 8 15:23:17 2016 InstallationDate: Installed on 2016-01-02 (65 days ago) InstallationMedia: Xubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021) SourcePackage: tar UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tar/+bug/1554715/+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 1830939] Re: package python-ibus 1.5.5-1ubuntu3.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
** Tags removed: need-duplicate-check -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1830939 Title: package python-ibus 1.5.5-1ubuntu3.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 Status in ibus package in Ubuntu: New Bug description: When I turn on my computer, it tells me there was an error and it asks me to report saying "Sorry, the application py3compile has stopped unexpectedly." ProblemType: Package DistroRelease: Ubuntu 14.04 Package: python-ibus 1.5.5-1ubuntu3.2 ProcVersionSignature: Ubuntu 3.19.0-80.88~14.04.1-generic 3.19.8-ckt22 Uname: Linux 3.19.0-80-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.29 Architecture: amd64 Date: Tue May 28 21:16:32 2019 DuplicateSignature: package:python-ibus:1.5.5-1ubuntu3.2:subprocess installed post-installation script returned error exit status 1 ErrorMessage: subprocess installed post-installation script returned error exit status 1 InstallationDate: Installed on 2019-05-21 (8 days ago) InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805) PackageArchitecture: all RelatedPackageVersions: dpkg 1.17.5ubuntu5.8 apt 1.0.1ubuntu2.23 SourcePackage: ibus Title: package python-ibus 1.5.5-1ubuntu3.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1830939/+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 1830479] Re: testcases expect first kernel log line, but not always in logs
** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: systemd (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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1830479 Title: testcases expect first kernel log line, but not always in logs Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Status in systemd source package in Cosmic: New Status in systemd source package in Disco: New Status in systemd source package in Eoan: New Bug description: [impact] boot-and-services and cmdline-upstart-boot expect the first(ish) kernel log line to be in the system logs, but that is not guaranteed to be in the logs. [test case] run autopkgtest on arm64 with the current kernel, whose kernel log size is too small for journald or rsyslogd to capture the first kernel log messages. [regression potential] low; testcase fix only. [other info] the specific cause of this currently is too-small kernel log buffer size on arm64, which is being fixed in bug 1824864, but increasing amounts of boot time logging may cause a failure again, or custom kernel configs with small log buffers. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830479/+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 1830939] [NEW] package python-ibus 1.5.5-1ubuntu3.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
Public bug reported: When I turn on my computer, it tells me there was an error and it asks me to report saying "Sorry, the application py3compile has stopped unexpectedly." ProblemType: Package DistroRelease: Ubuntu 14.04 Package: python-ibus 1.5.5-1ubuntu3.2 ProcVersionSignature: Ubuntu 3.19.0-80.88~14.04.1-generic 3.19.8-ckt22 Uname: Linux 3.19.0-80-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.29 Architecture: amd64 Date: Tue May 28 21:16:32 2019 DuplicateSignature: package:python-ibus:1.5.5-1ubuntu3.2:subprocess installed post-installation script returned error exit status 1 ErrorMessage: subprocess installed post-installation script returned error exit status 1 InstallationDate: Installed on 2019-05-21 (8 days ago) InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805) PackageArchitecture: all RelatedPackageVersions: dpkg 1.17.5ubuntu5.8 apt 1.0.1ubuntu2.23 SourcePackage: ibus Title: package python-ibus 1.5.5-1ubuntu3.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: ibus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package trusty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1830939 Title: package python-ibus 1.5.5-1ubuntu3.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 Status in ibus package in Ubuntu: New Bug description: When I turn on my computer, it tells me there was an error and it asks me to report saying "Sorry, the application py3compile has stopped unexpectedly." ProblemType: Package DistroRelease: Ubuntu 14.04 Package: python-ibus 1.5.5-1ubuntu3.2 ProcVersionSignature: Ubuntu 3.19.0-80.88~14.04.1-generic 3.19.8-ckt22 Uname: Linux 3.19.0-80-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.29 Architecture: amd64 Date: Tue May 28 21:16:32 2019 DuplicateSignature: package:python-ibus:1.5.5-1ubuntu3.2:subprocess installed post-installation script returned error exit status 1 ErrorMessage: subprocess installed post-installation script returned error exit status 1 InstallationDate: Installed on 2019-05-21 (8 days ago) InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805) PackageArchitecture: all RelatedPackageVersions: dpkg 1.17.5ubuntu5.8 apt 1.0.1ubuntu2.23 SourcePackage: ibus Title: package python-ibus 1.5.5-1ubuntu3.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1830939/+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 1830502] Re: apparmor fails to start with no parser errors
So I ran your snippet to determine which profiles weren't loaded and the
only one which wasn't loaded was:
```
$ sudo cat /sys/kernel/security/apparmor/profiles | awk '{ print $1 }' >
/tmp/foo ; sudo apparmor_parser -N /etc/apparmor.d/
/var/lib/snapd/apparmor/profiles/ >> /tmp/foo ; sort /tmp/foo | uniq -c | grep
-e ' 1 '
Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
1 snap-update-ns.layouts-test
```
which is a local snap I was developing quite some time ago. I will
attach the associated apparmor profile that was generated, but
curiously, when I try to load that profile manually with apparmor_parser
it succeeds:
```
$ sudo apparmor_parser -r
/var/lib/snapd/apparmor/profiles/snap-update-ns.layouts-test
$ echo $?
0
```
with the following output in the system journal indicating that the load
was successful:
```
May 29 11:23:22 audit[21275]: AVC apparmor="STATUS" operation="profile_load"
profile="unconfined" name="snap-update-ns.layouts-test" pid=21275
comm="apparmor_parser"
May 29 11:23:22 kernel: audit: type=1400 audit(1559147002.259:420):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="snap-update-ns.layouts-test" pid=21275 comm="apparmor_parser"
May 29 11:23:22 sudo[21273]: pam_unix(sudo:session): session closed for user
root
```
and no kernel messages regarding apparmor_parser being killed from the
OOM killer.
After doing this, then there is not a diff between the expected loaded
profiles and the actual loaded profiles using your snippet, but if I try
again to start apparmor.service it still gets killed by the OOM killer
with similar output as above.
** Attachment added: "layouts-test-1"
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+attachment/5267420/+files/layouts-test-1
--
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/1830502
Title:
apparmor fails to start with no parser errors
Status in apparmor package in Ubuntu:
New
Bug description:
On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk,
my system was unable to finish booting and I had to go into recovery
mode and remove a number of files before the system would boot. After
doing so I discovered that now the apparmor.service systemd unit
always fails to start. I see this in dmesg:
[ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796
or sacrifice child
[ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB,
anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB
[ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Whenever apparmor.service is attempted to be started by systemd, i.e.
either on boot, or later with `systemctl start apparmor`.
The log from journalctl doesn't show any actual issues with any
profiles just this:
-- Reboot --
May 25 17:00:58 systemd[1]: Starting AppArmor initialization...
May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles
May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable:
usr.bin.firefox
May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable:
usr.sbin.rsyslogd
May 25 17:01:40 apparmor[1521]:...fail!
May 25 17:01:40 systemd[1]: apparmor.service: Main process exited,
code=exited, status=123/n/a
May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'.
May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization.
May 25 17:04:53 systemd[1]: Starting AppArmor initialization...
May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles
May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable:
usr.bin.firefox
May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable:
usr.sbin.rsyslogd
May 25 17:05:25 apparmor[4747]:...fail!
May 25 17:05:25 systemd[1]: apparmor.service: Main process exited,
code=exited, status=123/n/a
May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'.
May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization.
I can see that apparmor profiles are active after doing this (using
aa-status), but it's still troubling that apparmor runs into an issue
without actually saying what the error is.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1825378] Re: systemd-networkd doesn't set wireguard peer endpoint
** Patch added: "lp1825378-eoan.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825378/+attachment/5267419/+files/lp1825378-eoan.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/1825378 Title: systemd-networkd doesn't set wireguard peer endpoint Status in systemd package in Ubuntu: In Progress Status in systemd source package in Cosmic: Invalid Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: In Progress Bug description: [impact] systemd does not set endpoints for wireguard interfaces correctly. This makes wireguard unusable. [test case] install a disco or eoan system and set up a wireguard interface: $ sudo add-apt-repository ppa:wireguard/wireguard $ sudo apt install wireguard ...(this does a lot of stuff)... create a file as below; There is no need to setup remote server to reproduce this issue, but PublicKey/PrivateKey should be valid one (used instructions from https://www.linode.com/docs/networking/vpn /set-up-wireguard-vpn-on-ubuntu/#configure-wireguard-server): $ cat /etc/systemd/network/wg0.netdev [NetDev] Name=wg0 Kind=wireguard [WireGuard] PrivateKey=uMuCbguKYdKanRYMbDSriIdgxGxJR57Us1zEy8wRc1M= ListenPort=51820 [WireGuardPeer] PublicKey=ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= AllowedIPs=10.0.0.0/8 Endpoint=192.168.1.1:51820 $ sudo systemctl restart systemd-networkd $ sudo wg show wg0 interface: wg0 public key: BnvFgvPiVb5xURfzZ5liV1P77qeGeJDIX3C1iNquA2k= private key: (hidden) listening port: 51820 peer: ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= allowed ips: 10.0.0.0/8 the last command should print remote endpoint address, e.g.: peer: ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= endpoint: 192.168.1.1:51820 allowed ips: 10.0.0.0/8 [regression potential] any changes to systemd contain the potential for serious regressions. However, this is cherry picked directly from upstream, with the releases requiring patching (disco and eoan) being at exactly the same version and very close to upstream already. Additionally, while this does add 2 new functions (from upstream commit https://github.com/systemd/systemd/pull/11580/commits/abd48ec87f2ac5dd571a99dcb4db88c4affdffc8), they are only used - and code is only changed in - wireguard.c, so any regressions should be limited to wireguard interfaces (unless systemd crashes completely). [other info] this bug is not present in cosmic and earlier, and is already fixed in upstream systemd, so this is needed only for disco and eoan. original description: --- systemd/disco 240 shipped with Ubuntu 19.04 beta does not set endpoints for [WireguradPeer] properly. This regression was introduced in v241 and merged into v240. systemd 241 doesn't set wireguard peer endpoint https://github.com/systemd/systemd/issues/11579 Revert of the regression was landed on v240 stable branch https://github.com/systemd/systemd-stable/pull/39 1)2) confirmed with, systemd/disco 240-6ubuntu5 amd64 3) put a netdev file /etc/systemd/network/wg0.netdev --- [NetDev] Name=wg0 Kind=wireguard [WireGuard] PrivateKey=** ListenPort=51820 [WireGuardPeer] PublicKey=* AllowedIPs=10.0.0.0/8 Endpoint=192.168.1.1:51820 and run --- # systemctl restart systemd-networkd # wg show wg0 interface: wg0 public key: * private key: (hidden) listening port: 51820 peer: * allowed ips: 10.0.0.0/8 4) the last command should print remote endpoint address. --- # wg show wg0 interface: wg0 public key: * private key: (hidden) listening port: 51820 peer: * endpoint: 192.168.1.1:51820 allowed ips: 10.0.0.0/8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825378/+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 1823422] Re: heimdal ftbfs in disco
** Changed in: heimdal (Debian) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to heimdal in Ubuntu. https://bugs.launchpad.net/bugs/1823422 Title: heimdal ftbfs in disco Status in Heimdal: New Status in heimdal package in Ubuntu: Triaged Status in heimdal package in Debian: Fix Released Bug description: https://launchpadlibrarian.net/417925401/buildlog_ubuntu-disco- amd64.heimdal_7.5.0+dfsg-2.1_BUILDING.txt.gz = Heimdal 7.5.0: lib/hx509/test-suite.log = # TOTAL: 16 # PASS: 15 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test_chain cert -> root cert -> root cert -> root sub-cert -> root sub-cert -> sub-ca -> root sub-cert -> sub-ca sub-cert -> sub-ca -> root sub-cert -> sub-ca -> root sub-cert -> sub-ca -> root max depth 2 (ok) max depth 1 (fail) ocsp non-ca responder ocsp ca responder ocsp no-ca responder, missing cert ocsp no-ca responder, missing cert, in pool ocsp no-ca responder, keyHash ocsp revoked cert ocsp print reply resp1-ocsp-no-cert ocsp print reply resp1-ca ocsp print reply resp1-keyhash ocsp print reply resp2 ocsp verify exists ocsp verify not exists ocsp verify revoked crl non-revoked cert FAIL test_chain (exit status: 1) Testsuite summary for Heimdal 7.5.0 # TOTAL: 16 # PASS: 15 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See lib/hx509/test-suite.log Please report to https://github.com/heimdal/heimdal/issues To manage notifications about this bug go to: https://bugs.launchpad.net/heimdal/+bug/1823422/+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 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
** Also affects: bash (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: bash (Ubuntu Bionic) Importance: Undecided => High ** Changed in: bash (Ubuntu Bionic) Assignee: (unassigned) => Bryce Harrington (bryce) ** Also affects: bash (Ubuntu Cosmic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: New Status in bash source package in Bionic: New Status in bash source package in Cosmic: New Bug description: Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. Edit as per the SRU procedure: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. [Test Case] Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. [Regression Potential] Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Other Info] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+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 1830479] Re: testcases expect first kernel log line, but not always in logs
** Bug watch added: Debian Bug tracker #929730 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929730 ** Also affects: systemd (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929730 Importance: Unknown Status: Unknown -- 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/1830479 Title: testcases expect first kernel log line, but not always in logs Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Status in systemd source package in Cosmic: New Status in systemd source package in Disco: New Status in systemd source package in Eoan: New Status in systemd package in Debian: Unknown Bug description: [impact] boot-and-services and cmdline-upstart-boot expect the first(ish) kernel log line to be in the system logs, but that is not guaranteed to be in the logs. [test case] run autopkgtest on arm64 with the current kernel, whose kernel log size is too small for journald or rsyslogd to capture the first kernel log messages. [regression potential] low; testcase fix only. [other info] the specific cause of this currently is too-small kernel log buffer size on arm64, which is being fixed in bug 1824864, but increasing amounts of boot time logging may cause a failure again, or custom kernel configs with small log buffers. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830479/+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 1796900] Re: Inconsistency in the man page regarding created archive file
This has been fixed upstream and is part of the 1.32 version of tar, which is not yet in Ubuntu or Debian. https://git.savannah.gnu.org/cgit/tar.git/commit/?id=b0930da045d4dc9750097876f0a3f672dc99ad11 ** Changed in: tar (Ubuntu) Status: New => Triaged ** Changed in: tar (Ubuntu) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1796900 Title: Inconsistency in the man page regarding created archive file Status in tar package in Ubuntu: Triaged Bug description: This is just a minor mistake, but still worth correcting, I think. In the man page for tar_1.29b-2_amd64 and also tar_1.30+dfsg-2_amd64, the first command demonstrating the option styles is tar cfv a.tar /etc which creates the archive a.tar. In the text, however, it is said to create the file etc.tar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tar/+bug/1796900/+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 1830945] [NEW] DNS settings from interfaces file are ignored
Public bug reported: Since a recent reboot (00:00 CEST on tuesday to be precise), DNS settings from the interfaces file are no longer present in resolvconf. A file /run/resolvconf/interface/eth0.inet exists but is empty. This is happening on a xenial system. I have since rebooted once more, with the same result. These are the contents of /etc/network/interfaces: iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.200.52 netmask 255.255.255.0 gateway 192.168.200.5 dns-nameserver 192.168.200.5 dns-nameserver 8.8.8.8 # second address iface eth0 inet static address 192.168.200.67 netmask 255.255.255.0 I'm running dnsmasq as a local DNS server on this system, which expects to get the "upstream" dns servers from resolvconf and thus can no longer resolve external addresses. Until this recent reboot, this configuration has worked without issue for many months, I have the etckeeper log to prove it :-). Here are some relevant excerpts from the logs: systemd[1]: Starting Clean up any mess left by 0dns-up... systemd[1]: Reached target Remote File Systems. systemd[1]: Started Clean up any mess left by 0dns-up. systemd[1]: Starting Nameserver information manager... systemd[1]: Started Nameserver information manager. systemd[1]: Reached target Sockets. systemd[1]: Reached target Basic System. systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server... systemd[1]: Starting Restore /etc/resolv.conf if the system crashed before the ppp link was shut down... systemd[1]: Starting Raise network interfaces... systemd[1]: Started ifup for eth0. systemd[1]: Started Restore /etc/resolv.conf if the system crashed before the ppp link was shut down. ifup[624]: /sbin/ifup: waiting for lock on /run/network/ifstate.eth0 systemd[1]: Started Raise network interfaces. systemd[1]: Reached target Network. dnsmasq[583]: dnsmasq: syntax check OK. systemd[1]: Reached target Network is Online. ntpdate[840]: name server cannot be used: Temporary failure in name resolution (-3) dnsmasq[975]: started, version 2.75 cachesize 150 dnsmasq[975]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dnsmasq[975]: DNS service limited to local subnets dnsmasq-dhcp[975]: DHCP, IP range 192.168.200.100 -- 192.168.200.200, lease time 1h dnsmasq[975]: using local addresses only for domain myname.local dnsmasq[975]: no servers found in /var/run/dnsmasq/resolv.conf, will retry dnsmasq[975]: read /etc/hosts - 14 addresses ntpd[1060]: error resolving pool 0.ubuntu.pool.ntp.org: Temporary failure in name resolution (-3) systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. systemd[1]: Reached target Host and Network Name Lookups. ntpd[1060]: error resolving pool 1.ubuntu.pool.ntp.org: Temporary failure in name resolution (-3) ** Affects: resolvconf (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1830945 Title: DNS settings from interfaces file are ignored Status in resolvconf package in Ubuntu: New Bug description: Since a recent reboot (00:00 CEST on tuesday to be precise), DNS settings from the interfaces file are no longer present in resolvconf. A file /run/resolvconf/interface/eth0.inet exists but is empty. This is happening on a xenial system. I have since rebooted once more, with the same result. These are the contents of /etc/network/interfaces: iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.200.52 netmask 255.255.255.0 gateway 192.168.200.5 dns-nameserver 192.168.200.5 dns-nameserver 8.8.8.8 # second address iface eth0 inet static address 192.168.200.67 netmask 255.255.255.0 I'm running dnsmasq as a local DNS server on this system, which expects to get the "upstream" dns servers from resolvconf and thus can no longer resolve external addresses. Until this recent reboot, this configuration has worked without issue for many months, I have the etckeeper log to prove it :-). Here are some relevant excerpts from the logs: systemd[1]: Starting Clean up any mess left by 0dns-up... systemd[1]: Reached target Remote File Systems. systemd[1]: Started Clean up any mess left by 0dns-up. systemd[1]: Starting Nameserver information manager... systemd[1]: Started Nameserver information manager. systemd[1]: Reached target Sockets. systemd[1]: Reached target Basic System. systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server... systemd[1]: Starting Restore /etc/resolv.conf if the system crashed before the ppp link was shut down... systemd[1]: Starting Raise network interfaces... systemd[1]:
[Touch-packages] [Bug 1830502] Re: apparmor fails to start with no parser errors
Ah actually, if I move that profile out of the way, then `systemctl start apparmor` starts immediately. So the issue must be with that profile being too large (and indeed it is 4-5 MB). -- 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/1830502 Title: apparmor fails to start with no parser errors Status in apparmor package in Ubuntu: New Bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa-status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
** Description changed: - Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops - when spawning sub processes and waiting for them. There is a fix: + [Impact] - https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 + Long running bash loops that create and reap processes will crash, + hanging at 100% CPU. - Our application started being affected (locking up) by this since - migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), - Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', - because of their unusual versions as patches, apt shows it as - 4.4.18-2ubuntu1). - The 4.4-020 version needs to be included. I think it's actually quite - critical. + [Test Case] + + Run this loop for a few days/weeks: + + #!/bin/bash + while true; do + sleep 0.5 & + wait + done + + It will eventually cause the 'wait' statement to hang, consuming 100% + after some indeterminate amount of time, dependent on how fast PIDs are + cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. - Edit as per the SRU procedure: -[Impact] + [Regression Potential] - Long running bash loops that create and reap processes will crash, - hanging at 100% CPU. + The fix has been reviewed and accepted upstream. The patch adds a test + at time of pid determination for if the pid is already in use and if so, + skip it and pick a different one. This does change behavior slightly in + that different pid numbers will be generated in rare cases, but nothing + should depend on how pids are generated, as the behavior is not + specified to be anything but random. - A justification for including the fix would be that a standard language - feature in a script language is broken, and that it's indeterminate when - it breaks. Considering the wide spread use of bash, I'm surprised not - more people have reported issues. My and a client started having issues - with independently of each other very soon after upgrading to an - affected version. - -[Test Case] - - Run this loop for a few days/weeks: - - #!/bin/bash - while true; do - sleep 0.5 & - wait - done - - - It will cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. - -[Regression Potential] + The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == + storage[psi].bucket_next", but this only shows when the original bug + would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). -[Other Info] + + [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. + + + [Original Report] + Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: + + https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 + + Our application started being affected (locking up) by this since + migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), + Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', + because of their unusual versions as patches, apt shows it as + 4.4.18-2ubuntu1). + + The 4.4-020 version needs to be included. I think it's actually quite + critical. + + A justification for including the fix would be that a standard language + feature in a script language is broken, and that it's indeterminate when + it breaks. Considering the wide spread use of bash, I'm surprised not + more people have reported issues. My and a client started having issues + with independently of each other very soon after upgrading to an + affected version. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: New Status in bash source package in Bionic: New Status in bash source package in Cosmic: New Bug
[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
Hi halfgaar, Robie asked me to help you with this bug, thanks for reporting it. I may not be able to get full attention on this until next week due to a project deadline, but I've had a quick look at the patch and your problem description, and it looks pretty straightforward. Thanks also for the test case, I'll run it and see if I can repro the bug myself. It looks like both bionic and cosmic are running 4.4.18-x, so I'm gathering cosmic will need the fix as well. disco and eoan have moved to bash 5.0, and I've verified the upstream source code includes the fix, so no changes are needed for those distro releases. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: New Status in bash source package in Bionic: New Status in bash source package in Cosmic: New Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+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 1830479] Re: testcases expect first kernel log line, but not always in logs
It's a critical but in the Ubuntu platform if the very first kernel log line is not available in the system logs. And it is present on all arches, apart from the identified buggy arm64 which is in-flight being fixed (in eoan-proposed & disco-proposed with other releases to follow). cmdline-upstart-boot is only present in xenial? and arm64-kvm testing only started to be done post xenial release. Hence systemd/arm64 autopkgtest status is currently "Always Failed" and doesn't block anything. This is not applicable to devel series, nor should be applied in prior releases, instead kernel should be fixed. ** Changed in: systemd (Ubuntu Eoan) Status: New => Won't Fix ** Changed in: systemd (Ubuntu Disco) Status: New => Won't Fix ** Changed in: systemd (Ubuntu Xenial) Status: New => Won't Fix -- 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/1830479 Title: testcases expect first kernel log line, but not always in logs Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: Won't Fix Status in systemd source package in Bionic: New Status in systemd source package in Cosmic: New Status in systemd source package in Disco: Won't Fix Status in systemd source package in Eoan: Won't Fix Status in systemd package in Debian: Unknown Bug description: [impact] boot-and-services and cmdline-upstart-boot expect the first(ish) kernel log line to be in the system logs, but that is not guaranteed to be in the logs. [test case] run autopkgtest on arm64 with the current kernel, whose kernel log size is too small for journald or rsyslogd to capture the first kernel log messages. [regression potential] low; testcase fix only. [other info] the specific cause of this currently is too-small kernel log buffer size on arm64, which is being fixed in bug 1824864, but increasing amounts of boot time logging may cause a failure again, or custom kernel configs with small log buffers. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830479/+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 1754671] Re: Full-tunnel VPN DNS leakage regression
** Also affects: network-manager (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Cosmic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Cosmic) Importance: Undecided => High ** Changed in: systemd (Ubuntu Cosmic) Status: New => In Progress ** Changed in: systemd (Ubuntu Bionic) Status: Triaged => In Progress -- 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/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: In Progress Status in network-manager source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+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 1829450] Re: test_systemd_fsck_with_plymouth_failure passes but marked expected failure
"and so causes autopkgtest failures." is not true. >From http://autopkgtest.ubuntu.com/packages/systemd/bionic/amd64 E.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/systemd/20190529_090547_1f40a@/log.gz Ensure that a failing plymouth doesn't prevent fsckd to reconnect/exit ... unexpected success FAILED (unexpected successes=1) autopkgtest [09:05:38]: test systemd-fsckd: ---] systemd-fsckdPASS Note systemd-fsckd only fails on failures & errors, and passed with unexpected successes: if len(result.failures) != 0 or len(result.errors) != 0: return_code = 1 I also wonder what has changed to make this test case reliable, in the past it used to be flakey, that's why i switched it to expectedfailure. I guess it's ok to reenable this in devel. I see no need to reenable it in stable series. It has a regression potential, since it used to be flakey, it may start to be flakey again blocking SRU migrations. -- 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/1829450 Title: test_systemd_fsck_with_plymouth_failure passes but marked expected failure Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: In Progress Bug description: [impact] this test case was marked as expected failure in the past to try to ignore failures, but it now passes and so causes autopkgtest failures. [test case] run autopkgtest and check for the 'test_systemd_fsck_with_plymouth_failure' test, e.g.: test_systemd_fsck_with_plymouth_failure (__main__.FsckdTest) Ensure that a failing plymouth doesn't prevent fsckd to reconnect/exit ... bash: line 1: 786 Killed /tmp/autopkgtest.84SCbj/build.1op/src/debian/tests/systemd-fsckd 2> >(tee -a /tmp/autopkgtest.84SCbj/systemd-fsckd-stderr >&2) > >(tee -a /tmp/autopkgtest.84SCbj/systemd-fsckd-stdout) autopkgtest [16:47:57]: test process requested reboot with marker test_systemd_fsck_with_plymouth_failure:0 Connection to 10.44.40.6 closed by remote host. autopkgtest-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds... test_systemd_fsck_with_plymouth_failure (__main__.FsckdTest) Ensure that a failing plymouth doesn't prevent fsckd to reconnect/exit ... unexpected success -- Ran 1 test in 17.952s FAILED (unexpected successes=1) [regression potential] low; test case expectation fix only. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829450/+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 1830945] Re: DNS settings from interfaces file are ignored
I have now removed the second address stanza from the interfaces file, and the dns settings work again. I am no longer sure the machine was in fact rebooted with these settings in place, since my logs only reach back to the start of april (the interfaces file was last changed in august of last year). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1830945 Title: DNS settings from interfaces file are ignored Status in resolvconf package in Ubuntu: New Bug description: Since a recent reboot (00:00 CEST on tuesday to be precise), DNS settings from the interfaces file are no longer present in resolvconf. A file /run/resolvconf/interface/eth0.inet exists but is empty. This is happening on a xenial system. I have since rebooted once more, with the same result. These are the contents of /etc/network/interfaces: iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.200.52 netmask 255.255.255.0 gateway 192.168.200.5 dns-nameserver 192.168.200.5 dns-nameserver 8.8.8.8 # second address iface eth0 inet static address 192.168.200.67 netmask 255.255.255.0 I'm running dnsmasq as a local DNS server on this system, which expects to get the "upstream" dns servers from resolvconf and thus can no longer resolve external addresses. Until this recent reboot, this configuration has worked without issue for many months, I have the etckeeper log to prove it :-). Here are some relevant excerpts from the logs: systemd[1]: Starting Clean up any mess left by 0dns-up... systemd[1]: Reached target Remote File Systems. systemd[1]: Started Clean up any mess left by 0dns-up. systemd[1]: Starting Nameserver information manager... systemd[1]: Started Nameserver information manager. systemd[1]: Reached target Sockets. systemd[1]: Reached target Basic System. systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server... systemd[1]: Starting Restore /etc/resolv.conf if the system crashed before the ppp link was shut down... systemd[1]: Starting Raise network interfaces... systemd[1]: Started ifup for eth0. systemd[1]: Started Restore /etc/resolv.conf if the system crashed before the ppp link was shut down. ifup[624]: /sbin/ifup: waiting for lock on /run/network/ifstate.eth0 systemd[1]: Started Raise network interfaces. systemd[1]: Reached target Network. dnsmasq[583]: dnsmasq: syntax check OK. systemd[1]: Reached target Network is Online. ntpdate[840]: name server cannot be used: Temporary failure in name resolution (-3) dnsmasq[975]: started, version 2.75 cachesize 150 dnsmasq[975]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dnsmasq[975]: DNS service limited to local subnets dnsmasq-dhcp[975]: DHCP, IP range 192.168.200.100 -- 192.168.200.200, lease time 1h dnsmasq[975]: using local addresses only for domain myname.local dnsmasq[975]: no servers found in /var/run/dnsmasq/resolv.conf, will retry dnsmasq[975]: read /etc/hosts - 14 addresses ntpd[1060]: error resolving pool 0.ubuntu.pool.ntp.org: Temporary failure in name resolution (-3) systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. systemd[1]: Reached target Host and Network Name Lookups. ntpd[1060]: error resolving pool 1.ubuntu.pool.ntp.org: Temporary failure in name resolution (-3) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1830945/+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 1830955] [NEW] Systemd removes OpenVPN IP addresses
You have been subscribed to a public bug:
This is probably related to, but not a duplicate of, bug 1815101.
Running
root@third:/home/leroy# lsb_release -rd
Description:Ubuntu 18.04.2 LTS
Release:18.04
Systemd version:
root@third:/home/leroy# apt-cache policy systemd
systemd:
Installed: 237-3ubuntu10.21
Candidate: 237-3ubuntu10.21
Version table:
*** 237-3ubuntu10.21 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64
Packages
100 /var/lib/dpkg/status
237-3ubuntu10.19 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64
Packages
237-3ubuntu10 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
I expected the OpenVPN IP addresses to remain, instead they were
removed, the physical NIC address remained, process:
Start OpenVPN with systemctl start openvpn@ (in this
situation, two instances). Result:
root@third:/etc/openvpn# ip addr sh tun0
7: tun0: mtu 1500 qdisc fq_codel
state UNKNOWN group default qlen 100
link/none
inet 10.57.3.1 peer 10.57.3.2/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::f0ea:151b:cb91:5d1b/64 scope link stable-privacy
valid_lft forever preferred_lft forever
root@third:/etc/openvpn# ip addr sh tun1
8: tun1: mtu 1500 qdisc fq_codel
state UNKNOWN group default qlen 100
link/none
inet 10.222.108.234 peer 10.222.108.233/32 scope global tun1
valid_lft forever preferred_lft forever
inet6 fe80::3103:7936:cf19:6237/64 scope link stable-privacy
valid_lft forever preferred_lft forever
Test a configuration (which, incidentally, isn't valid for this system)
with 'netplan try ..' and allow it to revert (which should have restored
the previous configuration), see below:
root@third:/etc/openvpn# cd ~leroy/Downloads
root@third:/home/leroy/Downloads# ll *.yaml
-rw-rw-r-- 1 leroy leroy 555 May 29 10:46 startup.yaml
root@third:/home/leroy/Downloads# netplan --debug try --config-file
~leroy/Downloads/startup.yaml --timeout 15
DEBUG:eno1 not found in {}
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets:
eno1:
addresses:
- 10.15.0.37/24
dhcp4: false
gateway4: 10.15.0.1
nameservers:
addresses:
- 10.15.0.8
- 10.3.77.11
- 10.45.77.11
- 8.8.8.8
vlans: {}
wifis: {}
DEBUG:New interfaces: {'eno1'}
** (generate:8216): DEBUG: 11:19:39.770: Processing input file
/etc/netplan/01-network-manager-all.yaml..
** (generate:8216): DEBUG: 11:19:39.771: starting new processing pass
** (generate:8216): DEBUG: 11:19:39.771: Processing input file
/etc/netplan/startup.1559146779.768221.yaml..
** (generate:8216): DEBUG: 11:19:39.771: starting new processing pass
** (generate:8216): DEBUG: 11:19:39.771: eno1: setting default backend to 2
** (generate:8216): DEBUG: 11:19:39.771: Generating output files..
** (generate:8216): DEBUG: 11:19:39.771: networkd: definition eno1 is not for
us (backend 2)
DEBUG:no netplan generated networkd configuration exists
DEBUG:netplan generated NM configuration exists, restarting NM
DEBUG:eno1 not found in {}
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets:
eno1:
addresses:
- 10.15.0.37/24
dhcp4: false
gateway4: 10.15.0.1
nameservers:
addresses:
- 10.15.0.8
- 10.3.77.11
- 10.45.77.11
- 8.8.8.8
vlans: {}
wifis: {}
DEBUG:Skipping non-physical interface: lo
DEBUG:Skipping non-physical interface: enp2s0
DEBUG:Skipping non-physical interface: virbr0
DEBUG:Skipping non-physical interface: virbr0-nic
DEBUG:Skipping non-physical interface: tun0
DEBUG:Skipping non-physical interface: tun1
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for enp2s0
DEBUG:netplan triggering .link rules for virbr0
DEBUG:netplan triggering .link rules for virbr0-nic
DEBUG:netplan triggering .link rules for tun0
DEBUG:netplan triggering .link rules for tun1
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 1 seconds
Reverting.
DEBUG:no netplan generated networkd configuration exists
DEBUG:netplan generated NM configuration exists, restarting NM
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets: {}
vlans: {}
wifis: {}
DEBUG:Skipping non-physical interface: lo
DEBUG:Skipping non-physical interface: enp2s0
DEBUG:Skipping non-physical interface: virbr0
DEBUG:Skipping non-physical interface: virbr0-nic
DEBUG:Skipping non-physical interface: tun0
DEBUG:Skipping non-physical interface: tun1
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for enp2s0
DEBUG:netplan triggering .link rules for virbr0
DEBUG:netplan triggering .link rules for virbr0-nic
DEBUG:netplan triggering .link rules for tun0
DEBUG:netplan triggering .link rules for tun1
DEBUG:eno1 will not be
[Touch-packages] [Bug 1830955] Re: Systemd removes OpenVPN IP addresses
** Package changed: 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/1830955
Title:
Systemd removes OpenVPN IP addresses
Status in systemd package in Ubuntu:
New
Bug description:
This is probably related to, but not a duplicate of, bug 1815101.
Running
root@third:/home/leroy# lsb_release -rd
Description:Ubuntu 18.04.2 LTS
Release:18.04
Systemd version:
root@third:/home/leroy# apt-cache policy systemd
systemd:
Installed: 237-3ubuntu10.21
Candidate: 237-3ubuntu10.21
Version table:
*** 237-3ubuntu10.21 500
500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64
Packages
100 /var/lib/dpkg/status
237-3ubuntu10.19 500
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64
Packages
237-3ubuntu10 500
500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
I expected the OpenVPN IP addresses to remain, instead they were
removed, the physical NIC address remained, process:
Start OpenVPN with systemctl start openvpn@ (in this
situation, two instances). Result:
root@third:/etc/openvpn# ip addr sh tun0
7: tun0: mtu 1500 qdisc fq_codel
state UNKNOWN group default qlen 100
link/none
inet 10.57.3.1 peer 10.57.3.2/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::f0ea:151b:cb91:5d1b/64 scope link stable-privacy
valid_lft forever preferred_lft forever
root@third:/etc/openvpn# ip addr sh tun1
8: tun1: mtu 1500 qdisc fq_codel
state UNKNOWN group default qlen 100
link/none
inet 10.222.108.234 peer 10.222.108.233/32 scope global tun1
valid_lft forever preferred_lft forever
inet6 fe80::3103:7936:cf19:6237/64 scope link stable-privacy
valid_lft forever preferred_lft forever
Test a configuration (which, incidentally, isn't valid for this
system) with 'netplan try ..' and allow it to revert (which should
have restored the previous configuration), see below:
root@third:/etc/openvpn# cd ~leroy/Downloads
root@third:/home/leroy/Downloads# ll *.yaml
-rw-rw-r-- 1 leroy leroy 555 May 29 10:46 startup.yaml
root@third:/home/leroy/Downloads# netplan --debug try --config-file
~leroy/Downloads/startup.yaml --timeout 15
DEBUG:eno1 not found in {}
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets:
eno1:
addresses:
- 10.15.0.37/24
dhcp4: false
gateway4: 10.15.0.1
nameservers:
addresses:
- 10.15.0.8
- 10.3.77.11
- 10.45.77.11
- 8.8.8.8
vlans: {}
wifis: {}
DEBUG:New interfaces: {'eno1'}
** (generate:8216): DEBUG: 11:19:39.770: Processing input file
/etc/netplan/01-network-manager-all.yaml..
** (generate:8216): DEBUG: 11:19:39.771: starting new processing pass
** (generate:8216): DEBUG: 11:19:39.771: Processing input file
/etc/netplan/startup.1559146779.768221.yaml..
** (generate:8216): DEBUG: 11:19:39.771: starting new processing pass
** (generate:8216): DEBUG: 11:19:39.771: eno1: setting default backend to 2
** (generate:8216): DEBUG: 11:19:39.771: Generating output files..
** (generate:8216): DEBUG: 11:19:39.771: networkd: definition eno1 is not for
us (backend 2)
DEBUG:no netplan generated networkd configuration exists
DEBUG:netplan generated NM configuration exists, restarting NM
DEBUG:eno1 not found in {}
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets:
eno1:
addresses:
- 10.15.0.37/24
dhcp4: false
gateway4: 10.15.0.1
nameservers:
addresses:
- 10.15.0.8
- 10.3.77.11
- 10.45.77.11
- 8.8.8.8
vlans: {}
wifis: {}
DEBUG:Skipping non-physical interface: lo
DEBUG:Skipping non-physical interface: enp2s0
DEBUG:Skipping non-physical interface: virbr0
DEBUG:Skipping non-physical interface: virbr0-nic
DEBUG:Skipping non-physical interface: tun0
DEBUG:Skipping non-physical interface: tun1
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for enp2s0
DEBUG:netplan triggering .link rules for virbr0
DEBUG:netplan triggering .link rules for virbr0-nic
DEBUG:netplan triggering .link rules for tun0
DEBUG:netplan triggering .link rules for tun1
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 1 seconds
Reverting.
DEBUG:no netplan generated networkd configuration exists
DEBUG:netplan generated NM configuration exists, restarting NM
DEBUG:Merged config:
network:
bonds: {}
bridges: {}
ethernets: {}
vlans: {}
wifis: {}
DEBUG:Skipping non-physical interface: lo
DEBUG:Skip
[Touch-packages] [Bug 1829347] Re: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
Failing to remove the module, means the testcase / systemd has failed.
Which has been diagnosed and narrowed down to a bug in systemd.
Whilst the proposed improvements to the test case are ok, they make it
skip a lot more without making it more fool proof.
Ideally, I'd like to make the testcase more resilient and enforce more.
Thus failing to remove the module should still be a hard failure.
And upon starting the test case we do need to re-insert the module, as
otherwise LUKS2 header creation would fail (that affects disco+ only).
I do like the add_host usage, but I wonder if it's best be used with
udevadm settle calls, rather than manual tight loops.
--
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/1829347
Title:
systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Cosmic:
In Progress
Status in systemd source package in Disco:
In Progress
Status in systemd source package in Eoan:
In Progress
Status in systemd package in Debian:
Unknown
Bug description:
[impact]
systemd autopkgtest fails
[test case]
run systemd autopkgtest, check for output like:
LUKS device with "tmp" option ... rmmod: ERROR: Module scsi_debug is in use
FAIL
==
FAIL: test_luks_tmp (__main__.CryptsetupTest)
LUKS device with "tmp" option
--
Traceback (most recent call last):
File "/tmp/autopkgtest.It858Q/build.e7O/src/debian/tests/storage", line 59,
in setUp
self.fail('%s exists already' % self.plaintext_dev)
AssertionError: /dev/mapper/testcrypt1 exists already
or for older releases something like:
autopkgtest [19:27:26]: test storage: [---
modprobe: FATAL: Module scsi_debug not found in directory
/lib/modules/4.18.0-1011-kvm
ERROR
==
ERROR: setUpClass (__main__.CryptsetupTest)
--
Traceback (most recent call last):
File "/tmp/autopkgtest.azsL0q/build.Hbd/src/debian/tests/storage", line 21,
in setUpClass
subprocess.check_call(['modprobe', 'scsi_debug'])
File "/usr/lib/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['modprobe', 'scsi_debug']' returned
non-zero exit status 1.
this has attempted to be fixed in disco/eoan so the output is a bit different
across different releases, but all of them have the common point of failing to
modprobe or rmmod the scsi_debug module, which by itself doesn't indicate a
failure.
[regression potential]
low; this is fixing a testcase only.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829347/+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 1829347] Re: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
The addition of the cryptsetup.target apply in the fstab test case is also
wrong.
We are trying to test that automatic apply of local-fs.target correctly
triggers the cryptsetup mounting as a dependency, without any special
cryptsetup.target poking first.
--
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/1829347
Title:
systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Cosmic:
In Progress
Status in systemd source package in Disco:
In Progress
Status in systemd source package in Eoan:
In Progress
Status in systemd package in Debian:
Unknown
Bug description:
[impact]
systemd autopkgtest fails
[test case]
run systemd autopkgtest, check for output like:
LUKS device with "tmp" option ... rmmod: ERROR: Module scsi_debug is in use
FAIL
==
FAIL: test_luks_tmp (__main__.CryptsetupTest)
LUKS device with "tmp" option
--
Traceback (most recent call last):
File "/tmp/autopkgtest.It858Q/build.e7O/src/debian/tests/storage", line 59,
in setUp
self.fail('%s exists already' % self.plaintext_dev)
AssertionError: /dev/mapper/testcrypt1 exists already
or for older releases something like:
autopkgtest [19:27:26]: test storage: [---
modprobe: FATAL: Module scsi_debug not found in directory
/lib/modules/4.18.0-1011-kvm
ERROR
==
ERROR: setUpClass (__main__.CryptsetupTest)
--
Traceback (most recent call last):
File "/tmp/autopkgtest.azsL0q/build.Hbd/src/debian/tests/storage", line 21,
in setUpClass
subprocess.check_call(['modprobe', 'scsi_debug'])
File "/usr/lib/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['modprobe', 'scsi_debug']' returned
non-zero exit status 1.
this has attempted to be fixed in disco/eoan so the output is a bit different
across different releases, but all of them have the common point of failing to
modprobe or rmmod the scsi_debug module, which by itself doesn't indicate a
failure.
[regression potential]
low; this is fixing a testcase only.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829347/+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 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
Thanks; it's not about getting it done yesterday so to speak, so I'll patiently await next week. I suspect you'll be able to reproduce it faster if you lower sysctl kernel.pid_max. With 32k PIDs, one of my apps spawning about a process every two seconds, needed about a week of running to hit it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: New Status in bash source package in Bionic: New Status in bash source package in Cosmic: New Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+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 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
Note that the regression which is introduced is cross-package; a latent bug in libwww-perl is exposed by the update of libio-socket-ssl-perl. This means libio-socket-ssl-perl needs a reupload to declare a breaks: on the older versions of libwww-perl, so that users don't install the libio-socket-ssl-perl update without also updating libwww-perl. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in libwww-perl package in Ubuntu: Incomplete Status in openssl package in Ubuntu: Fix Released Status in python-tornado package in Ubuntu: In Progress Status in libio-socket-ssl-perl source package in Bionic: Incomplete Status in libnet-ssleay-perl source package in Bionic: Incomplete Status in openssl source package in Bionic: Fix Committed Status in python-cryptography source package in Bionic: Fix Committed Status in python2.7 source package in Bionic: Fix Committed Status in python3.6 source package in Bionic: Fix Committed Status in python3.7 source package in Bionic: Fix Committed Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: Fix Committed Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Test cases for the python updates] python3.7 is a preview in bionic as a non-supported/non-default version of python3. Passing it's own autopkgtests is sufficient validation for python3.7. It includes a point release update, with OpenSSL 1.1.1 compat and features. python3.6 not only has OpenSSL 1.1.1 compat and features patches, but also includes a point release update to 3.6.8. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python3.6 and python3-defaults with regressions already fixed in the individual packages as appropriate. python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1 compat only. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python2.7 and python-defaults with regressions already fixed in the individual packages as appropriate. The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1 and python point releases as seen in: http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html And analyzed in https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652 [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. - non-application data records. TLSv1.3 sends more of these, when compared with previous versions, and some applications may not handle this correctly. Resulting in application data not being available, when previously expected. Mitigation around these involve disabling/enabling SSL_MODE_AUTO_RETRY or setting max protocol version to TLSv1.2. For example see discussion identified in the perl stack https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034 Similar hangs are possible with
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
And there needs to be an explicit test case for libwww-perl given the specific regression potential known here ** Changed in: libwww-perl (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in libwww-perl package in Ubuntu: Incomplete Status in openssl package in Ubuntu: Fix Released Status in python-tornado package in Ubuntu: In Progress Status in libio-socket-ssl-perl source package in Bionic: Incomplete Status in libnet-ssleay-perl source package in Bionic: Incomplete Status in openssl source package in Bionic: Fix Committed Status in python-cryptography source package in Bionic: Fix Committed Status in python2.7 source package in Bionic: Fix Committed Status in python3.6 source package in Bionic: Fix Committed Status in python3.7 source package in Bionic: Fix Committed Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: Fix Committed Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Test cases for the python updates] python3.7 is a preview in bionic as a non-supported/non-default version of python3. Passing it's own autopkgtests is sufficient validation for python3.7. It includes a point release update, with OpenSSL 1.1.1 compat and features. python3.6 not only has OpenSSL 1.1.1 compat and features patches, but also includes a point release update to 3.6.8. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python3.6 and python3-defaults with regressions already fixed in the individual packages as appropriate. python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1 compat only. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python2.7 and python-defaults with regressions already fixed in the individual packages as appropriate. The archive rebuilds done, were commulative with OpenJDK 11, OpenSSL 1.1.1 and python point releases as seen in: http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html And analyzed in https://docs.google.com/spreadsheets/d/1tMIwlwoHH_1h5sbvUbNac6-HIPKi3e0Xr8ebchIOU1A/edit#gid=147857652 [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. - non-application data records. TLSv1.3 sends more of these, when compared with previous versions, and some applications may not handle this correctly. Resulting in application data not being available, when previously expected. Mitigation around these involve disabling/enabling SSL_MODE_AUTO_RETRY or setting max protocol version to TLSv1.2. For example see discussion identified in the perl stack https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034 Similar hangs are possible with prior versions of TLS as well, it is however easier to trigger this with TLSv1.3. * Deprecated npn extenstion does not exist in TLSv1.3 implementation. * Thi
[Touch-packages] [Bug 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)
** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Eoan) Importance: Undecided Status: New -- 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/1830746 Title: memlock setting in systemd (pid 1) too low for containers (bionic) Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Status in systemd source package in Cosmic: New Status in systemd source package in Disco: New Status in systemd source package in Eoan: New Bug description: See also https://discuss.linuxcontainers.org/t/limits-kernel-memlock- cannot-exceed-16777216/4856/5 In containers, the limits.kernel.memlock cannot exceed 16777216 when the container is bionic. The memlock setting is set to 16M in systemd and cannot be bumped up in an unprivileged container. This is fixed in upstream systemd. Container ubuntu version: Distributor ID: Ubuntu Description: Ubuntu 18.04.2 LTS Release: 18.04 Codename: bionic systemd package version: 237-3ubuntu10.21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+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 1825378] Re: systemd-networkd doesn't set wireguard peer endpoint
** Changed in: systemd (Ubuntu Eoan) Status: In Progress => Fix Committed -- 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/1825378 Title: systemd-networkd doesn't set wireguard peer endpoint Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Cosmic: Invalid Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: Fix Committed Bug description: [impact] systemd does not set endpoints for wireguard interfaces correctly. This makes wireguard unusable. [test case] install a disco or eoan system and set up a wireguard interface: $ sudo add-apt-repository ppa:wireguard/wireguard $ sudo apt install wireguard ...(this does a lot of stuff)... create a file as below; There is no need to setup remote server to reproduce this issue, but PublicKey/PrivateKey should be valid one (used instructions from https://www.linode.com/docs/networking/vpn /set-up-wireguard-vpn-on-ubuntu/#configure-wireguard-server): $ cat /etc/systemd/network/wg0.netdev [NetDev] Name=wg0 Kind=wireguard [WireGuard] PrivateKey=uMuCbguKYdKanRYMbDSriIdgxGxJR57Us1zEy8wRc1M= ListenPort=51820 [WireGuardPeer] PublicKey=ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= AllowedIPs=10.0.0.0/8 Endpoint=192.168.1.1:51820 $ sudo systemctl restart systemd-networkd $ sudo wg show wg0 interface: wg0 public key: BnvFgvPiVb5xURfzZ5liV1P77qeGeJDIX3C1iNquA2k= private key: (hidden) listening port: 51820 peer: ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= allowed ips: 10.0.0.0/8 the last command should print remote endpoint address, e.g.: peer: ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= endpoint: 192.168.1.1:51820 allowed ips: 10.0.0.0/8 [regression potential] any changes to systemd contain the potential for serious regressions. However, this is cherry picked directly from upstream, with the releases requiring patching (disco and eoan) being at exactly the same version and very close to upstream already. Additionally, while this does add 2 new functions (from upstream commit https://github.com/systemd/systemd/pull/11580/commits/abd48ec87f2ac5dd571a99dcb4db88c4affdffc8), they are only used - and code is only changed in - wireguard.c, so any regressions should be limited to wireguard interfaces (unless systemd crashes completely). [other info] this bug is not present in cosmic and earlier, and is already fixed in upstream systemd, so this is needed only for disco and eoan. original description: --- systemd/disco 240 shipped with Ubuntu 19.04 beta does not set endpoints for [WireguradPeer] properly. This regression was introduced in v241 and merged into v240. systemd 241 doesn't set wireguard peer endpoint https://github.com/systemd/systemd/issues/11579 Revert of the regression was landed on v240 stable branch https://github.com/systemd/systemd-stable/pull/39 1)2) confirmed with, systemd/disco 240-6ubuntu5 amd64 3) put a netdev file /etc/systemd/network/wg0.netdev --- [NetDev] Name=wg0 Kind=wireguard [WireGuard] PrivateKey=** ListenPort=51820 [WireGuardPeer] PublicKey=* AllowedIPs=10.0.0.0/8 Endpoint=192.168.1.1:51820 and run --- # systemctl restart systemd-networkd # wg show wg0 interface: wg0 public key: * private key: (hidden) listening port: 51820 peer: * allowed ips: 10.0.0.0/8 4) the last command should print remote endpoint address. --- # wg show wg0 interface: wg0 public key: * private key: (hidden) listening port: 51820 peer: * endpoint: 192.168.1.1:51820 allowed ips: 10.0.0.0/8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825378/+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 1829347] Re: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
> Failing to remove the module, means the testcase / systemd has failed.
well, not if the module is built-in
> Whilst the proposed improvements to the test case are ok, they make it
skip a lot more
isn't the entire test currently skipped if the module is already loaded?
;)
but i get your point, it skips the test if 1) scsi_debug isn't
available, 2) scsi_debug add_host interface doesn't work right, 3)
scsi_debug adapter* subdir count is != 1 (instead of previously, failing
the test)
I don't think any of those should cause a test failure, but if you think
they should they can change from skiptest to assert.
> And upon starting the test case we do need to re-insert the module,
> as otherwise LUKS2 header creation would fail (that affects disco+ only).
why will it fail without module re-insertion? It doesn't in my test
runs.
> I do like the add_host usage, but I wonder if it's best be used with udevadm
> settle calls, rather than manual tight loops.
I don't think the add_host loops are needed at all; I only added them
because there's existing (infinite) loop waiting for the glob to match.
--
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/1829347
Title:
systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Cosmic:
In Progress
Status in systemd source package in Disco:
In Progress
Status in systemd source package in Eoan:
Won't Fix
Status in systemd package in Debian:
Unknown
Bug description:
[impact]
systemd autopkgtest fails
[test case]
run systemd autopkgtest, check for output like:
LUKS device with "tmp" option ... rmmod: ERROR: Module scsi_debug is in use
FAIL
==
FAIL: test_luks_tmp (__main__.CryptsetupTest)
LUKS device with "tmp" option
--
Traceback (most recent call last):
File "/tmp/autopkgtest.It858Q/build.e7O/src/debian/tests/storage", line 59,
in setUp
self.fail('%s exists already' % self.plaintext_dev)
AssertionError: /dev/mapper/testcrypt1 exists already
or for older releases something like:
autopkgtest [19:27:26]: test storage: [---
modprobe: FATAL: Module scsi_debug not found in directory
/lib/modules/4.18.0-1011-kvm
ERROR
==
ERROR: setUpClass (__main__.CryptsetupTest)
--
Traceback (most recent call last):
File "/tmp/autopkgtest.azsL0q/build.Hbd/src/debian/tests/storage", line 21,
in setUpClass
subprocess.check_call(['modprobe', 'scsi_debug'])
File "/usr/lib/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['modprobe', 'scsi_debug']' returned
non-zero exit status 1.
this has attempted to be fixed in disco/eoan so the output is a bit different
across different releases, but all of them have the common point of failing to
modprobe or rmmod the scsi_debug module, which by itself doesn't indicate a
failure.
[regression potential]
low; this is fixing a testcase only.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829347/+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 1825997] Re: boot-smoke fails due to running jobs
** Changed in: systemd (Ubuntu Eoan) Status: In Progress => Fix Committed -- 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/1825997 Title: boot-smoke fails due to running jobs Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: Fix Committed Bug description: [impact] boot-smoke test reboots 5 times and verifies systemd is fully started up after each boot, including checking if there are any running jobs (with list-jobs). However, this test makes the assumption that no further jobs will be started after systemd reaches 'running' (or 'degraded') state, which is a false assumption. [test case] see various boot-smoke failures in autopkgtest.ubuntu.com [regression potential] possible false-positive or false-negative autopkgtest results. [other info] Note: This patch is not required for debian, because debian's boot- smoke does not include the wait for systemctl is-system-running. The problem appears to be that systemd reaches 'running' (or 'degraded') state, and then other systemd services are started. This confuses the boot-smoke test, because it sees that 'is-system-running' is done, but then it sees running jobs, which fails the test. What is starting jobs after systemd reaches running state appears to be X inside the test system. There are various services started by gnome-session and dbus-daemon. Additionally, from the artifacts of one example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- bionic/bionic/i386/s/systemd/20190416_171327_478f6@/artifacts.tar.gz the artifacts/journal.txt shows that after the boot-smoke test causes the reboot and then re-ssh into the system after the reboot, it only gives the test system 9 seconds before deciding it has failed, and only 4 seconds after ssh'ing into the rebooted test system. Another wait is needed when checking for remaining running jobs. Or, the running jobs check could be removed entirely, and we can just trust that systemd correctly knows when it has reached running|degraded state. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825997/+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 1829829] Re: Ubuntu CI has been flaky for a week
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
** Changed in: systemd (Ubuntu)
Importance: Undecided => High
--
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/1829829
Title:
Ubuntu CI has been flaky for a week
Status in systemd package in Ubuntu:
Confirmed
Bug description:
It was originally reported in
https://github.com/systemd/systemd/pull/12583#issuecomment-492949206 5 days
ago. To judge from the logs VMs can't be rebooted there:
```
Ubuntu 18.04.2 LTS autopkgtest ttyS0
autopkgtest login:
---
--- nova show 91e76a78-d05c-412a-b383-55a26010ae69
(adt-bionic-amd64-systemd-upstream-20190516-051604) --
+--++
| Property | Value
|
+--++
| OS-DCF:diskConfig| MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-SRV-ATTR:host | euler
|
| OS-EXT-SRV-ATTR:hypervisor_hostname | euler.lcy01.scalingstack
|
| OS-EXT-SRV-ATTR:instance_name| instance-003d216a
|
| OS-EXT-STS:power_state | 1
|
| OS-EXT-STS:task_state| -
|
| OS-EXT-STS:vm_state | active
|
| OS-SRV-USG:launched_at | 2019-05-16T07:00:42.00
|
| OS-SRV-USG:terminated_at | -
|
| accessIPv4 |
|
| accessIPv6 |
|
| config_drive |
|
| created | 2019-05-16T07:00:33Z
|
| flavor | autopkgtest
(f878e70e-9991-46e0-ba02-8ea159a71656) |
| hostId |
1722c5f2face86c3fc9f338ae96835924721512372342f664e6941bd
|
| id | 91e76a78-d05c-412a-b383-55a26010ae69
|
| image|
adt/ubuntu-bionic-amd64-server-20190516.img
(d00bf12c-467e-433f-a4f5-15720f13bff1) |
| key_name |
testbed-juju-prod-ues-proposed-migration-machine-11
|
| metadata | {}
|
| name |
adt-bionic-amd64-systemd-upstream-20190516-051604
|
| net_ues_proposed_migration network | 10.42.40.13
|
| os-extended-volumes:volumes_attached | []
|
| progress | 0
|
| security_groups | autopkgtest@lcy01-27.secgroup
|
| status | ACTIVE
|
| tenant_id| afaef86b96dd4828a1ed5ee395ea1421
|
| updated | 2019-05-16T07:00:42Z
|
| user_id | 8524250971084851b3792a68fbc398dd
|
+--
[Touch-packages] [Bug 1788048] Re: systemd journald failed unmounting var
Does installing finalrd package help? It should pivot off root on shutdown, and unmount separate /var and /var/log cleanly. -- 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/1788048 Title: systemd journald failed unmounting var Status in systemd: Fix Released Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Status in systemd source package in Cosmic: New Status in systemd source package in Disco: New Status in systemd source package in Eoan: New Bug description: [impact] on a system with /var and/or /var/log mounted separately from /, shutdown can't unmount /var (or /var/log) cleanly because systemd- journald is using it. [test case] install a system with /var mounted separately from / shutdown, and notice: [FAILED] Failed unmounting /var. [regression potential] TBD [other info] original description: -- When the system is shut down or restarted the systemd-journal does not disassemble the disks correctly. On this thread https://unix.stackexchange.com/questions/378678/why- do-i-get-the-error-failed-unmounting-var-during-shutdown I checked what editing /etc/systemd/journald.conf to change the Storage = line to Storage = volatile the problem is solved, but some of the logs on the shutdown are lost. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.3 ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18 Uname: Linux 4.15.0-32-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 Date: Mon Aug 20 18:15:07 2018 ExecutablePath: /lib/systemd/systemd-journald InstallationDate: Installed on 2018-08-20 (0 days ago) InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) Lsusb: Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: innotek GmbH VirtualBox ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-32-generic root=UUID=65cb761b-4881-4031-9113-e6bb6a1437b4 ro SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/01/2006 dmi.bios.vendor: innotek GmbH dmi.bios.version: VirtualBox dmi.board.name: VirtualBox dmi.board.vendor: Oracle Corporation dmi.board.version: 1.2 dmi.chassis.type: 1 dmi.chassis.vendor: Oracle Corporation dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr: dmi.product.family: Virtual Machine dmi.product.name: VirtualBox dmi.product.version: 1.2 dmi.sys.vendor: innotek GmbH mtime.conffile..etc.systemd.journald.conf: 2018-08-20T18:00:58.586165 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1788048/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Changed in: systemd (Ubuntu Eoan) Status: In Progress => Fix Committed -- 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Committed Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: In Progress Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Status in udisks2 source package in Cosmic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: In Progress Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Fix Committed Status in udisks2 source package in Eoan: Invalid Status in systemd package in Debian: Unknown Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1829347] Re: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
** Changed in: systemd (Ubuntu Eoan)
Status: In Progress => Won't Fix
--
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/1829347
Title:
systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Cosmic:
In Progress
Status in systemd source package in Disco:
In Progress
Status in systemd source package in Eoan:
Won't Fix
Status in systemd package in Debian:
Unknown
Bug description:
[impact]
systemd autopkgtest fails
[test case]
run systemd autopkgtest, check for output like:
LUKS device with "tmp" option ... rmmod: ERROR: Module scsi_debug is in use
FAIL
==
FAIL: test_luks_tmp (__main__.CryptsetupTest)
LUKS device with "tmp" option
--
Traceback (most recent call last):
File "/tmp/autopkgtest.It858Q/build.e7O/src/debian/tests/storage", line 59,
in setUp
self.fail('%s exists already' % self.plaintext_dev)
AssertionError: /dev/mapper/testcrypt1 exists already
or for older releases something like:
autopkgtest [19:27:26]: test storage: [---
modprobe: FATAL: Module scsi_debug not found in directory
/lib/modules/4.18.0-1011-kvm
ERROR
==
ERROR: setUpClass (__main__.CryptsetupTest)
--
Traceback (most recent call last):
File "/tmp/autopkgtest.azsL0q/build.Hbd/src/debian/tests/storage", line 21,
in setUpClass
subprocess.check_call(['modprobe', 'scsi_debug'])
File "/usr/lib/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['modprobe', 'scsi_debug']' returned
non-zero exit status 1.
this has attempted to be fixed in disco/eoan so the output is a bit different
across different releases, but all of them have the common point of failing to
modprobe or rmmod the scsi_debug module, which by itself doesn't indicate a
failure.
[regression potential]
low; this is fixing a testcase only.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829347/+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 1829450] Re: test_systemd_fsck_with_plymouth_failure passes but marked expected failure
** Changed in: systemd (Ubuntu Eoan) Status: In Progress => Fix Committed -- 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/1829450 Title: test_systemd_fsck_with_plymouth_failure passes but marked expected failure Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: Fix Committed Bug description: [impact] this test case was marked as expected failure in the past to try to ignore failures, but it now passes and so causes autopkgtest failures. [test case] run autopkgtest and check for the 'test_systemd_fsck_with_plymouth_failure' test, e.g.: test_systemd_fsck_with_plymouth_failure (__main__.FsckdTest) Ensure that a failing plymouth doesn't prevent fsckd to reconnect/exit ... bash: line 1: 786 Killed /tmp/autopkgtest.84SCbj/build.1op/src/debian/tests/systemd-fsckd 2> >(tee -a /tmp/autopkgtest.84SCbj/systemd-fsckd-stderr >&2) > >(tee -a /tmp/autopkgtest.84SCbj/systemd-fsckd-stdout) autopkgtest [16:47:57]: test process requested reboot with marker test_systemd_fsck_with_plymouth_failure:0 Connection to 10.44.40.6 closed by remote host. autopkgtest-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds... test_systemd_fsck_with_plymouth_failure (__main__.FsckdTest) Ensure that a failing plymouth doesn't prevent fsckd to reconnect/exit ... unexpected success -- Ran 1 test in 17.952s FAILED (unexpected successes=1) [regression potential] low; test case expectation fix only. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829450/+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 1829404] Re: Suspends to RAM when shutdown order has been given if laptop lid is closed.
Oh joy! This is like the ultimate "have you tried turning it on and off again". I wonder, if shutdown should inhibit sleep as its first action. And/or sleep api should be checking for in flight shutdown transaction. I agree this is a bad behaviour. -- 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/1829404 Title: Suspends to RAM when shutdown order has been given if laptop lid is closed. Status in systemd package in Ubuntu: New Bug description: When I click to shutdown the laptop, if I close the lid before the shutdown process is completed, the laptop goes to sleep. This is annoying because it is consuming battery but specially because the suspend to RAM does not cancel the shutdown. When I open the laptop again, it restores from RAM, takes several minutes to shutdown and then I have to turn it on again. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.21 ProcVersionSignature: Ubuntu 4.18.0-20.21~18.04.1-generic 4.18.20 Uname: Linux 4.18.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: KDE Date: Thu May 16 16:26:41 2019 InstallationDate: Installed on 2019-02-23 (82 days ago) InstallationMedia: Kubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 5986:111c Acer, Inc Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: LENOVO 20K5S0T200 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-20-generic root=/dev/mapper/kubuntu--vg-root ro quiet splash vt.handoff=1 SourcePackage: systemd SystemdDelta: [MASKED] /etc/systemd/system/samba-ad-dc.service → /lib/systemd/system/samba-ad-dc.service [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 3 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/02/2017 dmi.bios.vendor: LENOVO dmi.bios.version: R0IET36W (1.14 ) dmi.board.asset.tag: Not Available dmi.board.name: 20K5S0T200 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40700 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR0IET36W(1.14):bd05/02/2017:svnLENOVO:pn20K5S0T200:pvrThinkPadX270W10DG:rvnLENOVO:rn20K5S0T200:rvrSDK0J40700WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad X270 W10DG dmi.product.name: 20K5S0T200 dmi.product.sku: LENOVO_MT_20K5_BU_Think_FM_ThinkPad X270 W10DG dmi.product.version: ThinkPad X270 W10DG dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829404/+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 1829450] Re: test_systemd_fsck_with_plymouth_failure passes but marked expected failure
> I see no need to reenable it in stable series. It has a regression potential, > since it used to be flakey, it may start to be flakey again blocking SRU > migrations. er, isn't that the point of these tests, if they start failing again we should investigate and fix the problem, instead of ignoring them? Maybe I'm not understanding what you mean, and if so, sorry. -- 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/1829450 Title: test_systemd_fsck_with_plymouth_failure passes but marked expected failure Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: Fix Committed Bug description: [impact] this test case was marked as expected failure in the past to try to ignore failures, but it now passes and so causes autopkgtest failures. [test case] run autopkgtest and check for the 'test_systemd_fsck_with_plymouth_failure' test, e.g.: test_systemd_fsck_with_plymouth_failure (__main__.FsckdTest) Ensure that a failing plymouth doesn't prevent fsckd to reconnect/exit ... bash: line 1: 786 Killed /tmp/autopkgtest.84SCbj/build.1op/src/debian/tests/systemd-fsckd 2> >(tee -a /tmp/autopkgtest.84SCbj/systemd-fsckd-stderr >&2) > >(tee -a /tmp/autopkgtest.84SCbj/systemd-fsckd-stdout) autopkgtest [16:47:57]: test process requested reboot with marker test_systemd_fsck_with_plymouth_failure:0 Connection to 10.44.40.6 closed by remote host. autopkgtest-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds... test_systemd_fsck_with_plymouth_failure (__main__.FsckdTest) Ensure that a failing plymouth doesn't prevent fsckd to reconnect/exit ... unexpected success -- Ran 1 test in 17.952s FAILED (unexpected successes=1) [regression potential] low; test case expectation fix only. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829450/+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 1829347] Re: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
** Changed in: systemd (Ubuntu Eoan)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu Disco)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu Cosmic)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu Bionic)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu)
Status: In Progress => New
** Changed in: systemd (Ubuntu Bionic)
Status: In Progress => New
** Changed in: systemd (Ubuntu Cosmic)
Status: In Progress => New
** Changed in: systemd (Ubuntu Disco)
Status: In Progress => New
** Tags removed: ddstreet-next
** Changed in: systemd (Ubuntu Disco)
Status: New => Incomplete
** Changed in: systemd (Ubuntu Cosmic)
Status: New => Incomplete
** Changed in: systemd (Ubuntu Bionic)
Status: New => Incomplete
--
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/1829347
Title:
systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug
Status in systemd package in Ubuntu:
New
Status in systemd source package in Bionic:
Incomplete
Status in systemd source package in Cosmic:
Incomplete
Status in systemd source package in Disco:
Incomplete
Status in systemd source package in Eoan:
Won't Fix
Status in systemd package in Debian:
Unknown
Bug description:
[impact]
systemd autopkgtest fails
[test case]
run systemd autopkgtest, check for output like:
LUKS device with "tmp" option ... rmmod: ERROR: Module scsi_debug is in use
FAIL
==
FAIL: test_luks_tmp (__main__.CryptsetupTest)
LUKS device with "tmp" option
--
Traceback (most recent call last):
File "/tmp/autopkgtest.It858Q/build.e7O/src/debian/tests/storage", line 59,
in setUp
self.fail('%s exists already' % self.plaintext_dev)
AssertionError: /dev/mapper/testcrypt1 exists already
or for older releases something like:
autopkgtest [19:27:26]: test storage: [---
modprobe: FATAL: Module scsi_debug not found in directory
/lib/modules/4.18.0-1011-kvm
ERROR
==
ERROR: setUpClass (__main__.CryptsetupTest)
--
Traceback (most recent call last):
File "/tmp/autopkgtest.azsL0q/build.Hbd/src/debian/tests/storage", line 21,
in setUpClass
subprocess.check_call(['modprobe', 'scsi_debug'])
File "/usr/lib/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['modprobe', 'scsi_debug']' returned
non-zero exit status 1.
this has attempted to be fixed in disco/eoan so the output is a bit different
across different releases, but all of them have the common point of failing to
modprobe or rmmod the scsi_debug module, which by itself doesn't indicate a
failure.
[regression potential]
low; this is fixing a testcase only.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829347/+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 1828892] Re: systemctl - alias service reports inactive while aliased is active
Only affects xenial at the moment. ** Changed in: systemd (Ubuntu Xenial) Status: In Progress => Triaged ** Changed in: systemd (Ubuntu) Status: In Progress => 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/1828892 Title: systemctl - alias service reports inactive while aliased is active Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Bug description: [Impact] 'systemctl is-active' command reports an alias service as inactive even though the aliased service is active. Currently the 'systemctl is-active' command does not load units to minimise its effect on the system (i.e. that a monitoring command does not itself alter the state of the system). However, this behaviour leads to inconsistencies when services are aliased. [Test case] - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin /etc/systemd/system$ ls -la libvirtd.service lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> /lib/systemd/system/libvirt-bin.service $ systemctl is-active libvirtd inactive $ systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh /ect/systemd/system$ ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> /lib/systemd/system/ssh.service $ systemctl is-active sshd inactive $ systemctl is-active ssh active [Regression Potential] This fix may result into systemctl reporting inconsistent information concerning the status of a service. [Other] Upstream issue : https://github.com/systemd/systemd/issues/7875 Upstream fix : https://github.com/systemd/systemd/pull/7997 Xenial is affected, fix exists on Bionic onward. $ lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04 $ apt-cache policy systemd systemd: Installed: 229-4ubuntu21.21 Candidate: 229-4ubuntu21.21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828892/+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 1754671] Re: Full-tunnel VPN DNS leakage regression
** Tags added: ddstreet-next -- 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/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: In Progress Status in network-manager source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+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 1828617] Re: Hosts randomly 'losing' disks, breaking ceph-osd service enumeration
** Package changed: systemd (Ubuntu) => ceph (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/1828617 Title: Hosts randomly 'losing' disks, breaking ceph-osd service enumeration Status in ceph package in Ubuntu: New Bug description: Ubuntu 18.04.2 Ceph deployment. Ceph OSD devices utilizing LVM volumes pointing to udev-based physical devices. LVM module is supposed to create PVs from devices using the links in /dev/disk/by-dname/ folder that are created by udev. However on reboot it happens (not always, rather like race condition) that Ceph services cannot start, and pvdisplay doesn't show any volumes created. The folder /dev/disk/by-dname/ however has all necessary device created by the end of boot process. The behaviour can be fixed manually by running "#/sbin/lvm pvscan --cache --activate ay /dev/nvme0n1" command for re-activating the LVM components and then the services can be started. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1828617/+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 1826459] Re: systemd-networkd not installing GatewayOnlink=true
enp0s31f6: Could not set route: Invalid argument enp0s31f6: Routes set addresses: - 95.216.96.148/26 gateway4: 95.216.96.129 routes: - on-link: true to: 95.216.96.148/26 via: 95.216.96.129 I do not quite understand what above is supposed to mean. 95.216.96.128/26 dev enp0s31f6 proto kernel scope link src 95.216.96.148 is a normal routing that is added for the self owned ip addresses, such that one shouldn't need to go via anything to talk to oneself. Is that a valid route? Also I see messages that link is not managed by us, and then later magically has an up to date state. I don't quite understand how above is expected to work, nor what is or isn't broken in networkd. I'll need to seek further help from netplan developers. ** Also affects: netplan Importance: Undecided Status: New -- 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/1826459 Title: systemd-networkd not installing GatewayOnlink=true Status in netplan: New Status in systemd package in Ubuntu: New Bug description: root@search-3 /run/systemd/network # for i in *; do echo $i; echo; cat $i; done ; sudo service systemd-networkd stop; SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd 10-netplan-enp0s31f6.network [Match] Name=enp0s31f6 [Network] LinkLocalAddressing=ipv6 Address=95.216.96.148/26 Gateway=95.216.96.129 DNS=8.8.8.8 DNS=1.1.1.1 Domains=148.96.216.95.clients.your-server.de VLAN=vlan4000 [Route] Destination=95.216.96.148/26 Gateway=95.216.96.129 GatewayOnlink=true 10-netplan-vlan4000.netdev [NetDev] Name=vlan4000 MTUBytes=1400 Kind=vlan [VLAN] Id=4000 10-netplan-vlan4000.network [Match] Name=vlan4000 [Network] LinkLocalAddressing=ipv6 Address=10.0.2.3/24 ConfigureWithoutCarrier=yes Failed to read $container of PID 1, ignoring: Permission denied Found container virtualization none. Bus n/a: changing state UNSET → OPENING Bus n/a: changing state OPENING → AUTHENTICATING Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory timestamp of '/etc/systemd/network' changed timestamp of '/run/systemd/network' changed Ignoring /run/systemd/network/10-netplan-enp0s31f6.network, because it's not a regular file with suffix .netdev. Ignoring /run/systemd/network/10-netplan-vlan4000.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-vz.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-ve.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-host0.network, because it's not a regular file with suffix .netdev. vlan4000: loaded vlan Ignoring /run/systemd/network/10-netplan-vlan4000.netdev, because it's not a regular file with suffix .network. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .network. tun0: MAC address not found for new device, continuing without tun0: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +POINTOPOINT +NOARP tun0: Link 12 added tun0: udev initialized link tun0: Saved original MTU: 1500 veth20a5a67: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST veth20a5a67: Link 8 added veth20a5a67: udev initialized link veth20a5a67: Saved original MTU: 1500 vlan4000: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST vlan4000: Link 6 added vlan4000: udev initialized link vlan4000: netdev has index 6 vlan4000: Saved original MTU: 1400 br-c7cc901345e8: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST br-c7cc901345e8: Link 5 added br-c7cc901345e8: udev initialized link br-c7cc901345e8: Saved original MTU: 1500 docker0: Flags change: +UP +MULTICAST +BROADCAST docker0: Link 3 added docker0: udev initialized link docker0: Saved original MTU: 1500 enp0s31f6: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST enp0s31f6: Link 2 added enp0s31f6: udev initialized link enp0s31f6: Saved original MTU: 1500 lo: Flags change: +LOOPBACK +UP +LOWER_UP +RUNNING lo: Link 1 added lo: udev initialized link lo: Saved original MTU: 0 vlan4000: Adding address: fe80::921b:eff:fe93:5015/64 (valid forever) vlan4000: Gained IPv6LL tun0: Adding address: 10.0.0.13/24 (valid forever) vlan4000: Adding address: 10.0.2.3/24 (valid forever) br-c7cc901345e8: Adding address: 172.18.0.1/16 (valid forever) docker0: Adding address: 172.17.0.1/16 (valid forever) enp0s31f6: Adding address: 95.216.96.148/26 (valid forever) lo: Adding address: 127.0.0.1/8 (valid forever) rtnl: received address with invalid family 129, ignoring Enumeration complet
[Touch-packages] [Bug 1830502] Re: apparmor fails to start with no parser errors
So yes that does appear to be part of it. I pulled your profile and
tested just a compile
time apparmor_parser -QT -D dfa-stats /tmp/layouts-test-1.txt
Created dfa: states 16780 proto { cache: size=16780 dups=36386 longest=1244
avg=6 }, nnodes { cache: size=16761 dups=36405 longest=1243 avg=5 }, anodes {
cache: size=11 dups=35437 longest=2 avg=1 }
Minimized dfa: final partitions 699 (accept 73) init 8 (accept 7)
Created dfa: states 34473 proto { cache: size=34473 dups=21674 longest=598
avg=7 }, nnodes { cache: size=34468 dups=21679 longest=598 avg=7 }, anodes {
cache: size=6 dups=4992 longest=2 avg=1 }
Minimized dfa: final partitions 27273 (accept 2095) init 4 (accept 3)
real0m27.084s
user0m26.735s
sys 0m0.348s
which is quite slow, but can happen for big profiles. With Valgrind
--tool=massif reporting a peak heap usage of 884.5MB
However Ubuntu defaults to using -O no-expr-simplify because it can
speed up small profiles. With that I get
time apparmor_parser -QT -D dfa-stats -O no-expr-simplify
/tmp/layouts-test-1.txt
Created dfa: states 40915 proto { cache: size=40915 dups=83997 longest=4870
avg=9 }, nnodes { cache: size=40633 dups=84279 longest=4869 avg=8 }, anodes {
cache: size=11 dups=82787 longest=2 avg=1 }
Minimized dfa: final partitions 699 (accept 73) init 8 (accept 7)
Created dfa: states 44769 proto { cache: size=44769 dups=28309 longest=33583
avg=226 }, nnodes { cache: size=44495 dups=28583 longest=33583 avg=226 },
anodes { cache: size=6 dups=8500 longest=2 avg=1 }
Minimized dfa: final partitions 27273 (accept 2095) init 4 (accept 3)
real0m45.947s
user0m39.770s
sys 0m6.166s
with valgrind --tool=massif reporting a peak usage of 15.4 GB
ouch
and that isn't the worst of it, because the initscripts run multiple
compiles in parallel. Mind you most compiles only take a few MB, but
still all of that happening at the same time puts a lot of pressure on
the system.
--
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/1830502
Title:
apparmor fails to start with no parser errors
Status in apparmor package in Ubuntu:
New
Bug description:
On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk,
my system was unable to finish booting and I had to go into recovery
mode and remove a number of files before the system would boot. After
doing so I discovered that now the apparmor.service systemd unit
always fails to start. I see this in dmesg:
[ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796
or sacrifice child
[ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB,
anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB
[ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Whenever apparmor.service is attempted to be started by systemd, i.e.
either on boot, or later with `systemctl start apparmor`.
The log from journalctl doesn't show any actual issues with any
profiles just this:
-- Reboot --
May 25 17:00:58 systemd[1]: Starting AppArmor initialization...
May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles
May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable:
usr.bin.firefox
May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable:
usr.sbin.rsyslogd
May 25 17:01:40 apparmor[1521]:...fail!
May 25 17:01:40 systemd[1]: apparmor.service: Main process exited,
code=exited, status=123/n/a
May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'.
May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization.
May 25 17:04:53 systemd[1]: Starting AppArmor initialization...
May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles
May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable:
usr.bin.firefox
May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable:
usr.sbin.rsyslogd
May 25 17:05:25 apparmor[4747]:...fail!
May 25 17:05:25 systemd[1]: apparmor.service: Main process exited,
code=exited, status=123/n/a
May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'.
May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization.
I can see that apparmor profiles are active after doing this (using
aa-status), but it's still troubling that apparmor runs into an issue
without actually saying what the error is.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1826459] Re: systemd-networkd not installing GatewayOnlink=true
>From what I can tell, the routing is exactly how it should be: [from the bug description] root@search-3 /run/systemd/network # ip route default via 95.216.96.129 dev enp0s31f6 proto static 10.0.0.0/24 dev tun0 proto kernel scope link src 10.0.0.13 10.0.2.0/24 dev vlan4000 proto kernel scope link src 10.0.2.3 95.216.96.128/26 dev enp0s31f6 proto kernel scope link src 95.216.96.148 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 172.18.0.0/16 dev br-c7cc901345e8 proto kernel scope link src 172.18.0.1 """ its missing to add 95.216.96.128/26 via 95.216.96.129 dev enp0s31f6 """ It's actually not missing a route -- the IP is defined as being 95.216.96.148/26; which means that it's on the same subnet as 95.216.96.129 (your gateway) already (/26 for this address is from 95.216.96.128 (the network address) to 95.216.96.191. The additional route is simply superfluous, it should not be required. networkd or the kernel may be ignoring them since the routes are already existing. Could you please tell us more about what you are trying to achieve? Are you trying to ping something that isn't responding the way you expect? Is some system not reachable? -- 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/1826459 Title: systemd-networkd not installing GatewayOnlink=true Status in netplan: Invalid Status in systemd package in Ubuntu: Incomplete Bug description: root@search-3 /run/systemd/network # for i in *; do echo $i; echo; cat $i; done ; sudo service systemd-networkd stop; SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd 10-netplan-enp0s31f6.network [Match] Name=enp0s31f6 [Network] LinkLocalAddressing=ipv6 Address=95.216.96.148/26 Gateway=95.216.96.129 DNS=8.8.8.8 DNS=1.1.1.1 Domains=148.96.216.95.clients.your-server.de VLAN=vlan4000 [Route] Destination=95.216.96.148/26 Gateway=95.216.96.129 GatewayOnlink=true 10-netplan-vlan4000.netdev [NetDev] Name=vlan4000 MTUBytes=1400 Kind=vlan [VLAN] Id=4000 10-netplan-vlan4000.network [Match] Name=vlan4000 [Network] LinkLocalAddressing=ipv6 Address=10.0.2.3/24 ConfigureWithoutCarrier=yes Failed to read $container of PID 1, ignoring: Permission denied Found container virtualization none. Bus n/a: changing state UNSET → OPENING Bus n/a: changing state OPENING → AUTHENTICATING Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory timestamp of '/etc/systemd/network' changed timestamp of '/run/systemd/network' changed Ignoring /run/systemd/network/10-netplan-enp0s31f6.network, because it's not a regular file with suffix .netdev. Ignoring /run/systemd/network/10-netplan-vlan4000.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-vz.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-ve.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-host0.network, because it's not a regular file with suffix .netdev. vlan4000: loaded vlan Ignoring /run/systemd/network/10-netplan-vlan4000.netdev, because it's not a regular file with suffix .network. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .network. tun0: MAC address not found for new device, continuing without tun0: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +POINTOPOINT +NOARP tun0: Link 12 added tun0: udev initialized link tun0: Saved original MTU: 1500 veth20a5a67: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST veth20a5a67: Link 8 added veth20a5a67: udev initialized link veth20a5a67: Saved original MTU: 1500 vlan4000: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST vlan4000: Link 6 added vlan4000: udev initialized link vlan4000: netdev has index 6 vlan4000: Saved original MTU: 1400 br-c7cc901345e8: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST br-c7cc901345e8: Link 5 added br-c7cc901345e8: udev initialized link br-c7cc901345e8: Saved original MTU: 1500 docker0: Flags change: +UP +MULTICAST +BROADCAST docker0: Link 3 added docker0: udev initialized link docker0: Saved original MTU: 1500 enp0s31f6: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST enp0s31f6: Link 2 added enp0s31f6: udev initialized link enp0s31f6: Saved original MTU: 1500 lo: Flags change: +LOOPBACK +UP +LOWER_UP +RUNNING lo: Link 1 added lo: udev initialized link lo: Saved original MTU: 0 vlan4000: Adding address: fe80::921b:eff:fe93:5015/64 (valid forever) vlan4000: Gained IPv6LL tun0: Adding address: 10.0.0.13/24 (valid forever) vlan4000: Adding address:
[Touch-packages] [Bug 1826459] Re: systemd-networkd not installing GatewayOnlink=true
Closing as Invalid for netplan: the config generated is exactly as it should for the netplan YAML that was provided. This isn't a bug in netplan. ** Changed in: netplan Status: New => Invalid -- 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/1826459 Title: systemd-networkd not installing GatewayOnlink=true Status in netplan: Invalid Status in systemd package in Ubuntu: Incomplete Bug description: root@search-3 /run/systemd/network # for i in *; do echo $i; echo; cat $i; done ; sudo service systemd-networkd stop; SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd 10-netplan-enp0s31f6.network [Match] Name=enp0s31f6 [Network] LinkLocalAddressing=ipv6 Address=95.216.96.148/26 Gateway=95.216.96.129 DNS=8.8.8.8 DNS=1.1.1.1 Domains=148.96.216.95.clients.your-server.de VLAN=vlan4000 [Route] Destination=95.216.96.148/26 Gateway=95.216.96.129 GatewayOnlink=true 10-netplan-vlan4000.netdev [NetDev] Name=vlan4000 MTUBytes=1400 Kind=vlan [VLAN] Id=4000 10-netplan-vlan4000.network [Match] Name=vlan4000 [Network] LinkLocalAddressing=ipv6 Address=10.0.2.3/24 ConfigureWithoutCarrier=yes Failed to read $container of PID 1, ignoring: Permission denied Found container virtualization none. Bus n/a: changing state UNSET → OPENING Bus n/a: changing state OPENING → AUTHENTICATING Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory timestamp of '/etc/systemd/network' changed timestamp of '/run/systemd/network' changed Ignoring /run/systemd/network/10-netplan-enp0s31f6.network, because it's not a regular file with suffix .netdev. Ignoring /run/systemd/network/10-netplan-vlan4000.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-vz.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-ve.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-host0.network, because it's not a regular file with suffix .netdev. vlan4000: loaded vlan Ignoring /run/systemd/network/10-netplan-vlan4000.netdev, because it's not a regular file with suffix .network. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .network. tun0: MAC address not found for new device, continuing without tun0: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +POINTOPOINT +NOARP tun0: Link 12 added tun0: udev initialized link tun0: Saved original MTU: 1500 veth20a5a67: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST veth20a5a67: Link 8 added veth20a5a67: udev initialized link veth20a5a67: Saved original MTU: 1500 vlan4000: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST vlan4000: Link 6 added vlan4000: udev initialized link vlan4000: netdev has index 6 vlan4000: Saved original MTU: 1400 br-c7cc901345e8: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST br-c7cc901345e8: Link 5 added br-c7cc901345e8: udev initialized link br-c7cc901345e8: Saved original MTU: 1500 docker0: Flags change: +UP +MULTICAST +BROADCAST docker0: Link 3 added docker0: udev initialized link docker0: Saved original MTU: 1500 enp0s31f6: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST enp0s31f6: Link 2 added enp0s31f6: udev initialized link enp0s31f6: Saved original MTU: 1500 lo: Flags change: +LOOPBACK +UP +LOWER_UP +RUNNING lo: Link 1 added lo: udev initialized link lo: Saved original MTU: 0 vlan4000: Adding address: fe80::921b:eff:fe93:5015/64 (valid forever) vlan4000: Gained IPv6LL tun0: Adding address: 10.0.0.13/24 (valid forever) vlan4000: Adding address: 10.0.2.3/24 (valid forever) br-c7cc901345e8: Adding address: 172.18.0.1/16 (valid forever) docker0: Adding address: 172.17.0.1/16 (valid forever) enp0s31f6: Adding address: 95.216.96.148/26 (valid forever) lo: Adding address: 127.0.0.1/8 (valid forever) rtnl: received address with invalid family 129, ignoring Enumeration completed Bus n/a: changing state AUTHENTICATING → HELLO Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName cookie=2 reply_cookie=0 signature=su error-name=n/a error-message=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMa
[Touch-packages] [Bug 1830502] Re: apparmor fails to start with no parser errors
Once you can get a profile to compile apparmor can cache the compile for you, so ideally the compile only needs to happen once per kernel. But I completely get even then, with this profile that is a problem. Can I keep the profile, and add it to a test suite, to look into reducing the compilers memory usage? -- 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/1830502 Title: apparmor fails to start with no parser errors Status in apparmor package in Ubuntu: New Bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa-status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1826459] Re: systemd-networkd not installing GatewayOnlink=true
The route looks invalid to me, please clarify ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- 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/1826459 Title: systemd-networkd not installing GatewayOnlink=true Status in netplan: Invalid Status in systemd package in Ubuntu: Incomplete Bug description: root@search-3 /run/systemd/network # for i in *; do echo $i; echo; cat $i; done ; sudo service systemd-networkd stop; SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd 10-netplan-enp0s31f6.network [Match] Name=enp0s31f6 [Network] LinkLocalAddressing=ipv6 Address=95.216.96.148/26 Gateway=95.216.96.129 DNS=8.8.8.8 DNS=1.1.1.1 Domains=148.96.216.95.clients.your-server.de VLAN=vlan4000 [Route] Destination=95.216.96.148/26 Gateway=95.216.96.129 GatewayOnlink=true 10-netplan-vlan4000.netdev [NetDev] Name=vlan4000 MTUBytes=1400 Kind=vlan [VLAN] Id=4000 10-netplan-vlan4000.network [Match] Name=vlan4000 [Network] LinkLocalAddressing=ipv6 Address=10.0.2.3/24 ConfigureWithoutCarrier=yes Failed to read $container of PID 1, ignoring: Permission denied Found container virtualization none. Bus n/a: changing state UNSET → OPENING Bus n/a: changing state OPENING → AUTHENTICATING Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory timestamp of '/etc/systemd/network' changed timestamp of '/run/systemd/network' changed Ignoring /run/systemd/network/10-netplan-enp0s31f6.network, because it's not a regular file with suffix .netdev. Ignoring /run/systemd/network/10-netplan-vlan4000.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-vz.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-ve.network, because it's not a regular file with suffix .netdev. Ignoring /lib/systemd/network/80-container-host0.network, because it's not a regular file with suffix .netdev. vlan4000: loaded vlan Ignoring /run/systemd/network/10-netplan-vlan4000.netdev, because it's not a regular file with suffix .network. Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .network. tun0: MAC address not found for new device, continuing without tun0: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +POINTOPOINT +NOARP tun0: Link 12 added tun0: udev initialized link tun0: Saved original MTU: 1500 veth20a5a67: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST veth20a5a67: Link 8 added veth20a5a67: udev initialized link veth20a5a67: Saved original MTU: 1500 vlan4000: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST vlan4000: Link 6 added vlan4000: udev initialized link vlan4000: netdev has index 6 vlan4000: Saved original MTU: 1400 br-c7cc901345e8: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST br-c7cc901345e8: Link 5 added br-c7cc901345e8: udev initialized link br-c7cc901345e8: Saved original MTU: 1500 docker0: Flags change: +UP +MULTICAST +BROADCAST docker0: Link 3 added docker0: udev initialized link docker0: Saved original MTU: 1500 enp0s31f6: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST enp0s31f6: Link 2 added enp0s31f6: udev initialized link enp0s31f6: Saved original MTU: 1500 lo: Flags change: +LOOPBACK +UP +LOWER_UP +RUNNING lo: Link 1 added lo: udev initialized link lo: Saved original MTU: 0 vlan4000: Adding address: fe80::921b:eff:fe93:5015/64 (valid forever) vlan4000: Gained IPv6LL tun0: Adding address: 10.0.0.13/24 (valid forever) vlan4000: Adding address: 10.0.2.3/24 (valid forever) br-c7cc901345e8: Adding address: 172.18.0.1/16 (valid forever) docker0: Adding address: 172.17.0.1/16 (valid forever) enp0s31f6: Adding address: 95.216.96.148/26 (valid forever) lo: Adding address: 127.0.0.1/8 (valid forever) rtnl: received address with invalid family 129, ignoring Enumeration completed Bus n/a: changing state AUTHENTICATING → HELLO Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName cookie=2 reply_cookie=0 signature=su error-name=n/a error-message=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch cookie=3 reply_cookie=0 signature=s error-name=n/a error-message=n/a Sent mes
[Touch-packages] [Bug 1829861] Re: handle TLS session renegotiation
This bug was fixed in the package apt - 1.8.2+19.10 --- apt (1.8.2+19.10) eoan; urgency=medium * Upload to eoan apt (1.8.2) unstable; urgency=medium [ Alwin Henseler ] * Flip /: in documented default value of DPkg::Path (Closes: #917986) [ TilmanK ] * Fix typo in German manpage translation [ Américo Monteiro ] * Portuguese manpages translation update (Closes: #926614) [ Jean-Pierre Giraud ] * French manpages translation update (Closes: #929290) [ Michael Zhivich ] * methods: https: handle requests for TLS re-handshake (LP: #1829861) [ Julian Andres Klode ] * Unlock dpkg locks in reverse locking order (LP: #1829860) -- Julian Andres Klode Tue, 28 May 2019 23:25:22 +0200 ** Changed in: apt (Ubuntu Eoan) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1829861 Title: handle TLS session renegotiation Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: New Status in apt source package in Cosmic: New Status in apt source package in Disco: New Status in apt source package in Eoan: Fix Released Bug description: [Impact] TLS sessions can renegotiate keys, but APT does not support it; meaning their HTTPS connections stop working. [Test case] ... [Regression potential] - Could we get stuck on renegotiation? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829861/+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 1829860] Re: APT unlocks in same order as it locks
This bug was fixed in the package apt - 1.8.2+19.10 --- apt (1.8.2+19.10) eoan; urgency=medium * Upload to eoan apt (1.8.2) unstable; urgency=medium [ Alwin Henseler ] * Flip /: in documented default value of DPkg::Path (Closes: #917986) [ TilmanK ] * Fix typo in German manpage translation [ Américo Monteiro ] * Portuguese manpages translation update (Closes: #926614) [ Jean-Pierre Giraud ] * French manpages translation update (Closes: #929290) [ Michael Zhivich ] * methods: https: handle requests for TLS re-handshake (LP: #1829861) [ Julian Andres Klode ] * Unlock dpkg locks in reverse locking order (LP: #1829860) -- Julian Andres Klode Tue, 28 May 2019 23:25:22 +0200 ** Changed in: apt (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1829860 Title: APT unlocks in same order as it locks Status in apt package in Ubuntu: Fix Released Bug description: [Impact] APT releases the locks in the same order it acquires them, rather than reverse order. Given that we have no waiting for locks, this is not _super_ problematic, but it might be wrong: You'd get a lock failure on dpkg's lock, rather than lock-frontend. [Test case] ... [Regression potential] ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829860/+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 1830796] Re: [Bionic][ARM64]Failure debugging linux kernel
** Description changed: [Impact] GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For example it is unable to print values of variables like 'jiffies_64'. [Test] # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic /proc/kcore [New process 1] Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic root=UUID=edb5e5a7-8272-4e13-aa25-37'. #0 0x in ?? () (gdb) p jiffies_64 Cannot access memory at address 0x09616980 (gdb) [Fix] This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by the following patch: 8727de56b0 Fix tagged pointer support [Regression Potential] - The risk of regression after applying this patch is low. + The risk of regression after applying this patch could be to architectures other than ARM64 due to changes to gdb/util.c. Please see comment #2 where I have tested the PPA package on a ppc64el system and found it does not introduce any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1830796 Title: [Bionic][ARM64]Failure debugging linux kernel Status in gdb package in Ubuntu: In Progress Bug description: [Impact] GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For example it is unable to print values of variables like 'jiffies_64'. [Test] # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic /proc/kcore [New process 1] Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic root=UUID=edb5e5a7-8272-4e13-aa25-37'. #0 0x in ?? () (gdb) p jiffies_64 Cannot access memory at address 0x09616980 (gdb) [Fix] This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by the following patch: 8727de56b0 Fix tagged pointer support [Regression Potential] The risk of regression after applying this patch could be to architectures other than ARM64 due to changes to gdb/util.c. Please see comment #2 where I have tested the PPA package on a ppc64el system and found it does not introduce any regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1830796/+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 1830502] Re: apparmor fails to start with no parser errors
Yes, certainly use the profile for whatever you can use it for. Would you like me to edit the description on this bug to reflect the actual underlying cause here or should I just close this and file a new bug for the memory usage of this profile? I'm no expert here but I think 15.4 GB memory usage seems a tad high and thus seems buggy :-) -- 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/1830502 Title: apparmor fails to start with no parser errors Status in apparmor package in Ubuntu: New Bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa-status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1830502] Re: apparmor fails to start with no parser errors
@Ian - how did you generate this profile? Is this something that snapd generated (it doesn't look like typical snap-update-ns profiles...)? If it did, can you attach the snap.yaml (this seems like atypical usage of the layouts feature)? -- 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/1830502 Title: apparmor fails to start with no parser errors Status in apparmor package in Ubuntu: New Bug description: On Ubuntu 18.04.2 LTS Desktop, after running out of space on my disk, my system was unable to finish booting and I had to go into recovery mode and remove a number of files before the system would boot. After doing so I discovered that now the apparmor.service systemd unit always fails to start. I see this in dmesg: [ 1066.975360] Out of memory: Kill process 6799 (apparmor_parser) score 796 or sacrifice child [ 1066.975364] Killed process 6799 (apparmor_parser) total-vm:15057348kB, anon-rss:15046148kB, file-rss:0kB, shmem-rss:0kB [ 1067.406595] oom_reaper: reaped process 6799 (apparmor_parser), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Whenever apparmor.service is attempted to be started by systemd, i.e. either on boot, or later with `systemctl start apparmor`. The log from journalctl doesn't show any actual issues with any profiles just this: -- Reboot -- May 25 17:00:58 systemd[1]: Starting AppArmor initialization... May 25 17:00:58 apparmor[1521]: * Starting AppArmor profiles May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:00:58 apparmor[1521]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:01:40 apparmor[1521]:...fail! May 25 17:01:40 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:01:40 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:01:40 systemd[1]: Failed to start AppArmor initialization. May 25 17:04:53 systemd[1]: Starting AppArmor initialization... May 25 17:04:53 apparmor[4747]: * Starting AppArmor profiles May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.bin.firefox May 25 17:04:53 apparmor[4747]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd May 25 17:05:25 apparmor[4747]:...fail! May 25 17:05:25 systemd[1]: apparmor.service: Main process exited, code=exited, status=123/n/a May 25 17:05:25 systemd[1]: apparmor.service: Failed with result 'exit-code'. May 25 17:05:25 systemd[1]: Failed to start AppArmor initialization. I can see that apparmor profiles are active after doing this (using aa-status), but it's still troubling that apparmor runs into an issue without actually saying what the error is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502/+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 1823550] Re: GtkSourceView (gedit - Text Editor and others) wrongly has monospaced font in dropdown (context) menu
This bug was fixed in the package ubuntu-mate-artwork - 19.10.2 --- ubuntu-mate-artwork (19.10.2) eoan; urgency=medium * Add suggested-action button style. * Add -secure icons required for correct VPN icon display in AppIndicator mode. (LP: #1681654) * Add Apport icons. * Optimise all .png and .jpg image assets. * De-duplicate icon themes. * Fix low contrast text selection in dialog windows. (LP: #1763942) * Fix inconsistent OK buttons. * Fix model buttons popovers. * Fix styling of paned headerbars. * Increase treeview expander size. * Increase minimum size of checkbox/radio buttons. * Improve font and font-size for context-menu. (LP: #1823550) * Improve spacing and padding for tabs, toolbars, menu items and column headers. -- Martin Wimpress Mon, 20 May 2019 08:12:40 +0100 ** Changed in: ubuntu-mate-artwork (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-themes in Ubuntu. https://bugs.launchpad.net/bugs/1823550 Title: GtkSourceView (gedit - Text Editor and others) wrongly has monospaced font in dropdown (context) menu Status in GtkSourceView: Fix Released Status in gtk+3.0 package in Ubuntu: Invalid Status in gtksourceview3 package in Ubuntu: Invalid Status in mate-themes package in Ubuntu: Invalid Status in pluma package in Ubuntu: Invalid Status in ubuntu-mate-artwork package in Ubuntu: Fix Released Status in ubuntu-themes package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu 17.04 or later installed 2. Open any application with GtkSourceView component - such as Pluma, Gedit, Giggle, Gitg, gnome-builder and maybe others (see complete list with `apt-cache rdepends libgtksourceview-3.0-1`) 3. Click right mouse button on text zone Expected result: * dropdown menu has normal font as all other interface elements Actual result: * dropdwon menu wrongly has monospaced font Notes: * first seen in 17.04, but persists in 17.10, 18.04 LTS, 18.10, 19.04 releases. * seems to be caused by GTK3 library ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: pluma 1.18.1-0ubuntu1 ProcVersionSignature: Ubuntu 4.10.0-42.46-generic 4.10.17 Uname: Linux 4.10.0-42-generic x86_64 ApportVersion: 2.20.4-0ubuntu4.10 Architecture: amd64 CurrentDesktop: MATE Date: Sun Apr 7 20:13:24 2019 InstallationDate: Installed on 2018-08-07 (243 days ago) InstallationMedia: Ubuntu-MATE 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801) SourcePackage: pluma UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gtksourceview/+bug/1823550/+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
