[Touch-packages] [Bug 1910576] Re: [MIR] libbpf (dependency of iproute2)
Thanks, this seems ready for promotion then -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1910576 Title: [MIR] libbpf (dependency of iproute2) Status in iproute2 package in Ubuntu: Invalid Status in libbpf package in Ubuntu: Fix Committed Bug description: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] Since the code is taken out of the Linux kernel, this should be treated similar to the kernel for security. Research uncovered no records about security issues. [Quality assurance] At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. Project is taken from the kernel source and claims static analysis via LGTM and Coverty. Also has CI via Travis (https://travis-ci.com/github/libbpf/libbpf). Right now there are no dep-8 tests. Though potentially it should be possible to create those, would this really add additional benefit beyond having upstream CI? A test build on hirsute was showing no warnings beyond lintian complaining about things which would be changed if we had delta (unstable as series for example). Otherwise was clean. [Dependencies] libc6: main libelf1: main zlib1g: main [Standards compliance] $ lintian --pedantic libbpf_0.3-2.dsc P: libbpf source: no-homepage-field P: libbpf source: silent-on-rules-requiring-root [Maintenance] As this is only taking out code from the kernel into a separate library package, the maintenance effort should be minimal. Packaging is done in Debian and is synced into Ubuntu (no delta). [Background information] A discourse about why this is packaged outside the kernel can be found at https://lwn.net/Articles/836911/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1910576/+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 1910576] Re: [MIR] libbpf (dependency of iproute2)
[Summary] MIR Team Ack to src:libbpf This does not need a security review IMHO, but as outlined below I'd want security to quickly ACK on that decision - assigning to Seth (security MIR Team member) for that. List of specific binary packages to be promoted to main: libbpf0 Required TODOs: - None Recommended TODOs: - Add build and/or autopkgtest tests to the package to spot issues early [Duplication] There is no other package in main providing the same functionality. Some packages that formerly had libbpf code slowly migrate to this lib. But that isn't duplication it is the right thing to do. [Dependencies] OK: - no other Dependencies to MIR due to this - -dev package will be auto-promoted, but all it's deps are ok as well [Embedded sources and static linking] - no embedded source present (this is in fact used to un-embed some in other pkg) - no static linking [Security] OK: - history of CVEs does not look concerning No issues on the lib yet, but the kernel backend has some (as one would expect for such a dynamic interface) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bpf - does not run a daemon as root - does not use webkit1,2 - does not use lib*v8 directly - does not open a port - does not process arbitrary web content - does not use centralized online accounts - does not integrate arbitrary javascript into the desktop - does not deal with system authentication (eg, pam), etc) Problems: - does not parse data formats, but no externally controlled ones I'm unsure if this needs a security review. They are currently rather busy with those and this package does replace code that was worse in iproute2 (pulling it into main). Since this is driven and in a lot of use by the bigger kernel community as well as Debian jumping onto this for Buster I think while I'd appreciate a review we don't strictly need it here as we are replacing better code. Also the new iproute needs to go along kernel 5.10 which just appeared in 21.04 so the runway is short. But I'll want security to do a 5-10 minute read of that reasoning and the code to agree to that decision. If they do we can go on promoting this immediately. If security decides that a full review is needed it will go their way as usual. [Common blockers] OK: - does not FTBFS currently - The package has a team bug subscriber - no translation present, but none needed for this case (user visible)? - not a python/go package, no extra constraints to consider int hat regard - no new python2 dependency Problems: - does not have a test suite that runs at build time - does not have a test suite that runs as autopkgtest Gladly that is somewhat covered by the upstream travis tests. None of the few but growing dependencies has higher level tests yet. This isn't a blocker since this is "just" the lib but certainly a step that would be recommended to the owning team to add. [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking is in place - d/watch is present and looks ok - Upstream update history is good, but it is yet rather new - Debian/Ubuntu update history is good - the current release is packaged - promoting this does not seem to cause issues for MOTUs that so far maintained the package - no massive Lintian warnings - d/rules is rather clean - Does not have Built-Using [Upstream red flags] OK: - no Errors/warnings during the build - no incautious use of malloc/sprintf (as far as I can check it) - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH - no use of user nobody - no use of setuid - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit, seed or libgoa-* - not part of the UI for extra checks ** Changed in: libbpf (Ubuntu) Assignee: Christian Ehrhardt (paelzer) => Seth Arnold (seth-arnold) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1910576 Title: [MIR] libbpf (dependency of iproute2) Status in iproute2 package in Ubuntu: Invalid Status in libbpf package in Ubuntu: New Bug description: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] Since the code is taken out of the Linux kernel, this should be treated similar to the kernel for security. Research uncovered no records about security issues. [Quality assurance] At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. Project is taken from the kernel source and claims static anal
[Touch-packages] [Bug 1910576] Re: [MIR] libbpf (dependency of iproute2)
** Changed in: iproute2 (Ubuntu) Assignee: Kernel Packages (kernel-packages) => (unassigned) ** Changed in: libbpf (Ubuntu) Assignee: Kernel Packages (kernel-packages) => Christian Ehrhardt (paelzer) ** Changed in: iproute2 (Ubuntu) Status: New => Invalid ** Changed in: libbpf (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1910576 Title: [MIR] libbpf (dependency of iproute2) Status in iproute2 package in Ubuntu: Invalid Status in libbpf package in Ubuntu: New Bug description: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] Since the code is taken out of the Linux kernel, this should be treated similar to the kernel for security. Research uncovered no records about security issues. [Quality assurance] At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. Project is taken from the kernel source and claims static analysis via LGTM and Coverty. Also has CI via Travis (https://travis-ci.com/github/libbpf/libbpf). Right now there are no dep-8 tests. Though potentially it should be possible to create those, would this really add additional benefit beyond having upstream CI? A test build on hirsute was showing no warnings beyond lintian complaining about things which would be changed if we had delta (unstable as series for example). Otherwise was clean. [Dependencies] libc6: main libelf1: main zlib1g: main [Standards compliance] $ lintian --pedantic libbpf_0.3-2.dsc P: libbpf source: no-homepage-field P: libbpf source: silent-on-rules-requiring-root [Maintenance] As this is only taking out code from the kernel into a separate library package, the maintenance effort should be minimal. Packaging is done in Debian and is synced into Ubuntu (no delta). [Background information] A discourse about why this is packaged outside the kernel can be found at https://lwn.net/Articles/836911/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1910576/+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 1908818] Re: pure packaging of libnss3
That should be this fix:
https://git.launchpad.net/ubuntu/+source/nss/commit/?h=applied/2%253.55-1ubuntu4=c17f28c15519fb4834860c021c078c6ea0d8ab50
Since this is kind of a patch-on-a-plate I'm marking it server-next.
** Tags added: server-next
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nss in Ubuntu.
https://bugs.launchpad.net/bugs/1908818
Title:
pure packaging of libnss3
Status in nss package in Ubuntu:
Fix Released
Status in nss source package in Groovy:
Triaged
Bug description:
dpkg -L libnss3
/.
/usr
/usr/lib
/usr/lib/${DEB_HOST_MULTIARCH}
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libnss3.so
/usr/lib/x86_64-linux-gnu/libnssutil3.so
/usr/lib/x86_64-linux-gnu/libsmime3.so
/usr/lib/x86_64-linux-gnu/libssl3.so
/usr/lib/x86_64-linux-gnu/nss
/usr/lib/x86_64-linux-gnu/nss/libfreebl3.chk
/usr/lib/x86_64-linux-gnu/nss/libfreebl3.so
/usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.chk
/usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.so
/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
/usr/lib/x86_64-linux-gnu/nss/libnssdbm3.chk
/usr/lib/x86_64-linux-gnu/nss/libnssdbm3.so
/usr/lib/x86_64-linux-gnu/nss/libsoftokn3.chk
/usr/lib/x86_64-linux-gnu/nss/libsoftokn3.so
/usr/share
/usr/share/doc
/usr/share/doc/libnss3
/usr/share/doc/libnss3/changelog.Debian.gz
/usr/share/doc/libnss3/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libnss3
/usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.chk
/usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so
/usr/lib/${DEB_HOST_MULTIARCH}/libfreeblpriv3.chk
as we can see soft links to libraries do nor resolve ${DEB_HOST_MULTIARCH} to
x86_64-linux-gnu
ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: libnss3 2:3.55-1ubuntu3
ProcVersionSignature: Ubuntu 5.8.0-33.36-generic 5.8.17
Uname: Linux 5.8.0-33-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu50.3
Architecture: amd64
CasperMD5CheckResult: skip
Date: Sun Dec 20 14:36:10 2020
SourcePackage: nss
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1908818/+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 1909748] Re: Apparmor profile improvements for letsencrypt
FYI - We've united this with a merge for 21.04 that was ongoing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1909748 Title: Apparmor profile improvements for letsencrypt Status in openldap package in Ubuntu: In Progress Bug description: I can see that the slapd apparmor profile goes 90% of the way to working out of the box with letsencrypt/certbot, but fails to include abstractions/ssl_keys. The attached patch should work support all the methods in these abstractions, and should be the default with the slapd package. Please can you look at including this in future? Many thanks, Paul. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1909748/+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 1909748] Re: Apparmor profile improvements for letsencrypt
The apparmor profile isn't in Debian yet and I've seen no effort to do so [1][2] yet. Therefore for now just update the profile we have. Therefore I proposed [3] which converted your contribution to the changes that will be needed on the packaging. P.S. I've spoken to Andreas and he said there was no old deny for apparmor in Debian, so we should at some point be able to get it there as well (with the fix then). [1]: https://salsa.debian.org/paelzer-guest/openldap/-/merge_requests [2]: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes=openldap [3]: https://code.launchpad.net/~paelzer/ubuntu/+source/openldap/+git/openldap/+merge/395730 ** Changed in: openldap (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1909748 Title: Apparmor profile improvements for letsencrypt Status in openldap package in Ubuntu: In Progress Bug description: I can see that the slapd apparmor profile goes 90% of the way to working out of the box with letsencrypt/certbot, but fails to include abstractions/ssl_keys. The attached patch should work support all the methods in these abstractions, and should be the default with the slapd package. Please can you look at including this in future? Many thanks, Paul. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1909748/+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 1909748] Re: Apparmor profile improvements for letsencrypt
FYI - Your change looks fine to me. I'll take a closer look later to consider where to best push this. ** Tags added: server-next ** Changed in: openldap (Ubuntu) Assignee: (unassigned) => Christian Ehrhardt (paelzer) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1909748 Title: Apparmor profile improvements for letsencrypt Status in openldap package in Ubuntu: New Bug description: I can see that the slapd apparmor profile goes 90% of the way to working out of the box with letsencrypt/certbot, but fails to include abstractions/ssl_keys. The attached patch should work support all the methods in these abstractions, and should be the default with the slapd package. Please can you look at including this in future? Many thanks, Paul. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1909748/+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 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2
Thank you, this is indeed ok for Qemu now. And systemd is all up to you as you get re-started in 2021 - happy new year and thanks for your work on this. ** Changed in: qemu (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1908259 Title: TEST-36-NUMAPOLICY fails with qemu 5.2 Status in systemd: Unknown Status in qemu package in Ubuntu: Fix Released Status in systemd package in Ubuntu: In Progress Bug description: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) E: QEMU failed with exit code 1 Isolated this to a test without systemd: $ apt install linux-image-generic qemu-system-x86 $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' Upgrading to 5.2 makes this: $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) The numa spec is indeed a bit short -numa node,nodeid=0 If I change this to -numa node,mem=512M,nodeid=0 It would work, but that kind of specification is forbidden >=5.1 Parameter -numa node,mem is not supported by this machine type Use -numa node,memdev instead You'd need also something like -M pc-i440fx-5.0 which isn't anything the test wants to set in stone I guess. Instead using memdev works: -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 This works fine and is in qemu since quite some time. Properly documented since 2.12 but actually available since 2.1 (2014) The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh QEMU_OPTIONS="-numa node,nodeid=0" Fixing that to a new form should help. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1908259/+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 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2
Upstream CI as well as local autopkgtest runs confirm that the new systemd test code will make the new qemu pass. # Formerly failing $ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries -o systemd-vs-qemu5.2 --apt-upgrade --apt-pocket=proposed=src:qemu --setup-commands="add-apt-repository ppa:ci-trg ... autopkgtest [17:09:01]: test upstream: ---] upstream PASS autopkgtest [17:09:02]: test upstream: - - - - - - - - - - results - - - - - - - - - - autopkgtest [17:09:03]: summary upstream PASS qemu-system-x86_64: terminating on signal 15 from pid 1783557 (/usr/bin/python3) -- 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/1908259 Title: TEST-36-NUMAPOLICY fails with qemu 5.2 Status in systemd: Unknown Status in qemu package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) E: QEMU failed with exit code 1 Isolated this to a test without systemd: $ apt install linux-image-generic qemu-system-x86 $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' Upgrading to 5.2 makes this: $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) The numa spec is indeed a bit short -numa node,nodeid=0 If I change this to -numa node,mem=512M,nodeid=0 It would work, but that kind of specification is forbidden >=5.1 Parameter -numa node,mem is not supported by this machine type Use -numa node,memdev instead You'd need also something like -M pc-i440fx-5.0 which isn't anything the test wants to set in stone I guess. Instead using memdev works: -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 This works fine and is in qemu since quite some time. Properly documented since 2.12 but actually available since 2.1 (2014) The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh QEMU_OPTIONS="-numa node,nodeid=0" Fixing that to a new form should help. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1908259/+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 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2
https://github.com/systemd/systemd/pull/17987 was accepted upstream. I assume with the amount of dependencies that systemd has there is no easy "just apply this and upload" that will make anyone happy :-/ But now that everything seems ready I wanted to ask the package maintainer (who usually has a plan on coming uploads already) when we could get this applied? ** 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/1908259 Title: TEST-36-NUMAPOLICY fails with qemu 5.2 Status in systemd: Unknown Status in qemu package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) E: QEMU failed with exit code 1 Isolated this to a test without systemd: $ apt install linux-image-generic qemu-system-x86 $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' Upgrading to 5.2 makes this: $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) The numa spec is indeed a bit short -numa node,nodeid=0 If I change this to -numa node,mem=512M,nodeid=0 It would work, but that kind of specification is forbidden >=5.1 Parameter -numa node,mem is not supported by this machine type Use -numa node,memdev instead You'd need also something like -M pc-i440fx-5.0 which isn't anything the test wants to set in stone I guess. Instead using memdev works: -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 This works fine and is in qemu since quite some time. Properly documented since 2.12 but actually available since 2.1 (2014) The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh QEMU_OPTIONS="-numa node,nodeid=0" Fixing that to a new form should help. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1908259/+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 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2
Tests are somewhat blocked by PPA being under maintenance. But I have filed the issue upstream for discussion and to trigger their CI. Issue => https://github.com/systemd/systemd/issues/17986 PR => https://github.com/systemd/systemd/pull/17987 ** Bug watch added: github.com/systemd/systemd/issues #17986 https://github.com/systemd/systemd/issues/17986 ** Also affects: systemd via https://github.com/systemd/systemd/issues/17986 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/1908259 Title: TEST-36-NUMAPOLICY fails with qemu 5.2 Status in systemd: Unknown Status in qemu package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) E: QEMU failed with exit code 1 Isolated this to a test without systemd: $ apt install linux-image-generic qemu-system-x86 $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' Upgrading to 5.2 makes this: $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) The numa spec is indeed a bit short -numa node,nodeid=0 If I change this to -numa node,mem=512M,nodeid=0 It would work, but that kind of specification is forbidden >=5.1 Parameter -numa node,mem is not supported by this machine type Use -numa node,memdev instead You'd need also something like -M pc-i440fx-5.0 which isn't anything the test wants to set in stone I guess. Instead using memdev works: -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 This works fine and is in qemu since quite some time. Properly documented since 2.12 but actually available since 2.1 (2014) The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh QEMU_OPTIONS="-numa node,nodeid=0" Fixing that to a new form should help. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1908259/+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 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2
Added qemu task for update-excuse tag to be resolved. I have a fix prepared that is building/testing right now. If successful I'll open an upstream issue for 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/1908259 Title: TEST-36-NUMAPOLICY fails with qemu 5.2 Status in qemu package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) E: QEMU failed with exit code 1 Isolated this to a test without systemd: $ apt install linux-image-generic qemu-system-x86 $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' Upgrading to 5.2 makes this: $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) The numa spec is indeed a bit short -numa node,nodeid=0 If I change this to -numa node,mem=512M,nodeid=0 It would work, but that kind of specification is forbidden >=5.1 Parameter -numa node,mem is not supported by this machine type Use -numa node,memdev instead You'd need also something like -M pc-i440fx-5.0 which isn't anything the test wants to set in stone I guess. Instead using memdev works: -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 This works fine and is in qemu since quite some time. Properly documented since 2.12 but actually available since 2.1 (2014) The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh QEMU_OPTIONS="-numa node,nodeid=0" Fixing that to a new form should help. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1908259/+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 1908259] [NEW] TEST-36-NUMAPOLICY fails with qemu 5.2
Public bug reported: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) E: QEMU failed with exit code 1 Isolated this to a test without systemd: $ apt install linux-image-generic qemu-system-x86 $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' Upgrading to 5.2 makes this: $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0' qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) The numa spec is indeed a bit short -numa node,nodeid=0 If I change this to -numa node,mem=512M,nodeid=0 It would work, but that kind of specification is forbidden >=5.1 Parameter -numa node,mem is not supported by this machine type Use -numa node,memdev instead You'd need also something like -M pc-i440fx-5.0 which isn't anything the test wants to set in stone I guess. Instead using memdev works: -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 This works fine and is in qemu since quite some time. Properly documented since 2.12 but actually available since 2.1 (2014) The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh QEMU_OPTIONS="-numa node,nodeid=0" Fixing that to a new form should help. ** Affects: qemu (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: update-excuse ** Also affects: qemu (Ubuntu) Importance: Undecided Status: New ** Tags added: update-excuse -- 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/1908259 Title: TEST-36-NUMAPOLICY fails with qemu 5.2 Status in qemu package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: Hi, this test now fails as seen on ppc here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel /boot/vmlinux-5.8.0-25-generic -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=hvc0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service ' E: QEMU failed with exit code 1 qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size (0x2000) Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2 On other architectures this test is just skipped and ppc happened to complete faster so I saw it earlier. The same happens on amd64 + /bin/qemu-system-x86_64 -smp
[Touch-packages] [Bug 1907789] Re: 2.35.50 breaks ld -no-pie
FYI - fix submitted to qemu upstream and for now added to the qemu package. If upstream eventually prefers a different solution I can refresh it accordingly. => https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg03684.html -- 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/1907789 Title: 2.35.50 breaks ld -no-pie Status in binutils: Fix Released Status in binutils package in Ubuntu: Fix Committed Status in qemu package in Ubuntu: In Progress Bug description: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1907789/+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 1907789] Re: 2.35.50 breaks ld -no-pie
** Also affects: qemu (Ubuntu) Importance: Undecided Status: New ** Changed in: qemu (Ubuntu) Status: New => In Progress ** Changed in: qemu (Ubuntu) Assignee: (unassigned) => Christian Ehrhardt (paelzer) ** Changed in: qemu (Ubuntu) Importance: Undecided => High -- 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/1907789 Title: 2.35.50 breaks ld -no-pie Status in binutils: Unknown Status in binutils package in Ubuntu: Fix Committed Status in qemu package in Ubuntu: In Progress Bug description: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1907789/+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 1900008] Re: Sessions of screen does not keep running in background
Since this started to seem different between Mate as discussed above I was giving a few more terminals I regularly use a try: - tilix (VTE based) - warns me that I'll close processes under this session, keeps screen alive detached - yakuake (kde based) - warns me that I'll close processes under this session, keeps screen alive detached - konsole - warns me that I'll close processes under this session, keeps screen alive detached - gnome-terminal - no warning, keeps screen alive detached So screen never totally died in any of those, just remained detached as one would want/expect. Since I even tried several KDE based terminals, but not had KDE itself running (I had default gnome based Desktop). I wonder if there might be some general KDE-setting that changes how closing sessions work. @Gustavo - when you get to retry it on a VM as you mentioned, would you mind trying the same on a KDE-Neon vs a default-Gnome desktop? -- 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/198 Title: Sessions of screen does not keep running in background Status in screen package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: In a new fresh installed 20.04, when I use screen command and close the terminal (not closing screen sesion), then I can't recover it with screen -x, since does not exist. I can only recover screen sesion if the original terminal running screen is not being closed. For some reason, this is closing screen session of that user: Oct 15 13:32:45 pc-caja2 systemd[1]: session-66.scope: Succeeded. Oct 15 13:32:45 pc-caja2 systemd[1]: Stopped Session 66 of user usuario. This does not happen in an upgraded system from 18.04 to 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/screen/+bug/198/+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 1907893] Re: package openssh-server 1:8.3p1-1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1
Thank you for taking the time to report this bug and helping to make Ubuntu better. On upgrading a service this service has to be restarted to pick up the fixes. Rather rarely a real issue occurs that the newer version does e.g. fail with the formerly working configuration. But most of the time what happens is, that a service was installed, but stays unconfigured or experimented with but left in a broken state. Now on any update of the related packages that service has to be restarted, but since its config is incomplete/faulty it fails to restart. Therefore the update of that package has to consider itself incomplete. Depending on your particular case there are two solutions: - either remove the offending package if you don't want to continue using it. - Or if you do want to keep it please fix the configuration so that re-starting the service will work. Since it seems likely to me that this is a local configuration problem, rather than a bug in Ubuntu, I'm marking this bug as Incomplete. If indeed this is a local configuration problem, you can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community Or if you believe that this is really a bug, then you may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to New. ** Changed in: openssh (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1907893 Title: package openssh-server 1:8.3p1-1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 Status in openssh package in Ubuntu: Incomplete Bug description: . ProblemType: Package DistroRelease: Ubuntu 20.10 Package: openssh-server 1:8.3p1-1 ProcVersionSignature: Ubuntu 5.8.0-33.36-generic 5.8.17 Uname: Linux 5.8.0-33-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.2 Architecture: amd64 CasperMD5CheckResult: skip Date: Fri Dec 11 23:16:05 2020 ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2020-12-12 (0 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) Python3Details: /usr/bin/python3.8, Python 3.8.6, python3-minimal, 3.8.6-0ubuntu1 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.20.5ubuntu2 apt 2.1.10ubuntu0.1 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: Missing privilege separation directory: /run/sshd SourcePackage: openssh Title: package openssh-server 1:8.3p1-1 failed to install/upgrade: installed openssh-server package post-installation script subprocess 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/openssh/+bug/1907893/+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 1907893] Re: package openssh-server 1:8.3p1-1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1
Hi Marcus, from your log: error: Bind to port 22 on :: failed: Address already in use. fatal: Cannot bind any address This indicates that some local configuration causes another service to run and bind port 22 which blocks sshd from (re-)starting. Sshd itself (the one of the package) would not block itself as it is restarted, but anything else on that port will. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1907893 Title: package openssh-server 1:8.3p1-1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 Status in openssh package in Ubuntu: Incomplete Bug description: . ProblemType: Package DistroRelease: Ubuntu 20.10 Package: openssh-server 1:8.3p1-1 ProcVersionSignature: Ubuntu 5.8.0-33.36-generic 5.8.17 Uname: Linux 5.8.0-33-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.2 Architecture: amd64 CasperMD5CheckResult: skip Date: Fri Dec 11 23:16:05 2020 ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2020-12-12 (0 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) Python3Details: /usr/bin/python3.8, Python 3.8.6, python3-minimal, 3.8.6-0ubuntu1 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.20.5ubuntu2 apt 2.1.10ubuntu0.1 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: Missing privilege separation directory: /run/sshd SourcePackage: openssh Title: package openssh-server 1:8.3p1-1 failed to install/upgrade: installed openssh-server package post-installation script subprocess 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/openssh/+bug/1907893/+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 1907789] [NEW] 2.35.50 breaks ld -no-pie
Public bug reported: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD ** Affects: binutils (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/1907789 Title: 2.35.50 breaks ld -no-pie Status in binutils package in Ubuntu: New Bug description: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+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 1907789] Re: 2.35.50 breaks ld -no-pie
** Attachment added: "linuxboot.o - build artifact to re-create the issue" https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+attachment/5442724/+files/linuxboot.o -- 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/1907789 Title: 2.35.50 breaks ld -no-pie Status in binutils package in Ubuntu: New Bug description: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+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 1907789] Re: 2.35.50 breaks ld -no-pie
** Attachment added: "flat.lds - build artifact to re-create the issue" https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+attachment/5442723/+files/flat.lds -- 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/1907789 Title: 2.35.50 breaks ld -no-pie Status in binutils package in Ubuntu: New Bug description: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+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 1906943] Re: package libsasl2-2:i386 2.1.27+dfsg-2 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuratio
Hi Alex, the logs you attached do not hold much more info to debug/analyze your case. But in general you'd more or less follow the steps mentioned in => https://askubuntu.com/questions/148715/how-to-fix-package-is-in-a-very-bad-inconsistent-state-error Could you try those out and see if they help? ** Changed in: cyrus-sasl2 (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906943 Title: package libsasl2-2:i386 2.1.27+dfsg-2 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration Status in cyrus-sasl2 package in Ubuntu: Incomplete Bug description: Happened during the installation of WineHQ stable ProblemType: Package DistroRelease: Ubuntu 20.04 Package: libsasl2-2:i386 2.1.27+dfsg-2 ProcVersionSignature: Ubuntu 5.4.0-56.62-generic 5.4.73 Uname: Linux 5.4.0-56-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.13 Architecture: amd64 CasperMD5CheckResult: skip Date: Sun Dec 6 01:03:26 2020 ErrorMessage: package is in a very bad inconsistent state; you should reinstall it before attempting configuration PackageArchitecture: i386 Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.1 SourcePackage: cyrus-sasl2 Title: package libsasl2-2:i386 2.1.27+dfsg-2 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1906943/+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 1905790] Re: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child
+1 to Timo to not go for "system nssdb" for the cause of this case here. Also system-wide-trust would be bug 1647285 and is quite a different scope. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child Status in ca-certificates package in Ubuntu: New Status in sssd package in Ubuntu: Fix Released Status in ca-certificates source package in Focal: New Status in sssd source package in Focal: New Bug description: [ Impact ] SSSD supports in 20.04 two security backends: NSS and OpenSSL (speaking in past tense as upstream dropped NSS support completely). Those two backends are used for various generic crypto features (so they are interchangeable), but also for the management of the PKCS#11 modules for smart cards. In this case, the main problem is that by using NSS it also relies on the presence of a "system NSS" database [1] that is something present in Fedora and RHEL, but not in ubuntu or generic Linux distributions. In order to make SSSD to find a smart card module, we would then need to create a such database that mentions a p11kit proxy that will eventually load the p11-kit module and then add the card CA certificate to the same DB (see more details in [2]). And even in such case... It will not work at login phase. This is making support for Smart-card based authentication in 20.04 quite complicated, and hard to implement in professional environments (see bug #1865226). As per this, recompiling SSSD's p11_child to use OpenSSL (as it already happens starting from 20.10) would be enough to make the this tool (the one in charge for smartcard authentications and certificate matching) to be able to get the smartcard devices from p11-kit allowed modules and to check their certificate using CA certificates in the ubuntu system ca certificate files (or other configured file). One more mayor reason to do this, is also that if we fix 20.04 now to use the "proper" method, people who will configure smartcard access there via SSSD (not easily possible right now) won't be affected by future migrations. [ Proposed Implementations ] 1) Use p11-kit and openssl for p11_child, by changing the build/test system (preferred) https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child 2) Build both versions and package things accordingly (hackish) https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child-v1 3) Recompile SSSD completely to use libcrypto as backend [ Test case ] With a smartcard reader available (and with a card in its slot) as reported by: $ p11-kit list-modules launch: $ sudo /usr/libexec/sssd/p11_child --pre -d 10 --debug-fd=2 \ --nssdb=/etc/ssl/certs/ca-certificates.crt The tool should find your card: (2020-11-26 21:34:22:020395): [p11_child[100729]] [do_card] (0x4000): Module List: (2020-11-26 21:34:22:020481): [p11_child[100729]] [do_card] (0x4000): common name: [p11-kit-trust]. (2020-11-26 21:34:22:020497): [p11_child[100729]] [do_card] (0x4000): dll name: [/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so]. (2020-11-26 21:34:22:020569): [p11_child[100729]] [do_card] (0x4000): Description [/etc/ssl/certs/ca-certificates.crt PKCS#11 Kit ] Manufacturer [PKCS#11 Kit ] flags [1] removable [false] token present [true]. (2020-11-26 21:34:22:020611): [p11_child[100729]] [do_card] (0x4000): common name: [opensc-pkcs11]. (2020-11-26 21:34:22:020646): [p11_child[100729]] [do_card] (0x4000): dll name: [/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so]. (2020-11-26 21:34:22:025443): [p11_child[100729]] [do_card] (0x4000): Description [VMware Virtual USB CCID 00 00 VMware ] Manufacturer [VMware ] flags [7] removable [true] token present [true]. (2020-11-26 21:34:22:025725): [p11_child[100729]] [do_card] (0x4000): Found [MARCO TREVISAN (PIN CNS0)] in slot [VMware Virtual USB CCID 00 00][0] of module [1][/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so]. Then the tool might fail if the card certificate is not added to the ca-certificates.crt, but this is outside the scope of the test case. What it matters is that the card is found. [ Regression potential ] While the change may involve quite different code paths when it comes to security features, I think we trust OpenSSL enough to be an acceptable crypto backend for PKCS#11 operations. Behavior should not change, also assuming that upstream dropped NSS support completely in latest release [3], keeping the same functionalities. As per a further review of this by xnox [4], we can safely assume that SSSD does
[Touch-packages] [Bug 1904192] Re: ebtables can not rename just created chain
Bfore upgrade: ubuntu@g-test:~$ sudo ebtables -t nat -N foo ubuntu@g-test:~$ sudo ebtables -t nat -E foo bar ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists Try `ebtables -h' or 'ebtables --help' for more information. Upgrade: ubuntu@g-test:~$ sudo apt install iptables Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libip4tc2 libip6tc2 libxtables12 Suggested packages: firewalld nftables The following packages will be upgraded: iptables libip4tc2 libip6tc2 libxtables12 4 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. Need to get 498 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Y Get:1 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 iptables amd64 1.8.5-3ubuntu2.20.10.2 [432 kB] Get:2 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libxtables12 amd64 1.8.5-3ubuntu2.20.10.2 [28.7 kB] Get:3 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libip6tc2 amd64 1.8.5-3ubuntu2.20.10.2 [19.1 kB] Get:4 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libip4tc2 amd64 1.8.5-3ubuntu2.20.10.2 [18.7 kB] Fetched 498 kB in 0s (1465 kB/s) (Reading database ... 64660 files and directories currently installed.) Preparing to unpack .../iptables_1.8.5-3ubuntu2.20.10.2_amd64.deb ... Unpacking iptables (1.8.5-3ubuntu2.20.10.2) over (1.8.5-3ubuntu2.20.10.1) ... Preparing to unpack .../libxtables12_1.8.5-3ubuntu2.20.10.2_amd64.deb ... Unpacking libxtables12:amd64 (1.8.5-3ubuntu2.20.10.2) over (1.8.5-3ubuntu2.20.10.1) ... Preparing to unpack .../libip6tc2_1.8.5-3ubuntu2.20.10.2_amd64.deb ... Unpacking libip6tc2:amd64 (1.8.5-3ubuntu2.20.10.2) over (1.8.5-3ubuntu2.20.10.1) ... Preparing to unpack .../libip4tc2_1.8.5-3ubuntu2.20.10.2_amd64.deb ... Unpacking libip4tc2:amd64 (1.8.5-3ubuntu2.20.10.2) over (1.8.5-3ubuntu2.20.10.1) ... Setting up libip4tc2:amd64 (1.8.5-3ubuntu2.20.10.2) ... Setting up libip6tc2:amd64 (1.8.5-3ubuntu2.20.10.2) ... Setting up libxtables12:amd64 (1.8.5-3ubuntu2.20.10.2) ... Setting up iptables (1.8.5-3ubuntu2.20.10.2) ... Processing triggers for man-db (2.9.3-2) ... Processing triggers for libc-bin (2.32-0ubuntu3) ... After upgrade ubuntu@g-test:~$ sudo ebtables -t nat -N foo2 ubuntu@g-test:~$ sudo ebtables -t nat -E foo2 bar Thanks, setting verified! ** Tags removed: verification-needed verification-needed-groovy ** Tags added: verification-done verification-done-groovy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1904192 Title: ebtables can not rename just created chain Status in iptables: Unknown Status in iptables package in Ubuntu: Fix Released Status in iptables source package in Groovy: Fix Committed Status in iptables source package in Hirsute: Fix Released Status in iptables package in Debian: Unknown Status in iptables package in Fedora: Fix Committed Bug description: [SRU] * Changes that went into 1.8.5 ave broken the errno handling. In particular loading extensions. Due to that it has become impossible to rename rules. * Upstream has created a fix and this backports that change to Ubuntu => http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247 [Test Case] * # ebtables -t nat -N foo # ebtables -t nat -E foo bar ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists * with the fix the above command sequence works [Where problems could occur] * The change moved code from nft_chain_user_rename to do_commandeb and therefore in theory any ebtables/xtables subcommand could be affected. Yet what it does is just resetting the error code in a better place, so while it "could" affect every subcommand it should (tm) not do so. [Other Info] * n/a --- Hi, I have an issue with ebtables that affects libvirt. While initially found in hirsute I had to realize this is broken in Groovy and even Bionic (might be a different reason back then) as well right now. But working in Focal (witch matches my memory of it being good before [1]). I was isolating the commands that libvirt runs (identical between Focal and Hirsute) to find a simplified trigger. Gladly I found one that leaves libvirt and other components out of the equation. The following works on focal, but fails on the other releases. Note: I checked which tool is in use and in both cases it is xtables-nft-multi. /usr/sbin/ebtables -> /etc/alternatives/ebtables* /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft* /usr/sbin/ebtables-nft -> xtables-nft-multi* So I converted the libvirt issued commands into xtables-nft-multi just to be sure in case a system to compare has other alternatives set. Focal (Good):
[Touch-packages] [Bug 1905735] Re: ubuntu-image autopkgtests failing since pytohn-debian 0.1.38
Seb has opened:
https://code.launchpad.net/~seb128/ubuntu-image/+git/ubuntu-image/+merge/394533
It is idential to what I build and tested in
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4353/+packages
If we don't want to wait and retrigger the tests with the new version, here a
hint:
https://code.launchpad.net/~paelzer/britney/+git/hints-ubuntu/+merge/394535
** Bug watch added: Debian Bug tracker #975910
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975910
** Also affects: python-debian (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975910
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-debian in Ubuntu.
https://bugs.launchpad.net/bugs/1905735
Title:
ubuntu-image autopkgtests failing since python-debian 0.1.38
Status in python-debian package in Ubuntu:
Triaged
Status in ubuntu-image package in Ubuntu:
Fix Committed
Status in python-debian package in Debian:
Unknown
Bug description:
In the tests it seems that since some - yet to be found - change ~20th
Nov the tests of ubuntu-image fail.
Tests all list those three sub-tests as failing:
unittests.sh FAIL non-zero exit status 1
qa FAIL non-zero exit status 1
coverage.sh FAIL non-zero exit status 1
Fails all seem to be related to some python/pytest/py* change that
might have slipped in without gating on this test.
Ubuntu-image itself also isn't new - still the same as in groovy
ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all
== log start
===
Obtaining file:///tmp/autopkgtest.ZuL7Da/build.chY/src
ERROR: Command errored out with exit status 1:
command:
/tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python -c 'import
sys, setuptools, tokenize; sys.argv[0] =
'"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';
__file__='"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';f=getattr(tokenize,
'"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"',
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info
--egg-base /tmp/pip-pip-egg-info-yaplrymq
cwd: /tmp/autopkgtest.ZuL7Da/build.chY/src/
Complete output (5 lines):
Traceback (most recent call last):
File "", line 1, in
File "/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py", line 49, in
__version__ = str(Changelog(infp).get_version())
AttributeError: 'Changelog' object has no attribute 'get_version'
ERROR: Command errored out with exit status 1: python setup.py egg_info Check
the logs for full command output.
=== log end
The issue reproducible in local KVM-autopkgtest against hirsute-proposed and
hirsute-release for me (I mistyped before).
Example:
sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries
--apt-upgrade --apt-pocket=proposed --shell-fail
ubuntu-image_1.10+20.10ubuntu2.dsc --testname=qa -- qemu --qemu-options='-cpu
host' --ram-size=1536 --cpus 2 ~/work/autopkgtest-hirsute-amd64.img
In terms of similar bug signatures I found
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973227
Fixed by:
https://gitlab.kitware.com/debian/dh-cmake/-/commit/3337c8e0e9ebd109490d3c40f0bd5c1e367bedc8
Looking for the same issue in ubuntu-image has shown an entry in setup.py
setup.py:49:__version__ = str(Changelog(infp).get_version())
And now that we know all that we see
https://launchpad.net/ubuntu/+source/python-debian/+publishinghistory
New version in since
2020-11-20 02:23:27 CET
That is a perfect match to our bug.
$ diff -Naur python-debian-0.1.3[78]/lib/debian/changelog.py
...
-def get_version(self):
-# type: () -> Version
+def _get_version(self):
+# type: () -> Optional[Version]
"""Return a Version object for the last version"""
-return self._blocks[0].version
+return self._blocks[0].version # type: ignore
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-debian/+bug/1905735/+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 1905735] Re: ubuntu-image autopkgtests failing since pytohn-debian 0.1.38
PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4353/
...
killing the rest as I've seen seb128 to do the same ...
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-debian in Ubuntu.
https://bugs.launchpad.net/bugs/1905735
Title:
ubuntu-image autopkgtests failing since python-debian 0.1.38
Status in python-debian package in Ubuntu:
Triaged
Status in ubuntu-image package in Ubuntu:
Fix Committed
Status in python-debian package in Debian:
Unknown
Bug description:
In the tests it seems that since some - yet to be found - change ~20th
Nov the tests of ubuntu-image fail.
Tests all list those three sub-tests as failing:
unittests.sh FAIL non-zero exit status 1
qa FAIL non-zero exit status 1
coverage.sh FAIL non-zero exit status 1
Fails all seem to be related to some python/pytest/py* change that
might have slipped in without gating on this test.
Ubuntu-image itself also isn't new - still the same as in groovy
ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all
== log start
===
Obtaining file:///tmp/autopkgtest.ZuL7Da/build.chY/src
ERROR: Command errored out with exit status 1:
command:
/tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python -c 'import
sys, setuptools, tokenize; sys.argv[0] =
'"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';
__file__='"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';f=getattr(tokenize,
'"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"',
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info
--egg-base /tmp/pip-pip-egg-info-yaplrymq
cwd: /tmp/autopkgtest.ZuL7Da/build.chY/src/
Complete output (5 lines):
Traceback (most recent call last):
File "", line 1, in
File "/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py", line 49, in
__version__ = str(Changelog(infp).get_version())
AttributeError: 'Changelog' object has no attribute 'get_version'
ERROR: Command errored out with exit status 1: python setup.py egg_info Check
the logs for full command output.
=== log end
The issue reproducible in local KVM-autopkgtest against hirsute-proposed and
hirsute-release for me (I mistyped before).
Example:
sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries
--apt-upgrade --apt-pocket=proposed --shell-fail
ubuntu-image_1.10+20.10ubuntu2.dsc --testname=qa -- qemu --qemu-options='-cpu
host' --ram-size=1536 --cpus 2 ~/work/autopkgtest-hirsute-amd64.img
In terms of similar bug signatures I found
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973227
Fixed by:
https://gitlab.kitware.com/debian/dh-cmake/-/commit/3337c8e0e9ebd109490d3c40f0bd5c1e367bedc8
Looking for the same issue in ubuntu-image has shown an entry in setup.py
setup.py:49:__version__ = str(Changelog(infp).get_version())
And now that we know all that we see
https://launchpad.net/ubuntu/+source/python-debian/+publishinghistory
New version in since
2020-11-20 02:23:27 CET
That is a perfect match to our bug.
$ diff -Naur python-debian-0.1.3[78]/lib/debian/changelog.py
...
-def get_version(self):
-# type: () -> Version
+def _get_version(self):
+# type: () -> Optional[Version]
"""Return a Version object for the last version"""
-return self._blocks[0].version
+return self._blocks[0].version # type: ignore
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-debian/+bug/1905735/+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 1905735] Re: ubuntu-image autopkgtests failing since pytohn-debian 0.1.38
** Description changed:
In the tests it seems that since some - yet to be found - change ~20th
Nov the tests of ubuntu-image fail.
Tests all list those three sub-tests as failing:
- unittests.sh FAIL non-zero exit status 1
- qa FAIL non-zero exit status 1
- coverage.sh FAIL non-zero exit status 1
+ unittests.sh FAIL non-zero exit status 1
+ qa FAIL non-zero exit status 1
+ coverage.sh FAIL non-zero exit status 1
Fails all seem to be related to some python/pytest/py* change that might
have slipped in without gating on this test.
Ubuntu-image itself also isn't new - still the same as in groovy
- ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
- ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all
-
+ ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
+ ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all
== log start
===
Obtaining file:///tmp/autopkgtest.ZuL7Da/build.chY/src
- ERROR: Command errored out with exit status 1:
- command:
/tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python -c 'import
sys, setuptools, tokenize; sys.argv[0] =
'"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';
__file__='"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';f=getattr(tokenize,
'"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"',
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info
--egg-base /tmp/pip-pip-egg-info-yaplrymq
- cwd: /tmp/autopkgtest.ZuL7Da/build.chY/src/
- Complete output (5 lines):
- Traceback (most recent call last):
- File "", line 1, in
- File "/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py", line 49, in
- __version__ = str(Changelog(infp).get_version())
- AttributeError: 'Changelog' object has no attribute 'get_version'
-
+ ERROR: Command errored out with exit status 1:
+ command:
/tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python -c 'import
sys, setuptools, tokenize; sys.argv[0] =
'"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';
__file__='"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';f=getattr(tokenize,
'"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"',
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info
--egg-base /tmp/pip-pip-egg-info-yaplrymq
+ cwd: /tmp/autopkgtest.ZuL7Da/build.chY/src/
+ Complete output (5 lines):
+ Traceback (most recent call last):
+ File "", line 1, in
+ File "/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py", line 49, in
+ __version__ = str(Changelog(infp).get_version())
+ AttributeError: 'Changelog' object has no attribute 'get_version'
+
ERROR: Command errored out with exit status 1: python setup.py egg_info Check
the logs for full command output.
=== log end
+ The issue reproducible in local KVM-autopkgtest against hirsute-proposed and
hirsute-release for me (I mistyped before).
+ Example:
+ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries
--apt-upgrade --apt-pocket=proposed --shell-fail
ubuntu-image_1.10+20.10ubuntu2.dsc --testname=qa -- qemu --qemu-options='-cpu
host' --ram-size=1536 --cpus 2 ~/work/autopkgtest-hirsute-amd64.img
- The issue not reproducible in local KVM-autopkgtest against hirsute-proposed
and hirsute-release for me atm. Which is odd, but could be due to whatever
python changes that are being all-in/all-out.
In terms of similar bug signatures I found
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973227
Fixed by:
https://gitlab.kitware.com/debian/dh-cmake/-/commit/3337c8e0e9ebd109490d3c40f0bd5c1e367bedc8
Looking for the same issue in ubuntu-image has shown an entry in setup.py
- setup.py:49:__version__ = str(Changelog(infp).get_version())
+ setup.py:49:__version__ = str(Changelog(infp).get_version())
And now that we know all that we see
https://launchpad.net/ubuntu/+source/python-debian/+publishinghistory
New version in since
2020-11-20 02:23:27 CET
That is a perfect match to our bug.
+
+
+ $ diff -Naur python-debian-0.1.3[78]/lib/debian/changelog.py
+ ...
+ -def get_version(self):
+ -# type: () -> Version
+ +def _get_version(self):
+ +# type: () -> Optional[Version]
+ """Return a Version object for the last version"""
+ -return self._blocks[0].version
+ +return self._blocks[0].version # type: ignore
+ ...
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-debian in Ubuntu.
[Touch-packages] [Bug 1905735] [NEW] ubuntu-image autopkgtests failing since pytohn-debian 0.1.38
Public bug reported:
In the tests it seems that since some - yet to be found - change ~20th
Nov the tests of ubuntu-image fail.
Tests all list those three sub-tests as failing:
unittests.sh FAIL non-zero exit status 1
qa FAIL non-zero exit status 1
coverage.sh FAIL non-zero exit status 1
Fails all seem to be related to some python/pytest/py* change that might
have slipped in without gating on this test.
Ubuntu-image itself also isn't new - still the same as in groovy
ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all
== log start ===
Obtaining file:///tmp/autopkgtest.ZuL7Da/build.chY/src
ERROR: Command errored out with exit status 1:
command: /tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python
-c 'import sys, setuptools, tokenize; sys.argv[0] =
'"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';
__file__='"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';f=getattr(tokenize,
'"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"',
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info
--egg-base /tmp/pip-pip-egg-info-yaplrymq
cwd: /tmp/autopkgtest.ZuL7Da/build.chY/src/
Complete output (5 lines):
Traceback (most recent call last):
File "", line 1, in
File "/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py", line 49, in
__version__ = str(Changelog(infp).get_version())
AttributeError: 'Changelog' object has no attribute 'get_version'
ERROR: Command errored out with exit status 1: python setup.py egg_info Check
the logs for full command output.
=== log end
The issue reproducible in local KVM-autopkgtest against hirsute-proposed and
hirsute-release for me (I mistyped before).
Example:
sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries
--apt-upgrade --apt-pocket=proposed --shell-fail
ubuntu-image_1.10+20.10ubuntu2.dsc --testname=qa -- qemu --qemu-options='-cpu
host' --ram-size=1536 --cpus 2 ~/work/autopkgtest-hirsute-amd64.img
In terms of similar bug signatures I found
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973227
Fixed by:
https://gitlab.kitware.com/debian/dh-cmake/-/commit/3337c8e0e9ebd109490d3c40f0bd5c1e367bedc8
Looking for the same issue in ubuntu-image has shown an entry in setup.py
setup.py:49:__version__ = str(Changelog(infp).get_version())
And now that we know all that we see
https://launchpad.net/ubuntu/+source/python-debian/+publishinghistory
New version in since
2020-11-20 02:23:27 CET
That is a perfect match to our bug.
$ diff -Naur python-debian-0.1.3[78]/lib/debian/changelog.py
...
-def get_version(self):
-# type: () -> Version
+def _get_version(self):
+# type: () -> Optional[Version]
"""Return a Version object for the last version"""
-return self._blocks[0].version
+return self._blocks[0].version # type: ignore
...
** Affects: python-debian (Ubuntu)
Importance: Undecided
Status: New
** Affects: ubuntu-image (Ubuntu)
Importance: Undecided
Status: New
** Tags: update-excuse
** Tags added: update-excuse
** Also affects: python-debian (Ubuntu)
Importance: Undecided
Status: New
** Summary changed:
- autopkgtests failing since 20th Nov
+ ubuntu-image autopkgtests failing since pytohn-debian 0.1.38
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-debian in Ubuntu.
https://bugs.launchpad.net/bugs/1905735
Title:
ubuntu-image autopkgtests failing since pytohn-debian 0.1.38
Status in python-debian package in Ubuntu:
New
Status in ubuntu-image package in Ubuntu:
New
Bug description:
In the tests it seems that since some - yet to be found - change ~20th
Nov the tests of ubuntu-image fail.
Tests all list those three sub-tests as failing:
unittests.sh FAIL non-zero exit status 1
qa FAIL non-zero exit status 1
coverage.sh FAIL non-zero exit status 1
Fails all seem to be related to some python/pytest/py* change that
might have slipped in without gating on this test.
Ubuntu-image itself also isn't new - still the same as in groovy
ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all
== log start
===
Obtaining file:///tmp/autopkgtest.ZuL7Da/build.chY/src
ERROR: Command errored out with exit status 1:
command:
/tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python -c 'import
sys, setuptools, tokenize; sys.argv[0] =
[Touch-packages] [Bug 1904811] Re: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status
Thank you for taking the time to report this bug and helping to make Ubuntu better. On upgrading a service this service has to be restarted to pick up the fixes. Rather rarely a real issue occurs that the newer version does e.g. fail with the formerly working configuration. But most of the time what happens is, that a service was installed, but stays unconfigured or experimented with but left in a broken state. Now on any update of the related packages that service has to be restarted, but since its config is incomplete/faulty it fails to restart. Therefore the update of that package has to consider itself incomplete. Depending on your particular case there are two solutions: - either remove the offending package if you don't want to continue using it. - Or if you do want to keep it please fix the configuration so that re-starting the service will work. Since it seems likely to me that this is a local configuration problem, rather than a bug in Ubuntu, I'm marking this bug as Incomplete. If indeed this is a local configuration problem, you can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community Or if you believe that this is really a bug, then you may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to New. ** Changed in: openssh (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1904811 Title: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 Status in openssh package in Ubuntu: Incomplete Bug description: ? ProblemType: Package DistroRelease: Ubuntu 20.04 Package: openssh-server 1:8.2p1-4ubuntu0.1 ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65 Uname: Linux 5.4.0-54-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.12 AptOrdering: openssh-sftp-server:amd64: Install openssh-server:amd64: Install ssh-import-id:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Nov 18 19:09:53 2020 ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2020-11-11 (7 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.1 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: /etc/ssh/sshd_config line 35: missing argument. SourcePackage: openssh Title: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: installed openssh-server package post-installation script subprocess 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/openssh/+bug/1904811/+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 1904811] Re: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status
Hi, from your log SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: /etc/ssh/sshd_config line 35: missing argument. That means you (or a program) have modified /etc/ssh/sshd_config and due to that the update (which needs to restart the server) fails. You can restore the file to its default [1] or fixup that issue in the config file manually. Then things should work again. If you are convinced this indeed is a bug in the package we'd need to see that config file what exactly is at that line 35. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1904811 Title: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 Status in openssh package in Ubuntu: Incomplete Bug description: ? ProblemType: Package DistroRelease: Ubuntu 20.04 Package: openssh-server 1:8.2p1-4ubuntu0.1 ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65 Uname: Linux 5.4.0-54-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.12 AptOrdering: openssh-sftp-server:amd64: Install openssh-server:amd64: Install ssh-import-id:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Nov 18 19:09:53 2020 ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2020-11-11 (7 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.1 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: /etc/ssh/sshd_config line 35: missing argument. SourcePackage: openssh Title: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: installed openssh-server package post-installation script subprocess 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/openssh/+bug/1904811/+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 1904192] Re: ebtables can not rename just created chain
** Bug watch added: Debian Bug tracker #975028 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975028 ** Also affects: iptables (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975028 Importance: Unknown Status: Unknown ** Changed in: iptables (Ubuntu Groovy) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1904192 Title: ebtables can not rename just created chain Status in iptables: Unknown Status in iptables package in Ubuntu: Confirmed Status in iptables source package in Groovy: In Progress Status in iptables package in Debian: Unknown Status in iptables package in Fedora: Confirmed Bug description: [SRU] * Changes that went into 1.8.5 ave broken the errno handling. In particular loading extensions. Due to that it has become impossible to rename rules. * Upstream has created a fix and this backports that change to Ubuntu => http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247 [Test Case] * # ebtables -t nat -N foo # ebtables -t nat -E foo bar ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists * with the fix the above command sequence works [Where problems could occur] * The change moved code from nft_chain_user_rename to do_commandeb and therefore in theory any ebtables/xtables subcommand could be affected. Yet what it does is just resetting the error code in a better place, so while it "could" affect every subcommand it should (tm) not do so. [Other Info] * n/a --- Hi, I have an issue with ebtables that affects libvirt. While initially found in hirsute I had to realize this is broken in Groovy and even Bionic (might be a different reason back then) as well right now. But working in Focal (witch matches my memory of it being good before [1]). I was isolating the commands that libvirt runs (identical between Focal and Hirsute) to find a simplified trigger. Gladly I found one that leaves libvirt and other components out of the equation. The following works on focal, but fails on the other releases. Note: I checked which tool is in use and in both cases it is xtables-nft-multi. /usr/sbin/ebtables -> /etc/alternatives/ebtables* /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft* /usr/sbin/ebtables-nft -> xtables-nft-multi* So I converted the libvirt issued commands into xtables-nft-multi just to be sure in case a system to compare has other alternatives set. Focal (Good): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed Groovy/Hirsute (Fail): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists Try `ebtables -h' or 'ebtables --help' for more information. What might be the root cause for this? -- Old test instructions -- As I said I was tracking a fail in libvirt so the test instructions initially were around that: # the following us done as 2nd level guest (to not mess with the host, # but works on bare metal jst as much) uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 --password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily # On guest then sudo apt update sudo apt install uvtool uvtool-libvirt uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu hirsute-2nd-lvm release=hirsute arch=amd64 label=daily uvt-kvm wait hirsute-2nd-lvm virsh shutdown hirsute-2nd-lvm virsh edit hirsute-2nd-lvm # add this to the network virsh start hirsute-2nd-lvm error: Failed to start domain hirsute-2nd-nwfilter error: internal error: applyDHCPOnlyRules failed - spoofing not protected! FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf log_filters="1:util.firewall" log_outputs="1:syslog:libvirtd" -- -- [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037 To manage notifications about this bug go to: https://bugs.launchpad.net/iptables/+bug/1904192/+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 1904192] Re: ebtables can not rename just created chain
The issue was confirmed and a fix now committed to the upstream repository. => http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247 @Alex will you (as usual) do the upload of that - will eventually be Groovy and Hirsute that needs this. ** Also affects: iptables (Ubuntu Groovy) Importance: Undecided Status: New ** Description changed: + [SRU] + + * Changes that went into 1.8.5 ave broken the errno handling. +In particular loading extensions. Due to that it has become +impossible to rename rules. + + * Upstream has created a fix and this backports that change to +Ubuntu +=> http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247 + + [Test Case] + + * # ebtables -t nat -N foo +# ebtables -t nat -E foo bar +ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists + + * with the fix the above command sequence works + + [Where problems could occur] + + * The change moved code from nft_chain_user_rename to do_commandeb and +therefore in theory any ebtables/xtables subcommand could be affected. +Yet what it does is just resetting the error code in a better place, so +while it "could" affect every subcommand it should (tm) not do so. + + + [Other Info] + + * n/a + + + --- + Hi, I have an issue with ebtables that affects libvirt. While initially found in hirsute I had to realize this is broken in Groovy and even Bionic (might be a different reason back then) as well right now. But working in Focal (witch matches my memory of it being good before [1]). I was isolating the commands that libvirt runs (identical between Focal and Hirsute) to find a simplified trigger. Gladly I found one that leaves libvirt and other components out of the equation. The following works on focal, but fails on the other releases. Note: I checked which tool is in use and in both cases it is xtables-nft-multi. /usr/sbin/ebtables -> /etc/alternatives/ebtables* /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft* /usr/sbin/ebtables-nft -> xtables-nft-multi* So I converted the libvirt issued commands into xtables-nft-multi just to be sure in case a system to compare has other alternatives set. Focal (Good): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed Groovy/Hirsute (Fail): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists Try `ebtables -h' or 'ebtables --help' for more information. What might be the root cause for this? - -- Old test instructions -- As I said I was tracking a fail in libvirt so the test instructions initially were around that: - # the following us done as 2nd level guest (to not mess with the host, # but works on bare metal jst as much) uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 --password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily # On guest then sudo apt update sudo apt install uvtool uvtool-libvirt uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu hirsute-2nd-lvm release=hirsute arch=amd64 label=daily uvt-kvm wait hirsute-2nd-lvm virsh shutdown hirsute-2nd-lvm virsh edit hirsute-2nd-lvm # add this to the network - - - + + + virsh start hirsute-2nd-lvm - error: Failed to start domain hirsute-2nd-nwfilter - error: internal error: applyDHCPOnlyRules failed - spoofing not protected! + error: Failed to start domain hirsute-2nd-nwfilter + error: internal error: applyDHCPOnlyRules failed - spoofing not protected! FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf log_filters="1:util.firewall" log_outputs="1:syslog:libvirtd" -- -- [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1904192 Title: ebtables can not rename just created chain Status in iptables: Unknown Status in iptables package in Ubuntu: Confirmed Status in iptables source package in Groovy: New Status in iptables package in Fedora: Confirmed Bug description: [SRU] * Changes that went into 1.8.5 ave broken the errno handling. In particular loading extensions. Due to that it has become impossible to rename rules. * Upstream has created a fix and this backports that change to Ubuntu =>
[Touch-packages] [Bug 1903484] Re: package python-six 1.14.0-2 failed to install/upgrade: installed python-six package post-installation script subprocess returned error exit status 127
>From your log: /var/lib/dpkg/info/python-six.postinst: 6: pycompile: not found The missing binary pycompile is of pkg:python2 And python-six in Focal has: Depends: python2:any (<< 2.8), python2:any (>= 2.7~) According to your log you should have python2-minimal:amd64 2.7.17-2ubuntu4 Which provides the missing binary. So everything should work, but it didn't. Could you check the following things on your system: # which pycompile /usr/bin/pycompile # dpkg --verify python2 # dpkg -S pycompile ... python2-minimal: /usr/bin/pycompile # ll /usr/bin/pycompile -rwxr-xr-x 1 root root 11895 Mar 13 2020 /usr/bin/pycompile* If your output is different that might be an indicator what is wrong. But with the logs so far I fail to see the root cause. ** Changed in: six (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to six in Ubuntu. https://bugs.launchpad.net/bugs/1903484 Title: package python-six 1.14.0-2 failed to install/upgrade: installed python-six package post-installation script subprocess returned error exit status 127 Status in six package in Ubuntu: Incomplete Bug description: Plz fix this bug ProblemType: Package DistroRelease: Ubuntu 20.04 Package: python-six 1.14.0-2 ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65 Uname: Linux 5.4.0-52-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.11 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 5 21:00:52 2020 Dependencies: DuplicateSignature: package:python-six:1.14.0-2 Setting up python-six (1.14.0-2) ... /var/lib/dpkg/info/python-six.postinst: 6: pycompile: not found dpkg: error processing package python-six (--configure): installed python-six package post-installation script subprocess returned error exit status 127 ErrorMessage: installed python-six package post-installation script subprocess returned error exit status 127 InstallationDate: Installed on 2020-10-22 (17 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.1 SourcePackage: six Title: package python-six 1.14.0-2 failed to install/upgrade: installed python-six package post-installation script subprocess returned error exit status 127 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/six/+bug/1903484/+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 1903484] Re: package python-six 1.14.0-2 failed to install/upgrade: installed python-six package post-installation script subprocess returned error exit status 127
Forgot, also: dpkg --verify python2-minimal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to six in Ubuntu. https://bugs.launchpad.net/bugs/1903484 Title: package python-six 1.14.0-2 failed to install/upgrade: installed python-six package post-installation script subprocess returned error exit status 127 Status in six package in Ubuntu: Incomplete Bug description: Plz fix this bug ProblemType: Package DistroRelease: Ubuntu 20.04 Package: python-six 1.14.0-2 ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65 Uname: Linux 5.4.0-52-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.11 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Nov 5 21:00:52 2020 Dependencies: DuplicateSignature: package:python-six:1.14.0-2 Setting up python-six (1.14.0-2) ... /var/lib/dpkg/info/python-six.postinst: 6: pycompile: not found dpkg: error processing package python-six (--configure): installed python-six package post-installation script subprocess returned error exit status 127 ErrorMessage: installed python-six package post-installation script subprocess returned error exit status 127 InstallationDate: Installed on 2020-10-22 (17 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.1 SourcePackage: six Title: package python-six 1.14.0-2 failed to install/upgrade: installed python-six package post-installation script subprocess returned error exit status 127 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/six/+bug/1903484/+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 1904192] Re: ebtables can not rename just created chain
** Bug watch added: Red Hat Bugzilla #1898130 https://bugzilla.redhat.com/show_bug.cgi?id=1898130 ** Also affects: iptables (Fedora) via https://bugzilla.redhat.com/show_bug.cgi?id=1898130 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1904192 Title: ebtables can not rename just created chain Status in iptables: Unknown Status in iptables package in Ubuntu: Confirmed Status in iptables package in Fedora: Unknown Bug description: Hi, I have an issue with ebtables that affects libvirt. While initially found in hirsute I had to realize this is broken in Groovy and even Bionic (might be a different reason back then) as well right now. But working in Focal (witch matches my memory of it being good before [1]). I was isolating the commands that libvirt runs (identical between Focal and Hirsute) to find a simplified trigger. Gladly I found one that leaves libvirt and other components out of the equation. The following works on focal, but fails on the other releases. Note: I checked which tool is in use and in both cases it is xtables-nft-multi. /usr/sbin/ebtables -> /etc/alternatives/ebtables* /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft* /usr/sbin/ebtables-nft -> xtables-nft-multi* So I converted the libvirt issued commands into xtables-nft-multi just to be sure in case a system to compare has other alternatives set. Focal (Good): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed Groovy/Hirsute (Fail): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists Try `ebtables -h' or 'ebtables --help' for more information. What might be the root cause for this? -- Old test instructions -- As I said I was tracking a fail in libvirt so the test instructions initially were around that: # the following us done as 2nd level guest (to not mess with the host, # but works on bare metal jst as much) uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 --password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily # On guest then sudo apt update sudo apt install uvtool uvtool-libvirt uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu hirsute-2nd-lvm release=hirsute arch=amd64 label=daily uvt-kvm wait hirsute-2nd-lvm virsh shutdown hirsute-2nd-lvm virsh edit hirsute-2nd-lvm # add this to the network virsh start hirsute-2nd-lvm error: Failed to start domain hirsute-2nd-nwfilter error: internal error: applyDHCPOnlyRules failed - spoofing not protected! FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf log_filters="1:util.firewall" log_outputs="1:syslog:libvirtd" -- -- [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037 To manage notifications about this bug go to: https://bugs.launchpad.net/iptables/+bug/1904192/+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 1904192] Re: ebtables can not rename just created chain
FYI: via the libvirt discussion it was reported that - legacy 2.0.11 works on fedora (for us as well on Ubuntu) - 1.8.4 works on RHEL8 (we have 1.8.5 that fails) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1904192 Title: ebtables can not rename just created chain Status in iptables: Unknown Status in iptables package in Ubuntu: Confirmed Bug description: Hi, I have an issue with ebtables that affects libvirt. While initially found in hirsute I had to realize this is broken in Groovy and even Bionic (might be a different reason back then) as well right now. But working in Focal (witch matches my memory of it being good before [1]). I was isolating the commands that libvirt runs (identical between Focal and Hirsute) to find a simplified trigger. Gladly I found one that leaves libvirt and other components out of the equation. The following works on focal, but fails on the other releases. Note: I checked which tool is in use and in both cases it is xtables-nft-multi. /usr/sbin/ebtables -> /etc/alternatives/ebtables* /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft* /usr/sbin/ebtables-nft -> xtables-nft-multi* So I converted the libvirt issued commands into xtables-nft-multi just to be sure in case a system to compare has other alternatives set. Focal (Good): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed Groovy/Hirsute (Fail): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists Try `ebtables -h' or 'ebtables --help' for more information. What might be the root cause for this? -- Old test instructions -- As I said I was tracking a fail in libvirt so the test instructions initially were around that: # the following us done as 2nd level guest (to not mess with the host, # but works on bare metal jst as much) uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 --password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily # On guest then sudo apt update sudo apt install uvtool uvtool-libvirt uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu hirsute-2nd-lvm release=hirsute arch=amd64 label=daily uvt-kvm wait hirsute-2nd-lvm virsh shutdown hirsute-2nd-lvm virsh edit hirsute-2nd-lvm # add this to the network virsh start hirsute-2nd-lvm error: Failed to start domain hirsute-2nd-nwfilter error: internal error: applyDHCPOnlyRules failed - spoofing not protected! FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf log_filters="1:util.firewall" log_outputs="1:syslog:libvirtd" -- -- [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037 To manage notifications about this bug go to: https://bugs.launchpad.net/iptables/+bug/1904192/+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 1904192] Re: ebtables can not rename just created chain
FYI Since I started on this with libvirt and the libvirt people were helpful as always in debugging this I also pinged the ML since this issue should affect libvirt in any place where it runs with the new ebtables. https://www.redhat.com/archives/libvir-list/2020-November/msg00790.html @Oibaf - thanks for reporting this upstream. Does it affect you in another use-case/context than libvirt? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1904192 Title: ebtables can not rename just created chain Status in iptables: Unknown Status in iptables package in Ubuntu: Confirmed Bug description: Hi, I have an issue with ebtables that affects libvirt. While initially found in hirsute I had to realize this is broken in Groovy and even Bionic (might be a different reason back then) as well right now. But working in Focal (witch matches my memory of it being good before [1]). I was isolating the commands that libvirt runs (identical between Focal and Hirsute) to find a simplified trigger. Gladly I found one that leaves libvirt and other components out of the equation. The following works on focal, but fails on the other releases. Note: I checked which tool is in use and in both cases it is xtables-nft-multi. /usr/sbin/ebtables -> /etc/alternatives/ebtables* /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft* /usr/sbin/ebtables-nft -> xtables-nft-multi* So I converted the libvirt issued commands into xtables-nft-multi just to be sure in case a system to compare has other alternatives set. Focal (Good): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed Groovy/Hirsute (Fail): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists Try `ebtables -h' or 'ebtables --help' for more information. What might be the root cause for this? -- Old test instructions -- As I said I was tracking a fail in libvirt so the test instructions initially were around that: # the following us done as 2nd level guest (to not mess with the host, # but works on bare metal jst as much) uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 --password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily # On guest then sudo apt update sudo apt install uvtool uvtool-libvirt uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu hirsute-2nd-lvm release=hirsute arch=amd64 label=daily uvt-kvm wait hirsute-2nd-lvm virsh shutdown hirsute-2nd-lvm virsh edit hirsute-2nd-lvm # add this to the network virsh start hirsute-2nd-lvm error: Failed to start domain hirsute-2nd-nwfilter error: internal error: applyDHCPOnlyRules failed - spoofing not protected! FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf log_filters="1:util.firewall" log_outputs="1:syslog:libvirtd" -- -- [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037 To manage notifications about this bug go to: https://bugs.launchpad.net/iptables/+bug/1904192/+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 1904192] [NEW] ebtables can not rename just created chain
Public bug reported: Hi, I have an issue with ebtables that affects libvirt. While initially found in hirsute I had to realize this is broken in Groovy and even Bionic (might be a different reason back then) as well right now. But working in Focal (witch matches my memory of it being good before [1]). I was isolating the commands that libvirt runs (identical between Focal and Hirsute) to find a simplified trigger. Gladly I found one that leaves libvirt and other components out of the equation. The following works on focal, but fails on the other releases. Note: I checked which tool is in use and in both cases it is xtables-nft-multi. /usr/sbin/ebtables -> /etc/alternatives/ebtables* /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft* /usr/sbin/ebtables-nft -> xtables-nft-multi* So I converted the libvirt issued commands into xtables-nft-multi just to be sure in case a system to compare has other alternatives set. Focal (Good): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed Groovy/Hirsute (Fail): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists Try `ebtables -h' or 'ebtables --help' for more information. What might be the root cause for this? -- Old test instructions -- As I said I was tracking a fail in libvirt so the test instructions initially were around that: # the following us done as 2nd level guest (to not mess with the host, # but works on bare metal jst as much) uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 --password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily # On guest then sudo apt update sudo apt install uvtool uvtool-libvirt uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu hirsute-2nd-lvm release=hirsute arch=amd64 label=daily uvt-kvm wait hirsute-2nd-lvm virsh shutdown hirsute-2nd-lvm virsh edit hirsute-2nd-lvm # add this to the network virsh start hirsute-2nd-lvm error: Failed to start domain hirsute-2nd-nwfilter error: internal error: applyDHCPOnlyRules failed - spoofing not protected! FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf log_filters="1:util.firewall" log_outputs="1:syslog:libvirtd" -- -- [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037 ** Affects: iptables (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1904192 Title: ebtables can not rename just created chain Status in iptables package in Ubuntu: New Bug description: Hi, I have an issue with ebtables that affects libvirt. While initially found in hirsute I had to realize this is broken in Groovy and even Bionic (might be a different reason back then) as well right now. But working in Focal (witch matches my memory of it being good before [1]). I was isolating the commands that libvirt runs (identical between Focal and Hirsute) to find a simplified trigger. Gladly I found one that leaves libvirt and other components out of the equation. The following works on focal, but fails on the other releases. Note: I checked which tool is in use and in both cases it is xtables-nft-multi. /usr/sbin/ebtables -> /etc/alternatives/ebtables* /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft* /usr/sbin/ebtables-nft -> xtables-nft-multi* So I converted the libvirt issued commands into xtables-nft-multi just to be sure in case a system to compare has other alternatives set. Focal (Good): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed Groovy/Hirsute (Fail): /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3 /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 testrule3-renamed ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists Try `ebtables -h' or 'ebtables --help' for more information. What might be the root cause for this? -- Old test instructions -- As I said I was tracking a fail in libvirt so the test instructions initially were around that: # the following us done as 2nd level guest (to not mess with the host, # but works on bare metal jst as much) uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 --password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily # On guest then sudo apt update sudo apt install uvtool uvtool-libvirt
[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository
Fixed by https://launchpad.net/ubuntu/+source/python-apt/2.1.3ubuntu3 migrating after some work on dependencies. Note cloud and lxd images do not yet contain this, so you'll need to update before add-apt-repository or wait another day or two. Thanks everyone. ** Changed in: python-apt (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1902540 Title: hirsute fails on add-apt-repository Status in python-apt package in Ubuntu: Fix Released Status in software-properties package in Ubuntu: Invalid Bug description: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+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 1902540] Re: hirsute fails on add-apt-repository
FYI - Until this migrated into groovy the quick-fix with the attached diff is: $ wget -q https://launchpadlibrarian.net/505009270/fix-hirsute-python-apt.diff -O - | sudo patch -p1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1902540 Title: hirsute fails on add-apt-repository Status in python-apt package in Ubuntu: Triaged Status in software-properties package in Ubuntu: Invalid Bug description: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+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 1902540] Re: hirsute fails on add-apt-repository
** Changed in: python-apt (Ubuntu) Assignee: Steve Langasek (vorlon) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1902540 Title: hirsute fails on add-apt-repository Status in python-apt package in Ubuntu: Triaged Status in software-properties package in Ubuntu: Invalid Bug description: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+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 1902540] Re: hirsute fails on add-apt-repository
Ok, I see that there is an upload for it that would fix this in 1 python-apt (2.1.3ubuntu3) hirsute; urgency=medium 2 3 * Add hirsute to the Ubuntu template. 4 5 -- Steve Langasek Mon, 26 Oct 2020 16:28:01 -0700 But it is stuck in excuses breaking apt-clone and sshuttle autopkgtests. Since Steve (thanks) prepped that upload I'll subscribe him so he can close the bug once python-apt moves. ** Changed in: python-apt (Ubuntu) Status: Confirmed => Triaged ** Changed in: python-apt (Ubuntu) Assignee: (unassigned) => Steve Langasek (vorlon) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1902540 Title: hirsute fails on add-apt-repository Status in python-apt package in Ubuntu: Triaged Status in software-properties package in Ubuntu: Invalid Bug description: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+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 1902540] Re: hirsute fails on add-apt-repository
Ok, checking the recent tests it seems that vorlon and juliank are on it already. So I can hold back (to not make things more confusing) and let them handle it. The attachment here in comment #6 can serve as a workaround until resolved. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1902540 Title: hirsute fails on add-apt-repository Status in python-apt package in Ubuntu: Triaged Status in software-properties package in Ubuntu: Invalid Bug description: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+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 1902540] Re: hirsute fails on add-apt-repository
It seems that data is parsed from /usr/share/python-apt/templates/Ubuntu.info class SourcesList(object): """ represents the full sources.list + sources.list.d file """ def __init__(self, withMatcher=True, matcherPath="/usr/share/python-apt/templates/"): Which also is part of Source: python-apt I added hirsute manually there (as attached) and things started working. ** Patch added: "add hirsute to python-apt /usr/share/python-apt/templates/Ubuntu.info" https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+attachment/5430564/+files/fix-hirsute-python-apt.diff ** Changed in: python-apt (Ubuntu) Status: New => Confirmed ** Changed in: software-properties (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1902540 Title: hirsute fails on add-apt-repository Status in python-apt package in Ubuntu: Triaged Status in software-properties package in Ubuntu: Invalid Bug description: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+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 1902540] Re: hirsute fails on add-apt-repository
Yeah still present for me as well in a new hirsute container of today :-/ Thanks for double checking as Bryce/Sergio as that is excluding a lot of caching/net-setup/... questions. >From the debugging I know that the self-detect is right self.codename == hirsute But the list in self.sourceslist.matcher.templates does not contain a hirsute. That comes from /usr/lib/python3/dist-packages/aptsources/sourceslist.py from src:python-apt. Maybe the bug is over there and adding a task for that can help to trigger the right people (or there maybe is even a bug open already). ** Also affects: python-apt (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/1902540 Title: hirsute fails on add-apt-repository Status in python-apt package in Ubuntu: New Status in software-properties package in Ubuntu: Confirmed Bug description: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+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 1902540] Re: hirsute fails on add-apt-repository
Throwing a debug in the failing code:
# find the distro template
for template in self.sourceslist.matcher.templates:
print("Try '%s': self.is_codename(template.name) '%s' && self.id >>
'%s' == '%s' << template.distribution" % (template.name,
self.is_codename(template.name), self.id, template.distribution))
if (self.is_codename(template.name) and
template.distribution == self.id):
print("yeah! found a template")
self.source_template = template
break
if self.source_template is None:
raise NoDistroTemplateException(
"Error: could not find a distribution template for %s/%s" %
(self.id, self.codename))
Gives me:
Try 'bullseye': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu'
== 'Debian' << template.distribution
Try 'bullseye/updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'bullseye-updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'bullseye-proposed-updates': self.is_codename(template.name) 'False' &&
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'buster': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' ==
'Debian' << template.distribution
Try 'buster/updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'buster-updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'buster-proposed-updates': self.is_codename(template.name) 'False' &&
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'stretch': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu'
== 'Debian' << template.distribution
Try 'stretch/updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'stretch-updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'stretch-proposed-updates': self.is_codename(template.name) 'False' &&
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'jessie': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' ==
'Debian' << template.distribution
Try 'jessie/updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'jessie-updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'jessie-proposed-updates': self.is_codename(template.name) 'False' &&
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'wheezy': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' ==
'Debian' << template.distribution
Try 'wheezy/updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'wheezy-updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'wheezy-proposed-updates': self.is_codename(template.name) 'False' &&
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'squeeze': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu'
== 'Debian' << template.distribution
Try 'squeeze-proposed-updates': self.is_codename(template.name) 'False' &&
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'squeeze/updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'lenny': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' ==
'Debian' << template.distribution
Try 'lenny-proposed-updates': self.is_codename(template.name) 'False' &&
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'lenny/updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'etch': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' ==
'Debian' << template.distribution
Try 'etch-proposed-updates': self.is_codename(template.name) 'False' && self.id
>> 'Ubuntu' == 'Debian' << template.distribution
Try 'etch/updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'sarge': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' ==
'Debian' << template.distribution
Try 'sarge-proposed-updates': self.is_codename(template.name) 'False' &&
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'sarge/updates': self.is_codename(template.name) 'False' && self.id >>
'Ubuntu' == 'Debian' << template.distribution
Try 'stable': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' ==
'Debian' << template.distribution
Try 'testing': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu'
== 'Debian' << template.distribution
Try 'sid':
[Touch-packages] [Bug 1902540] [NEW] hirsute fails on add-apt-repository
Public bug reported: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? ** 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/1902540 Title: hirsute fails on add-apt-repository Status in software-properties package in Ubuntu: New Bug description: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1902540/+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 1902135] Re: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: el subproceso instalado paquete openssh-server script post-installation devolvió el código de sa
Hi, thanks for the report but IMHO there is not much to do, port 22 is SSHs port and it is right to default to it. If your local configuration has port 22 bound to something else (Docker in your case) you need to adapt the configuration of either (ssh in its half installed state or your docker/images). There is not much the ssh (package) could do IMHO. So this looks like a local configuration problem, rather than a bug in Ubuntu. You can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community Since we use this bug tracker to track bugs in Ubuntu, rather than configuration problems, I'm marking this bug as Invalid. This helps us to focus on fixing bugs in Ubuntu. If you believe that this is really a bug, then you may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to New. ** Changed in: openssh (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1902135 Title: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: el subproceso instalado paquete openssh-server script post- installation devolvió el código de salida de error 1 Status in openssh package in Ubuntu: Incomplete Bug description: just following the installation guide https://community.home-assistant.io/t/installing-home-assistant-supervised-on-debian-10/200253 it crashed installing openssh-server, because docker already have the port 22 binded ProblemType: Package DistroRelease: Ubuntu 20.04 Package: openssh-server 1:8.2p1-4ubuntu0.1 ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65 Uname: Linux 5.4.0-52-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.10 AptOrdering: ncurses-term:amd64: Install openssh-sftp-server:amd64: Install openssh-server:amd64: Install ssh-import-id:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Oct 29 21:04:55 2020 ErrorMessage: el subproceso instalado paquete openssh-server script post-installation devolvió el código de salida de error 1 InstallationDate: Installed on 2020-10-29 (0 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.1 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: Missing privilege separation directory: /run/sshd SourcePackage: openssh Title: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: el subproceso instalado paquete openssh-server script post-installation devolvió el código de salida de error 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1902135/+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 1902109] Re: rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted
Awesome, thanks for updating the bug tasks and tracking bug already
Alkis!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1902109
Title:
rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted
Status in GLibC:
Unknown
Status in glibc package in Ubuntu:
New
Status in rsync package in Ubuntu:
Triaged
Bug description:
Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it
returned "no" before.
Steps to reproduce:
# Emulate /proc not being mounted
$ mount --bind / /mnt
$ chroot /mnt rsync -a /bin/ls .
rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not
supported (95)
rsync error: some files/attrs were not transferred (see previous errors)
(code 3) at main.c(1330) [sender=3.2.3]
I reported this issue upstream in
https://github.com/WayneD/rsync/issues/109 but the rsync developer
says it's a problem in libc, and it might well be.
Simple C code to reproduce the problem without rsync:
printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));
If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails
when /proc isn't mounted, yet it succeeds if it is mounted.
Python had a similar issue, and they ended up avoiding
AC_CHECK_FUNC(lchmod) under Linux:
https://bugs.python.org/issue34652
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140
```c
if test "$MACHDEP" != linux; then
AC_CHECK_FUNC(lchmod)
fi
```
So I'm not sure which package is causing the bug here. Should autoconf
return false? Should libc implement lchown without the bug? Or should
rsync skip lchmod under Linux, like python did?
To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/1902109/+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 1901295] Re: python3-chardet breaks install of python-chardet
Maintainers are free to remove python2 if there are no reverse dependencies left for the obvious unsupportability. This happened here in [1] to resolve [2] There also is no installation candidate left in a recent archive. Maybe replaces/breaks was a bit too much (as users like you could be happy to keep the old one around on an upgrade). But I'm unsure about the policy on such cleanups, maybe it was intentional to remove old no more supported bits. If you read the Debian bug I linked that makes sense. This isn't jsuta n Ubuntu/Debian decision, also all upstream archives/support for 2.x have ended. I'm unsure what to do here, asking you to get your application that depends on it upgraded? [1]: https://salsa.debian.org/python-team/packages/chardet/-/commit/5b4be98c3c408e1b73f94f8fb133bb7ceadec81f [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936289 ** Bug watch added: Debian Bug tracker #936289 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936289 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3-chardet in Ubuntu. https://bugs.launchpad.net/bugs/1901295 Title: python3-chardet breaks install of python-chardet Status in python3-chardet package in Ubuntu: Confirmed Bug description: I'm trying to install python-chardet (for python-2.7), but it fails because latest python3-chardet breaks python-chardet. I fail to understand why the python3 version of chardet would break the python2.7 version of the same module. PS: I know that python2.7 is not supported anymore, but I have an application that depends on it, and I need to install it, and that's now impossible because of this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3-chardet/+bug/1901295/+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 1901295] Re: python3-chardet breaks install of python-chardet
I can confirm the behavior ** Changed in: python3-chardet (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3-chardet in Ubuntu. https://bugs.launchpad.net/bugs/1901295 Title: python3-chardet breaks install of python-chardet Status in python3-chardet package in Ubuntu: Confirmed Bug description: I'm trying to install python-chardet (for python-2.7), but it fails because latest python3-chardet breaks python-chardet. I fail to understand why the python3 version of chardet would break the python2.7 version of the same module. PS: I know that python2.7 is not supported anymore, but I have an application that depends on it, and I need to install it, and that's now impossible because of this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3-chardet/+bug/1901295/+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 1899852] Re: Cannot assign requested address: AH00072: make_sock: could not bind to address
Thank you for taking the time to report this bug and helping to make Ubuntu better. Since it seems likely to me that this is a local configuration problem, rather than a bug in Ubuntu, I'm marking this bug as Incomplete. If indeed this is a local configuration problem, you can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community Or if you believe that this is really a bug, then you may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to 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/1899852 Title: Cannot assign requested address: AH00072: make_sock: could not bind to address Status in apache2 package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Bug description: Hello, Let's first list my configuration items: * apache2 2.4.29-1ubuntu4.14 * release: Ubuntu 18.04.5 LTS Upon reboot, the following message is seen in apache2.service logs: -- Unit apache2.service has begun starting up. Oct 14 12:18:32 SERVER apachectl[3833]: (99)Cannot assign requested address: AH00072: make_sock: could not bind to address [REDACTED IPV6.33]:443 Oct 14 12:18:32 SERVER apachectl[3833]: no listening sockets available, shutting down Oct 14 12:18:32 SERVER apachectl[3833]: AH00015: Unable to open logs Oct 14 12:18:32 SERVER apachectl[3833]: Action 'start' failed. Oct 14 12:18:32 SERVER apachectl[3833]: The Apache error log may have more information. Oct 14 12:18:33 SERVER systemd[1]: apache2.service: Control process exited, code=exited status=1 Oct 14 12:18:33 SERVER systemd[1]: apache2.service: Failed with result 'exit-code'. Oct 14 12:18:33 SERVER systemd[1]: Failed to start The Apache HTTP Server. The apache2 configuration is using the ipv4 and ipv6 present on the server: /etc/apache2/ports.conf:Listen :443 /etc/apache2/ports.conf:Listen :443 /etc/apache2/ports.conf:Listen [REDACTED IPV6::33]:443 /etc/apache2/ports.conf:Listen [REDACTED IPV6::35]:443 and the /etc/network/interfaces looks like this (no netplan): # Additional IPs that are used to serve https traffic for # releases.ubuntu.com so that archive doesn't respond on 443. auto bond0:1 iface bond0:1 inet static address .247/32 # Using up/down to avoid LP:1347246. up /sbin/ip addr add REDACTED IPV6::33/128 dev $IFACE preferred_lft 0 down /bin/ip addr del REDACTED IPV6::33/128 dev $IFACE preferred_lft 0 # Additional IPs that are used to serve *.clouds.archive.ubuntu.com # with HTTPProtocolOptions unsafe, which is needed to work around # cloud-init bug LP:1868232 (cRT#125271). auto bond0:2 iface bond0:2 inet static address .245/32 # Using up/down to avoid LP:1347246. up /sbin/ip addr add REDACTED IPV6::35/128 dev $IFACE preferred_lft 0 down /bin/ip addr del REDACTED IPV6::35/128 dev $IFACE preferred_lft 0 I was surprised that the apache2.service does not contain a After=network-online.target $ systemctl show apache2.service | grep -E '(Wants|Require|After|Before)' RemainAfterExit=no Requires=system.slice sysinit.target -.mount Before=multi-user.target shutdown.target After=basic.target sysinit.target systemd-journald.socket system.slice network.target nss-lookup.target systemd-tmpfiles-setup.service remote-fs.target -.mount RequiresMountsFor=/var/tmp /tmp $ systemctl show network.target | grep "^After" After=network-pre.target ifup@bond0.service ifup@ens2f0.service ifup@ens2f1.service systemd-resolved.service ufw.service networking.service systemd-networkd.service So I was wondering if the "ifup@bond0" was enough as a dependency here, to be sure to have the ipv6 up and running or if we would need something like "ifup@bond0:2" and "ifup@bond0:1" as part of the list of the services in the network.target "After" list. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1899852/+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 1899852] Re: Cannot assign requested address: AH00072: make_sock: could not bind to address
Now to your actual question of "how to order after a given bond interface", that is actually a systemd-networkd/systemd question (reminder question, not a bug - so not a bug report actually). I'll add bug tasks but think they are incomplete as that is a config/consulting question more than anything else. ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: apache2 (Ubuntu) Status: New => Invalid ** Changed in: systemd (Ubuntu) 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/1899852 Title: Cannot assign requested address: AH00072: make_sock: could not bind to address Status in apache2 package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Bug description: Hello, Let's first list my configuration items: * apache2 2.4.29-1ubuntu4.14 * release: Ubuntu 18.04.5 LTS Upon reboot, the following message is seen in apache2.service logs: -- Unit apache2.service has begun starting up. Oct 14 12:18:32 SERVER apachectl[3833]: (99)Cannot assign requested address: AH00072: make_sock: could not bind to address [REDACTED IPV6.33]:443 Oct 14 12:18:32 SERVER apachectl[3833]: no listening sockets available, shutting down Oct 14 12:18:32 SERVER apachectl[3833]: AH00015: Unable to open logs Oct 14 12:18:32 SERVER apachectl[3833]: Action 'start' failed. Oct 14 12:18:32 SERVER apachectl[3833]: The Apache error log may have more information. Oct 14 12:18:33 SERVER systemd[1]: apache2.service: Control process exited, code=exited status=1 Oct 14 12:18:33 SERVER systemd[1]: apache2.service: Failed with result 'exit-code'. Oct 14 12:18:33 SERVER systemd[1]: Failed to start The Apache HTTP Server. The apache2 configuration is using the ipv4 and ipv6 present on the server: /etc/apache2/ports.conf:Listen :443 /etc/apache2/ports.conf:Listen :443 /etc/apache2/ports.conf:Listen [REDACTED IPV6::33]:443 /etc/apache2/ports.conf:Listen [REDACTED IPV6::35]:443 and the /etc/network/interfaces looks like this (no netplan): # Additional IPs that are used to serve https traffic for # releases.ubuntu.com so that archive doesn't respond on 443. auto bond0:1 iface bond0:1 inet static address .247/32 # Using up/down to avoid LP:1347246. up /sbin/ip addr add REDACTED IPV6::33/128 dev $IFACE preferred_lft 0 down /bin/ip addr del REDACTED IPV6::33/128 dev $IFACE preferred_lft 0 # Additional IPs that are used to serve *.clouds.archive.ubuntu.com # with HTTPProtocolOptions unsafe, which is needed to work around # cloud-init bug LP:1868232 (cRT#125271). auto bond0:2 iface bond0:2 inet static address .245/32 # Using up/down to avoid LP:1347246. up /sbin/ip addr add REDACTED IPV6::35/128 dev $IFACE preferred_lft 0 down /bin/ip addr del REDACTED IPV6::35/128 dev $IFACE preferred_lft 0 I was surprised that the apache2.service does not contain a After=network-online.target $ systemctl show apache2.service | grep -E '(Wants|Require|After|Before)' RemainAfterExit=no Requires=system.slice sysinit.target -.mount Before=multi-user.target shutdown.target After=basic.target sysinit.target systemd-journald.socket system.slice network.target nss-lookup.target systemd-tmpfiles-setup.service remote-fs.target -.mount RequiresMountsFor=/var/tmp /tmp $ systemctl show network.target | grep "^After" After=network-pre.target ifup@bond0.service ifup@ens2f0.service ifup@ens2f1.service systemd-resolved.service ufw.service networking.service systemd-networkd.service So I was wondering if the "ifup@bond0" was enough as a dependency here, to be sure to have the ipv6 up and running or if we would need something like "ifup@bond0:2" and "ifup@bond0:1" as part of the list of the services in the network.target "After" list. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1899852/+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 1900008] Re: Sessions of screen does not keep running in background
Thanks Axel, I think I didn't closed a terminal windows with anything other but CTRL+D for years (which is an implicit call to exit), but you are absolutely right. It could be "click on the X on the window decoration to close the terminal". Thanks for making me see that ... :-) @Gustavo - never the less please speak up what exactly is-done/happens in your case as we are still making assumptions. ** Also affects: systemd (Ubuntu) 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/198 Title: Sessions of screen does not keep running in background Status in screen package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: In a new fresh installed 20.04, when I use screen command and close the terminal (not closing screen sesion), then I can't recover it with screen -x, since does not exist. I can only recover screen sesion if the original terminal running screen is not being closed. For some reason, this is closing screen session of that user: Oct 15 13:32:45 pc-caja2 systemd[1]: session-66.scope: Succeeded. Oct 15 13:32:45 pc-caja2 systemd[1]: Stopped Session 66 of user usuario. This does not happen in an upgraded system from 18.04 to 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/screen/+bug/198/+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 1744328] Re: libfreebl3.so should be public, not in the nss subdir
FYI since comment #6 not a lot happened in Debian other than other bugs
being merged.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nss in Ubuntu.
https://bugs.launchpad.net/bugs/1744328
Title:
libfreebl3.so should be public, not in the nss subdir
Status in nss package in Ubuntu:
Fix Released
Status in nss package in Debian:
New
Bug description:
Hi,
I tried to move the chrony dependency from tomcrypt to libnss to avoid
universe dependencies.
While doing so I found that libfreebl3 is not "normally" linkable being
outside the normal ld paths.
E.g. sample program
#include
#include
#include
int main(int argc, char **argv) {
NSSLOWHASH_Begin(NSSLOWHASH_NewContext(NSSLOW_Init(), HASH_AlgSHA512));
return 0;
}
Build:
gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security
-Wmissing-prototypes -Wall -pthread -Wdate-time -D_FORTIFY_SOURCE=2
-I/usr/include/nss -I/usr/include/nspr -o docheck docheck.c -lfreebl3
-Wl,-Bsymbolic-functions -Wl,-z,relro -v -Wl,-v -L/usr/lib/x86_64-linux-gnu/nss
Then:
ldd docheck
will give you
libfreebl3.so => not found
Obviously a link into /usr/lib/x86_64-linux-gnu/ fixes the issue but
needs some more consideration if that is the thing we want (there
might be a reason it is where it is).
Note: Required to go on with the chrony MIR which is rather urgent to
be sorted out as it has a lot of other dependencies that need to be
adapted.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1744328/+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 1897744] Re: VerifyHostKeyDNS not working due to missing trust-ad flag
I just re-debugged into the same case - now marked as dup. You might consider using https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1898590/comments/7 as test steps to verify that once uploaded to focal-proposed. -- 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/1897744 Title: VerifyHostKeyDNS not working due to missing trust-ad flag Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Bug description: [impact] without trust-ad resolv.conf option, glibc will strip AD from systemd- resolved responses. one thing this will prevent working is ssh VerifyHostKeyDNS [test case] setup a target system to ssh into, and create a SSHFP DNS record for its public key. on a different source system, setup dns to enable DNSSEC, and attempt to ssh to the target system using the VerifyHostKeyDNS=yes option. setup of the SSHFP is out of scope for this bug, but e.g.: https://en.wikipedia.org/wiki/SSHFP_record https://tools.ietf.org/html/rfc4255 [regression potential] regressions would likely involve DNS lookup failures, probably if DNSSEC is enabled but possibly even without, and likely when the application requesting the dns lookup processes the response AD. [scope] this is needed only in focal. glibc first stripped the AD in version 2.31, so this is not needed in bionic or earlier. this was added upstream in commit a742f9828ea which was included in v246, so this is fixed already in groovy. [original description] Hi, 1) Description: Ubuntu 20.04.1 LTS Release: 20.04 2) systemd:245.4-4ubuntu3.2 3) I set VerifyHostKeyDNS to YES and hosts are automatically verified via sshfp. 4) I still get the security question Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no/[fingerprint])? The issue is known and fixed in systemd v246. https://github.com/systemd/systemd/pull/16072 Best regards Daniel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1897744/+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 1898590] Re: Verify DNS fingerprints not working
*** This bug is a duplicate of bug 1897744 *** https://bugs.launchpad.net/bugs/1897744 @Dan - now I saw your update - that might have shortened my dnssec trip :-) It indeed is a duplicate of that - marking as such. ** This bug has been marked a duplicate of bug 1897744 VerifyHostKeyDNS not working due to missing trust-ad flag -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1898590 Title: Verify DNS fingerprints not working Status in systemd: Unknown Status in glibc package in Ubuntu: Invalid Status in openssh package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Status in openssh package in Debian: Unknown Bug description: When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints are fetched, but the result is always: debug1: found n insecure fingerprints in DNS With dig +dnssec -tsshfp hostname the result is ok: ad flg is set. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1898590/+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 1898590] Re: Verify DNS fingerprints not working
*** This bug is a duplicate of bug 1897744 *** https://bugs.launchpad.net/bugs/1897744 Summary: - we understand what happened - we have a workaround for users by changing a config - we have a systemd change that can be considered to be backported by the systemd package maintainers ** Tags removed: server-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/1898590 Title: Verify DNS fingerprints not working Status in systemd: Unknown Status in glibc package in Ubuntu: Invalid Status in openssh package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Status in openssh package in Debian: Unknown Bug description: When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints are fetched, but the result is always: debug1: found n insecure fingerprints in DNS With dig +dnssec -tsshfp hostname the result is ok: ad flg is set. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1898590/+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 1898590] Re: Verify DNS fingerprints not working
*** This bug is a duplicate of bug 1897744 *** https://bugs.launchpad.net/bugs/1897744 TL;DR: one affected by this upgrade triggered behavior change needs to set options edns0 trust-ad in /etc/resolv.conf to fix the issue. And as usual, once you already know what things are about - then (but only then :-/ ) you find the important related issues - reported by Laney \o/ Subscribing him to the bug FYI Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960023 I'll add a bug link to Debian. Discussed and declared to be systed issue and asked to file upstream. Which led to ... Systemd https://github.com/systemd/systemd/issues/15767 This is fixed in newer systemd and will set trust-ad I'll add a systemd task to consider backporting this to Focal -- 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/1898590 Title: Verify DNS fingerprints not working Status in systemd: Unknown Status in glibc package in Ubuntu: Invalid Status in openssh package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Status in openssh package in Debian: Unknown Bug description: When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints are fetched, but the result is always: debug1: found n insecure fingerprints in DNS With dig +dnssec -tsshfp hostname the result is ok: ad flg is set. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1898590/+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 1898590] Re: Verify DNS fingerprints not working
*** This bug is a duplicate of bug 1897744 *** https://bugs.launchpad.net/bugs/1897744 ok up/downgrading just "libc6" is enough to trigger. I also found that libc6 from Eoan version 2.30-0ubuntu2.2 is good. So it is new in 2.31! The changelog mentions soem DNSSEC https://sourceware.org/legacy-ml/libc-announce/2020/msg1.html "* The DNS stub resolver will optionally send the AD (authenticated data) bit in queries if the trust-ad option is set via the options directive in /etc/resolv.conf (or if RES_TRUSTAD is set in _res.options). In this mode, the AD bit, as provided by the name server, is available to applications which call res_search and related functions. In the default mode, the AD bit is not set in queries, and it is automatically cleared in responses, indicating a lack of DNSSEC validation. (Therefore, the name servers and the network path to them are treated as untrusted.)" Once I knew that it was a small step and I found that options edns0 trust-ad in /etc/resolv.conf indeed fixes the issue. I'm not sure if openssh would be entitled to set RES_TRUSTAD is set in _res.options. Maybe not as that is more a decision of the admin setting up and configuring the system than the openssh software. Therefore I think this is actually a little detail that upgraders that use dnssec for openssh (and maybe others) via libc6 resolv need to consider. ** Bug watch added: Debian Bug tracker #960023 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960023 ** Also affects: openssh (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960023 Importance: Unknown Status: Unknown ** Bug watch added: github.com/systemd/systemd/issues #15767 https://github.com/systemd/systemd/issues/15767 ** Also affects: systemd via https://github.com/systemd/systemd/issues/15767 Importance: Unknown Status: Unknown ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released ** Also affects: glibc (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** No longer affects: glibc (Ubuntu Focal) ** Changed in: openssh (Ubuntu) Status: Confirmed => Invalid ** No longer affects: openssh (Ubuntu Focal) ** Changed in: glibc (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1898590 Title: Verify DNS fingerprints not working Status in systemd: Unknown Status in glibc package in Ubuntu: Invalid Status in openssh package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Status in openssh package in Debian: Unknown Bug description: When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints are fetched, but the result is always: debug1: found n insecure fingerprints in DNS With dig +dnssec -tsshfp hostname the result is ok: ad flg is set. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1898590/+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 1898590] Re: Verify DNS fingerprints not working
As a first step I tried to make sure this actually is a change in openssh. Because my reading of the issues referred above has shown that not all of the verification is done inside ssh but partially in glibc. So I upgraded on the bionic test system step by step. The upgrade dependency list for openssh-client is "libc-bin libc6 libgssapi-krb5-2 libkrb5-3 libkrb5support0 locales" I found that the bug is reproducible with openssh-client 1:7.6p1-4ubuntu0.3 running against the newer glibc. I can switch in/out the reported bug be switching on a Bionic system between glibc 2.27-3ubuntu1.2 - Bionic - Good 2.31-0ubuntu9.1 - Focal - Bad ** Also affects: glibc (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1898590 Title: Verify DNS fingerprints not working Status in glibc package in Ubuntu: New Status in openssh package in Ubuntu: Confirmed Bug description: When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints are fetched, but the result is always: debug1: found n insecure fingerprints in DNS With dig +dnssec -tsshfp hostname the result is ok: ad flg is set. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1898590/+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 1898590] Re: Verify DNS fingerprints not working
Something helpful for anyone looking into this later I found what seems a good testcase without requiring too much a local setup (of a dnssec dns server): To get unbound (brute force) do: apt install unbound sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved sudo systemctl enable unbound-resolvconf sudo systemctl enable unbound # set 127.0.0.1 vim /etc/resolv.conf Now this should show the ad flag as reported: $ dig salsa.debian.org -t sshfp ... ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 $ ssh -v -o "VerifyHostKeyDNS=yes" t...@salsa.debian.org This indeed (as reported), does show the changed behavior (clean LXD containers, just changes as mentioned above, edns0 set by default): Bionic: debug1: found 4 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS Focal: debug1: found 4 insecure fingerprints in DNS debug1: matching host key fingerprint found in DNS The authenticity of host 'salsa.debian.org (209.87.16.44)' can't be established. ED25519 key fingerprint is SHA256:OAD3pGSwcODIthxF+zIRvPTZ8UCJAYI75E42XDfGr84. Matching host key fingerprint found in DNS. ** Changed in: openssh (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1898590 Title: Verify DNS fingerprints not working Status in openssh package in Ubuntu: Confirmed Bug description: When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints are fetched, but the result is always: debug1: found n insecure fingerprints in DNS With dig +dnssec -tsshfp hostname the result is ok: ad flg is set. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1898590/+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 1898590] Re: Verify DNS fingerprints not working
Turns out this seems to be a never ending story and you might have found a comeback of that issue for your particular configuration as you say this worked on 18.04 but fails on 20.04. This goes way back https://bugzilla.mindrot.org/show_bug.cgi?id=1455 Or half way back https://trac.macports.org/ticket/49007 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618863 https://bugzilla.mindrot.org/show_bug.cgi?id=2119 Other more recent similar issues were around "options edns0" being required to be set for this to work now: https://github.com/NixOS/nixpkgs/issues/12470 https://exanames.typepad.com/blog/2009/06/one-more-thing-to-do-with-dnssec-ssh.html https://bugzilla.redhat.com/show_bug.cgi?id=1630180 https://bugzilla.redhat.com/show_bug.cgi?id=1878166 Note: that option was the default for /etc/resolv.conf on Bionic/Focal for me. Various working setups seem to have been affected by 7.5 https://lists.mindrot.org/pipermail/openssh-bugs/2017-April/017631.html https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-January/036600.html https://bugzilla.mindrot.org/show_bug.cgi?id=2708 But Bionic -> Focal is openssh version 7.6 -> 8.3 Multiple of the above and some other references refer to requiring ldns support. That clearly is in openssh since ~v6 but we don't enable it at build time libldns support: no Is that required and is it now more required than before - I don't know :-/ Sorry, all that I could provide so far was a collection of a (disturbing) history of that feature. ** Bug watch added: OpenSSH Portable Bugzilla #1455 https://bugzilla.mindrot.org/show_bug.cgi?id=1455 ** Bug watch added: trac.macports.org #49007 http://trac.macports.org/ticket/49007 ** Bug watch added: Debian Bug tracker #618863 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618863 ** Bug watch added: OpenSSH Portable Bugzilla #2119 https://bugzilla.mindrot.org/show_bug.cgi?id=2119 ** Bug watch added: github.com/NixOS/nixpkgs/issues #12470 https://github.com/NixOS/nixpkgs/issues/12470 ** Bug watch added: Red Hat Bugzilla #1630180 https://bugzilla.redhat.com/show_bug.cgi?id=1630180 ** Bug watch added: Red Hat Bugzilla #1878166 https://bugzilla.redhat.com/show_bug.cgi?id=1878166 ** Bug watch added: OpenSSH Portable Bugzilla #2708 https://bugzilla.mindrot.org/show_bug.cgi?id=2708 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1898590 Title: Verify DNS fingerprints not working Status in openssh package in Ubuntu: Confirmed Bug description: When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints are fetched, but the result is always: debug1: found n insecure fingerprints in DNS With dig +dnssec -tsshfp hostname the result is ok: ad flg is set. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1898590/+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 1898590] Re: Verify DNS fingerprints not working
** Tags added: server-next -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1898590 Title: Verify DNS fingerprints not working Status in openssh package in Ubuntu: New Bug description: When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints are fetched, but the result is always: debug1: found n insecure fingerprints in DNS With dig +dnssec -tsshfp hostname the result is ok: ad flg is set. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1898590/+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 1892559] Re: [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite
Hi Seth and Joy, I see you cleared the list a lot - awesome! You have subscribed and pinged the remaining ones which is a reasonable approach as most might be no more real issues as of today. I'm ok for the Ubuntu side of the pcsc-lite bugs now, what still needs to be addressed is https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=930530 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pcsc-lite in Ubuntu. https://bugs.launchpad.net/bugs/1892559 Title: [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite Status in ccid package in Ubuntu: New Status in opensc package in Ubuntu: Incomplete Status in pam-pkcs11 package in Ubuntu: New Status in pcsc-lite package in Ubuntu: New Status in pcsc-perl package in Ubuntu: Invalid Status in pcsc-tools package in Ubuntu: Invalid Bug description: ==> ccid <== [Availability] ccid is in universe, and builds on all architectures. [Rationale] The desktop team and security team are interested in bringing smartcard authentication to enterprise desktop environments. [Security] No CVEs for ccid are listed in our database. Doesn't appear to bind to a socket. No privileged executables, but does have udev rules. Probably needs a security review. [Quality assurance] No test suite. Does require odd hardware that we'll probably need to buy. I don't see debconf questions. ccid is well maintained in Debian by upstream author. One open wishlist bug in BTS, harmless. One open bug in launchpad, not security, but looks very frustrating for the users. The upstream author was engaged but it never reached resolution. https://bugs.launchpad.net/ubuntu/+source/ccid/+bug/1175465 Has a debian/watch file. Quilt packaging. P: ccid source: no-dep5-copyright P: ccid source: package-uses-experimental-debhelper-compat-version 13 [Dependencies] Minimal dependencies, in main [Standards compliance] Appears to satisfy FHS and Debian policy [Maintenance] The desktop team will subscribe to bugs, however it is expected that the security team will assist with security-relevant questions. [Background information] ccid provides drivers to interact with usb-connected smart card readers. ==> libpam-pkcs11 <== [Availability] Source package pam-pkcs11 is in universe and builds on all architectures. [Rationale] The desktop team and security team are interested in bringing smartcard authentication to enterprise desktop environments. [Security] No CVEs in our database. Doesn't appear to bind to sockets. No privileged executables (but is a PAM module). As a PAM module this will require a security review. [Quality assurance] The package does not call pam-auth-update in its postinst #1650366 Does not ask questions during install. One Ubuntu bug claims very poor behaviour if a card isn't plugged in. No Debian bugs. Occasional updates in Debian by long-term maintainer. Does require odd hardware that we'll probably need to buy. Does not appear to run tests during build. Has scary warnings in the build logs. Has a debian/watch file. Ancient standards version; other smaller lintian messages, mostly documentation problems. Quilt packaging. [Dependencies] Depends on libcurl4, libldap-2.4-2, libpam0g, libpcsclite1, libssl1.1 All are in main. [Standards compliance] The package does not call pam-auth-update in its postinst #1650366 Otherwise looks to conform to FHS and Debian policies [Maintenance] The desktop team will subscribe to bugs, however it is expected that the security team will assist with security-relevant questions. [Background information] This PAM module can use CRLs and full-chain verification of certificates. It can also do LDAP, AD, and Kerberos username mapping. ==> libpcsc-perl <== [Availability] Source package pcsc-perl is in universe, builds for all architectures, plus i386 [Rationale] The desktop team and security team are interested in bringing smartcard authentication to enterprise desktop environments. [Security] There are no cves for pcsc-perl in our database. No privileged executables. Doesn't appear to bind to sockets. Probably needs a security review. [Quality assurance] Library package not intended to be used directly. No debconf questions. No bugs in Debian. No bugs in Ubuntu. Does require odd hardware that we'll probably need to buy. Tests exist, not run during the build; probably can't run during the build. Includes debian/watch file. A handful of lintian issues Quilt packaging. [Dependencies] libpcsc-perl depends upon libpcsclite1, libc6, perl, perlapi-5.30.0. All are in main. [Standards compliance] One oddity, Card.pod is stored in /usr/lib/x86_64-linux-gnu/perl5/5.30/Chipcard/PCSC/ Many other perl packages have .pod files in these directory trees so maybe it's fine, but it
[Touch-packages] [Bug 857651] Re: Unable to hide users from login screen / user switcher
Since so many components are involved a fix/change might have been missed. And since I recently didn't hear anything about this otherwise rather hot bug I was giving focal a try. It turns out that this was indeed improved. Only the user of pkg:ifmail user fdt name "Fidonet" is still visible. All other formerly affected packages are good in Focal. I can't (without digging through history a lot) say what fixed that but I'll update the bug tasks accordingly. Setting Focal fixed and marking Bionic/Xenial as still affected releases. The backport tasks for those packages are incomplete thou as it is unclear which change in which package fixed it for Focal. Note: This is only speaking for the "default config" of Ubuntu Desktop as in 20.04 we know that certain environments will behave differently (e.g. KDE never was affected). ** Also affects: ifmail (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: libvirt (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: ceph (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: lightdm (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: accountsservice (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: netqmail (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: sddm (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: ifmail (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: libvirt (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: ceph (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: lightdm (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: accountsservice (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: netqmail (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: sddm (Ubuntu Xenial) Importance: Undecided Status: New ** No longer affects: accountsservice (Ubuntu Xenial) ** No longer affects: accountsservice (Ubuntu Bionic) ** Changed in: ceph (Ubuntu Xenial) Status: New => Incomplete ** Changed in: ceph (Ubuntu Bionic) Status: New => Incomplete ** Changed in: ceph (Ubuntu) Status: Triaged => Fix Released ** No longer affects: ifmail (Ubuntu Xenial) ** No longer affects: ifmail (Ubuntu Bionic) ** No longer affects: lightdm (Ubuntu Xenial) ** No longer affects: lightdm (Ubuntu Bionic) ** Changed in: libvirt (Ubuntu) Status: Triaged => Fix Released ** Changed in: libvirt (Ubuntu Xenial) Status: New => Incomplete ** Changed in: libvirt (Ubuntu Bionic) Status: New => Incomplete ** Changed in: netqmail (Ubuntu Xenial) Status: New => Incomplete ** Changed in: netqmail (Ubuntu Bionic) Status: New => Incomplete ** Changed in: netqmail (Ubuntu) Status: Triaged => Fix Released ** No longer affects: sddm (Ubuntu Xenial) ** No longer affects: sddm (Ubuntu Bionic) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/857651 Title: Unable to hide users from login screen / user switcher Status in accountsservice: Unknown Status in SDDM: Fix Released Status in accountsservice package in Ubuntu: Triaged Status in ceph package in Ubuntu: Fix Released Status in ifmail package in Ubuntu: Triaged Status in libvirt package in Ubuntu: Fix Released Status in lightdm package in Ubuntu: Triaged Status in netqmail package in Ubuntu: Fix Released Status in sddm package in Ubuntu: Fix Released Status in ceph source package in Xenial: Incomplete Status in libvirt source package in Xenial: Incomplete Status in netqmail source package in Xenial: Incomplete Status in ceph source package in Bionic: Incomplete Status in libvirt source package in Bionic: Incomplete Status in netqmail source package in Bionic: Incomplete Bug description: Users that I have appended to the 'hidden-users' field in /etc/lightdm/users.conf are not actually hidden. They are still listed on the login screen and in Unity's user switching menu. ProblemType: Bug DistroRelease: Ubuntu 11.10 Package: lightdm 0.9.7-0ubuntu1 ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4 Uname: Linux 3.0.0-11-generic x86_64 ApportVersion: 1.23-0ubuntu1 Architecture: amd64 Date: Fri Sep 23 11:44:29 2011 InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Beta amd64 (20110413) SourcePackage: lightdm UpgradeStatus: Upgraded to oneiric on 2011-09-23 (0 days ago) mtime.conffile..etc.lightdm.users.conf: 2011-09-23T08:46:55.039175 To manage notifications about this bug go to: https://bugs.launchpad.net/accountsservice/+bug/857651/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
Tested the change - works as expected, prepping an MP -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
That patch by Christian Bolz is already applied (which seems reasonable after that much time), but when merging 3.0 the old patch for bug 1824812 should have been dropped. -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
As refrence, it is a re-occurrence of https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1824812 , look who filed that bug :-) -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
https://gitlab.com/apparmor/apparmor/-/commit/61c27d8808f0589beb6a319cc04073e8bb32d860 -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
And we are back with Christian Bolz :-) commit 61c27d8808f0589beb6a319cc04073e8bb32d860 Author: Christian Boltz Date: Fri Jun 21 19:22:15 2019 +0200 Fix and simplify setting SFS_MOUNTPOINT The question is why isn't this in the apparmor 3.0 package in groovy- proposed ? -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore
Isn't that "Not starting AppArmor in container" message just in:
/lib/apparmor/apparmor.systemd
-> /lib/apparmor/rc.apparmor.functions
-> function is_container_with_internal_policy()
That looks unchanged (except a comment) but it behaves differently:
root@testguest-apparmor-good:~# . /usr/lib/apparmor/rc.apparmor.functions
root@testguest-apparmor-good:~# is_container_with_internal_policy
root@testguest-apparmor-good:~# echo $?
0
root@testguest-apparmor-bad:~# . /usr/lib/apparmor/rc.apparmor.functions
root@testguest-apparmor-bad:~# is_container_with_internal_policy
root@testguest-apparmor-bad:~# echo $?
1
Looking into what happens in detail ...
good:
+ SFS_MOUNTPOINT=/sys/kernel/security/apparmor
+ local ns_stacked_path=/sys/kernel/security/apparmor/.ns_stacked
bad:
+ SFS_MOUNTPOINT=/sys/kernel/security/
+ local ns_stacked_path=/sys/kernel/security//.ns_stacked
Once we know that we can see that it is missing in the bad case
good:
root@testguest-apparmor-good:~# grep MODULE
/usr/lib/apparmor/rc.apparmor.functions
MODULE=apparmor
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"
if [ -f "${SECURITYFS}/${MODULE}/profiles" ]; then
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"
MODULE=apparmor
/sbin/modprobe -qr $MODULE
bad:
root@testguest-apparmor-bad:~# grep MODULE
/usr/lib/apparmor/rc.apparmor.functions
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"
So whatever took away the modprobe from
/usr/lib/apparmor/rc.apparmor.functions also removed the variable, but
that has broken function is_container_with_internal_policy
--
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/1895967
Title:
Apparmor 3.0.0 does not load profiles in containers anymore
Status in apparmor package in Ubuntu:
Confirmed
Bug description:
Hi,
I stumbled over this due to automatic tests checking proposed.
I found that Focal no more could migrate to Groovy with:
$ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
error: unsupported configuration: Security driver model 'apparmor' is not
available
I looked after it and found that while all former releases detected
apparmor correctly:
$ virsh capabilities | grep -C 3 secmodel
apparmor
0
dac
0
+64055:+108
+64055:+108
Now on groovy that didn't work anymore:
none
0
dac
0
+64055:+108
+64055:+108
Since 3.0 is only in proposed:
# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
3.0.0~beta1-0ubuntu1 500
500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64
Packages
*** 2.13.3-7ubuntu6 500
500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
100 /var/lib/dpkg/status
I installed the former version.
$ apt install apparmor=2.13.3-7ubuntu6
$ rm /var/cache/libvirt/qemu/capabilities/*
$ systemctl restart libvirtd
And it works again.
Interestingly going back to 3.0 then works and keeps working.
Therefore maybe it is a red-herring and I'll consider it incomplete & low
prio for now until I know more (allowing others that might see the same to find
this bug and chime in).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Bad case:
$ ./repro.sh bad
+ '[' bad == bad ']'
+ echo 'Bad case: Using apparmor from proposed'
Bad case: Using apparmor from proposed
+ BADCASE=1
+ lxc stop --force testguest-apparmor-bad
+ lxc delete --force testguest-apparmor-bad
+ lxc launch ubuntu-daily:groovy/amd64 testguest-apparmor-bad --profile default
--profile kvm
Creating testguest-apparmor-bad
Starting testguest-apparmor-bad
+ sleep 30s
+ lxc exec testguest-apparmor-bad runlevel
N 5
+ lxc exec testguest-apparmor-bad -- bash -c 'H=`cat /etc/hostname`; if [ -f
/var/lib/cloud/instance/boot-finished ]; then echo "LXD container $H ready";
else echo "LXD container $H not ready yet"; exit 2; fi'
LXD container testguest-apparmor-bad ready
+ lxc exec testguest-apparmor-bad --env DEBIAN_FRONTEND=noninteractive -- bash
-c 'apt-get --allow-unauthenticated --assume-yes -o
Dpkg::Options::='\''--force-confdef'\'' -o
Dpkg::Options::='\''--force-confold'\'' install apparmor-utils'
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
libfreetype6
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
python3-apparmor python3-libapparmor
Suggested packages:
vim-addon-manager
The following NEW packages will be installed:
apparmor-utils python3-apparmor python3-libapparmor
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 157 kB of archives.
After this operation, 966 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu groovy/main amd64 python3-libapparmor
amd64 2.13.3-7ubuntu6 [26.7 kB]
Get:2 http://archive.ubuntu.com/ubuntu groovy/main amd64 python3-apparmor amd64
2.13.3-7ubuntu6 [78.6 kB]
Get:3 http://archive.ubuntu.com/ubuntu groovy/main amd64 apparmor-utils amd64
2.13.3-7ubuntu6 [51.4 kB]
Fetched 157 kB in 0s (385 kB/s)
Selecting previously unselected package python3-libapparmor.
(Reading database ... 31714 files and directories currently installed.)
Preparing to unpack .../python3-libapparmor_2.13.3-7ubuntu6_amd64.deb ...
Unpacking python3-libapparmor (2.13.3-7ubuntu6) ...
Selecting previously unselected package python3-apparmor.
Preparing to unpack .../python3-apparmor_2.13.3-7ubuntu6_amd64.deb ...
Unpacking python3-apparmor (2.13.3-7ubuntu6) ...
Selecting previously unselected package apparmor-utils.
Preparing to unpack .../apparmor-utils_2.13.3-7ubuntu6_amd64.deb ...
Unpacking apparmor-utils (2.13.3-7ubuntu6) ...
Setting up python3-libapparmor (2.13.3-7ubuntu6) ...
Setting up python3-apparmor (2.13.3-7ubuntu6) ...
Setting up apparmor-utils (2.13.3-7ubuntu6) ...
Processing triggers for man-db (2.9.3-2) ...
+ lxc exec testguest-apparmor-bad -- aa-status
apparmor module is loaded.
28 profiles are loaded.
28 profiles are in enforce mode.
/snap/snapd/9279/usr/lib/snapd/snap-confine
/snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/usr/bin/man
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/lib/snapd/snap-confine
/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/{,usr/}sbin/dhclient
lsb_release
man_filter
man_groff
nvidia_modprobe
nvidia_modprobe//kmod
snap-update-ns.lxd
snap.lxd.activate
snap.lxd.benchmark
snap.lxd.buginfo
snap.lxd.check-kernel
snap.lxd.daemon
snap.lxd.hook.configure
snap.lxd.hook.install
snap.lxd.hook.remove
snap.lxd.lxc
snap.lxd.lxc-to-lxd
snap.lxd.lxd
snap.lxd.migrate
tcpdump
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
+ '[' 1 -eq 1 ']'
+ lxc exec testguest-apparmor-bad -- bash -c 'echo '\''deb
http://archive.ubuntu.com/ubuntu/ groovy-proposed restricted main multiverse
universe'\'' >> /etc/apt/sources.list'
+ lxc exec testguest-apparmor-bad --env DEBIAN_FRONTEND=noninteractive -- bash
-c 'apt-get --allow-unauthenticated --assume-yes -o
Dpkg::Options::='\''--force-confdef'\'' -o
Dpkg::Options::='\''--force-confold'\'' update'
Hit:1 http://security.ubuntu.com/ubuntu groovy-security InRelease
Get:2 http://archive.ubuntu.com/ubuntu groovy InRelease [267 kB]
Get:3 http://security.ubuntu.com/ubuntu groovy-security/universe amd64 c-n-f
Metadata [116 B]
Get:4 http://security.ubuntu.com/ubuntu groovy-security/multiverse amd64 c-n-f
Metadata [116 B]
Hit:5 http://archive.ubuntu.com/ubuntu groovy-updates InRelease
Get:6 http://archive.ubuntu.com/ubuntu groovy-backports InRelease [89.2 kB]
Get:7 http://archive.ubuntu.com/ubuntu groovy-proposed InRelease [118 kB]
Get:8 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages [969 kB]
Get:9 http://archive.ubuntu.com/ubuntu groovy/main Translation-en [507 kB]
Get:10 http://archive.ubuntu.com/ubuntu groovy/main amd64
[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
It seems it comes down to a change in /lib/apparmor/apparmor.systemd which now refuses to load profiles when running in a container. Example with 3.0: $ /lib/apparmor/apparmor.systemd reload Not starting AppArmor in container Example with 2.x /lib/apparmor/apparmor.systemd reload Restarting AppArmor Reloading AppArmor profiles This also explains why snap profiles work, the are loaded by snapd and not by apparmor.service. I'll attach a repro script and full logs of good and bad case. ** Attachment added: "repro script comparing current and proposed apparmor version" https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+attachment/5413150/+files/apparmor-repro.sh -- 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/1895967 Title: Apparmor 3.0.0 does not load profiles in containers anymore Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
FYI - other testing might miss this as "starting a guest on groovy" works with the new versions, but it will be without apparmor. Migrating from focal or a pre-upgrade groovy shows the issues broken by apparmor not being enabled. ** Changed in: apparmor (Ubuntu) Status: Incomplete => New ** Changed in: apparmor (Ubuntu) Importance: Low => High ** Tags added: block-proposed -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: New Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
I have backed up this container and its snapshot for later and re-run the whole automation which got me that bad state. That allowed me to run my automation again without removing this container (in case we need it for debugging later). So I ran everything again to check if it would happen again with the version now in groovy proposed. Ok it ran into the same issues again so it is reproducible with the current version in proposed. Since in the tests have plenty of systems involved I need to cut it down and simplify it to just one ... -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: New Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Ok, I have definitely a snapshot left that has "conserved" the bad state. $ lxc stop testkvm-groovy-from $ lxc restore testkvm-groovy-from orig $ lxc start testkvm-groovy-from $ lxc exec testkvm-groovy-from # aa-status apparmor module is loaded. 15 profiles are loaded. 15 profiles are in enforce mode. /snap/snapd/9279/usr/lib/snapd/snap-confine /snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper snap-update-ns.lxd snap.lxd.activate snap.lxd.benchmark snap.lxd.buginfo snap.lxd.check-kernel snap.lxd.daemon snap.lxd.hook.configure snap.lxd.hook.install snap.lxd.hook.remove snap.lxd.lxc snap.lxd.lxc-to-lxd snap.lxd.lxd snap.lxd.migrate 0 profiles are in complain mode. 0 profiles are in kill mode. 0 profiles are in unconfined mode. 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. 0 processes are in mixed mode. 0 processes are in kill mode. While silly this gets me back to normal from here # aa-enforce /etc/apparmor.d/* # aa-status apparmor module is loaded. 32 profiles are loaded. 32 profiles are in enforce mode. ... You see that we now have more than twice as much loaded -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Hi Christian Bolz o/ I'd have such rules but this isn't the problem here as that would matter only much later. I libvirtd itself isn't confined it refuses to go on confining the guests and that is here the problem. The current question really comes down to "how did I manage to have everything but snaps loose enforce mode"? -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
I knew from my former tests: 1. apparmor 3.0 = bad 2. downgrading to 2.13.3-7ubuntu6 and back up to 3.0 = good 3. aa-enforce + service restart = good I checked the logs on the affected systems how this got into the bad state: $ grep -E 'configure (lib)?(apparmor|libvirt)' /var/log/dpkg.log 2020-09-16 05:56:09 configure libapparmor1:amd64 3.0.0~beta1-0ubuntu1 2020-09-16 05:56:18 configure apparmor:amd64 3.0.0~beta1-0ubuntu1 2020-09-16 05:57:31 configure libvirt-daemon-system-systemd:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:31 configure libvirt0:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:33 configure libvirt-clients:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon-driver-qemu:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon-system:amd64 6.6.0-1ubuntu2 2020-09-16 05:58:05 configure apparmor-utils:amd64 3.0.0~beta1-0ubuntu1 2020-09-17 14:04:17 configure libvirt-daemon-system-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt0-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-daemon-driver-qemu-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-clients-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-daemon-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-22 06:56:34 configure apparmor:amd64 3.0.0~beta1-0ubuntu5 It seems I had: 1. groovy container 2. upgrade to proposed (including libapparmor1 / apparmor 3.0) 3. install libvirt I was trying to recreate the above with a new container as of today: 1. groovy container (2.13.3-7ubuntu6, all still confined) 2. upgrade to proposed (3.0.0~beta1-0ubuntu5, all still confined) 3. install libvirt (confinement working well) Hmm, something must have been different. I know I have used container snapshots when I ran into that - I need to sort out in what order that happened and if it would occur again. -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895060] Re: [FFe] apparmor 3 upstream release
Sorry, while being about evaluating the new apparmor this got posted to the wrong bug :-/ -- 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/1895060 Title: [FFe] apparmor 3 upstream release Status in apparmor package in Ubuntu: Fix Committed Bug description: As per the draft upstream release notes[1]: AppArmor 3.0 is a major new release of the AppArmor user space that makes an important change to policy development and support. Its focus is transitioning policy to the new features ABI and as such other new features have been limited. Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the newer AppArmor 3 style policy which requires the declaration of a features abi. As such AppArmor 3.0 will be a short lived release, and will not receive long term support. The following AppArmor 3.1 feature release is planned to be a regular release, please take this into account when including AppArmor 3.0 into a distro release. As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3 to Ubuntu and provide these new capabilities to users and system administrators. The short support lifespan of Ubuntu 20.10 ensures that there is alignment with the limited support lifetime of AppArmor 3.0 from upstream, whilst giving good exposure and opportunity to test and exercise the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight of new features provided by AppArmor 3.0 include: - Policy now must declare the feature abi it was developed for if it is to use any new features. This ensures that old policy will not become incompatible with new kernels that support additional AppArmor features. - The use of profile names that are based on pathnames are deprecated. - Support for new kernel features (requires appropriate features abi tagging in policy) - upstream v8 network socket rules - xattr attachment conditionals - capabilities PERFMON and BPF - Improved compiler warnings and semantic checks - aa-status rewritten in C (previously was python) with additional features - supports use in systems/images where python is not available - supports kill, unconfined and mixed profile modes - Rewritten aa-notify (previously was perl, now python3) - shared backend with other python tools - support use of aa.CONFDIR instead of hard coded /etc/apparmor - improved message layout - Improved support for kernels that support LSM stacking - New utility aa-features-abi to extract and work with kernel abi features - New utility aa-load to load binary policy without calling the apparmor_parser - Support for profile modes - enforce (default when no mode flag is supplied) - kill (experimental) - unconfined (experimental) The use of the new AppArmor profile feature ABI includes a default configuration (for the Ubuntu packaged version of AppArmor proposed in this FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures that all profiles provided in AppArmor3 for groovy will conform to this feature set and that upgrades to the kernel version (say to 5.8) that may include newer AppArmor confinement features will not result in additional policy denials as a result (since say the existing profile did not specify a rule for a new AppArmor feature which is now supported by the upgraded kernel). This ensures that there will be no regressions in application behaviour as a result of AppArmor kernel feature upgrades. TESTING This has been extensively tested by the security team - this includes following the documented Ubuntu merges test plan[2] for AppArmor and the extensive QA Regression Tests[3] for AppArmor as well. This ensures that the various applications that make heavy use of AppArmor (LXD, docker, lxc, dbus, libvirt, snapd etc) have all been exercised and no regressions have been observed. All tests have passed and demonstrated both apparmor and the various applications that use it to be working as expected. BUILD LOGS This is currently uploaded to groovy-proposed, build logs can be found on Launchpad at: https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1 INSTALL LOG See attached (https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files /groovy-proposed-apparmor-install.log) for a log showing install of the packages from groovy-proposed [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0 [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor [3] https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post
[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release
I knew from my former tests: 1. apparmor 3.0 = bad 2. downgrading to 2.13.3-7ubuntu6 and back up to 3.0 = good 3. aa-enforce + service restart = good I checked the logs on the affected systems how this got into the bad state: $ grep -E 'configure (lib)?(apparmor|libvirt)' /var/log/dpkg.log 2020-09-16 05:56:09 configure libapparmor1:amd64 3.0.0~beta1-0ubuntu1 2020-09-16 05:56:18 configure apparmor:amd64 3.0.0~beta1-0ubuntu1 2020-09-16 05:57:31 configure libvirt-daemon-system-systemd:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:31 configure libvirt0:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:33 configure libvirt-clients:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon-driver-qemu:amd64 6.6.0-1ubuntu2 2020-09-16 05:57:36 configure libvirt-daemon-system:amd64 6.6.0-1ubuntu2 2020-09-16 05:58:05 configure apparmor-utils:amd64 3.0.0~beta1-0ubuntu1 2020-09-17 14:04:17 configure libvirt-daemon-system-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt0-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-daemon-driver-qemu-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-clients-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-17 14:04:17 configure libvirt-daemon-dbgsym:amd64 6.6.0-1ubuntu2 2020-09-22 06:56:34 configure apparmor:amd64 3.0.0~beta1-0ubuntu5 It seems I had: 1. groovy container 2. upgrade to proposed (including libapparmor1 / apparmor 3.0) 3. install libvirt I was trying to recreate the above with a new container as of today: 1. groovy container (2.13.3-7ubuntu6, all still confined) 2. upgrade to proposed (3.0.0~beta1-0ubuntu5, all still confined) 3. install libvirt (confinement working well) Hmm, something must have been different. I know I have used container snapshots when I ran into that - I need to sort out in what order that happened and if it would occur again. -- 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/1895060 Title: [FFe] apparmor 3 upstream release Status in apparmor package in Ubuntu: Fix Committed Bug description: As per the draft upstream release notes[1]: AppArmor 3.0 is a major new release of the AppArmor user space that makes an important change to policy development and support. Its focus is transitioning policy to the new features ABI and as such other new features have been limited. Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the newer AppArmor 3 style policy which requires the declaration of a features abi. As such AppArmor 3.0 will be a short lived release, and will not receive long term support. The following AppArmor 3.1 feature release is planned to be a regular release, please take this into account when including AppArmor 3.0 into a distro release. As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3 to Ubuntu and provide these new capabilities to users and system administrators. The short support lifespan of Ubuntu 20.10 ensures that there is alignment with the limited support lifetime of AppArmor 3.0 from upstream, whilst giving good exposure and opportunity to test and exercise the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight of new features provided by AppArmor 3.0 include: - Policy now must declare the feature abi it was developed for if it is to use any new features. This ensures that old policy will not become incompatible with new kernels that support additional AppArmor features. - The use of profile names that are based on pathnames are deprecated. - Support for new kernel features (requires appropriate features abi tagging in policy) - upstream v8 network socket rules - xattr attachment conditionals - capabilities PERFMON and BPF - Improved compiler warnings and semantic checks - aa-status rewritten in C (previously was python) with additional features - supports use in systems/images where python is not available - supports kill, unconfined and mixed profile modes - Rewritten aa-notify (previously was perl, now python3) - shared backend with other python tools - support use of aa.CONFDIR instead of hard coded /etc/apparmor - improved message layout - Improved support for kernels that support LSM stacking - New utility aa-features-abi to extract and work with kernel abi features - New utility aa-load to load binary policy without calling the apparmor_parser - Support for profile modes - enforce (default when no mode flag is supplied) - kill (experimental) - unconfined (experimental) The use of the new AppArmor profile feature ABI includes a default configuration (for the Ubuntu packaged version of AppArmor proposed in this FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures that all
[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Yeah and the comment above this function pointed the right way:
Good case (libvirt is enforced):
oot@testkvm-groovy-to:~# aa-status
apparmor module is loaded.
31 profiles are loaded.
31 profiles are in enforce mode.
/snap/snapd/9279/usr/lib/snapd/snap-confine
/snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/usr/bin/man
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/lib/snapd/snap-confine
/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/{,usr/}sbin/dhclient
libvirtd
libvirtd//qemu_bridge_helper
lsb_release
man_filter
man_groff
nvidia_modprobe
nvidia_modprobe//kmod
snap-update-ns.lxd
snap.lxd.activate
snap.lxd.benchmark
snap.lxd.buginfo
snap.lxd.check-kernel
snap.lxd.daemon
snap.lxd.hook.configure
snap.lxd.hook.install
snap.lxd.hook.remove
snap.lxd.lxc
snap.lxd.lxc-to-lxd
snap.lxd.lxd
snap.lxd.migrate
tcpdump
virt-aa-helper
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
1 processes have profiles defined.
1 processes are in enforce mode.
/usr/sbin/libvirtd (14751) libvirtd
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.
Bad case libvirt (and plenty of other things) are not confined:
# aa-status
apparmor module is loaded.
15 profiles are loaded.
15 profiles are in enforce mode.
/snap/snapd/9279/usr/lib/snapd/snap-confine
/snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
snap-update-ns.lxd
snap.lxd.activate
snap.lxd.benchmark
snap.lxd.buginfo
snap.lxd.check-kernel
snap.lxd.daemon
snap.lxd.hook.configure
snap.lxd.hook.install
snap.lxd.hook.remove
snap.lxd.lxc
snap.lxd.lxc-to-lxd
snap.lxd.lxd
snap.lxd.migrate
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.
As if only snap profiles are loaded.
--
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/1895967
Title:
3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Status in apparmor package in Ubuntu:
Incomplete
Bug description:
Hi,
I stumbled over this due to automatic tests checking proposed.
I found that Focal no more could migrate to Groovy with:
$ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
error: unsupported configuration: Security driver model 'apparmor' is not
available
I looked after it and found that while all former releases detected
apparmor correctly:
$ virsh capabilities | grep -C 3 secmodel
apparmor
0
dac
0
+64055:+108
+64055:+108
Now on groovy that didn't work anymore:
none
0
dac
0
+64055:+108
+64055:+108
Since 3.0 is only in proposed:
# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
3.0.0~beta1-0ubuntu1 500
500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64
Packages
*** 2.13.3-7ubuntu6 500
500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
100 /var/lib/dpkg/status
I installed the former version.
$ apt install apparmor=2.13.3-7ubuntu6
$ rm /var/cache/libvirt/qemu/capabilities/*
$ systemctl restart libvirtd
And it works again.
Interestingly going back to 3.0 then works and keeps working.
Therefore maybe it is a red-herring and I'll consider it incomplete & low
prio for now until I know more (allowing others that might see the same to find
this bug and chime in).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
This gets me back to a working system $ aa-enforce /etc/apparmor.d/usr.sbin.libvirtd $ systemctl restart libvirtd And this also explains why on the system where I re-installed libvirt things might have worked. The re-install runs dh_apparmor which has loaded and enforced it. -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Sorry my system broke down in various way stalling debugging of this for a few days. Back on it ... -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
This is the failing function
221 /* returns -1 on error or profile for libvirtd is unconfined, 0 if
complain
222 * mode and 1 if enforcing. This is required because at present you cannot
223 * aa_change_profile() from a process that is unconfined.
224 */
225 static int
226 use_apparmor(void)
227 {
228 int rc = -1;
229 char *libvirt_daemon = NULL;
230
231 if (virFileResolveLink("/proc/self/exe", _daemon) < 0) {
232 virReportError(VIR_ERR_INTERNAL_ERROR,
233"%s", _("could not find libvirtd"));
234 return rc;
235 }
236
237 /* If libvirt_lxc is calling us, then consider apparmor is used
238 * and enforced. */
239 if (strstr(libvirt_daemon, "libvirt_lxc"))
240 return 1;
241
242 if (access(APPARMOR_PROFILES_PATH, R_OK) != 0)
243 goto cleanup;
244
245 /* First check profile status using full binary path. If that fails
246 * check using profile name.
247 */
248 rc = profile_status(libvirt_daemon, 1);
249 if (rc < 0) {
250 rc = profile_status("libvirtd", 1);
251 /* Error or unconfined should all result in -1 */
252 if (rc < 0)
253 rc = -1;
254 }
255
256 cleanup:
257 VIR_FREE(libvirt_daemon);
258 return rc;
259 }
--
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/1895967
Title:
3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Status in apparmor package in Ubuntu:
Incomplete
Bug description:
Hi,
I stumbled over this due to automatic tests checking proposed.
I found that Focal no more could migrate to Groovy with:
$ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
error: unsupported configuration: Security driver model 'apparmor' is not
available
I looked after it and found that while all former releases detected
apparmor correctly:
$ virsh capabilities | grep -C 3 secmodel
apparmor
0
dac
0
+64055:+108
+64055:+108
Now on groovy that didn't work anymore:
none
0
dac
0
+64055:+108
+64055:+108
Since 3.0 is only in proposed:
# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
3.0.0~beta1-0ubuntu1 500
500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64
Packages
*** 2.13.3-7ubuntu6 500
500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
100 /var/lib/dpkg/status
I installed the former version.
$ apt install apparmor=2.13.3-7ubuntu6
$ rm /var/cache/libvirt/qemu/capabilities/*
$ systemctl restart libvirtd
And it
[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Lookup fails: (gdb) fin Run till exit from #0 virSecurityDriverLookup (name=name@entry=0x0, virtDriver=virtDriver@entry=0x7fffd26ae1b2 "QEMU") at ../../../src/security/security_driver.c:50 virSecurityManagerNew (name=name@entry=0x0, virtDriver=virtDriver@entry=0x7fffd26ae1b2 "QEMU", flags=flags@entry=10) at ../../../src/security/security_manager.c:182 182 ../../../src/security/security_manager.c: No such file or directory. Value returned is $2 = (virSecurityDriver *) 0x77fad4c0 This goes via AppArmorSecurityManagerProbe Good: Value returned is $3 = 0 Bad: Value returned is $5 = -2 -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Need to check the init of the bunch in qemuSecurityInit and qemuSecurityNew. But that happens at daemon start and not later when probing caps. virQEMUDriverConfigLoadSecurityEntry load this from config and it includes apparmor in both: /etc/libvirt/qemu.conf:# security_driver = [ "selinux", "apparmor" ] So the initialization must go wrong in the bad case. virSecurityManagerNew loooks up the driver via virSecurityDriverLookup(name, virtDriver); Then it calls virSecurityManagerNewDriver Already differs here: bad: Thread 17 "daemon-init" hit Breakpoint 1, virSecurityManagerNew (name=name@entry=0x0, virtDriver=virtDriver@entry=0x7fffea6ae1b2 "QEMU", flags=flags@entry=10) at ../../../src/security/security_manager.c:180 180 ../../../src/security/security_manager.c: No such file or directory. (gdb) c Continuing. Thread 17 "daemon-init" hit Breakpoint 2, virSecurityDriverLookup (name=name@entry=0x0, virtDriver=virtDriver@entry=0x7fffea6ae1b2 "QEMU") at ../../../src/security/security_driver.c:50 50 ../../../src/security/security_driver.c: No such file or directory. (gdb) c Continuing. Thread 17 "daemon-init" hit Breakpoint 3, virSecurityManagerNewDriver (drv=0x77fad4c0 , virtDriver=virtDriver@entry=0x7fffea6ae1b2 "QEMU", flags=8) at ../../../src/security/security_manager.c:78 78 ../../../src/security/security_manager.c: No such file or directory. (gdb) c Continuing. Thread 17 "daemon-init" hit Breakpoint 3, virSecurityManagerNewDriver (drv=0x77fad640 , virtDriver=0x7fffea6ae1b2 "QEMU", flags=flags@entry=8) at ../../../src/security/security_manager.c:78 78 in ../../../src/security/security_manager.c Good: Thread 17 "daemon-init" hit Breakpoint 1, virSecurityManagerNew (name=name@entry=0x0, virtDriver=virtDriver@entry=0x7f694365e1b2 "QEMU", flags=flags@entry=10) at ../../../src/security/security_manager.c:180 180 ../../../src/security/security_manager.c: No such file or directory. (gdb) c Continuing. Thread 17 "daemon-init" hit Breakpoint 2, virSecurityDriverLookup (name=name@entry=0x0, virtDriver=virtDriver@entry=0x7f694365e1b2 "QEMU") at ../../../src/security/security_driver.c:50 50 ../../../src/security/security_driver.c: No such file or directory. (gdb) c Continuing. Thread 17 "daemon-init" hit Breakpoint 3, virSecurityManagerNewDriver (drv=0x7f694ff5cae0 , virtDriver=virtDriver@entry=0x7f694365e1b2 "QEMU", flags=10) at ../../../src/security/security_manager.c:78 78 ../../../src/security/security_manager.c: No such file or directory. (gdb) c Continuing. Thread 17 "daemon-init" hit Breakpoint 3, virSecurityManagerNewDriver (drv=0x7f694ff5c640 , virtDriver=0x7f694365e1b2 "QEMU", flags=flags@entry=10) at ../../../src/security/security_manager.c:78 78 in ../../../src/security/security_manager.c P.S. I might need a debug build going further yet I'm unsure if installing that might change the bug conditions. -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions -- Mailing list:
[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Good:
(gdb) p *((virSecurityStackDataPtr)(((virQEMUDriverPtr)conn->privateData
)->securityManager->privateData))->itemsHead->securityManager
$7 = {parent = {parent = {parent_instance = {g_type_instance = {g_class =
0x7f430805ddf0}, ref_count = 1, qdata = 0x0}}, lock = {lock = {__data = {__lock
= 0, __count = 0, __owner = 0,
__nusers = 0, __kind = 512, __spins = 0, __elision = 0, __list =
{__prev = 0x0, __next = 0x0}}, __size = '\000' , "\002",
'\000' ,
__align = 0}}}, drv = 0x7f435aadfae0 , flags
= 10, virtDriver = 0x7f43541e71b2 "QEMU", privateData = 0x0}
(gdb) p *((virSecurityStackDataPtr)(((virQEMUDriverPtr)conn->privateData
)->securityManager->privateData))->itemsHead->next->securityManager
$8 = {parent = {parent = {parent_instance = {g_type_instance = {g_class =
0x7f430805ddf0}, ref_count = 1, qdata = 0x0}}, lock = {lock = {__data = {__lock
= 0, __count = 0, __owner = 0,
__nusers = 0, __kind = 512, __spins = 0, __elision = 0, __list =
{__prev = 0x0, __next = 0x0}}, __size = '\000' , "\002",
'\000' ,
__align = 0}}}, drv = 0x7f435aadf7c0 , flags =
10, virtDriver = 0x7f43541e71b2 "QEMU", privateData = 0x7f430807b180}
Bad:
(gdb) p *((virSecurityStackDataPtr)(((virQEMUDriverPtr)conn->privateData
)->securityManager->privateData))->itemsHead->securityManager
$9 = {parent = {parent = {parent_instance = {g_type_instance = {g_class =
0x7f8b0c0259e0}, ref_count = 1, qdata = 0x0}}, lock = {lock = {__data = {__lock
= 0, __count = 0, __owner = 0,
__nusers = 0, __kind = 512, __spins = 0, __elision = 0, __list =
{__prev = 0x0, __next = 0x0}}, __size = '\000' , "\002",
'\000' ,
__align = 0}}}, drv = 0x7f8b572d24c0 , flags = 8,
virtDriver = 0x7f8b501d91b2 "QEMU", privateData = 0x0}
(gdb) p *((virSecurityStackDataPtr)(((virQEMUDriverPtr)conn->privateData
)->securityManager->privateData))->itemsHead->next->securityManager
$10 = {parent = {parent = {parent_instance = {g_type_instance = {g_class =
0x7f8b0c0259e0}, ref_count = 1, qdata = 0x0}}, lock = {lock = {__data = {__lock
= 0, __count = 0, __owner = 0,
__nusers = 0, __kind = 512, __spins = 0, __elision = 0, __list =
{__prev = 0x0, __next = 0x0}}, __size = '\000' , "\002",
'\000' ,
__align = 0}}}, drv = 0x7f8b572d27c0 , flags =
10, virtDriver = 0x7f8b501d91b2 "QEMU", privateData = 0x7f8b0c07add0}
See virSecurityDriverNop vs virAppArmorSecurityDriver in the above
output
--
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/1895967
Title:
3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Status in apparmor package in Ubuntu:
Incomplete
Bug description:
Hi,
I stumbled over this due to automatic tests checking proposed.
I found that Focal no more could migrate to Groovy with:
$ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
error: unsupported configuration: Security driver model 'apparmor' is not
available
I looked after it and found that while all former releases detected
apparmor correctly:
$ virsh capabilities | grep -C 3 secmodel
apparmor
0
dac
0
+64055:+108
+64055:+108
Now on groovy that didn't work anymore:
none
0
dac
0
+64055:+108
+64055:+108
Since 3.0 is only in proposed:
# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
3.0.0~beta1-0ubuntu1 500
500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64
Packages
*** 2.13.3-7ubuntu6 500
500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
100 /var/lib/dpkg/status
I installed the former version.
$ apt install apparmor=2.13.3-7ubuntu6
$ rm /var/cache/libvirt/qemu/capabilities/*
$ systemctl restart libvirtd
And it works again.
Interestingly going back to 3.0 then works and keeps working.
Therefore maybe it is a red-herring and I'll consider it incomplete & low
prio for now until I know more (allowing others that might see the same to find
this bug and chime in).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
for (i = 0; sec_managers[i]; i++) {
...
VIR_DEBUG("Initialized caps for security driver \"%s\" with "
Good:
- apparmor
- dac
Bad:
- none
- dac
In function virQEMUDriverCreateCapabilities.
So it isn't probing apparmor because it isn't even in the list.
That list is from "qemuSecurityGetNested"
qemuSecurityGetNested == virSecurityManagerGetNested
-> virSecurityStackGetNested(mgr)
The latter iterates on the list priv->itemsHead which is from the
security manager.
That in turn is from driver->securityManager of
virQEMUDriverGetCapabilities(driver)
virCapsPtr virQEMUDriverCreateCapabilities(virQEMUDriverPtr driver)
(gdb) bt
#0 virSecurityStackGetNested (mgr=mgr@entry=0x7f8b0c00dde0) at
../../../src/security/security_stack.c:613
#1 0x7f8b5704f2b8 in virSecurityManagerGetNested (mgr=0x7f8b0c00dde0) at
../../../src/security/security_manager.c:1035
#2 0x7f8b50133970 in virQEMUDriverCreateCapabilities
(driver=0x7f8b0c051550) at ../../../src/qemu/qemu_conf.c:1344
#3 0x7f8b50133c18 in virQEMUDriverGetCapabilities (driver=0x7f8b0c051550,
refresh=) at ../../../src/qemu/qemu_conf.c:1397
#4 0x7f8b5019e0b8 in qemuConnectGetCapabilities (conn=) at
../../../src/qemu/qemu_driver.c:1328
#5 0x7f8b57171953 in virConnectGetCapabilities (conn=0x7f8b28004050) at
../../../src/libvirt-host.c:467
#6 0xa51f16ec in remoteDispatchConnectGetCapabilities
(server=0xa5c1d080, msg=0xa5c2bc80, ret=0x7f8b48000e60,
rerr=0x7f8b51be6920, client=0xa5c2c070)
at ./remote/remote_daemon_dispatch_stubs.h:766
#7 remoteDispatchConnectGetCapabilitiesHelper (server=0xa5c1d080,
client=0xa5c2c070, msg=0xa5c2bc80, rerr=0x7f8b51be6920, args=0x0,
ret=0x7f8b48000e60)
at ./remote/remote_daemon_dispatch_stubs.h:748
#8 0x7f8b5707d470 in virNetServerProgramDispatchCall (msg=0xa5c2bc80,
client=0xa5c2c070, server=0xa5c1d080, prog=0xa5c25810)
at ../../../src/rpc/virnetserverprogram.c:430
#9 virNetServerProgramDispatch (prog=0xa5c25810,
server=server@entry=0xa5c1d080, client=0xa5c2c070, msg=0xa5c2bc80)
at ../../../src/rpc/virnetserverprogram.c:302
#10 0x7f8b570825a8 in virNetServerProcessMsg (msg=,
prog=, client=, srv=0xa5c1d080) at
../../../src/rpc/virnetserver.c:137
#11 virNetServerHandleJob (jobOpaque=0xa5bf97f0, opaque=0xa5c1d080) at
../../../src/rpc/virnetserver.c:154
#12 0x7f8b56f901e2 in virThreadPoolWorker (opaque=) at
../../../src/util/virthreadpool.c:163
#13 0x7f8b56f8f769 in virThreadHelper (data=) at
../../../src/util/virthread.c:233
#14 0x7f8b56c61590 in start_thread (arg=0x7f8b51be7640) at
pthread_create.c:463
#15 0x7f8b56b6c223 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
--
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/1895967
Title:
3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Status in apparmor package in Ubuntu:
Incomplete
Bug description:
Hi,
I stumbled over this due to automatic tests checking proposed.
I found that Focal no more could migrate to Groovy with:
$ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
error: unsupported configuration: Security driver model 'apparmor' is not
available
I looked after it and found that while all former releases detected
apparmor correctly:
$ virsh capabilities | grep -C 3 secmodel
apparmor
0
dac
0
+64055:+108
+64055:+108
Now on groovy that didn't work anymore:
none
0
dac
0
+64055:+108
+64055:+108
Since 3.0 is only in proposed:
# apt-cache policy apparmor
apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
3.0.0~beta1-0ubuntu1 500
500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64
Packages
*** 2.13.3-7ubuntu6 500
500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
100 /var/lib/dpkg/status
I installed the former version.
$ apt install apparmor=2.13.3-7ubuntu6
$ rm /var/cache/libvirt/qemu/capabilities/*
$ systemctl restart libvirtd
And it works again.
Interestingly going back to 3.0 then works and keeps working.
Therefore maybe it is a red-herring and I'll consider it incomplete & low
prio for now until I know more (allowing others that might see the same to find
this bug and chime in).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
It seems once fixed the system is ok and I can't get into the bad state again :/ I tried on another bad system (withotu changing back to the former version) 1. A restart of the service 2. Trying to force capabilities reset (remove cache) + service restart None of these got it into the good case, so I might be able to debug here what happens when probing. -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1895967] [NEW] 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM
Public bug reported: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). ** Affects: apparmor (Ubuntu) Importance: Low Status: Incomplete ** Changed in: apparmor (Ubuntu) Status: New => Incomplete ** Changed in: apparmor (Ubuntu) Importance: Undecided => Low -- 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/1895967 Title: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM Status in apparmor package in Ubuntu: Incomplete Bug description: Hi, I stumbled over this due to automatic tests checking proposed. I found that Focal no more could migrate to Groovy with: $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system error: unsupported configuration: Security driver model 'apparmor' is not available I looked after it and found that while all former releases detected apparmor correctly: $ virsh capabilities | grep -C 3 secmodel apparmor 0 dac 0 +64055:+108 +64055:+108 Now on groovy that didn't work anymore: none 0 dac 0 +64055:+108 +64055:+108 Since 3.0 is only in proposed: # apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu6 Candidate: 3.0.0~beta1-0ubuntu1 Version table: 3.0.0~beta1-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages *** 2.13.3-7ubuntu6 500 500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status I installed the former version. $ apt install apparmor=2.13.3-7ubuntu6 $ rm /var/cache/libvirt/qemu/capabilities/* $ systemctl restart libvirtd And it works again. Interestingly going back to 3.0 then works and keeps working. Therefore maybe it is a red-herring and I'll consider it incomplete & low prio for now until I know more (allowing others that might see the same to find this bug and chime in). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+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 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default
The tests confirmed the issue that Iain reported and that the fix works. Also no other issues popped up in the NM test using it. autopkgtest [08:47:12]: summary wpa-dhclient PASS nm.pyPASS killswitches-no-urfkill PASS urfkill-integration PASS And while https://bileto.ubuntu.com/excuses/4266/groovy.html looks pretty bad after we skip the known badtests not much is left and of those nothing seems to be due to this change. I replied upstream hoping they will accept the change so we can then push it to groovy (sooner or later we have to even without upstream saying "yes" but I'd prefer to pick exactly what is committed). => http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014387.html Actually since this holds back other things, let us upload to groovy now (it essentially reverts to old behavior) but come back in a week to potentially update to whatever upstream did by then. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1894619 Title: [2.82 regression] router announcements have 'forever' lifetime by default Status in dnsmasq package in Ubuntu: Triaged Bug description: The default lifetime was changed to 1 day in 2.82 in the change corresponding to this changelog entry: Change default lease time for DHCPv6 to one day. Fine, but the same commit also did this: Alter calculation of preferred and valid times in router advertisements, so that these do not have a floor applied of the lease time in the dhcp-range if this is not explicitly specified and is merely the default. And that change is buggy and causes advertisements to have infinite lifetime, when you are using the default. See this thread http://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2020q3/014341.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+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 1895576] Re: boot-and-services in tests-in-lxd autopkgtest fails in groovy on s390x
For now the hint is in groovy, but the next systemd upload needs to resolve it one (fix) or the other (mark this one as flaky) way. -- 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/1895576 Title: boot-and-services in tests-in-lxd autopkgtest fails in groovy on s390x Status in systemd package in Ubuntu: New Bug description: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- groovy/groovy/s390x/s/systemd/20200903_184028_2bbdf@/log.gz ... test_rsyslog (__main__.ServicesTest) ... FAIL test_tmp_cleanup (__main__.ServicesTest) ... ok test_tmp_mount (__main__.ServicesTest) ... ok test_udev (__main__.ServicesTest) ... skipped 'udev does not work in containers' == FAIL: test_rsyslog (__main__.ServicesTest) -- Traceback (most recent call last): File "/tmp/autopkgtest.15TVnz/build.ZVh/real-tree/debian/tests/boot-and-services", line 120, in test_rsyslog self.assertRegex(log, 'systemd.*Reached target Graphical Interface') ... Interestingly it does not fail locally on an s390x Focal VM running boot-and-services in LXD. Kernel: Linux juju-d7a408-generic-21 5.4.0-14-generic Also interestingly it is passing with cryptsetup/2:2.3.3-1ubuntu5 glibc/2.32-0ubuntu2. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895576/+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 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default
FYI: builds complete - Running the test builds of network- manager_1.26.2-1ubuntu1.dsc in groovy against the proposed and the PPA version. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1894619 Title: [2.82 regression] router announcements have 'forever' lifetime by default Status in dnsmasq package in Ubuntu: Triaged Bug description: The default lifetime was changed to 1 day in 2.82 in the change corresponding to this changelog entry: Change default lease time for DHCPv6 to one day. Fine, but the same commit also did this: Alter calculation of preferred and valid times in router advertisements, so that these do not have a floor applied of the lease time in the dhcp-range if this is not explicitly specified and is merely the default. And that change is buggy and causes advertisements to have infinite lifetime, when you are using the default. See this thread http://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2020q3/014341.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+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 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default
Ok changed MP and PPA to work for 1.0 source -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1894619 Title: [2.82 regression] router announcements have 'forever' lifetime by default Status in dnsmasq package in Ubuntu: Triaged Bug description: The default lifetime was changed to 1 day in 2.82 in the change corresponding to this changelog entry: Change default lease time for DHCPv6 to one day. Fine, but the same commit also did this: Alter calculation of preferred and valid times in router advertisements, so that these do not have a floor applied of the lease time in the dhcp-range if this is not explicitly specified and is merely the default. And that change is buggy and causes advertisements to have infinite lifetime, when you are using the default. See this thread http://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2020q3/014341.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+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 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default
Arrr 1.0 source, need to apply differently -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1894619 Title: [2.82 regression] router announcements have 'forever' lifetime by default Status in dnsmasq package in Ubuntu: Triaged Bug description: The default lifetime was changed to 1 day in 2.82 in the change corresponding to this changelog entry: Change default lease time for DHCPv6 to one day. Fine, but the same commit also did this: Alter calculation of preferred and valid times in router advertisements, so that these do not have a floor applied of the lease time in the dhcp-range if this is not explicitly specified and is merely the default. And that change is buggy and causes advertisements to have infinite lifetime, when you are using the default. See this thread http://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2020q3/014341.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+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 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default
BTW I randomly picked the latter patch of the two as no one seems to have jumped on the first one and said "yes let us apply it". -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1894619 Title: [2.82 regression] router announcements have 'forever' lifetime by default Status in dnsmasq package in Ubuntu: Triaged Bug description: The default lifetime was changed to 1 day in 2.82 in the change corresponding to this changelog entry: Change default lease time for DHCPv6 to one day. Fine, but the same commit also did this: Alter calculation of preferred and valid times in router advertisements, so that these do not have a floor applied of the lease time in the dhcp-range if this is not explicitly specified and is merely the default. And that change is buggy and causes advertisements to have infinite lifetime, when you are using the default. See this thread http://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2020q3/014341.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+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 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default
The patch suggested at http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014346.html isn't applied yet. I guess this waits for feedback if it worked before they apply it. To get this going here a PPA and an associated MP: PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4266 MP: https://code.launchpad.net/~paelzer/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/390832 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1894619 Title: [2.82 regression] router announcements have 'forever' lifetime by default Status in dnsmasq package in Ubuntu: Triaged Bug description: The default lifetime was changed to 1 day in 2.82 in the change corresponding to this changelog entry: Change default lease time for DHCPv6 to one day. Fine, but the same commit also did this: Alter calculation of preferred and valid times in router advertisements, so that these do not have a floor applied of the lease time in the dhcp-range if this is not explicitly specified and is merely the default. And that change is buggy and causes advertisements to have infinite lifetime, when you are using the default. See this thread http://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2020q3/014341.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+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 1892559] Re: [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite
Sorry, I forgot to update one section for pcsc-lite on packaging: - important open bugs (crashers, etc) in Debian or Ubuntu There are quite some: https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bugs?field.searchtext=crash=Search%3Alist=NEW%3Alist=INCOMPLETE_WITH_RESPONSE%3Alist=INCOMPLETE_WITHOUT_RESPONSE%3Alist=CONFIRMED%3Alist=TRIAGED%3Alist=INPROGRESS%3Alist=FIXCOMMITTED=_reporter=_dupes=on_patch=_no_package==-date_last_updated=0 Also this one should be fixed or at least checked https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930530 I have already had that in my overall summary, just the details were missing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pcsc-lite in Ubuntu. https://bugs.launchpad.net/bugs/1892559 Title: [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite Status in ccid package in Ubuntu: New Status in opensc package in Ubuntu: Incomplete Status in pam-pkcs11 package in Ubuntu: New Status in pcsc-lite package in Ubuntu: New Status in pcsc-perl package in Ubuntu: Invalid Status in pcsc-tools package in Ubuntu: Invalid Bug description: ==> ccid <== [Availability] ccid is in universe, and builds on all architectures. [Rationale] The desktop team and security team are interested in bringing smartcard authentication to enterprise desktop environments. [Security] No CVEs for ccid are listed in our database. Doesn't appear to bind to a socket. No privileged executables, but does have udev rules. Probably needs a security review. [Quality assurance] No test suite. Does require odd hardware that we'll probably need to buy. I don't see debconf questions. ccid is well maintained in Debian by upstream author. One open wishlist bug in BTS, harmless. One open bug in launchpad, not security, but looks very frustrating for the users. The upstream author was engaged but it never reached resolution. https://bugs.launchpad.net/ubuntu/+source/ccid/+bug/1175465 Has a debian/watch file. Quilt packaging. P: ccid source: no-dep5-copyright P: ccid source: package-uses-experimental-debhelper-compat-version 13 [Dependencies] Minimal dependencies, in main [Standards compliance] Appears to satisfy FHS and Debian policy [Maintenance] The desktop team will subscribe to bugs, however it is expected that the security team will assist with security-relevant questions. [Background information] ccid provides drivers to interact with usb-connected smart card readers. ==> libpam-pkcs11 <== [Availability] Source package pam-pkcs11 is in universe and builds on all architectures. [Rationale] The desktop team and security team are interested in bringing smartcard authentication to enterprise desktop environments. [Security] No CVEs in our database. Doesn't appear to bind to sockets. No privileged executables (but is a PAM module). As a PAM module this will require a security review. [Quality assurance] The package does not call pam-auth-update in its postinst #1650366 Does not ask questions during install. One Ubuntu bug claims very poor behaviour if a card isn't plugged in. No Debian bugs. Occasional updates in Debian by long-term maintainer. Does require odd hardware that we'll probably need to buy. Does not appear to run tests during build. Has scary warnings in the build logs. Has a debian/watch file. Ancient standards version; other smaller lintian messages, mostly documentation problems. Quilt packaging. [Dependencies] Depends on libcurl4, libldap-2.4-2, libpam0g, libpcsclite1, libssl1.1 All are in main. [Standards compliance] The package does not call pam-auth-update in its postinst #1650366 Otherwise looks to conform to FHS and Debian policies [Maintenance] The desktop team will subscribe to bugs, however it is expected that the security team will assist with security-relevant questions. [Background information] This PAM module can use CRLs and full-chain verification of certificates. It can also do LDAP, AD, and Kerberos username mapping. ==> libpcsc-perl <== [Availability] Source package pcsc-perl is in universe, builds for all architectures, plus i386 [Rationale] The desktop team and security team are interested in bringing smartcard authentication to enterprise desktop environments. [Security] There are no cves for pcsc-perl in our database. No privileged executables. Doesn't appear to bind to sockets. Probably needs a security review. [Quality assurance] Library package not intended to be used directly. No debconf questions. No bugs in Debian. No bugs in Ubuntu. Does require odd hardware that we'll probably need to buy. Tests exist, not run during the build; probably can't run during the build. Includes debian/watch file. A handful of lintian issues Quilt packaging. [Dependencies]
[Touch-packages] [Bug 1892559] Re: [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite
## pcsc-lite ## [Summary] Mir Team ACK under the condition that the required TODOs are resolved. While the owning Team should look at that security can already start a review. This does need a security review, so I'll assign ubuntu-security list specific binary packages to be promoted to main: pcscd, libpcsclite1 Clarifications: - @Seth - the filing is done as if one would only need libpcsclite1 but Joy said in comment #12 that pcscd is also needed. Could you clarify which is true as the security risk increases if we add the daemon as well. For now I'll go on as if the daemon would be part of it. Required TODOs: - The package has no team bug subscriber - please fix - Please look into open bugs and crashes before we promote. Do a bug-scrub and ensure we know what is outdated and no more true and what else is still an issue. This can be seen as preview to the latter maintenance - so don't skip all of them due to "don't have the HW" :-) [Duplication] There is no other package in main providing the same functionality. Note: Joy checked if the other bits can do it without but it is required. See comment #12. [Dependencies] OK: - no other Dependencies to MIR due to this - one -dev package that will be auto-promoted but no bad deps from there [Embedded sources and static linking] OK: - no embedded source present - no static linking [Security] OK: - history of CVEs does not look too concerning - does not run a daemon as root - does not use webkit1,2 - does not use lib*v8 directly - does not process arbitrary web content - does not use centralized online accounts - does not integrate arbitrary javascript into the desktop Problems: - does parse data formats - does open a port - does deal with system authentication (eg, pam), etc) This needs a security review, before doing so please clarify if the daemon pcscsd is part of the scope. [Common blockers] OK: - does not FTBFS currently - no translation present, but none needed for this case (user visible)? - not a python/go package, no extra constraints to consider int hat regard Problems: - does not have a test suite that runs at build time - does not have a test suite that runs as autopkgtest We have talked about tests before, no reason to re-iterate - The package has no team bug subscriber - please fix [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking is in place - d/watch is present and looks ok - Upstream update history is good - Debian/Ubuntu update history is good - the current release is packaged - promoting this does not seem to cause issues for MOTUs that so far maintained the package - no massive Lintian warnings - d/rules is rather clean - Does not have Built-Using [Upstream red flags] OK: - no Errors/warnings during the build - no incautious use of malloc/sprintf (as far as I can check it) - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH - no use of user nobody - no use of setuid - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit, seed or libgoa-* - no embedded source copies - not part of the UI for extra checks ** Changed in: pcsc-lite (Ubuntu) Assignee: Christian Ehrhardt (paelzer) => Ubuntu Security Team (ubuntu-security) ** Bug watch added: Debian Bug tracker #930530 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930530 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pcsc-lite in Ubuntu. https://bugs.launchpad.net/bugs/1892559 Title: [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite Status in ccid package in Ubuntu: New Status in opensc package in Ubuntu: Incomplete Status in pam-pkcs11 package in Ubuntu: New Status in pcsc-lite package in Ubuntu: New Status in pcsc-perl package in Ubuntu: Invalid Status in pcsc-tools package in Ubuntu: Invalid Bug description: ==> ccid <== [Availability] ccid is in universe, and builds on all architectures. [Rationale] The desktop team and security team are interested in bringing smartcard authentication to enterprise desktop environments. [Security] No CVEs for ccid are listed in our database. Doesn't appear to bind to a socket. No privileged executables, but does have udev rules. Probably needs a security review. [Quality assurance] No test suite. Does require odd hardware that we'll probably need to buy. I don't see debconf questions. ccid is well maintained in Debian by upstream author. One open wishlist bug in BTS, harmless. One open bug in launchpad, not security, but looks very frustrating for the users. The upstream author was engaged but it never reached resolution. https://bugs.launchpad.net/ubuntu/+source/ccid/+bug/1175465 Has a debian/watch file. Quilt packaging. P: ccid source: no-dep5-copyright P: ccid source: package-uses-experimental-debhelper-compat-version 13 [Dependencies] Minimal dependencies, in
