[Group.of.nepali.translators] [Bug 2044657] Re: Multiple data corruption issues in zfs
** Changed in: zfs-linux (Ubuntu Noble) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/2044657 Title: Multiple data corruption issues in zfs Status in zfs-linux package in Ubuntu: Fix Released Status in zfs-linux source package in Xenial: Confirmed Status in zfs-linux source package in Bionic: Confirmed Status in zfs-linux source package in Focal: Confirmed Status in zfs-linux source package in Jammy: Confirmed Status in zfs-linux source package in Lunar: Confirmed Status in zfs-linux source package in Mantic: Incomplete Status in zfs-linux source package in Noble: Fix Released Bug description: [ Impact ] * Multiple data corruption issues have been identified and fixed in ZFS. Some of them, at varying real-life reproducibility frequency have been deterimed to affect very old zfs releases. Recommendation is to upgrade to 2.2.2 or 2.1.14 or backport dnat patch alone. This is to ensure users get other potentially related fixes and runtime tunables to possibly mitigate other bugs that are related and are being fixed upstream for future releases. * For jammy the 2.1.14 upgrade will bring HWE kernel support and also compatiblity/support for hardened kernel builds that mitigate SLS (straight-line-speculation). [ Test Plan ] * !!! Danger !!! use reproducer from https://zfsonlinux.topicbox.com/groups/zfs-discuss/T12876116b8607cdb and confirm if that issue is resolved or not. Do not run on production ZFS pools / systems. * autopkgtest pass (from https://ubuntu-archive- team.ubuntu.com/proposed-migration/ ) * adt-matrix pass (from https://kernel.ubuntu.com/adt-matrix/ ) * kernel regression zfs testsuite pass (from Kernel team RT test results summary, private) * zsys integration test pass (upgrade of zsys installed systems for all releases) * zsys install test pass (for daily images of LTS releases only that have such installer support, as per iso tracker test case) * LXD (ping LXD team to upgrade vendored in tooling to 2.2.2 and 2.1.14, and test LXD on these updated kernels) [ Where problems could occur ] * Upgrade to 2.1.14 on jammy with SLS mitigations compatiblity will introduce slight slow down on amd64 (for hw accelerated assembly code-paths only in the encryption primitives) * Uncertain of the perfomance impact of the extra checks in dnat patch fix itself. Possibly affecting speed of operation, at the benefit of correctness. [ Other Info ] * https://github.com/openzfs/zfs/pull/15571 is most current consideration of affairs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044657/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 2004391] Re: xenial/linux-aws-hwe: 4.15.0-1151.164~16.04.1 -proposed tracker
The build is correct w.r.t. builtin revocations and the vmlinuz signature. However for the furture uploads sbsigntools build-depends should be added on the -signed package. ** Also affects: kernel-sru-workflow/kernel-signoff Importance: Undecided Status: New ** Changed in: kernel-sru-workflow/kernel-signoff Status: New => Fix Released ** Changed in: kernel-sru-workflow/kernel-signoff Assignee: (unassigned) => Dimitri John Ledkov (xnox) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/2004391 Title: xenial/linux-aws-hwe: 4.15.0-1151.164~16.04.1 -proposed tracker Status in canonical-signing-jobs task00 series: Fix Released Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Invalid Status in Kernel SRU Workflow boot-testing series: Fix Released Status in Kernel SRU Workflow certification-testing series: Invalid Status in Kernel SRU Workflow kernel-signoff series: Fix Released Status in Kernel SRU Workflow new-review series: Fix Released Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-generate series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-signing-to-proposed series: Invalid Status in Kernel SRU Workflow promote-to-proposed series: Fix Committed Status in Kernel SRU Workflow promote-to-security series: Invalid Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: New Status in Kernel SRU Workflow security-signoff series: Invalid Status in Kernel SRU Workflow sru-review series: Fix Released Status in Kernel SRU Workflow verification-testing series: New Status in linux-aws-hwe source package in Xenial: Confirmed Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- built: from: d013442608a07737 route-entry: 1 delta: promote-to-proposed: [meta, signed, main, generate] flag: boot-testing-requested: true stream-from-cycle: true issue: KSRU-6505 kernel-stable-master-bug: 2004392 packages: generate: linux-generate-aws-hwe main: linux-aws-hwe meta: linux-meta-aws-hwe signed: linux-signed-aws-hwe phase: Promote to Proposed phase-changed: Friday, 24. February 2023 20:16 UTC reason: promote-to-proposed: Pending -- packages copying to Signing (main:M generate:M signed:M meta:M) synthetic: :promote-to-as-proposed: Invalid variant: debs versions: main: 4.15.0-1151.164~16.04.1 meta: 4.15.0.1151.134 signed: 4.15.0-1151.164~16.04.1 ~~: clamps: new-review: d013442608a07737 promote-to-proposed: d013442608a07737 self: 4.15.0-1151.164~16.04.1 sru-review: d013442608a07737 To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-signing-jobs/task00/+bug/2004391/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 2004407] Re: xenial/linux-oracle: 4.15.0-1115.126~16.04.1 -proposed tracker
** Also affects: kernel-sru-workflow/kernel-signoff Importance: Undecided Status: New ** Changed in: kernel-sru-workflow/kernel-signoff Status: New => Fix Released ** Changed in: kernel-sru-workflow/kernel-signoff Assignee: (unassigned) => Dimitri John Ledkov (xnox) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/2004407 Title: xenial/linux-oracle: 4.15.0-1115.126~16.04.1 -proposed tracker Status in canonical-signing-jobs task00 series: Fix Released Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Invalid Status in Kernel SRU Workflow boot-testing series: Fix Released Status in Kernel SRU Workflow certification-testing series: Invalid Status in Kernel SRU Workflow kernel-signoff series: Fix Released Status in Kernel SRU Workflow new-review series: Fix Released Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-generate series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-signing-to-proposed series: Invalid Status in Kernel SRU Workflow promote-to-proposed series: Fix Committed Status in Kernel SRU Workflow promote-to-security series: Invalid Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: New Status in Kernel SRU Workflow security-signoff series: Invalid Status in Kernel SRU Workflow sru-review series: Fix Released Status in Kernel SRU Workflow verification-testing series: New Status in linux-oracle source package in Xenial: Confirmed Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- built: from: 3ffa4673de8b0a71 route-entry: 1 delta: promote-to-proposed: [meta, signed, main, generate] flag: boot-testing-requested: true stream-from-cycle: true issue: KSRU-6521 kernel-stable-master-bug: 2004408 packages: generate: linux-generate-oracle main: linux-oracle meta: linux-meta-oracle signed: linux-signed-oracle phase: Promote to Proposed phase-changed: Monday, 20. February 2023 14:16 UTC reason: promote-to-proposed: Pending -- packages copying to Signing (main:M generate:M signed:M meta:M) synthetic: :promote-to-as-proposed: Invalid variant: debs versions: main: 4.15.0-1115.126~16.04.1 meta: 4.15.0.1115.96 signed: 4.15.0-1115.126~16.04.1 ~~: clamps: new-review: 3ffa4673de8b0a71 promote-to-proposed: 3ffa4673de8b0a71 self: 4.15.0-1115.126~16.04.1 sru-review: 3ffa4673de8b0a71 To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-signing-jobs/task00/+bug/2004407/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1936857] Re: grub-install: error: efibootmgr: not found.
** Tags added: bionic regression-proposed ** Package changed: grub2 (Ubuntu) => grub2-signed (Ubuntu) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1936857 Title: grub-install: error: efibootmgr: not found. Status in grub2-signed package in Ubuntu: New Status in grub2-signed source package in Xenial: Confirmed Status in grub2-signed source package in Bionic: Confirmed Bug description: grub-install from 2.02~beta2-36ubuntu3.32 on xenial/arm64 fails with: ubuntu@ubuntu:~$ sudo grub-install Installing for arm64-efi platform. grub-install: error: efibootmgr: not found. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1936857/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1979200] [NEW] check-tasks
Public bug reported: check-tasks ** Affects: hello (Ubuntu) Importance: Undecided Status: New ** Affects: hello (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: hello (Ubuntu Focal) Importance: Undecided Status: New ** Affects: hello (Ubuntu Impish) Importance: Undecided Status: New ** Affects: hello (Ubuntu Jammy) Importance: Undecided Status: New ** Affects: hello (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: hello (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: hello (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: hello (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: hello (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: hello (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1979200 Title: check-tasks Status in hello package in Ubuntu: New Status in hello source package in Xenial: New Status in hello source package in Focal: New Status in hello source package in Impish: New Status in hello source package in Jammy: New Status in hello source package in Kinetic: New Bug description: check-tasks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hello/+bug/1979200/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1928648] Re: expiring trust anchor compatibility issue
** Changed in: gnutls28 (Ubuntu Trusty) Status: Confirmed => Won't Fix ** Also affects: gnutls28 (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1928648 Title: expiring trust anchor compatibility issue Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls28 source package in Precise: Won't Fix Status in gnutls28 source package in Trusty: Won't Fix Status in gnutls28 source package in Xenial: Fix Released Status in gnutls28 source package in Bionic: Fix Released Status in gnutls28 source package in Focal: New Bug description: [Impact] * gnutls28 fails to talk to letsencrypt website past September 2021, despite trusting the letsencrypt root certificate. [Test Plan] * Import staging cert equivalent to ISRG Root X1 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem * Import expired staging cert equivalen tto DST Root CA X3 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem * Test connectivity to the expired-root-ca test website https://expired-root-ca-test.germancoding.com setup: apt install wget gnutls-bin wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem test case: gnutls-cli --x509cafile=ca.pem expired-root-ca-test.germancoding.com bad result: - Status: The certificate is NOT trusted. The certificate chain uses expired certificate. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** handshake has failed: Error in the certificate. good result: - Status: The certificate is trusted. - Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) - Session ID: A8:2B:AF:85:54:64:3A:79:81:99:16:D4:6D:9A:FC:30:F1:EC:49:A4:09:A9:0C:31:37:38:C2:0E:73:C7:C9:04 - Options: OCSP status request, - Handshake was completed Connection should be successful and trusted with correctly working gnutls client that can manage to ignore expired CA, and build a valid trust path using non-expired CA in the chain. [Where problems could occur] * Changes as to how the trust paths are built in TLS connection may result in introducing bugs (failure to connect to valid sites) and/or security vulnerabilities (connecting to invalid sites successfully). [Other Info] * Background info * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues when using old gnutls/openssl against websites using the default letsencrypt configuration after September 2021. https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816 https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817 Currently gnutls28 in bionic and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in GnuTLS 3.6.14, but probably should be backported to bionic and earlier if it was not already been done so. https://gitlab.com/gnutls/gnutls/-/issues/1008 https://gitlab.com/gnutls/gnutls/-/merge_requests/1271 Openssl bug report for this issue is https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 Bionic packages available from https://launchpad.net/~ci-train-ppa- service/+archive/ubuntu/4661 Xenial packages available from https://launchpad.net/~ci-train-ppa- service/+archive/ubuntu/4663 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1928679] Re: Support importing mokx keys into revocation list from the mok table
** Also affects: linux-azure-5.8 (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-azure-5.8 (Ubuntu Hirsute) Status: New => Invalid ** Changed in: linux-azure-5.8 (Ubuntu) Status: New => Invalid ** Changed in: linux-azure-5.8 (Ubuntu Bionic) Status: New => Invalid ** Changed in: linux-azure-5.8 (Ubuntu Xenial) Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1928679 Title: Support importing mokx keys into revocation list from the mok table Status in linux package in Ubuntu: Fix Released Status in linux-azure-5.8 package in Ubuntu: Invalid Status in linux-oem-5.10 package in Ubuntu: Invalid Status in linux source package in Xenial: New Status in linux-azure-5.8 source package in Xenial: Invalid Status in linux-oem-5.10 source package in Xenial: Invalid Status in linux source package in Bionic: New Status in linux-azure-5.8 source package in Bionic: Invalid Status in linux-oem-5.10 source package in Bionic: Invalid Status in linux source package in Focal: New Status in linux-azure-5.8 source package in Focal: New Status in linux-oem-5.10 source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Status in linux-azure-5.8 source package in Hirsute: Invalid Status in linux-oem-5.10 source package in Hirsute: Invalid Bug description: [Impact] * Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx) which revokes many Ubuntu kernel hashes and 2012 signing key. * Kernel should import those into it's %:.blacklist keyring such that it prohibits signed kexec of the revoked kernels. * v5.13-rc1 kernel has learned how to import mokx and how to import full certs into the %:.blacklist keyring. * However, it only does so by reading MokListXRT efi variable. * Due to the large size of Ubuntu's vendor-dbx, shim does not create MokListXRT efi variable, but instead creates MokListXRT1 MokListXRT2 MokListXRT3 which currently v5.13-rc1 kernel cannot read. Shim also exposes MokListXRT via mokvar table, which is easier to parse and contains all the revocations in full. Kernel needs a patch to read MokListXRT via mokvar table. * We have two options on how to proceed from here, either we include the same hashes and certs as our vendordbx in in the kernel as revocation list, or we fix kernel to read MokListXRT via mokvar table * The above is known as CVE-2020-26541 * Separately it would be nice to add informational dmesg messages when revoking signing certificates, as a good indication that signing key rotation events have happened and have been applied correctly. [Test Plan] * Boot kernel with 15.4 based Ubuntu shim * Install keyutils package * Execute $ sudo keyctl list %:.blacklist it should list in exccess of 300+ hash entries. It also must list assymetric Canonical signing key from 2012. * Separately check dmesg to observe that asymmetric canonical signing key from 2012 is revoked. * $ sudo ls /sys/firmware/efi/mok-variables MokListRT MokListXRT SbatLevelRT When booted with shim, the mok-variables directory above should exist, and contain at least `MokListRT MokListXRT SbatLevelRT` files. In kernel messages, the CA certificate should be loaded via MOKvar table i.e: * $ sudo journalctl -b -k | grep -A1 'MOKvar table' Sep 27 13:11:04 champion-spaniel kernel: integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table) Sep 27 13:11:04 champion-spaniel kernel: integrity: Loaded X.509 cert 'Canonical Ltd. Master Certificate Authority: ad91990bc22ab1f517048c23b6655a268e345a63 [Where problems could occur] * EFI variable storage can be full thus preventing shim to mirror efivars and the moktable. On decent hardware this should not happen, but has been observed to be corrupted on some older EDKII based OVMF instances with small EFI variable storage space (pre-4MB). [Other Info] * The patches to fix the above have been submitted upstream https://lore.kernel.org/keyrings/20210512153100.285169-1-dimitri.led...@canonical.com/ https://lore.kernel.org/keyrings/20210512110302.262104-1-dimitri.led...@canonical.com/ This will now be submitted as SAUCE patches for the Ubuntu UNSTABLE kernel, until accepted upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928679/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1932029] Re: Support builtin revoked certificates
** Also affects: linux-azure-5.8 (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-azure-5.8 (Ubuntu Hirsute) Status: New => Invalid ** Changed in: linux-azure-5.8 (Ubuntu Bionic) Status: New => Invalid ** Changed in: linux-azure-5.8 (Ubuntu Xenial) Status: New => Invalid ** Changed in: linux-azure-5.8 (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1932029 Title: Support builtin revoked certificates Status in linux package in Ubuntu: Fix Released Status in linux-azure-5.8 package in Ubuntu: Invalid Status in linux-oem-5.10 package in Ubuntu: Invalid Status in linux source package in Xenial: New Status in linux-azure-5.8 source package in Xenial: Invalid Status in linux-oem-5.10 source package in Xenial: Invalid Status in linux source package in Bionic: New Status in linux-azure-5.8 source package in Bionic: Invalid Status in linux-oem-5.10 source package in Bionic: Invalid Status in linux source package in Focal: New Status in linux-azure-5.8 source package in Focal: New Status in linux-oem-5.10 source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Status in linux-azure-5.8 source package in Hirsute: Invalid Status in linux-oem-5.10 source package in Hirsute: Invalid Bug description: [Impact] Upstream linux kernel now supports configuring built-in revoked certificates for the .blacklist keyring. Add support in our kernel configuration to have built-in revoked certificates. Revoke UEFI amd64 & arm64 2012 signing certificate. Under UEFI Secureboot with lockdown, shim may attempt to communicate revoked certificates to the kernel and depending on how good EFI firmware is, this may or may not succeed. By having these built-in, it will be prohibited to kexec file_load older kernels that were signed with now revoked certificates, however one boots. [Test Plan] * Boot kernel directly, or just with grub, and without shim * Check that $ sudo keyctl list %:.blacklist Contains assymetric 2012 key. [Where problems could occur] * Derivative and per-arch kernels may need to revoke different keys, thus this should be evaluated on per arch & flavour basis as to which keys to revoke. [Other Info] * In theory, this only needs to be revoked on amd64 and arm64, but empty revocation list is not allowed by the kernel configury, thus at the moment revoking 2012 UEFI cert for all architectures. * an ubuntu kernel team regression test is being added to assert that expected revoked certificates have been revoked see https://lists.ubuntu.com/archives/kernel-team/2021-August/122986.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932029/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1928648] Re: expiring trust anchor compatibility issue
** Changed in: gnutls28 (Ubuntu Bionic) Status: New => In Progress ** Changed in: gnutls28 (Ubuntu Precise) Status: New => Won't Fix ** Changed in: gnutls28 (Ubuntu Bionic) Assignee: (unassigned) => Dimitri John Ledkov (xnox) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1928648 Title: expiring trust anchor compatibility issue Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls28 source package in Precise: Won't Fix Status in gnutls28 source package in Trusty: New Status in gnutls28 source package in Xenial: New Status in gnutls28 source package in Bionic: In Progress Bug description: [Impact] * gnutls28 fails to talk to letsencrypt website past September 2021, despite trusting the letsencrypt root certificate. [Test Plan] * Import staging cert equivalent to ISRG Root X1 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem * Import expired staging cert equivalen tto DST Root CA X3 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem * Test connectivity to the expired-root-ca test website https://expired-root-ca-test.germancoding.com setup: apt install wget gnutls-bin wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem test case: gnutls-cli --x509cafile=ca.pem expired-root-ca-test.germancoding.com bad result: - Status: The certificate is NOT trusted. The certificate chain uses expired certificate. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** handshake has failed: Error in the certificate. good result: - Status: The certificate is trusted. - Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) - Session ID: A8:2B:AF:85:54:64:3A:79:81:99:16:D4:6D:9A:FC:30:F1:EC:49:A4:09:A9:0C:31:37:38:C2:0E:73:C7:C9:04 - Options: OCSP status request, - Handshake was completed Connection should be successful and trusted with correctly working gnutls client that can manage to ignore expired CA, and build a valid trust path using non-expired CA in the chain. [Where problems could occur] * Changes as to how the trust paths are built in TLS connection may result in introducing bugs (failure to connect to valid sites) and/or security vulnerabilities (connecting to invalid sites successfully). [Other Info] * Background info * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues when using old gnutls/openssl against websites using the default letsencrypt configuration after September 2021. https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816 https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817 Currently gnutls28 in bionic and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in GnuTLS 3.6.14, but probably should be backported to bionic and earlier if it was not already been done so. https://gitlab.com/gnutls/gnutls/-/issues/1008 https://gitlab.com/gnutls/gnutls/-/merge_requests/1271 Openssl bug report for this issue is https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1928989] [NEW] expiring trust anchor compatibility issue
Public bug reported: [Impact] * openssl fails to talk to letsencrypt website past September 2021, despite trusting the letsencrypt root certificate. [Test Plan] * Import staging cert equivalent to ISRG Root X1 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem * Import expired staging cert equivalen tto DST Root CA X3 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem * Test connectivity to the expired-root-ca test website https://expired-root-ca-test.germancoding.com setup: apt install openssl wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem test case: openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem bad result: connection failed good result: connection successful Connection should be successful and trusted with correctly working openssl s_client that can manage to ignore expired CA, and build a valid trust path using non-expired CA in the chain. [Where problems could occur] * Changes as to how the trust paths are built in TLS connection may result in introducing bugs (failure to connect to valid sites) and/or security vulnerabilities (connecting to invalid sites successfully). [Other Info] * Background info * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues when using old gnutls/openssl against websites using the default letsencrypt configuration after September 2021. https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816 https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817 Currently openssl in xenial and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in OpenSSL 1.1.0+ by setting X509_V_FLAG_TRUSTED_FIRST by default see https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c gnutls bug for this is https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648 ** Affects: openssl (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: openssl (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: openssl (Ubuntu Xenial) Importance: Undecided Status: New ** Tags: letsencrypt ** Also affects: openssl (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: openssl (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1928989 Title: expiring trust anchor compatibility issue Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Trusty: New Status in openssl source package in Xenial: New Bug description: [Impact] * openssl fails to talk to letsencrypt website past September 2021, despite trusting the letsencrypt root certificate. [Test Plan] * Import staging cert equivalent to ISRG Root X1 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem * Import expired staging cert equivalen tto DST Root CA X3 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem * Test connectivity to the expired-root-ca test website https://expired-root-ca-test.germancoding.com setup: apt install openssl wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem test case: openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem bad result: connection failed good result: connection successful Connection should be successful and trusted with correctly working openssl s_client that can manage to ignore expired CA, and build a valid trust path using non-expired CA in the chain. [Where problems could occur] * Changes as to how the trust paths are built in TLS connection may result in introducing bugs (failure to connect to valid sites) and/or security vulnerabilities (connecting to invalid sites successfully). [Other Info] * Background info * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues w
[Group.of.nepali.translators] [Bug 1928674] [NEW] due to a new recommends grub-efi-arm64-signed is installed which does not have postinst.d script
*** This bug is a security vulnerability *** Public security bug reported: [Impact] * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64 with grub-efi-arm64-signed installed, without grub-efi-arm64. * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64 with grub-efi-amd64-signed installed without grub-pc or grub-efi-amd64. * This results in newly installed kernels not getting added to grub.cfg and thus upon reboot one does not boot into the new kernel. * In later series these scripts moved to grub2-common. Maybe we should move these to grub2-common in bionic and earlier too, for compatibility with onegrub. Or alternatively grub2-signed should ship these in grub- efi-{amd64,arm64}-signed packages too. [Test Plan] * Install new grubs * Install a new kernel that was not installed before * Observe that grub.cfg is regenerated and new kernel is present * Remove an old kernel * Observe that grub.cfg is regenerated and new kernel is removed from grub.cfg [Where problems could occur] * These are conffiles. Although nobody should modify them, care should be taken when moving conffiles around. [Other Info] * First reported by klebers ** Affects: grub2-signed (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: grub2-signed (Ubuntu Trusty) Importance: Undecided Status: Triaged ** Affects: grub2-signed (Ubuntu Xenial) Importance: Undecided Status: Triaged ** Affects: grub2-signed (Ubuntu Bionic) Importance: Undecided Status: Triaged ** Also affects: grub2-signed (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu Bionic) Importance: Undecided Status: New ** Information type changed from Public to Public Security ** Changed in: grub2-signed (Ubuntu) Status: New => Fix Released ** Changed in: grub2-signed (Ubuntu Trusty) Status: New => Triaged ** Changed in: grub2-signed (Ubuntu Xenial) Status: New => Triaged ** Changed in: grub2-signed (Ubuntu Bionic) Status: New => Triaged ** Description changed: [Impact] - * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64 + * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64 with grub-efi-arm64-signed installed, without grub-efi-arm64. - * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64 + * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64 with grub-efi-amd64-signed installed without grub-pc or grub-efi-amd64. - * This results in newly installed kernels not getting added to grub.cfg + * This results in newly installed kernels not getting added to grub.cfg and thus upon reboot one does not boot into the new kernel. - * In later series these scripts moved to grub2-common. Maybe we should + * In later series these scripts moved to grub2-common. Maybe we should move these to grub2-common in bionic and earlier too, for compatibility - with onegrub. - + with onegrub. Or alternatively grub2-signed should ship these in grub- + efi-{amd64,arm64}-signed packages too. [Test Plan] - * Install new grubs + * Install new grubs - * Install a new kernel that was not installed before + * Install a new kernel that was not installed before - * Observe that grub.cfg is regenerated and new kernel is present + * Observe that grub.cfg is regenerated and new kernel is present - * Remove an old kernel + * Remove an old kernel - * Observe that grub.cfg is regenerated and new kernel is removed from + * Observe that grub.cfg is regenerated and new kernel is removed from grub.cfg [Where problems could occur] - * These are conffiles. Although nobody should modify them, care should + * These are conffiles. Although nobody should modify them, care should be taken when moving conffiles around. [Other Info] - - * First reported by klebers + + * First reported by klebers -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1928674 Title: due to a new recommends grub-efi-arm64-signed is installed which does not have postinst.d script Status in grub2-signed package in Ubuntu: Fix Released Status in grub2-signed source package in Trusty: Triaged Status in grub2-signed source package in Xenial: Triaged Status in grub2-signed source package in Bionic: Triaged Bug description: [Impact] * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64 with grub-efi-arm64-signed installed, without grub-efi-arm64. * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64 with grub-efi-amd64-signed installed without grub-pc or grub-efi- amd64. * This results in newly installed ke
[Group.of.nepali.translators] [Bug 1928648] [NEW] expiring trust anchor compatibility issue
*** This bug is a security vulnerability *** Public security bug reported: https://community.letsencrypt.org/t/openssl-client-compatibility- changes-for-let-s-encrypt-certificates/143816 Currently gnutls28 in bionic and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in GnuTLS 3.6.14, but probably should be backported to bionic and earlier if it was not already been done so. https://gitlab.com/gnutls/gnutls/-/issues/1008 https://gitlab.com/gnutls/gnutls/-/merge_requests/1271 ** Affects: gnutls28 (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: gnutls28 (Ubuntu Precise) Importance: Undecided Status: New ** Affects: gnutls28 (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: gnutls28 (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: gnutls28 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Precise) Importance: Undecided Status: New ** Changed in: gnutls28 (Ubuntu) Status: New => Fix Released ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1928648 Title: expiring trust anchor compatibility issue Status in gnutls28 package in Ubuntu: Fix Released Status in gnutls28 source package in Precise: New Status in gnutls28 source package in Trusty: New Status in gnutls28 source package in Xenial: New Status in gnutls28 source package in Bionic: New Bug description: https://community.letsencrypt.org/t/openssl-client-compatibility- changes-for-let-s-encrypt-certificates/143816 Currently gnutls28 in bionic and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in GnuTLS 3.6.14, but probably should be backported to bionic and earlier if it was not already been done so. https://gitlab.com/gnutls/gnutls/-/issues/1008 https://gitlab.com/gnutls/gnutls/-/merge_requests/1271 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1926748] [NEW] regression in xenial updates - grub2 cannot handle new arm64 relocations
Public bug reported: [Impact] * regression in xenial updates - grub2 cannot handle new relocations * grub-efi-arm64-bin gained new recommends on -signed package which is attempted to be installed * it pulls in one grub which was built with a newer toolchain and has more relocations * non-secureboot grub-install in xenial fails to install it when creating core.efi, because it does not know how to handle new relocations. * We need to cherrypick patches from 2.02 (which are in bionic+) to xenial & trusty. [Test Plan] * install new grub2-common grub-common * install grub-efi-arm64-signed from xenial-updates * package installation should be successful * this is executed as part of autopkgtest upgrades when testing any package on xenial in our autopkgtest cloud [Where problems could occur] * we are rebuilding grub2 which will have to go into security pocket eventually. Thus it's best to rebuild grub2 in security pocket. ** Affects: grub2 (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: grub2 (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: grub2 (Ubuntu Xenial) Importance: Undecided Status: New ** Tags: regresion-update-xenial regression-update xenial ** Tags removed: regression-up ** Tags added: regresion-update-xenial regression-update xenial ** Also affects: grub2 (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: grub2 (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: grub2 (Ubuntu) Status: New => Fix Released ** Description changed: [Impact] - * regression in xenial updates - grub2 cannot handle new relocations + * regression in xenial updates - grub2 cannot handle new relocations - * grub-efi-arm64-bin gained new recommends on -signed package which is + * grub-efi-arm64-bin gained new recommends on -signed package which is attempted to be installed - * it pulls in one grub which was built with a newer toolchain and has + * it pulls in one grub which was built with a newer toolchain and has more relocations - * non-secureboot grub-install in xenial fails to install it when + * non-secureboot grub-install in xenial fails to install it when creating core.efi, because it does not know how to handle new relocations. + * We need to cherrypick patches from 2.02 (which are in bionic+) to + xenial & trusty. + [Test Plan] - * install new grub2-common grub-common + * install new grub2-common grub-common - * install grub-efi-arm64-signed from xenial-updates + * install grub-efi-arm64-signed from xenial-updates - * package installation should be successful + * package installation should be successful - * this is executed as part of autopkgtest upgrades when testing any + * this is executed as part of autopkgtest upgrades when testing any package on xenial in our autopkgtest cloud [Where problems could occur] - * we are rebuilding grub2 which will have to go into security pocket + * we are rebuilding grub2 which will have to go into security pocket eventually. Thus it's best to rebuild grub2 in security pocket. -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1926748 Title: regression in xenial updates - grub2 cannot handle new arm64 relocations Status in grub2 package in Ubuntu: Fix Released Status in grub2 source package in Trusty: New Status in grub2 source package in Xenial: New Bug description: [Impact] * regression in xenial updates - grub2 cannot handle new relocations * grub-efi-arm64-bin gained new recommends on -signed package which is attempted to be installed * it pulls in one grub which was built with a newer toolchain and has more relocations * non-secureboot grub-install in xenial fails to install it when creating core.efi, because it does not know how to handle new relocations. * We need to cherrypick patches from 2.02 (which are in bionic+) to xenial & trusty. [Test Plan] * install new grub2-common grub-common * install grub-efi-arm64-signed from xenial-updates * package installation should be successful * this is executed as part of autopkgtest upgrades when testing any package on xenial in our autopkgtest cloud [Where problems could occur] * we are rebuilding grub2 which will have to go into security pocket eventually. Thus it's best to rebuild grub2 in security pocket. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1926748/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https
[Group.of.nepali.translators] [Bug 1926175] [NEW] something something precise (test bug)
Public bug reported: something something precise (test bug) ** Affects: linux-gcp (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: linux-gcp (Ubuntu Precise) Importance: Undecided Status: Won't Fix ** Affects: linux-gcp (Ubuntu Trusty) Importance: Undecided Status: In Progress ** Affects: linux-gcp (Ubuntu Xenial) Importance: Undecided Status: Invalid ** Also affects: linux-gcp (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux-gcp (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: linux-gcp (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: linux-gcp (Ubuntu) Status: New => Fix Released ** Changed in: linux-gcp (Ubuntu Xenial) Status: New => Fix Released ** Changed in: linux-gcp (Ubuntu Xenial) Status: Fix Released => Invalid ** Changed in: linux-gcp (Ubuntu Precise) Status: New => Won't Fix ** Changed in: linux-gcp (Ubuntu Trusty) Status: New => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1926175 Title: something something precise (test bug) Status in linux-gcp package in Ubuntu: Fix Released Status in linux-gcp source package in Precise: Won't Fix Status in linux-gcp source package in Trusty: In Progress Status in linux-gcp source package in Xenial: Invalid Bug description: something something precise (test bug) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-gcp/+bug/1926175/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1915536] Re: one grub
** Changed in: grub2-unsigned (Ubuntu Groovy) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1915536 Title: one grub Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in grub2-unsigned package in Ubuntu: Fix Released Status in grub2 source package in Xenial: Fix Committed Status in grub2-signed source package in Xenial: Fix Committed Status in grub2-unsigned source package in Xenial: Fix Committed Status in grub2 source package in Bionic: Fix Committed Status in grub2-signed source package in Bionic: Fix Committed Status in grub2-unsigned source package in Bionic: Fix Committed Status in grub2 source package in Focal: Fix Committed Status in grub2-signed source package in Focal: Fix Committed Status in grub2-unsigned source package in Focal: Fix Committed Status in grub2 source package in Groovy: Fix Released Status in grub2-signed source package in Groovy: Fix Released Status in grub2-unsigned source package in Groovy: Fix Released Status in grub2 source package in Hirsute: Fix Released Status in grub2-signed source package in Hirsute: Fix Released Status in grub2-unsigned source package in Hirsute: Fix Released Bug description: [Impact] The proposal is to split src:grub2 into two source packages. src:grub2 will continue to build most things, apart from bin|dbg |signing-tempate binary packages for platforms that get signed. src:grub2-unsigned source package is source-full copy of src:grub2 that only builds bin|dbg|signing-tempate binary packages for platforms that get signed and submits monolithic binaries for signing. src:grub2-signed is built as before, but its maintainer scripts should be compatible across grub2-common from precise and up. Stable series will receive grub2 update that drops building bin|dbg |signing-template. Stable series will receive binary-copy of grub2-unsigned & grub2-signed, thus on signed platforms EFI apps and modules will be the same across all series. [Caveats] * In devel series, always upload grub2 with matching src:grub2-unsigned and src:grub2-signed. The unsigned package can be build with ./debian/rules generate-grub2-unsigned command from src:grub2. * In stable series, only upload src:grub2 when fixes needed in update- grub / grub.cfg / grub-install / etc, but not in the efi modules & apps. * As needed, binary copy grub2-unsigned & grub2-signed from later series to stable series. [Test Case] * Upgrade to new packages * Observe that system boots, one can use grub-mkimage / grub-mkrescue without issues. [Where problems could occur] * There might be regression on the EFI platforms with grub 2.04 that have not so far been caught on Focal / Groovy / Hirsute. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1915536/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1878969] Re: time-epoch never changes in SRUs
with core-initrd v40, each new initrd build increases time epoch. This still means that for brand new account keys, one needs to wait or build a new kernel to be able to boot in UC20. ** Changed in: ubuntu-core-initramfs Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1878969 Title: time-epoch never changes in SRUs Status in ubuntu-core-initramfs: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Bug description: [Impact] * Systems without hwclock come up with a fixed time epoch which is not updated in SRUs * Ideally booting with a newer built of systemd should move time epoch to be at least when systemd was last built. For example to the value of SOURCE_DATE_EPOCH. [Test Case] * Boot without network NTP or hwclock * Observe that the epoch is the same as the time when NEWS entry in the systemd source code was last touched. * Boot newer update of systemd, observe that the time epoch is at least 2020 [Regression Potential] * Bad epoch, may result in unable to perform TLS connections, validated GPG signatures, and snapd assertions. Changing epoch to be more recent is desired. Some machines may rely on the fact that "bionic" without hwclock always comes up in year 2018. But in practice that is incorrect thing to do. [Other Info] * By default option('time-epoch', type : 'integer', value : '-1', description : 'time epoch for time clients') in systemd is set to the modification time of the NEW entry time_epoch = run_command(stat, '-c', '%Y', NEWS).stdout().to_int() If available, it should be set to SOURCE_DATE_EPOCH=1585051767 value to be compliant with the https://reproducible- builds.org/docs/timestamps/ specification. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-core-initramfs/+bug/1878969/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1915536] Re: one grub
** Changed in: grub2 (Ubuntu Hirsute) Status: Fix Released => In Progress ** Changed in: grub2-signed (Ubuntu Hirsute) Status: Fix Released => In Progress ** Also affects: grub2-unsigned (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1915536 Title: one grub Status in grub2 package in Ubuntu: In Progress Status in grub2-signed package in Ubuntu: In Progress Status in grub2-unsigned package in Ubuntu: New Status in grub2 source package in Xenial: Fix Committed Status in grub2-signed source package in Xenial: Fix Committed Status in grub2-unsigned source package in Xenial: New Status in grub2 source package in Bionic: Fix Committed Status in grub2-signed source package in Bionic: Fix Committed Status in grub2-unsigned source package in Bionic: New Status in grub2 source package in Focal: Fix Committed Status in grub2-signed source package in Focal: Fix Committed Status in grub2-unsigned source package in Focal: New Status in grub2 source package in Groovy: Fix Committed Status in grub2-signed source package in Groovy: Fix Committed Status in grub2-unsigned source package in Groovy: New Status in grub2 source package in Hirsute: In Progress Status in grub2-signed source package in Hirsute: In Progress Status in grub2-unsigned source package in Hirsute: New Bug description: [Impact] The proposal is to split src:grub2 into two source packages. src:grub2 will continue to build most things, apart from bin|dbg |signing-tempate binary packages for platforms that get signed. src:grub2-unsigned source package is source-full copy of src:grub2 that only builds bin|dbg|signing-tempate binary packages for platforms that get signed and submits monolithic binaries for signing. src:grub2-signed is built as before, but its maintainer scripts should be compatible across grub2-common from precise and up. Stable series will receive grub2 update that drops building bin|dbg |signing-template. Stable series will receive binary-copy of grub2-unsigned & grub2-signed, thus on signed platforms EFI apps and modules will be the same across all series. [Caveats] * In devel series, always upload grub2 with matching src:grub2-unsigned and src:grub2-signed. The unsigned package can be build with ./debian/rules generate-grub2-unsigned command from src:grub2. * In stable series, only upload src:grub2 when fixes needed in update- grub / grub.cfg / grub-install / etc, but not in the efi modules & apps. * As needed, binary copy grub2-unsigned & grub2-signed from later series to stable series. [Test Case] * Upgrade to new packages * Observe that system boots, one can use grub-mkimage / grub-mkrescue without issues. [Where problems could occur] * There might be regression on the EFI platforms with grub 2.04 that have not so far been caught on Focal / Groovy / Hirsute. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1915536/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1912830] Re: Use non-removable uefi bootloader in cloud-images by default
** Changed in: livecd-rootfs (Ubuntu Xenial) Status: Fix Committed => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1912830 Title: Use non-removable uefi bootloader in cloud-images by default Status in livecd-rootfs package in Ubuntu: Fix Released Status in livecd-rootfs source package in Xenial: Won't Fix Status in livecd-rootfs source package in Bionic: Fix Committed Status in livecd-rootfs source package in Focal: Fix Committed Status in livecd-rootfs source package in Groovy: Fix Committed Bug description: [Impact] * use non --removable uefi installation for cloud-images * Currently cloud-images use --removable grub installation, which makes the disk images look at lot more like our installer .isos, than installed systems. This causes many issues: * ubuntu efiboot entry is not created by the fallback manager from shim * one cannot reorder ubuntu boot entry, and/or boot and apply fwupdate updates (if possible) * measurements are unstable, and change if one call grub-install and or upgrades things * often grub & shim upgrades are not applied at all as \EFI\ubuntu does not exist on the ESP * We should switch to only shipping shim/fallback/mm in \ESP\Boot and ship \ESP\ubuntu on the cloud-image ESPs such that we regain stable measurements; ubuntu boot entry; and upgrades of grub and shim. [Test Case] * After UEFI firstboot $ efibootmgr --verbose => should contain `ubuntu` entry pointing at ESP\ubuntu\shim*.efi binary, which should be added to the bootorder [Where problems could occur] * Existing systems which were booted from previous style images, will not upgrade shim|grub on the ESP, and must call `grub-install` or `grub-multi-install` to correct that. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1912830/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1778848] Re: Support for grub upgrades with bios+uefi bootloader targets
** Also affects: grub2 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: grub-installer (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: ubiquity (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: shim-signed (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1778848 Title: Support for grub upgrades with bios+uefi bootloader targets Status in grub-installer package in Ubuntu: Fix Released Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in shim-signed package in Ubuntu: Fix Released Status in ubiquity package in Ubuntu: Fix Released Status in grub-installer source package in Xenial: New Status in grub2 source package in Xenial: New Status in grub2-signed source package in Xenial: New Status in shim-signed source package in Xenial: New Status in ubiquity source package in Xenial: New Status in grub-installer source package in Bionic: Fix Released Status in grub2 source package in Bionic: Fix Released Status in grub2-signed source package in Bionic: Fix Released Status in shim-signed source package in Bionic: Fix Released Status in ubiquity source package in Bionic: Fix Released Bug description: [Impact] There are multiple use cases which require both BIOS and UEFI bootloaders installed on a target image and to keep them both updated. - cloud images on clouds that support both BIOS and UEFI boot in alternate instance types - PC installs that should remain bootable in the face of firmware upgrades or reconfigurations This currently doesn't work because 'grub-install' selects its install target based on which of grub-pc or grub-efi-amd64 is installed. In cosmic we have introduced a --auto-nvram grub-install option that automatically determines if we're running with NVRAM access or not and if yes, updates the NVRAM contents. This allows such dual BIOS-UEFI bootloader setups to work. Same changes are required to be backported to bionic for our cloud images. [Test Case] Basic grub2 grub-install test: * Boot up a bionic system in UEFI mode. * Upgrade grub2-common to the version in -proposed. * Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds. * Prepare a system with an UEFI installed system that can be booted into in legacy BIOS mode. * Boot up the UEFI-installed bionic system in legacy BIOS mode. * Upgrade grub2-common to the version in -proposed. * Run `grub-install --target=x86_64-efi --auto-nvram` and make sure it succeeds (actually not doing anything). Install test for UEFI (repeat for both server-live, server and desktop): * Download the latest bionic -proposed-enabled image. * Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity). * Install the system normally on an EFI system. * Reboot and make sure the system is bootable. Install test for legacy BIOS (repeat for both server-live, server and desktop): * Download the latest bionic -proposed-enabled image. * Make sure the image includes the -proposed version of grub2, grub2-signed, shim-signed and grub-installer (and/or ubiquity). * Install the system normally on a BIOS system. * Reboot and make sure the system is bootable. TODO: Add cloud image testing. [Regression Potential] The backport introduces a change in the dependency chain for grub which, in some cases, can lead to systems loosing their ability to boot. Basically the symptoms to look for is the inability of booting the installed system on EFI or BIOS. A lot of testing and dogfooding will be required to make sure no installation-case has been broken by this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1778848/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1780897] Re: Installation failure on UEFI systems using older images with automatic download of updates enabled
** Also affects: grub2-signed (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1780897 Title: Installation failure on UEFI systems using older images with automatic download of updates enabled Status in grub2-signed package in Ubuntu: Fix Released Status in grub2-signed source package in Xenial: New Status in grub2-signed source package in Bionic: Fix Released Status in grub2-signed source package in Cosmic: Fix Released Bug description: [Impact] Recent grub2-signed dependency chain changes required some changes to be made to the installer parts to make sure the end system is bootable. However, older isos (like, release images for bionic) do not have these installer changes, so users using those with automatic download of updates enabled on UEFI systems will end up with a broken system. [Test Case] Checking if the bug has been fixed: * Download an older iso (for bionic, let it be the 18.04 release image) * Prepare an UEFI-based VM * Install Ubuntu with automatic download of updates enabled * Reboot and make sure the system is bootable Checking if no regressions have been introduced for the installer: * Download the latest daily server iso * Prepare an UEFI-based VM * Install Ubuntu * Reboot and make sure the system is bootable [Regression Potential] There should be no real regression potential here as we are basically adding dependencies that should otherwise be installed when using a newer image. All potential regressions would be made visible during the installation tests from the test case. [Original Description] Regression caused by https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1778848 Steps to reproduce 1) Install ubuntu-18.04-desktop-amd64.iso in a VM using QEMU and OVMF 2) Reboot the VM 3) See GRUB shell instead of GDM The system can be rescued by running configfile (hd0,gpt2)/boot/grub/grub.cfg at the GRUB shell Installing grub-efi-amd64 in the rescued system then makes it bootable. Previously grub-efi-amd64-signed depended on grub-efi-amd64, and the system was bootable immediately after installation. Additionally, the removal of this dependency has resulted in a very sparse /etc/default/grub after installation. I've attached a simple script for installation with QEMU and OVMF. I suspect that installs are broken on actual hardware with SecureBoot disabled, but I'm not able to test that right now. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1780897/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1910557] Re: Buildd images do not launch on macOS under multipass due to missing unpacked kernels and initrd
** Also affects: livecd-rootfs (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu Groovy) Importance: Undecided Status: New ** Changed in: livecd-rootfs (Ubuntu Hirsute) Status: New => Fix Released ** Changed in: livecd-rootfs (Ubuntu Groovy) Status: New => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1910557 Title: Buildd images do not launch on macOS under multipass due to missing unpacked kernels and initrd Status in livecd-rootfs package in Ubuntu: Fix Released Status in livecd-rootfs source package in Xenial: New Status in livecd-rootfs source package in Bionic: New Status in livecd-rootfs source package in Focal: New Status in livecd-rootfs source package in Groovy: In Progress Status in livecd-rootfs source package in Hirsute: Fix Released Bug description: livecd-rootfs v2.700 in hirsute introduced a fix to produce unpacked artifacts for use by multipass on macOS hosts. These hosts require direct access to a kernel and initrd to boot the buildd images. See: https://git.launchpad.net/livecd- rootfs/commit/?id=065c82314464fa78337d5122e1d4826a7d6edbb0 This change needs to be backported to all suites. [Impact] * Without this change, users are unable to use the buildd images with multipass on macOS hosts. Snapcraft utilizes multipass to build snaps, so this blocks macOS users from building snaps. As a workaround, the CPC team is manually extracting these artifacts and publishing them to cloud-images.ubuntu.com. This is not ideal for the long-term, and could result in breakage in the event that the CPC team forgets to manually publish these artifacts. [Test Case] * After this change lands, a user should be able to build images with the ubuntu-base project and buildd subproject, and the resulting build should produce extracted kernel and initrd artifacts. [Where problems could occur] * These changes are minor, but a mistake could result in broken buildd image hooks (where the build fails) or broken buildd image artifacts (where the images don't work as expected). * Since all buildd images are manually tested by the launchpad team, multipass team, and snapcraft team before they enter production, the risk of introducing breakage for end users is low. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1910557/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1865032] Re: [UBUNTU] zipl/libc: Fix potential buffer overflow in printf
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1865032 Title: [UBUNTU] zipl/libc: Fix potential buffer overflow in printf Status in Ubuntu on IBM z Systems: Fix Released Status in s390-tools package in Ubuntu: Fix Released Status in s390-tools source package in Xenial: Fix Released Status in s390-tools source package in Bionic: Fix Released Status in s390-tools source package in Eoan: Won't Fix Status in s390-tools source package in Focal: Fix Released Bug description: [Impact] * Crash of the zipl boot loader during boot. * due to printf buffer overflow in zipl/libc implementation [Test Case] * Use printf to print a string with >81 characters (exact number depends on the stack layout/compiler used). [Where problems could occur] * regressions in zipl could break the booting on IBM Z, in certain scenarios * the package is only available on s390x and thus could only affect IBM Z machines [Other Info] * Patches provided by IBM * In addition to the 4 commit IDs from the original description, I needed to include part of another upstream commit, to add the "memmove()" function. This was taken from: https://github.com/ibm-s390-tools/s390-tools/commit/e764f460c457ab2a6000acb5f2eb7169866ce192 === Original Description === Description: zipl/libc: Fix potential buffer overflow in printf Symptom: Crash of the zipl boot loader during boot. Problem: The zipl boot loaders have their own minimalistic libc implementation. In it printf and sprintf use vsprintf for string formatting. Per definition vsprintf assumes that the buffer it writes to is large enough to contain the formatted string and performs no size checks. This is problematic for the boot loaders because the buffer they use are often allocated on the stack. Thus even small changes to the string format can potentially cause buffer overflows on the stack. Solution: Implement vsnprintf and make use of it. Reproduction: Use printf to print a string with >81 characters (exact number depends on the stack layout/compiler used). Upstream commit(s) for s390-tools: 6fe9e6c55c69c14971dca1009f5060418aae 8874b908254c47c8a6fd7a1aca2c7371c11035c4 f7430027b41d5ad6220e962a179c2a5213330a44 36fed0e6c6590631c4ce1707c8fe3c3397bcce4d Problem was introduced with version 1.24. Therefore these patches need to be applied to all distros in service. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1865032/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1856682] Re: [UBUNTU 20.04] GCC Miscompilation in vectorized code
** Changed in: gcc-8 (Ubuntu) Status: New => Fix Released ** Changed in: gcc-8 (Ubuntu Focal) Status: New => Fix Released ** Changed in: gcc-8 (Ubuntu Bionic) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1856682 Title: [UBUNTU 20.04] GCC Miscompilation in vectorized code Status in gcc: Fix Released Status in Ubuntu on IBM z Systems: Triaged Status in gcc-5 package in Ubuntu: Invalid Status in gcc-6 package in Ubuntu: Invalid Status in gcc-7 package in Ubuntu: New Status in gcc-8 package in Ubuntu: Fix Released Status in gcc-9 package in Ubuntu: Fix Released Status in gcc-5 source package in Xenial: New Status in gcc-6 source package in Xenial: Invalid Status in gcc-7 source package in Xenial: Invalid Status in gcc-8 source package in Xenial: Invalid Status in gcc-9 source package in Xenial: Invalid Status in gcc-5 source package in Bionic: New Status in gcc-6 source package in Bionic: New Status in gcc-7 source package in Bionic: New Status in gcc-8 source package in Bionic: Fix Released Status in gcc-9 source package in Bionic: Invalid Status in gcc-5 source package in Disco: Invalid Status in gcc-6 source package in Disco: Invalid Status in gcc-7 source package in Disco: Invalid Status in gcc-8 source package in Disco: Invalid Status in gcc-9 source package in Disco: Invalid Status in gcc-5 source package in Eoan: Invalid Status in gcc-6 source package in Eoan: Invalid Status in gcc-7 source package in Eoan: Invalid Status in gcc-8 source package in Eoan: Invalid Status in gcc-9 source package in Eoan: Invalid Status in gcc-5 source package in Focal: Invalid Status in gcc-6 source package in Focal: Invalid Status in gcc-7 source package in Focal: New Status in gcc-8 source package in Focal: Fix Released Status in gcc-9 source package in Focal: Fix Released Bug description: Miscompilation in autovectorized code. ---Steps to Reproduce--- See GCC BZ: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950 The following testcase abort when being compiled with -O3 -march=z13 on IBM Z: struct a { int b; char c; }; struct a d = {1, 16}; struct a *e = &d; int f = 0; int main() { struct a g = {0, 0 }; f = 0; for (; f <= 1; f++) { g = d; *e = g; } if (d.c != 16) __builtin_abort(); } The movv1qi pattern emits halfword load instructions instead of character loads. All GCC versions since GCC 5 are affected. Patches for GCC 8, 9, and 10 have been committed to the gcc.gnu.org branches. Userspace tool common name: gcc The userspace tool has the following bit modes: 64 Userspace rpm: various Ubuntu gcc packages Package need to updated within LP To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/1856682/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1895160] Re: Backport finalrd 6 to xenial and up
** Changed in: finalrd (Ubuntu Xenial) Status: Triaged => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1895160 Title: Backport finalrd 6 to xenial and up Status in finalrd package in Ubuntu: Fix Released Status in finalrd source package in Xenial: Fix Released Status in finalrd source package in Bionic: Fix Released Status in finalrd source package in Focal: Fix Released Bug description: [Impact] * finalrd is a useful tool, that improves ability to cleanly shut down systems. It is now desired to backport it all the way back to xenial. On classic systems it will not be installed by default, but available for users to opt-in into having it. On Ubuntu Core systems it will be installed by default, and used instead of snap-shutdown. As finalrd does everything that snap-shutdown already did, and much more. * finalrd is only tweaked slightly in version 6 to be compatible with any systemd from xenial to groovy. [Test Case] Classic * Install finalrd * execute `sudo finalrd` and observe that no stderr is printed, and command exits successfully * check that /run/initramfs is created and populated with /run/initramfs/shutdown, binaries and libraries. * Reboot * Observe that finalrd unit is started ** (optional) to make observing finalrd easier add /etc/finalrd/echo.finalrd hook that does `echo $@` with a sleep * Shutdown, capture console-log observe that finalrd was executed [xenial extra testcase] * finalrd binary package should have Task: ubuntu-core, such that when building core snap, it is installed by livebuild. Core * Create custom core, core18 with finalrd preinstalled * Building custom Ubuntu Core 16 and Ubuntu Core 18 image with above core * Observe that finalrd unit is started on boot * Shutdown, capture console-log observe that finarld was executed. * Boot again * execute `sudo finalrd` and observe that no stderr is printed, and command exits successfully * check that /run/initramfs is created and populated with /run/initramfs/shutdown, binaries and libraries. [Regression Potential] * Packaging & tmpfiles were changed to be compatible with older systemd versions. There are no changes to api/abi of the systemd units, or .finalrd hooks. The package is not installed by default on xenial/bionic, hence the number and type of machines affected is small. If regressions are identified, reverting to previous version of the package is safe course of action, as there are no upgrade/downgrade incompatibilities between old & new versions of finalrd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/finalrd/+bug/1895160/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1895160] Re: Backport finalrd 6 to xenial and up
finalrd is now seeded into system-image in xenial. But because it is a brand new package in -updates pocket only, it doesn't gain Task: ubuntu- core, as that is only done for packages that exist in release pocket. Thus adding Task:ubuntu-core by hand. ** Description changed: [Impact] - * finalrd is a useful tool, that improves ability to cleanly shut down + * finalrd is a useful tool, that improves ability to cleanly shut down systems. It is now desired to backport it all the way back to xenial. On classic systems it will not be installed by default, but available for users to opt-in into having it. On Ubuntu Core systems it will be installed by default, and used instead of snap-shutdown. As finalrd does everything that snap-shutdown already did, and much more. - * finalrd is only tweaked slightly in version 6 to be compatible with + * finalrd is only tweaked slightly in version 6 to be compatible with any systemd from xenial to groovy. [Test Case] Classic - * Install finalrd - * execute `sudo finalrd` and observe that no stderr is printed, and command exits successfully - * check that /run/initramfs is created and populated with /run/initramfs/shutdown, binaries and libraries. - * Reboot - * Observe that finalrd unit is started - ** (optional) to make observing finalrd easier add /etc/finalrd/echo.finalrd hook that does `echo $@` with a sleep - * Shutdown, capture console-log observe that finalrd was executed + * Install finalrd + * execute `sudo finalrd` and observe that no stderr is printed, and command exits successfully + * check that /run/initramfs is created and populated with /run/initramfs/shutdown, binaries and libraries. + * Reboot + * Observe that finalrd unit is started + ** (optional) to make observing finalrd easier add /etc/finalrd/echo.finalrd hook that does `echo $@` with a sleep + * Shutdown, capture console-log observe that finalrd was executed + + [xenial extra testcase] + + * finalrd binary package should have Task: ubuntu-core, such that when + building core snap, it is installed by livebuild. Core - * Create custom core, core18 with finalrd preinstalled - * Building custom Ubuntu Core 16 and Ubuntu Core 18 image with above core - * Observe that finalrd unit is started on boot - * Shutdown, capture console-log observe that finarld was executed. - * Boot again - * execute `sudo finalrd` and observe that no stderr is printed, and command exits successfully - * check that /run/initramfs is created and populated with /run/initramfs/shutdown, binaries and libraries. + * Create custom core, core18 with finalrd preinstalled + * Building custom Ubuntu Core 16 and Ubuntu Core 18 image with above core + * Observe that finalrd unit is started on boot + * Shutdown, capture console-log observe that finarld was executed. + * Boot again + * execute `sudo finalrd` and observe that no stderr is printed, and command exits successfully + * check that /run/initramfs is created and populated with /run/initramfs/shutdown, binaries and libraries. [Regression Potential] - * Packaging & tmpfiles were changed to be compatible with older systemd + * Packaging & tmpfiles were changed to be compatible with older systemd versions. There are no changes to api/abi of the systemd units, or .finalrd hooks. The package is not installed by default on xenial/bionic, hence the number and type of machines affected is small. If regressions are identified, reverting to previous version of the package is safe course of action, as there are no upgrade/downgrade incompatibilities between old & new versions of finalrd. ** Changed in: finalrd (Ubuntu Xenial) Status: Fix Released => Triaged -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1895160 Title: Backport finalrd 6 to xenial and up Status in finalrd package in Ubuntu: Fix Released Status in finalrd source package in Xenial: Triaged Status in finalrd source package in Bionic: Fix Released Status in finalrd source package in Focal: Fix Released Bug description: [Impact] * finalrd is a useful tool, that improves ability to cleanly shut down systems. It is now desired to backport it all the way back to xenial. On classic systems it will not be installed by default, but available for users to opt-in into having it. On Ubuntu Core systems it will be installed by default, and used instead of snap-shutdown. As finalrd does everything that snap-shutdown already did, and much more. * finalrd is only tweaked slightly in version 6 to be compatible with any systemd from xenial to groovy. [Test Case] Classic * Install finalrd * execute `sudo finalrd` and observe that no stderr is printed, and command exits successfully * check that /run/initramfs is created and populated wi
[Group.of.nepali.translators] [Bug 1895294] Re: Fix Raccoon vulnerability (CVE-2020-1968)
It is true that said vulnerability is not patched in xenial; but also it is low; and no public patches for it exist. Please upgrade to bionic or focal? which are unaffected / fixes released? ** Information type changed from Public to Public Security ** Also affects: openssl (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: openssl (Ubuntu Xenial) Status: New => Confirmed ** Changed in: openssl (Ubuntu) Status: New => Fix Released ** Changed in: openssl (Ubuntu Xenial) Importance: Undecided => Low -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1895294 Title: Fix Raccoon vulnerability (CVE-2020-1968) Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Xenial: Confirmed Bug description: Xenial's current OpenSSL (1.0.2g-1ubuntu4.16) seems to not have been patched yet against the Raccoon Attack (CVE-2020-1968): - https://www.openssl.org/news/secadv/20200909.txt - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1968 - https://raccoon-attack.com/ Ubuntu's CVE tracker still lists this as NEEDED for Xenial: - https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-1968.html - https://people.canonical.com/~ubuntu-security/cve/pkg/openssl.html Other supported Ubuntu releases use versions of OpenSSL that are not affected. Indeed: $ apt-cache policy openssl openssl: Installed: 1.0.2g-1ubuntu4.16 $ apt-get changelog openssl | grep CVE-2020-1968 || echo "Not patched" Not patched What is the status? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1895294/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1690484] Re: pcre2: CVE-2017-7186 and CVE-2016-3191
** Also affects: pcre2 (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: pcre2 (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1690484 Title: pcre2: CVE-2017-7186 and CVE-2016-3191 Status in pcre2 package in Ubuntu: Fix Released Status in pcre2 source package in Xenial: New Bug description: CVE-2017-7186 - CVE-2017-7186 is the one known CVE fixed in Debian stretch that still affects Ubuntu 16.04 LTS and 16.10. It was fixed in 17.04 already. CVE-2016-3191 - CVE-2016-3191 is the one known CVE fixed in Debian stretch that still affects Ubuntu 16.04 LTS. It was fixed in 16.10 and newer already. "The compile_branch function in pcre_compile.c in PCRE 8.x before 8.39 and pcre2_compile.c in PCRE2 before 10.22 mishandles patterns containing an (*ACCEPT) substring in conjunction with nested parentheses, which allows remote attackers to execute arbitrary code or cause a denial of service (stack-based buffer overflow) via a crafted regular expression, as demonstrated by a JavaScript RegExp object encountered by Konqueror, aka ZDI-CAN-3542." https://security-tracker.debian.org/tracker/CVE-2016-3191 https://bugzilla.redhat.com/show_bug.cgi?id=1311503 Fedora patch: http://pkgs.fedoraproject.org/cgit/rpms/pcre2.git/tree/pcre2-10.21-Fix-workspace-overflow-for-deep-nested-parentheses-w.patch?id=fc9ba26 https://vcs.pcre.org/pcre2?view=revision&revision=489 Testing Done None Packaging Info -- The Debian maintainer uses dgit for the pcre packages. You can run 'dgit clone pcre2' to get the packaging along with the extra metadata that actually describes the changes that were done to the source package. I did this and pushed it to https://git.launchpad.net/~jbicha/ubuntu/+source/pcre2 But the Debian source package itself does not have a patch system which makes it much more difficult for us to see what changes were made and why. I think for maintainability with how Ubuntu packaging generally works, it makes sense here to switch to 3.0 (quilt). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1690484/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1862938] Re: Enable late loading of microcode by default
** Changed in: intel-microcode (Ubuntu) Status: Fix Released => Won't Fix ** Changed in: intel-microcode (Ubuntu Xenial) Status: New => Won't Fix ** Changed in: intel-microcode (Ubuntu Bionic) Status: New => Won't Fix ** Changed in: intel-microcode (Ubuntu Eoan) Status: Fix Committed => Won't Fix ** Changed in: intel-microcode (Ubuntu Focal) Status: Fix Released => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1862938 Title: Enable late loading of microcode by default Status in intel-microcode package in Ubuntu: Won't Fix Status in intel-microcode source package in Xenial: Won't Fix Status in intel-microcode source package in Bionic: Won't Fix Status in intel-microcode source package in Eoan: Won't Fix Status in intel-microcode source package in Focal: Won't Fix Bug description: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. * Normally intel microcode is applied "early" for an uncompressed prepended initramfs archive. However, on systems booting without an initrd, or a missbuilt one, microcode might not get applied. In that case, we need to attempt loading microcode late which may give users security protection against CPU vulnerabilities which they might otherwise be lacking. In an ideal world, everyone would apply their bios/OEM updates with microcode updates in a timely fashion and then we wouldn't need to update CPU microcode from userspace at all. [Test Case] * Install updated package * Reobot * Observe early application of microcode $ journalctl -b | grep microcode Feb 12 12:02:48 ottawa kernel: microcode: microcode updated early to revision 0xd6, date = 2019-10-03 * Remove /usr/share/initramfs-tools/hooks/intel_microcode to prevent correct generation of early microcode updates * Rebuild initrd with update-initramfs -u * Reboot * Observe in dmesg that late loading of microcode is performed $ journalctl -b | grep microcode Feb 12 12:32:54 ottawa kernel: TAA: Vulnerable: Clear CPU buffers attempted, no microcode Feb 12 12:32:54 ottawa kernel: MDS: Vulnerable: Clear CPU buffers attempted, no microcode Feb 12 12:32:54 ottawa kernel: microcode: sig=0x506e3, pf=0x20, revision=0xc6 Feb 12 12:32:54 ottawa kernel: microcode: Microcode Update Driver: v2.2. Feb 12 12:32:57 ottawa kernel: microcode: updated to revision 0xd6, date = 2019-10-03 Feb 12 12:32:57 ottawa kernel: x86/CPU: CPU features have changed after loading microcode, but might not take effect. Feb 12 12:32:57 ottawa kernel: microcode: Reload completed, microcode revision: 0xd6 (Note the lack of "early" in above messages) [Regression Potential] * Application of microcode is a risky operation, especially if the cores are busy. Hence we prefer bios updates & early microcode updates, and those will remain the place. The late loading of microcode is really here for the cases were the previous two update strategies have failed. For example, from time to time, certain microcode updates are pulled or get blacklisted from late loading. [Other Info] * The majority of our users on bare-metal machines boot correctly with early microcode updates. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1862938/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1881588] Re: pre-seeding lxd on Core appliances breaks console-conf user creation
Do we need this in the core snap too, or just core18 images? I.e. are all appliance images core18+snapd based? ** Changed in: subiquity (Ubuntu Bionic) Status: Confirmed => In Progress ** Changed in: subiquity Status: In Progress => Fix Released ** No longer affects: subiquity (Ubuntu Bionic) ** No longer affects: subiquity (Ubuntu Xenial) ** No longer affects: subiquity (Ubuntu) ** Also affects: subiquity/core18 Importance: Undecided Status: New ** Also affects: subiquity/core16 Importance: Undecided Status: New ** Also affects: subiquity/core20 Importance: Undecided Status: New ** Changed in: subiquity/core20 Status: New => Fix Committed ** Changed in: subiquity/core18 Status: New => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1881588 Title: pre-seeding lxd on Core appliances breaks console-conf user creation Status in snapd: Invalid Status in subiquity: Fix Released Status in subiquity core16 series: New Status in subiquity core18 series: In Progress Status in subiquity core20 series: Fix Committed Bug description: when seeding appliance images with lxd, user creation gets impossible. console-conf skips the user creation, system-user assertions do not work either because there is already a user exisiting in the image. the tty screen shows instructions to log in with "lxd@" ... since the lxd user is a special case hack in Ubuntu Core images, "snap create-user ..." should probably learn to ignore its existence ... To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1881588/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1881588] Re: pre-seeding lxd on Core appliances breaks console-conf user creation
** Changed in: snapd Status: Invalid => New ** Changed in: subiquity Status: New => Incomplete ** Changed in: subiquity (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1881588 Title: pre-seeding lxd on Core appliances breaks console-conf user creation Status in snapd: New Status in subiquity: Incomplete Status in subiquity package in Ubuntu: Invalid Status in subiquity source package in Xenial: New Status in subiquity source package in Bionic: New Bug description: when seeding appliance images with lxd, user creation gets impossible. console-conf skips the user creation, system-user assertions do not work either because there is already a user exisiting in the image. the tty screen shows instructions to log in with "lxd@" ... since the lxd user is a special case hack in Ubuntu Core images, "snap create-user ..." should probably learn to ignore its existence ... To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1881588/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1881588] Re: pre-seeding lxd on Core appliances breaks console-conf user creation
** Also affects: subiquity Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1881588 Title: pre-seeding lxd on Core appliances breaks console-conf user creation Status in snapd: Invalid Status in subiquity: New Status in subiquity package in Ubuntu: New Status in subiquity source package in Xenial: New Status in subiquity source package in Bionic: New Bug description: when seeding appliance images with lxd, user creation gets impossible. console-conf skips the user creation, system-user assertions do not work either because there is already a user exisiting in the image. the tty screen shows instructions to log in with "lxd@" ... since the lxd user is a special case hack in Ubuntu Core images, "snap create-user ..." should probably learn to ignore its existence ... To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1881588/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1555904] Re: opal-prd not installed by default on ppc64el systems
** Also affects: subiquity Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1555904 Title: opal-prd not installed by default on ppc64el systems Status in subiquity: New Status in The Ubuntu-power-systems project: Fix Released Status in debian-installer package in Ubuntu: Fix Released Status in hw-detect package in Ubuntu: Fix Released Status in debian-installer source package in Xenial: Fix Released Status in hw-detect source package in Xenial: Fix Released Bug description: [Impact] * opal-prd should be installed on OpenPOWER systems [Test Case] * install power system * check that /sys/firmware/devicetree/base/ibm,opal/diagnostics exists * if above is true, check that opal-prd package is installed [Regression Potential] * Additional package installation is performed, thus the install process may take longer, and additional disk space will be used. However the new code path is non-fatal, and all errors are ignored, thus all installation should still proceed past this point. For systems without relevant diagnostics exposed, this code path is a no- op. [Other Info] * Original bug report Just tried an install with current 16.04 network media, using standard server package selections, and it looks like opal-prd isn't installed by default: [jk@fstn ~]$ dpkg -l opal-prd dpkg-query: no packages found matching opal-prd This is required for RAS-type functions on OpenPOWER machines; and has a similar role to something like acpid, on x86. I'm not sure whether filing this against the skiboot package is best, or whether this should be moved to something installer-related. Happy to shift if necessary. To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1555904/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1876055] Re: SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base
** Changed in: libseccomp (Ubuntu Groovy) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1876055 Title: SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Xenial: Confirmed Status in libseccomp source package in Bionic: Confirmed Status in libseccomp source package in Eoan: Confirmed Status in libseccomp source package in Focal: Confirmed Status in libseccomp source package in Groovy: Fix Released Bug description: [Impact] The combination of snap-confine and snap-seccomp from snapd uses libseccomp to filter various system calls for confinement. The current version in eoan/bionic/xenial (2.4.1) is missing knowledge of various system calls for various architectures. As such this causes strange issues like python snaps segfaulting (https://github.com/snapcore/core20/issues/48) or the inadvertent denial of system calls which should be permitted by the base policy (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal- arm64/17237). libseccomp in groovy is using the latest upstream base release (2.4.3) plus it includes a patch to add some missing aarch64 system calls (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633). SRUing this version back to older stable releases allows libseccomp to operate correctly on all supported architectures. Included as part of this SRU are test-suite reliability improvements - currently the xenial libseccomp package overrides test-suite failures at build time to ignore failures. This masks the fact that on ppc64el and s390x there are currently test suite failures at build time for xenial - these failures occur since libseccomp now includes knowledge of system calls for these architectures but which the linux-libc-dev package for xenial does not actually define (since this is based of the 4.4 kernel in xenial whereas libseccomp 2.4.1 in xenial has knowledge of all system calls up to 5.4). In this SRU I have instead fixed the test suite failures for xenial by including a local (test-suite specific) set of architecture specific kernel headers from the linux-libc-dev in focal for all releases. These are just the headers which define the system call numbers for each architecture *and* these are added to tests/include/$ARCH in the source package (and tests/Makefile.am is then updated to include these new headers only). As such this ensures the actual build of libseccomp or any of the tools does not reference these headers. This allows the test suite in libseccomp to then be aware of theses system calls and so all unit tests for all architectures now pass. In any future updates for libseccomp to add new system calls, we can then similarly update these local headers to ensure the unit tests continue to work as expected. [Test Case] libseccomp includes a significant unit test suite that is run during the build and as part of autopkgtests. To verify the new aarch64 system calls are resolved as expected the scmp_sys_resolver command can be used as well: $ scmp_sys_resolver -a aarch64 getrlimit 163 (whereas in the current version in focal this returns -10180 as libseccomp was not aware of this system-call at compile-time). As part of this SRU, the test suite in libseccomp has been patched to include a local copy of the architecture-specific kernel headers from the 5.4 kernel in focal *for all releases*, so that all system calls which are defined for the 5.4 kernel are known about *for the libseccomp test suite*. This allows all unit tests to pass on older releases as well and defaults the build to fail on unit test failures (whereas currently in xenial this has been overridden to ignore failures). [Regression Potential] This has a low regression potential due to significant testing with many packages that depend on libseccomp (lxc, qemu, snapd, apt, man etc) and none have shown any regression using this new version. The re-enablement of build failure on test failure at build time also ensures that we can reliably detect FTBFS issues in the future. No symbols have been removed (or added) with this update in version so there is no chance of regression due to ABI change etc. In the past, the security team has performed more significant version upgrades for libseccomp (2.2, 2.3, 2.4) -> 2.4.1 without major incident. In the case of *this* SRU, we are only doing a micro-version upgrade from 2.4.1 to 2.4.3 so this carries even less change of regressions. Any possible regressions may include applications now seeing correct system call resolution whereas previously th
[Group.of.nepali.translators] [Bug 1881278] [NEW] Ship 2018 Archive key in xenial's ubuntu-keyring
Public bug reported: [Impact] * Xenial systems will not be able to debootstrap Groovy archives when it finally switches to be signed by single 2018 key. To have support for xenial to operate against Groovy+ archives it needs access to 2018 archive key. Ship it. [Test Case] * Start xenial chroot or lxd container. * Observe that 4 keys are trusted - the original 2004 archive & cdimage, 2012 archive & cdimage # apt-key list --fingerprint /etc/apt/trusted.gpg pub 1024D/437D05B5 2004-09-12 Key fingerprint = 6302 39CC 130E 1A7F D81A 27B1 4097 6EAF 437D 05B5 uid Ubuntu Archive Automatic Signing Key sub 2048g/79164387 2004-09-12 pub 4096R/C0B21F32 2012-05-11 Key fingerprint = 790B C727 7767 219C 42C8 6F93 3B4F E6AC C0B2 1F32 uid Ubuntu Archive Automatic Signing Key (2012) pub 4096R/EFE21092 2012-05-11 Key fingerprint = 8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092 uid Ubuntu CD Image Automatic Signing Key (2012) pub 1024D/FBB75451 2004-12-30 Key fingerprint = C598 6B4F 1257 FFA8 6632 CBA7 4618 1433 FBB7 5451 uid Ubuntu CD Image Automatic Signing Key * Install the new ubuntu-keyring package * Observe that 5 keys are now trusted, including the 2018 archive key # apt-key list --fingerprint /etc/apt/trusted.gpg pub 1024D/437D05B5 2004-09-12 Key fingerprint = 6302 39CC 130E 1A7F D81A 27B1 4097 6EAF 437D 05B5 uid Ubuntu Archive Automatic Signing Key sub 2048g/79164387 2004-09-12 pub 4096R/C0B21F32 2012-05-11 Key fingerprint = 790B C727 7767 219C 42C8 6F93 3B4F E6AC C0B2 1F32 uid Ubuntu Archive Automatic Signing Key (2012) pub 4096R/EFE21092 2012-05-11 Key fingerprint = 8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092 uid Ubuntu CD Image Automatic Signing Key (2012) pub 1024D/FBB75451 2004-12-30 Key fingerprint = C598 6B4F 1257 FFA8 6632 CBA7 4618 1433 FBB7 5451 uid Ubuntu CD Image Automatic Signing Key pub 4096R/991BC93C 2018-09-17 Key fingerprint = F6EC B376 2474 EDA9 D21B 7022 8719 20D1 991B C93C uid Ubuntu Archive Automatic Signing Key (2018) * Dist upgrade to bionic * Observe that only 3 keys are trusted the 2012 cdimage&archive + 2018 key, and that none of them are in /etc/apt/trusted.gpg but are key snippets in /etc/apt/trusted.gpg.d/ # apt-key list /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-archive.gpg -- pub rsa4096 2012-05-11 [SC] 790B C727 7767 219C 42C8 6F93 3B4F E6AC C0B2 1F32 uid [ unknown] Ubuntu Archive Automatic Signing Key (2012) /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg -- pub rsa4096 2012-05-11 [SC] 8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092 uid [ unknown] Ubuntu CD Image Automatic Signing Key (2012) /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg -- pub rsa4096 2018-09-17 [SC] F6EC B376 2474 EDA9 D21B 7022 8719 20D1 991B C93C uid [ unknown] Ubuntu Archive Automatic Signing Key (2018) [Regression Potential] * Adding additional new trust key can trigger support request (aka why are you adding this key on xenial). The reason to add this key on xenial, is for xenial to allow securely debootstrap and operate on Groovy+ repositories which are about to drop 2012 key signatures. [Other Info] * Bionic switched from shipping keys in /etc/apt/trusted.gpg keyring, to individual snippets. Thus xenial's upload that adds the future key to /etc/apt/trusted.gpg should also remove it, during upgrade to bionic. To ensure that the systems upgraded from xenial to bionic, look the same as those that are fresh bionic installations. ** Affects: ubuntu-keyring (Ubuntu) Importance: Undecided Status: Invalid ** Affects: ubuntu-keyring (Ubuntu Xenial) Importance: Undecided Status: Triaged ** Also affects: ubuntu-keyring (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: ubuntu-keyring (Ubuntu) Status: New => Invalid ** Changed in: ubuntu-keyring (Ubuntu Xenial) Status: New => Triaged -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1881278 Title: Ship 2018 Archive key in xenial's ubuntu-keyring Status in ubuntu-keyring package in Ubuntu: Invalid Status in ubuntu-keyring source package in Xenial: Triaged Bug description: [Impact] * Xenial systems will not be able to debootstrap Groovy archives when it finally switches to be signed by single 2018 key. To have support for xenial to operate against Groovy+ archiv
[Group.of.nepali.translators] [Bug 1878969] [NEW] time-epoch never changes in SRUs
Public bug reported: [Impact] * Systems without hwclock come up with a fixed time epoch which is not updated in SRUs * Ideally booting with a newer built of systemd should move time epoch to be at least when systemd was last built. For example to the value of SOURCE_DATE_EPOCH. [Test Case] * Boot without network NTP or hwclock * Observe that the epoch is the same as the time when NEWS entry in the systemd source code was last touched. * Boot newer update of systemd, observe that the time epoch is at least 2020 [Regression Potential] * Bad epoch, may result in unable to perform TLS connections, validated GPG signatures, and snapd assertions. Changing epoch to be more recent is desired. Some machines may rely on the fact that "bionic" without hwclock always comes up in year 2018. But in practice that is incorrect thing to do. [Other Info] * By default option('time-epoch', type : 'integer', value : '-1', description : 'time epoch for time clients') in systemd is set to the modification time of the NEW entry time_epoch = run_command(stat, '-c', '%Y', NEWS).stdout().to_int() If available, it should be set to SOURCE_DATE_EPOCH=1585051767 value to be compliant with the https://reproducible-builds.org/docs/timestamps/ specification. ** Affects: ubuntu-core-initramfs Importance: Undecided Status: New ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: ubuntu-core-initramfs Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1878969 Title: time-epoch never changes in SRUs Status in ubuntu-core-initramfs: New Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Bug description: [Impact] * Systems without hwclock come up with a fixed time epoch which is not updated in SRUs * Ideally booting with a newer built of systemd should move time epoch to be at least when systemd was last built. For example to the value of SOURCE_DATE_EPOCH. [Test Case] * Boot without network NTP or hwclock * Observe that the epoch is the same as the time when NEWS entry in the systemd source code was last touched. * Boot newer update of systemd, observe that the time epoch is at least 2020 [Regression Potential] * Bad epoch, may result in unable to perform TLS connections, validated GPG signatures, and snapd assertions. Changing epoch to be more recent is desired. Some machines may rely on the fact that "bionic" without hwclock always comes up in year 2018. But in practice that is incorrect thing to do. [Other Info] * By default option('time-epoch', type : 'integer', value : '-1', description : 'time epoch for time clients') in systemd is set to the modification time of the NEW entry time_epoch = run_command(stat, '-c', '%Y', NEWS).stdout().to_int() If available, it should be set to SOURCE_DATE_EPOCH=1585051767 value to be compliant with the https://reproducible- builds.org/docs/timestamps/ specification. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-core-initramfs/+bug/1878969/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1875092] [NEW] support v5.4 syscalls
Public bug reported: [Impact] * update libssecomp syscalls, for example current seccomp on xenial and up, cannot correctly filter calls for focal armhf chroots on v5.4 kernels, due to new syscalls usage. [Test Case] * Boot v5.4 kernel * Use seccomp to try to resolve new syscall numbers * Rebuild snapd snap against bileto ppa with this change * Test that this rebuild snapd snap, can correctly launch confined python armhf interpreter on arm64 v5.4 kernel (i.e. uc20 raspi arm64 beta image) [Regression Potential] * The issue only impacts when one is running on a newer / hwe kernel, and tries to seccomp filter newer binaries that use new syscalls. No changes are made to any existing syscalls or apis. [Other Info] * Bileto PPA with this change is being prepared with this change. ** Affects: libseccomp (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: libseccomp (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: libseccomp (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: libseccomp (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: libseccomp (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: libseccomp (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1875092 Title: support v5.4 syscalls Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Xenial: New Status in libseccomp source package in Bionic: New Status in libseccomp source package in Eoan: New Bug description: [Impact] * update libssecomp syscalls, for example current seccomp on xenial and up, cannot correctly filter calls for focal armhf chroots on v5.4 kernels, due to new syscalls usage. [Test Case] * Boot v5.4 kernel * Use seccomp to try to resolve new syscall numbers * Rebuild snapd snap against bileto ppa with this change * Test that this rebuild snapd snap, can correctly launch confined python armhf interpreter on arm64 v5.4 kernel (i.e. uc20 raspi arm64 beta image) [Regression Potential] * The issue only impacts when one is running on a newer / hwe kernel, and tries to seccomp filter newer binaries that use new syscalls. No changes are made to any existing syscalls or apis. [Other Info] * Bileto PPA with this change is being prepared with this change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1875092/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1862938] Re: Enable late loading of microcode by default
I'm trying to fix the case when users/manufacturers failed to provide/install uefi capsule update on the motherboard, failed to first- boot with up to date microcode, and thus remain unsecured, whilst one can install microcode. In bare-metal cloud context, late loading of microcode can be done as the line of last defence to apply microcode. ** Changed in: intel-microcode (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1862938 Title: Enable late loading of microcode by default Status in intel-microcode package in Ubuntu: Fix Released Status in intel-microcode source package in Xenial: New Status in intel-microcode source package in Bionic: New Status in intel-microcode source package in Eoan: Fix Committed Status in intel-microcode source package in Focal: Fix Released Bug description: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. * Normally intel microcode is applied "early" for an uncompressed prepended initramfs archive. However, on systems booting without an initrd, or a missbuilt one, microcode might not get applied. In that case, we need to attempt loading microcode late which may give users security protection against CPU vulnerabilities which they might otherwise be lacking. In an ideal world, everyone would apply their bios/OEM updates with microcode updates in a timely fashion and then we wouldn't need to update CPU microcode from userspace at all. [Test Case] * Install updated package * Reobot * Observe early application of microcode $ journalctl -b | grep microcode Feb 12 12:02:48 ottawa kernel: microcode: microcode updated early to revision 0xd6, date = 2019-10-03 * Remove /usr/share/initramfs-tools/hooks/intel_microcode to prevent correct generation of early microcode updates * Rebuild initrd with update-initramfs -u * Reboot * Observe in dmesg that late loading of microcode is performed $ journalctl -b | grep microcode Feb 12 12:32:54 ottawa kernel: TAA: Vulnerable: Clear CPU buffers attempted, no microcode Feb 12 12:32:54 ottawa kernel: MDS: Vulnerable: Clear CPU buffers attempted, no microcode Feb 12 12:32:54 ottawa kernel: microcode: sig=0x506e3, pf=0x20, revision=0xc6 Feb 12 12:32:54 ottawa kernel: microcode: Microcode Update Driver: v2.2. Feb 12 12:32:57 ottawa kernel: microcode: updated to revision 0xd6, date = 2019-10-03 Feb 12 12:32:57 ottawa kernel: x86/CPU: CPU features have changed after loading microcode, but might not take effect. Feb 12 12:32:57 ottawa kernel: microcode: Reload completed, microcode revision: 0xd6 (Note the lack of "early" in above messages) [Regression Potential] * Application of microcode is a risky operation, especially if the cores are busy. Hence we prefer bios updates & early microcode updates, and those will remain the place. The late loading of microcode is really here for the cases were the previous two update strategies have failed. For example, from time to time, certain microcode updates are pulled or get blacklisted from late loading. [Other Info] * The majority of our users on bare-metal machines boot correctly with early microcode updates. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1862938/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1862938] [NEW] Enable late loading of microcode by default
Public bug reported: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. * Normally intel microcode is applied "early" for an uncompressed prepended initramfs archive. However, on systems booting without an initrd, or a missbuilt one, microcode might not get applied. In that case, we need to attempt loading microcode late which may give users security protection against CPU vulnerabilities which they might otherwise be lacking. In an ideal world, everyone would apply their bios/OEM updates with microcode updates in a timely fashion and then we wouldn't need to update CPU microcode from userspace at all. [Test Case] * Install updated package * Reobot * Observe early application of microcode $ journalctl -b | grep microcode Feb 12 12:02:48 ottawa kernel: microcode: microcode updated early to revision 0xd6, date = 2019-10-03 * Remove /usr/share/initramfs-tools/hooks/intel_microcode to prevent correct generation of early microcode updates * Rebuild initrd with update-initramfs -u * Reboot * Observe in dmesg that late loading of microcode is performed $ journalctl -b | grep microcode Feb 12 12:32:54 ottawa kernel: TAA: Vulnerable: Clear CPU buffers attempted, no microcode Feb 12 12:32:54 ottawa kernel: MDS: Vulnerable: Clear CPU buffers attempted, no microcode Feb 12 12:32:54 ottawa kernel: microcode: sig=0x506e3, pf=0x20, revision=0xc6 Feb 12 12:32:54 ottawa kernel: microcode: Microcode Update Driver: v2.2. Feb 12 12:32:57 ottawa kernel: microcode: updated to revision 0xd6, date = 2019-10-03 Feb 12 12:32:57 ottawa kernel: x86/CPU: CPU features have changed after loading microcode, but might not take effect. Feb 12 12:32:57 ottawa kernel: microcode: Reload completed, microcode revision: 0xd6 (Note the lack of "early" in above messages) [Regression Potential] * Application of microcode is a risky operation, especially if the cores are busy. Hence we prefer bios updates & early microcode updates, and those will remain the place. The late loading of microcode is really here for the cases were the previous two update strategies have failed. For example, from time to time, certain microcode updates are pulled or get blacklisted from late loading. [Other Info] * The majority of our users on bare-metal machines boot correctly with early microcode updates. ** Affects: intel-microcode (Ubuntu) Importance: Undecided Status: Fix Committed ** Affects: intel-microcode (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: intel-microcode (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: intel-microcode (Ubuntu Eoan) Importance: Undecided Status: New ** Affects: intel-microcode (Ubuntu Focal) Importance: Undecided Status: Fix Committed ** Also affects: intel-microcode (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: intel-microcode (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: intel-microcode (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: intel-microcode (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: intel-microcode (Ubuntu Focal) Status: New => Fix Committed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1862938 Title: Enable late loading of microcode by default Status in intel-microcode package in Ubuntu: Fix Committed Status in intel-microcode source package in Xenial: New Status in intel-microcode source package in Bionic: New Status in intel-microcode source package in Eoan: New Status in intel-microcode source package in Focal: Fix Committed Bug description: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. * Normally intel microcode is applied "early" for an uncompressed prepended initramfs archive. However, on systems booting without an initrd, or a missbuilt one, microcode might not get applied. In that case, we need to attempt loading microcode late which may give users security protection against CPU vulnerabilities which they might otherwise be lacking. In an ideal world, everyone would apply their bios/OEM updates with microcode updates in a timely fashion and then we wouldn't need to update CPU microcode from userspace at all. [Test Case] * Install updated package * Reobot * Observe early application of microcode $ journalctl -b | grep microcode Feb 12 12:02:48 ottawa ke
[Group.of.nepali.translators] [Bug 1856682] Re: GCC Miscompilation in vectorized code
gcc-5 affected in xenial and bionic. gcc-6 affected in bionic only. gcc-7 and gcc-8 affected, and currently have inflight SRU updates to v7.5 and v8.3 in bionic, thus are not going to be updated at the moment anywhere I don't think. gcc-9 is fixed in focal. ** Also affects: gcc-6 (Ubuntu) Importance: Undecided Status: New ** Also affects: gcc-5 (Ubuntu) Importance: Undecided Status: New ** Also affects: gcc-5 (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: gcc-6 (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: gcc-7 (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: gcc-8 (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: gcc-9 (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: gcc-5 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gcc-6 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gcc-7 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gcc-8 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gcc-9 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gcc-5 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: gcc-6 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: gcc-7 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: gcc-8 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: gcc-9 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: gcc-5 (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: gcc-6 (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: gcc-7 (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: gcc-8 (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: gcc-9 (Ubuntu Focal) Importance: High Assignee: Canonical Foundations Team (canonical-foundations) Status: Fix Released ** Also affects: gcc-5 (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: gcc-6 (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: gcc-7 (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: gcc-8 (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: gcc-9 (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: gcc-6 (Ubuntu Eoan) Status: New => Invalid ** Changed in: gcc-6 (Ubuntu Focal) Status: New => Invalid ** Changed in: gcc-6 (Ubuntu Xenial) Status: New => Invalid ** Changed in: gcc-5 (Ubuntu Disco) Status: New => Invalid ** Changed in: gcc-5 (Ubuntu Eoan) Status: New => Invalid ** Changed in: gcc-5 (Ubuntu Focal) Status: New => Invalid ** Changed in: gcc-7 (Ubuntu Xenial) Status: New => Invalid ** Changed in: gcc-8 (Ubuntu Xenial) Status: New => Invalid ** Changed in: gcc-9 (Ubuntu Xenial) Status: New => Invalid ** Changed in: gcc-9 (Ubuntu Bionic) Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1856682 Title: GCC Miscompilation in vectorized code Status in gcc: Unknown Status in Ubuntu on IBM z Systems: Triaged Status in gcc-5 package in Ubuntu: Invalid Status in gcc-6 package in Ubuntu: Invalid Status in gcc-7 package in Ubuntu: New Status in gcc-8 package in Ubuntu: New Status in gcc-9 package in Ubuntu: Fix Released Status in gcc-5 source package in Xenial: New Status in gcc-6 source package in Xenial: Invalid Status in gcc-7 source package in Xenial: Invalid Status in gcc-8 source package in Xenial: Invalid Status in gcc-9 source package in Xenial: Invalid Status in gcc-5 source package in Bionic: New Status in gcc-6 source package in Bionic: New Status in gcc-7 source package in Bionic: New Status in gcc-8 source package in Bionic: New Status in gcc-9 source package in Bionic: Invalid Status in gcc-5 source package in Disco: Invalid Status in gcc-6 source package in Disco: New Status in gcc-7 source package in Disco: New Status in gcc-8 source package in Disco: New Status in gcc-9 source package in Disco: New Status in gcc-5 source package in Eoan: Invalid Status in gcc-6 source package in Eoan: Invalid Status in gcc-7 source package in Eoan: New Status in gcc-8 source package in Eoan: New Status in gcc-9 source package in Eoan: New Status in gcc-5 source package in Focal: Invalid Status in gcc-6 source package in Focal: Invalid Status in gcc-7 source package in Focal: New Status in gcc-8 source package in Focal: New Status in gcc-9 source package in
[Group.of.nepali.translators] [Bug 1859013] [NEW] openssh tests use "not valid yet" certificate from 2020, which is now valid
Public bug reported: openssh tests use "not valid yet" certificate from 2020, which is now valid https://anongit.mindrot.org/openssh.git/commit/?id=ff31f15773ee173502eec4d7861ec56f26bba381 this causes autopkgtest regression suite fail in 2020 grep 20200101 -r . ./openssh-7.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" ./openssh-7.6p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" ./openssh-7.2p2/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" ./openssh-7.2p2/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" ./openssh-6.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" ./openssh-6.6p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" ./openssh-5.9p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" ./openssh-5.9p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" fixed in debian https://tracker.debian.org/news/1092767/accepted- openssh-181p1-4-source-into-unstable/ ** Affects: openssh (Ubuntu) Importance: Undecided Status: New ** Affects: openssh (Ubuntu Precise) Importance: Undecided Status: New ** Affects: openssh (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: openssh (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: openssh (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: openssh (Ubuntu Disco) Importance: Undecided Status: New ** Affects: openssh (Ubuntu Eoan) Importance: Undecided Status: New ** Affects: openssh (Ubuntu Focal) Importance: Undecided Status: New ** Tags: update-excuse ** Tags added: update-excuse ** Description changed: openssh tests use "not valid yet" certificate from 2020, which is now valid https://anongit.mindrot.org/openssh.git/commit/?id=ff31f15773ee173502eec4d7861ec56f26bba381 this causes autopkgtest regression suite fail in 2020 + + grep 20200101 -r . + ./openssh-7.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" + ./openssh-7.6p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" + ./openssh-7.2p2/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" + ./openssh-7.2p2/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" + ./openssh-6.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" + ./openssh-6.6p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" + ./openssh-5.9p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" + ./openssh-5.9p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" ** Also affects: openssh (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Disco) Importance: Undecided Status: New ** Description changed: openssh tests use "not valid yet" certificate from 2020, which is now valid https://anongit.mindrot.org/openssh.git/commit/?id=ff31f15773ee173502eec4d7861ec56f26bba381 this causes autopkgtest regression suite fail in 2020 - grep 20200101 -r . + grep 20200101 -r . ./openssh-7.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" ./openssh-7.6p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" ./openssh-7.2p2/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" ./openssh-7.2p2/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" ./openssh-6.6p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" ./openssh-6.6p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" ./openssh-5.9p1/regress/cert-hostkey.sh:test_one "cert not yet valid" failure "-h -V20200101:20300101" ./openssh-5.9p1/regress/cert-userkey.sh:test_one "cert not yet valid" failure "-n ${USER} -V20200101:20300101" + + fixed in debian https://tracker.debian.org/news/1092767/acce
[Group.of.nepali.translators] [Bug 1851499] Re: lz4 SIGSEGV in LZ4_decompress_generic
** Changed in: lz4 (Ubuntu Focal) Status: Triaged => Fix Released ** Also affects: lz4 (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: lz4 (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: lz4 (Ubuntu Eoan) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1851499 Title: lz4 SIGSEGV in LZ4_decompress_generic Status in lz4 package in Ubuntu: Fix Released Status in lz4 source package in Xenial: New Status in lz4 source package in Bionic: New Status in lz4 source package in Disco: New Status in lz4 source package in Eoan: Fix Released Status in lz4 source package in Focal: Fix Released Bug description: Affected packages: https://packages.ubuntu.com/xenial/liblz4-1 https://packages.ubuntu.com/bionic/liblz4-1 https://packages.ubuntu.com/cosmic/liblz4-1 https://packages.ubuntu.com/disco/liblz4-1 Non-Affected packages: https://packages.ubuntu.com/eoan/liblz4-1 Description: I got SIGSEGV with lz4, when trying to read a corrupted stream No null ptr check of source in LZ4_decompress_generic Description of problem: No null ptr check of source in LZ4_decompress_generic (gdb) bt #0 0x774ede70 in LZ4_decompress_generic (source=0x0, dest=0x63128800 "press.foo.bar.6057 1 349830001\ncompress.foo.bar.6058 1 349830001\ncompress.foo.bar.6059 1 349830001\ncompress.foo.bar.6060 1 349830001\ncompress.foo.bar.6061 1 349830001\ncompress.foo.bar.6062 1 349830001"..., inputSize=1253, outputSize=65536, endOnInput=1, partialDecoding=0, targetOutputSize=0, dict=0, lowPrefix=0x63128800 "press.foo.bar.6057 1 349830001\ncompress.foo.bar.6058 1 349830001\ncompress.foo.bar.6059 1 349830001\ncompress.foo.bar.6060 1 349830001\ncompress.foo.bar.6061 1 349830001\ncompress.foo.bar.6062 1 349830001"..., dictStart=0x0, dictSize=0) at lz4.c:1157 #1 LZ4_decompress_safe (source=0x0, dest=0x63128800 "press.foo.bar.6057 1 349830001\ncompress.foo.bar.6058 1 349830001\ncompress.foo.bar.6059 1 349830001\ncompress.foo.bar.6060 1 349830001\ncompress.foo.bar.6061 1 349830001\ncompress.foo.bar.6062 1 349830001"..., compressedSize=1253, maxDecompressedSize=65536) at lz4.c:1290 #2 0x77560631 in LZ4F_decompress_safe (source=0x0, dest=0x63128800 "press.foo.bar.6057 1 349830001\ncompress.foo.bar.6058 1 349830001\ncompress.foo.bar.6059 1 349830001\ncompress.foo.bar.6060 1 349830001\ncompress.foo.bar.6061 1 349830001\ncompress.foo.bar.6062 1 349830001"..., compressedSize=1253, maxDecompressedSize=65536, dictStart=0x63128800 "press.foo.bar.6057 1 349830001\ncompress.foo.bar.6058 1 349830001\ncompress.foo.bar.6059 1 349830001\ncompress.foo.bar.6060 1 349830001\ncompress.foo.bar.6061 1 349830001\ncompress.foo.bar.6062 1 349830001"..., dictSize=0) at lz4frame.c:957 #3 0x7755595b in LZ4F_decompress (decompressionContext=0x6110ff40, dstBuffer=0x7fffe8bdd82c, dstSizePtr=0x70cf96e0, srcBuffer=0x62d14400, srcSizePtr=0x70cf96c0, decompressOptionsPtr=0x70cf8120) at lz4frame.c:1294 Version-Release number of selected component (if applicable): In lz4 from HEAD bug was fixed https://github.com/lz4/lz4/blob/master/lib/lz4.c#L1668 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1851499/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH
** Changed in: snapd (Ubuntu Bionic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1771858 Title: /snap/bin not in default PATH for units, snapd should ship system- environment-generators to inject /snap/bin into $PATH Status in snapd package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in snapd source package in Xenial: Won't Fix Status in systemd source package in Xenial: Fix Released Status in snapd source package in Bionic: Fix Released Status in systemd source package in Bionic: Fix Released Status in snapd source package in Cosmic: Fix Released Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] * This means that software installed via snap isn't transparently available for units to use. As snaps are first-class citizens in Ubuntu, we should update the PATH. * When a generator started to be provided by systemd, it was recognized that $PATH is not correctly set, nonetheless, due to an environment bug that systemd generators run in. [Testcase] # make snapd-env-generator executable if it is not $ sudo chmod +x /usr/lib/systemd/system-environment-generators/snapd-env-generator # reboot, then test the effect of the fix $ systemd-run /usr/bin/env $ journalctl -e | grep PATH Output should contain /snap/bin Output should contain a complete and a valid PATH, i.e. PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" or similar. [Regression Potential] * snapd generator was already fixed separately to cause no harm, when running under a broken systemd. With the corrected environment, generators will now run with a correct PATH out of the box. A slight change of PATH will be observed by all generators, when running in containers/initramfs-less boots. However most generators will not be affected as they typically do not execute external binaries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1771858/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH
Installed snapd from proposed, rebooted, and /snap/bin is now in path of systemd-run unit Nov 18 18:25:26 well-monkey env[298]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin # dpkg-query -W snapd snapd 2.42.1+18.04 Prior to reboot it was not in PATH of a systemd-run unit. ** Changed in: snapd (Ubuntu Bionic) Status: Confirmed => Fix Committed ** Changed in: snapd (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1771858 Title: /snap/bin not in default PATH for units, snapd should ship system- environment-generators to inject /snap/bin into $PATH Status in snapd package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in snapd source package in Xenial: Invalid Status in systemd source package in Xenial: Fix Released Status in snapd source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Released Status in snapd source package in Cosmic: Fix Released Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] * This means that software installed via snap isn't transparently available for units to use. As snaps are first-class citizens in Ubuntu, we should update the PATH. * When a generator started to be provided by systemd, it was recognized that $PATH is not correctly set, nonetheless, due to an environment bug that systemd generators run in. [Testcase] # make snapd-env-generator executable if it is not $ sudo chmod +x /usr/lib/systemd/system-environment-generators/snapd-env-generator # reboot, then test the effect of the fix $ systemd-run /usr/bin/env $ journalctl -e | grep PATH Output should contain /snap/bin Output should contain a complete and a valid PATH, i.e. PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" or similar. [Regression Potential] * snapd generator was already fixed separately to cause no harm, when running under a broken systemd. With the corrected environment, generators will now run with a correct PATH out of the box. A slight change of PATH will be observed by all generators, when running in containers/initramfs-less boots. However most generators will not be affected as they typically do not execute external binaries. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1771858/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1840652] Re: upgrade amd64-microcode with new microcode for 17h family
** Summary changed: - upgrade amd64-microcode with new microcode & better initramfs hook + upgrade amd64-microcode with new microcode for 17h family ** Description changed: - upgrade amd64-microcode with new microcode & better initramfs hook - [Impact] - * New microcode is available - - * It is hard to generate initrd, with all microcodes included because the initramfs hook ignores -preset defaults. Adjust hook to take preset defaults into account. + * New microcode is available [Test Case] - * There is no testcase for new microcode, as it is unknown what has + * There is no testcase for new microcode, as it is unknown what has changed. - - * Install new package, and check that initrd with default settings (i.e. modules=most) has amd64 -microcode included. And that with modules=dep|list it only does so, if one is on AMD cpu. - - * Install initramfs-tools-ubuntu-core from snap image PPA, the resulting initrd should contian -both amd64 and intel microcode, despite using modules=list, due to the conf.d default settings -it overrides. [Regression Potential] - * New microcode is published without a changelog, thus it is unknown what it fixes or regresses, -yet it is recommeded to upgrade it. The 17h family microcode has been updated, almost doubling in size. - - * The hook default behaviour is not changed, only integration with - custom conf.d's is improved. - - * This both shows the SRU team that the risks have been considered, -and provides guidance to testers in regression-testing the SRU. + * New microcode is published without a changelog, thus it is unknown what it fixes or regresses, + yet it is recommeded to upgrade it. The 17h family microcode has been updated, almost doubling in size. [Other Info] - - * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amd-ucode?id=8aa9e3e3886d49b8e1427c1084cbbe567ca2b6ca + + * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux- + firmware.git/commit/amd- + ucode?id=8aa9e3e3886d49b8e1427c1084cbbe567ca2b6ca ** Changed in: amd64-microcode (Ubuntu Disco) Status: New => Fix Released ** Changed in: amd64-microcode (Ubuntu Bionic) Status: New => Triaged ** Changed in: amd64-microcode (Ubuntu Xenial) Status: New => Triaged -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1840652 Title: upgrade amd64-microcode with new microcode for 17h family Status in amd64-microcode package in Ubuntu: Fix Released Status in amd64-microcode source package in Xenial: Triaged Status in amd64-microcode source package in Bionic: In Progress Status in amd64-microcode source package in Disco: Fix Released Bug description: [Impact] * New microcode is available [Test Case] * There is no testcase for new microcode, as it is unknown what has changed. [Regression Potential] * New microcode is published without a changelog, thus it is unknown what it fixes or regresses, yet it is recommeded to upgrade it. The 17h family microcode has been updated, almost doubling in size. [Other Info] * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux- firmware.git/commit/amd- ucode?id=8aa9e3e3886d49b8e1427c1084cbbe567ca2b6ca To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/1840652/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1840670] [NEW] amd64-microcode better initramfs hook
Public bug reported: [Impact] * It is hard to generate initrd, with all microcodes included because the initramfs hook ignores preset defaults. Adjust hook to take preset defaults into account. [Test Case] * Install new package, and check that initrd with default settings (i.e. modules=most) has amd64 microcode included. And that with modules=dep|list it only does so, if one is on AMD cpu. * Install initramfs-tools-ubuntu-core from snap image PPA, the resulting initrd should contian both amd64 and intel microcode, despite using modules=list, due to the conf.d default settings it overrides. [Regression Potential] * The hook default behaviour is not changed, only integration with custom conf.d's is improved. ** Affects: amd64-microcode (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: amd64-microcode (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: amd64-microcode (Ubuntu Bionic) Importance: Undecided Status: In Progress ** Affects: amd64-microcode (Ubuntu Disco) Importance: Undecided Status: In Progress ** Also affects: amd64-microcode (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: amd64-microcode (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: amd64-microcode (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: amd64-microcode (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1840670 Title: amd64-microcode better initramfs hook Status in amd64-microcode package in Ubuntu: Fix Released Status in amd64-microcode source package in Xenial: New Status in amd64-microcode source package in Bionic: In Progress Status in amd64-microcode source package in Disco: In Progress Bug description: [Impact] * It is hard to generate initrd, with all microcodes included because the initramfs hook ignores preset defaults. Adjust hook to take preset defaults into account. [Test Case] * Install new package, and check that initrd with default settings (i.e. modules=most) has amd64 microcode included. And that with modules=dep|list it only does so, if one is on AMD cpu. * Install initramfs-tools-ubuntu-core from snap image PPA, the resulting initrd should contian both amd64 and intel microcode, despite using modules=list, due to the conf.d default settings it overrides. [Regression Potential] * The hook default behaviour is not changed, only integration with custom conf.d's is improved. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/1840670/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1840652] [NEW] upgrade amd64-microcode with new microcode & better initramfs hook
Public bug reported: upgrade amd64-microcode with new microcode & better initramfs hook [Impact] * New microcode is available * It is hard to generate initrd, with all microcodes included because the initramfs hook ignores preset defaults. Adjust hook to take preset defaults into account. [Test Case] * There is no testcase for new microcode, as it is unknown what has changed. * Install new package, and check that initrd with default settings (i.e. modules=most) has amd64 microcode included. And that with modules=dep|list it only does so, if one is on AMD cpu. * Install initramfs-tools-ubuntu-core from snap image PPA, the resulting initrd should contian both amd64 and intel microcode, despite using modules=list, due to the conf.d default settings it overrides. [Regression Potential] * New microcode is published without a changelog, thus it is unknown what it fixes or regresses, yet it is recommeded to upgrade it. The 17h family microcode has been updated, almost doubling in size. * The hook default behaviour is not changed, only integration with custom conf.d's is improved. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amd-ucode?id=8aa9e3e3886d49b8e1427c1084cbbe567ca2b6ca ** Affects: amd64-microcode (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: amd64-microcode (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: amd64-microcode (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: amd64-microcode (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: amd64-microcode (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: amd64-microcode (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: amd64-microcode (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: amd64-microcode (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1840652 Title: upgrade amd64-microcode with new microcode & better initramfs hook Status in amd64-microcode package in Ubuntu: Fix Released Status in amd64-microcode source package in Xenial: New Status in amd64-microcode source package in Bionic: New Status in amd64-microcode source package in Disco: New Bug description: upgrade amd64-microcode with new microcode & better initramfs hook [Impact] * New microcode is available * It is hard to generate initrd, with all microcodes included because the initramfs hook ignores preset defaults. Adjust hook to take preset defaults into account. [Test Case] * There is no testcase for new microcode, as it is unknown what has changed. * Install new package, and check that initrd with default settings (i.e. modules=most) has amd64 microcode included. And that with modules=dep|list it only does so, if one is on AMD cpu. * Install initramfs-tools-ubuntu-core from snap image PPA, the resulting initrd should contian both amd64 and intel microcode, despite using modules=list, due to the conf.d default settings it overrides. [Regression Potential] * New microcode is published without a changelog, thus it is unknown what it fixes or regresses, yet it is recommeded to upgrade it. The 17h family microcode has been updated, almost doubling in size. * The hook default behaviour is not changed, only integration with custom conf.d's is improved. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amd-ucode?id=8aa9e3e3886d49b8e1427c1084cbbe567ca2b6ca To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/amd64-microcode/+bug/1840652/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1839500] [NEW] Add a future-proof provides btrfs-progs name for ease of usability
Public bug reported: [Impact] * Upstream, other distributions, and Ubuntu Bionic+ use btrfs-progs name for this package * For historical reasons, this package was called btrfs-tools * To ease usability and automation it would be nice if the future-proof name would be available on older releases as a Provides: [Test Case] * $ apt install btrfs-progs Should install btrfs-tools package on xenial, and have btrfs [Regression Potential] * We are rebuilding the btrfs package, and adding extra metadata without any other code changes. So the only risks there are, are from doing a no-change rebuild of the package. [Other Info] * Examples of automation that install btrfs: - ansible playbooks - lxd - curtin - cloud-init - juju - interactive sysadmins ** Affects: btrfs-tools (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: btrfs-tools (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: btrfs-tools (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: btrfs-tools (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1839500 Title: Add a future-proof provides btrfs-progs name for ease of usability Status in btrfs-tools package in Ubuntu: Fix Released Status in btrfs-tools source package in Xenial: New Bug description: [Impact] * Upstream, other distributions, and Ubuntu Bionic+ use btrfs-progs name for this package * For historical reasons, this package was called btrfs-tools * To ease usability and automation it would be nice if the future- proof name would be available on older releases as a Provides: [Test Case] * $ apt install btrfs-progs Should install btrfs-tools package on xenial, and have btrfs [Regression Potential] * We are rebuilding the btrfs package, and adding extra metadata without any other code changes. So the only risks there are, are from doing a no-change rebuild of the package. [Other Info] * Examples of automation that install btrfs: - ansible playbooks - lxd - curtin - cloud-init - juju - interactive sysadmins To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/btrfs-tools/+bug/1839500/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1831443] [NEW] [hint] [sru] autopkgtest regressed as an API key is now required
Public bug reported: libgeo-coder-googlev3-perl uses a remote Google Maps service, which has started to require unique API keys. As there is no API key for the autopkgtests, they have started to fail. Autopkgtests for 0.16-1 will thus now always fail and should be hinted as expected failure. In 0.17-1 networked tests have been disabled during autopkgtests, and I'm proposing to SRU such a fix to bionic too. [Impact] * Unbreak autopkgtests by disabling networked tests due to remote service requiring authentication API tokens. [Test Case] * autopkgtests should pass [Regression Potential] * as networked tests are no longer performed, further regressions in utilising the remote service will not be caught. [Hints] bionic: force-badtest libgeo-coder-googlev3-perl/0.16-1 xenial: force-badtest libgeo-coder-googlev3-perl/0.14-1 ** Affects: libgeo-coder-googlev3-perl (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: libgeo-coder-googlev3-perl (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: libgeo-coder-googlev3-perl (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: libgeo-coder-googlev3-perl (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: libgeo-coder-googlev3-perl (Ubuntu) Status: New => Fix Released ** Also affects: libgeo-coder-googlev3-perl (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1831443 Title: [hint] [sru] autopkgtest regressed as an API key is now required Status in libgeo-coder-googlev3-perl package in Ubuntu: Fix Released Status in libgeo-coder-googlev3-perl source package in Xenial: New Status in libgeo-coder-googlev3-perl source package in Bionic: New Bug description: libgeo-coder-googlev3-perl uses a remote Google Maps service, which has started to require unique API keys. As there is no API key for the autopkgtests, they have started to fail. Autopkgtests for 0.16-1 will thus now always fail and should be hinted as expected failure. In 0.17-1 networked tests have been disabled during autopkgtests, and I'm proposing to SRU such a fix to bionic too. [Impact] * Unbreak autopkgtests by disabling networked tests due to remote service requiring authentication API tokens. [Test Case] * autopkgtests should pass [Regression Potential] * as networked tests are no longer performed, further regressions in utilising the remote service will not be caught. [Hints] bionic: force-badtest libgeo-coder-googlev3-perl/0.16-1 xenial: force-badtest libgeo-coder-googlev3-perl/0.14-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libgeo-coder-googlev3-perl/+bug/1831443/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1494851] Re: initramfs cryptroot hook script doesn't install cryptsetup if keyfile but no keyscript
Doesn't affect post-bionic releases. Marking as fixed. ** Changed in: cryptsetup (Ubuntu) Status: Incomplete => Fix Released ** Changed in: cryptsetup (Ubuntu) Assignee: TJ (tj) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1494851 Title: initramfs cryptroot hook script doesn't install cryptsetup if keyfile but no keyscript Status in cryptsetup package in Ubuntu: Fix Released Status in cryptsetup source package in Xenial: New Status in cryptsetup source package in Bionic: New Bug description: When crypttab specifies a key-file for the container of the root file- system but there is no keyscript= option no cryptsetup support is installed in the initrd.img. Currently the cryptroot initramfs hook script knows its a problem and will report: cryptsetup: WARNING: target LUKS_OS uses a key file, skipped This is BAD behaviour that renders the root file-system container inaccessible at boot time. Regardless of a key-script being available cryptsetup support should be installed into the initrd.img to enable the user to take manual steps to unlock the container. The hook script has no knowledge about pass phrases that might be set in other LUKS slots that are available to the user. This is the behaviour when a keyscript is specified but doesn't exist. The attached patch modifies the behaviour to include cryptsetup in the initrd.img and modify the warning to the user. cryptsetup: WARNING: target LUKS_OS uses a key file, but no keyscript is set. Please ensure there is also a typed pass-phrase set. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1494851/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1828892] Re: systemctl - alias service reports inactive while aliased is active
Only affects xenial at the moment. ** Changed in: systemd (Ubuntu Xenial) Status: In Progress => Triaged ** Changed in: systemd (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1828892 Title: systemctl - alias service reports inactive while aliased is active Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Bug description: [Impact] 'systemctl is-active' command reports an alias service as inactive even though the aliased service is active. Currently the 'systemctl is-active' command does not load units to minimise its effect on the system (i.e. that a monitoring command does not itself alter the state of the system). However, this behaviour leads to inconsistencies when services are aliased. [Test case] - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin /etc/systemd/system$ ls -la libvirtd.service lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> /lib/systemd/system/libvirt-bin.service $ systemctl is-active libvirtd inactive $ systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh /ect/systemd/system$ ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> /lib/systemd/system/ssh.service $ systemctl is-active sshd inactive $ systemctl is-active ssh active [Regression Potential] This fix may result into systemctl reporting inconsistent information concerning the status of a service. [Other] Upstream issue : https://github.com/systemd/systemd/issues/7875 Upstream fix : https://github.com/systemd/systemd/pull/7997 Xenial is affected, fix exists on Bionic onward. $ lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04 $ apt-cache policy systemd systemd: Installed: 229-4ubuntu21.21 Candidate: 229-4ubuntu21.21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828892/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1830479] Re: testcases expect first kernel log line, but not always in logs
It's a critical but in the Ubuntu platform if the very first kernel log line is not available in the system logs. And it is present on all arches, apart from the identified buggy arm64 which is in-flight being fixed (in eoan-proposed & disco-proposed with other releases to follow). cmdline-upstart-boot is only present in xenial? and arm64-kvm testing only started to be done post xenial release. Hence systemd/arm64 autopkgtest status is currently "Always Failed" and doesn't block anything. This is not applicable to devel series, nor should be applied in prior releases, instead kernel should be fixed. ** Changed in: systemd (Ubuntu Eoan) Status: New => Won't Fix ** Changed in: systemd (Ubuntu Disco) Status: New => Won't Fix ** Changed in: systemd (Ubuntu Xenial) Status: New => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1830479 Title: testcases expect first kernel log line, but not always in logs Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: Won't Fix Status in systemd source package in Bionic: New Status in systemd source package in Cosmic: New Status in systemd source package in Disco: Won't Fix Status in systemd source package in Eoan: Won't Fix Status in systemd package in Debian: Unknown Bug description: [impact] boot-and-services and cmdline-upstart-boot expect the first(ish) kernel log line to be in the system logs, but that is not guaranteed to be in the logs. [test case] run autopkgtest on arm64 with the current kernel, whose kernel log size is too small for journald or rsyslogd to capture the first kernel log messages. [regression potential] low; testcase fix only. [other info] the specific cause of this currently is too-small kernel log buffer size on arm64, which is being fixed in bug 1824864, but increasing amounts of boot time logging may cause a failure again, or custom kernel configs with small log buffers. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830479/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1604737] Re: headless installations are degraded due to failed setvtrgb.service
** Changed in: console-setup (Ubuntu Xenial) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1604737 Title: headless installations are degraded due to failed setvtrgb.service Status in console-setup package in Ubuntu: Fix Released Status in console-setup source package in Xenial: Won't Fix Bug description: s390x installations are degraded due to failed setvtrgb.service on z/vm, suspecting that it should be limited to just kvm on s390x, somehow. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1604737/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1634161] Re: Default multipath policy is round-robin, shows considerably worse read throughput compared to using service-time
** Changed in: multipath-tools (Ubuntu Xenial) Status: New => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1634161 Title: Default multipath policy is round-robin, shows considerably worse read throughput compared to using service-time Status in Ubuntu on IBM z Systems: Fix Released Status in multipath-tools package in Ubuntu: Fix Released Status in multipath-tools source package in Xenial: Won't Fix Bug description: ---Problem Description--- Default multipath policy is round-robin, shows considerably worse read throughput compared to using service-time Contact Information = Barbara Mundle, barbara.mun...@de.ibm.com ---uname output--- 4.4.0-21-generic Machine Type = z systems: Type 2964, Model 701 NC9 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Conducting throughput measurements with both policies shows the difference Userspace tool common name: multipath-tools The userspace tool has the following bit modes: 64-bit Userspace rpm: multipath-tools_0.5.0+git1.656f8865-5ubuntu2.2_s390x.deb Userspace tool obtained from project website: na *Additional Instructions for Barbara Mundle, barbara.mun...@de.ibm.com: -Attach ltrace and strace of userspace application. Throughput numbers with FIO for sequential read (in KBPS) with multipath policies service.time/round-robin (varying with number of jobs from 1 - 64): service-time round-robin 13193030 2917220 25248430 5020375 48453570 6438140 89708690 6444175 16 9712100 6448080 32 9714035 6450905 64 9718355 6461650 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1634161/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1824864] Re: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
$ cat /boot/config-5.0.0-16-generic | grep LOG_BUF CONFIG_LOG_BUF_SHIFT=18 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 $ uname -a Linux doerfel 5.0.0-16-generic #17-Ubuntu SMP Wed May 15 10:54:19 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux And journal shows complete kernel boot messages, thus this all now good on disco. ** Tags removed: verification-needed-disco ** Tags added: verification-done-disco ** No longer affects: systemd (Ubuntu Xenial) ** No longer affects: systemd (Ubuntu Bionic) ** No longer affects: systemd (Ubuntu Cosmic) ** No longer affects: systemd (Ubuntu Disco) ** No longer affects: systemd (Ubuntu Eoan) ** No longer affects: systemd (Ubuntu) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1824864 Title: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64 Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Status in linux source package in Disco: Fix Committed Status in linux source package in Eoan: Confirmed Bug description: [Impact] * Too small dmsg kernel buf ring size leads to loosing/missing early boot kernel messages which happen before journald starts slurping them up and storing them on disc. This results in messages similar to this one on boot "missed NN kernel messages on boot". This is especially pronounced on arm64 as the default setting there is way lower than any other 32bit or 64bit architecture we ship. Also amd64 appears to have the highest setting of 18 among all architectures we ship. The best course of action to bump all 64bit arches to 18, and keep all 32bit arches at the current & upstream default of 17. [Test Case] * $ cat /boot/config-`uname -r` | grep CONFIG_LOG_BUF_SHIFT on 64bit arches result should be: CONFIG_LOG_BUF_SHIFT=18 on 32bit arches result should be: CONFIG_LOG_BUF_SHIFT=17 * run systemd adt test, the boot-and-services test case should not fail journald tests with "missed kernel messages" visible in the error logs. [Regression Potential] * Increasing the size of the log_buf, will increase kernel memory usage which cannot be reclaimed. It will now become 256kb on arm64, ppc64el, s390x instead of 8kB/128kb/128kb respectively. 32bit arches remain unchanged at 128kb. [Other Info] * Original bug report CONFIG_LOG_BUF_SHIFT policy<{ 'amd64' : '18', 'arm64' : '14', 'armhf' : '17', 'i386' : '17', 'ppc64el': '17', 's390x' : '17'}> Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64. Potentially bump all 64-bit arches to 18 (or higher!) as was done on amd64, meaning set 18 on arm64 s390x ppc64el. I have a systemd autopkgtest test that asserts that we see Linux kernel command line in the dmesg (journalctl -k -b). And it is consistently failing on arm64 scalingstack KVM EFI machines with messages of "missing 81 kernel messages". config LOG_BUF_SHIFT int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" range 12 25 default 17 depends on PRINTK help Select the minimal kernel log buffer size as a power of 2. The final size is affected by LOG_CPU_MAX_BUF_SHIFT config parameter, see below. Any higher size also might be forced by "log_buf_len" boot parameter. Examples: 17 => 128 KB 16 => 64 KB 15 => 32 KB 14 => 16 KB 13 => 8 KB 12 => 4 KB 14 sounds like redictiously low for arm64. given that 17 is default across 32-bit arches, and 18 is default on amd64. On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el': '13', 's390x': '13'}> I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not. Please backport this to xenial and up. === systemd === systemd, boot-and-services test case can bump the ring buffer before running the tests. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824864/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1827391] Re: Japanese era Reiwa SRU
** Changed in: icu (Ubuntu Eoan) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1827391 Title: Japanese era Reiwa SRU Status in icu package in Ubuntu: Fix Released Status in icu source package in Precise: New Status in icu source package in Trusty: New Status in icu source package in Xenial: New Status in icu source package in Bionic: New Status in icu source package in Cosmic: New Status in icu source package in Disco: New Status in icu source package in Eoan: Fix Released Status in icu package in Debian: Fix Released Bug description: Japanese era Reiwa SRU $ rmadison icu 4.8.1.1-3ubuntu0.7 | precise-updates 52.1-3ubuntu0.8| trusty-updates 55.1-7ubuntu0.4| xenial-updates 60.2-3ubuntu3 | bionic 60.2-6ubuntu1 | cosmic 63.1-6 | disco 63.1-6 | eoan Note reported abi break / crash of chromium at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927933 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1827391/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1614080] Re: PATH contains dot when PATH is unset before running bash
** Changed in: bash (Ubuntu Trusty) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1614080 Title: PATH contains dot when PATH is unset before running bash Status in bash package in Ubuntu: Fix Released Status in bash source package in Precise: Fix Released Status in bash source package in Trusty: Won't Fix Status in bash source package in Xenial: Fix Committed Status in bash source package in Bionic: Fix Committed Status in bash source package in Cosmic: Fix Released Status in bash source package in Disco: Fix Committed Status in bash source package in Eoan: Fix Released Bug description: [Impact] * The fallback path built into bash contains '.' which leads to unexpected addition of the current working directory. It should not be there, just like it isnt' in pre-precise and cosmic+. [Test Case] * $ env -u PATH /bin/bash -c 'echo $PATH' Should not have '.' as any component. Nor should there be any empty components, i.e. '::'. [Regression Potential] * Normally PATH is always set by either init, systemd, or any other hypervisor. Thus this only affects executions under bash, when it was started without any environment - e.g. booting with 'init=/bin/bash'. [Other Info] * Original bug report. On ubuntu 16.04 (but also 14.04), running bash with PATH unset always adds '.' to PATH: philippe@pv-desktop:~$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games philippe@pv-desktop:~$ unset PATH philippe@pv-desktop:~$ /bin/bash philippe@pv-desktop:~$ echo $PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. Even when testing in a virtual machine / docker, and erasing /root/.profile /root/.bashrc /etc/profile /etc/bash.bashrc the problem still happens. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1614080/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1827391] Re: Japanese era Reiwa SRU
** Description changed: Japanese era Reiwa SRU $ rmadison icu 4.8.1.1-3ubuntu0.7 | precise-updates 52.1-3ubuntu0.8| trusty-updates 55.1-7ubuntu0.4| xenial-updates 60.2-3ubuntu3 | bionic 60.2-6ubuntu1 | cosmic 63.1-6 | disco 63.1-6 | eoan + + Note reported abi break / crash of chromium at https://bugs.debian.org + /cgi-bin/bugreport.cgi?bug=927933 ** Description changed: Japanese era Reiwa SRU $ rmadison icu 4.8.1.1-3ubuntu0.7 | precise-updates 52.1-3ubuntu0.8| trusty-updates 55.1-7ubuntu0.4| xenial-updates 60.2-3ubuntu3 | bionic 60.2-6ubuntu1 | cosmic 63.1-6 | disco 63.1-6 | eoan - Note reported abi break / crash of chromium at https://bugs.debian.org - /cgi-bin/bugreport.cgi?bug=927933 + Note reported abi break / crash of chromium at + + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927933 ** Bug watch added: Debian Bug tracker #927933 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927933 ** Also affects: icu (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927933 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1827391 Title: Japanese era Reiwa SRU Status in icu package in Ubuntu: New Status in icu source package in Precise: New Status in icu source package in Trusty: New Status in icu source package in Xenial: New Status in icu source package in Bionic: New Status in icu source package in Cosmic: New Status in icu source package in Disco: New Status in icu source package in Eoan: New Status in icu package in Debian: Unknown Bug description: Japanese era Reiwa SRU $ rmadison icu 4.8.1.1-3ubuntu0.7 | precise-updates 52.1-3ubuntu0.8| trusty-updates 55.1-7ubuntu0.4| xenial-updates 60.2-3ubuntu3 | bionic 60.2-6ubuntu1 | cosmic 63.1-6 | disco 63.1-6 | eoan Note reported abi break / crash of chromium at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927933 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1827391/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1614080] Re: PATH contains dot when PATH is unset before running bash
** Also affects: bash (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: bash (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: bash (Ubuntu Eoan) Importance: Medium Status: Fix Released ** Also affects: bash (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: bash (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: bash (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: bash (Ubuntu Eoan) Status: Fix Released => In Progress ** Changed in: bash (Ubuntu Cosmic) Status: New => Fix Released ** Changed in: bash (Ubuntu Disco) Status: New => In Progress ** Changed in: bash (Ubuntu Eoan) Status: In Progress => Fix Committed ** Changed in: bash (Ubuntu Bionic) Status: New => In Progress ** Changed in: bash (Ubuntu Xenial) Status: New => In Progress ** Changed in: bash (Ubuntu Trusty) Status: New => In Progress ** Also affects: bash (Ubuntu Precise) Importance: Undecided Status: New ** Changed in: bash (Ubuntu Precise) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1614080 Title: PATH contains dot when PATH is unset before running bash Status in bash package in Ubuntu: Fix Committed Status in bash source package in Precise: Fix Released Status in bash source package in Trusty: In Progress Status in bash source package in Xenial: In Progress Status in bash source package in Bionic: In Progress Status in bash source package in Cosmic: Fix Released Status in bash source package in Disco: In Progress Status in bash source package in Eoan: Fix Committed Bug description: [Impact] * The fallback path built into bash contains '.' which leads to unexpected addition of the current working directory. It should not be there, just like it isnt' in pre-precise and cosmic+. [Test Case] * $ env -u PATH /bin/bash -c 'echo $PATH' Should not have '.' as any component. Nor should there be any empty components, i.e. '::'. [Regression Potential] * Normally PATH is always set by either init, systemd, or any other hypervisor. Thus this only affects executions under bash, when it was started without any environment - e.g. booting with 'init=/bin/bash'. [Other Info] * Original bug report. On ubuntu 16.04 (but also 14.04), running bash with PATH unset always adds '.' to PATH: philippe@pv-desktop:~$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games philippe@pv-desktop:~$ unset PATH philippe@pv-desktop:~$ /bin/bash philippe@pv-desktop:~$ echo $PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. Even when testing in a virtual machine / docker, and erasing /root/.profile /root/.bashrc /etc/profile /etc/bash.bashrc the problem still happens. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1614080/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1825448] Re: gnupg2 autopkgtest 'simple-tests' should be included in x/b/c
Adding new autopkgtests in devel series - good. Adding new autopkgtests in stable series - not good. Fixing regressions that got introduced during the lifetime of a stable series - good. The only times when we introduced new autopkgtests in stable series, is when we upload fixes for regressions / SRU bugs and attempt at preventing them from regressing again in the stable series. This development does not appear to be that. Uploading new smoke-tests is out of the scope of the SRU policy. What prompted this bug report? I feel like rejecting the series tasks of this bug report. ** Changed in: gnupg2 (Ubuntu Cosmic) Status: In Progress => Won't Fix ** Changed in: gnupg2 (Ubuntu Bionic) Status: In Progress => Won't Fix ** Changed in: gnupg2 (Ubuntu Xenial) Status: In Progress => Won't Fix ** Changed in: gnupg (Ubuntu Xenial) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825448 Title: gnupg2 autopkgtest 'simple-tests' should be included in x/b/c Status in gnupg package in Ubuntu: Invalid Status in gnupg2 package in Ubuntu: Fix Released Status in gnupg source package in Xenial: Won't Fix Status in gnupg2 source package in Xenial: Won't Fix Status in gnupg2 source package in Bionic: Won't Fix Status in gnupg2 source package in Cosmic: Won't Fix Bug description: [impact] b/c currently only have gpgv-win32 test, which is limited in what it tests and what archs it runs on. additionally, it always fails (see bug 1825186). x currently has no tests at all for gnupg or gnupg2. [test case] run autopkgtests for gnupg2 on b/c. [regession potential] adding a testcase may result in the testcase incorrectly failing in the future. [other info] this test case is cherry-picked from gnupg2 in disco. the test case required slight modification for gnupg v1, as 'Key-Type: default' only works with v2. Note that Xenial is the last release that carries gnupg v1; Bionic and later carry only gnupg v2. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825448/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1825099] Re: Unable to deploy Xenial on a s390x KVM
Hopefully this fixes s390-tools chreipl for xenial. Cherrypick from s390-tools v1.35 release. ** Patch added: "chreipl-fix-chreipl-node-for-virtio-devices.patch" https://bugs.launchpad.net/ubuntu/xenial/+source/s390-tools/+bug/1825099/+attachment/5259139/+files/chreipl-fix-chreipl-node-for-virtio-devices.patch ** Changed in: s390-tools (Ubuntu Xenial) Status: Confirmed => In Progress ** Changed in: s390-tools (Ubuntu) Status: New => Fix Released ** Description changed: - When trying to deploy Xenial on a s390x KVM, the deployment will fail. - (it works for B/C) + [Impact] + + * chreipl is a tool that can set/change the IPL settings of a guest, + meaning what should it boot next upon a reboot call (ie. which device to + boot from, or to like dumpkernel, etc). v1.34 has a processing bug, + meaning that chreipl does not work with virtio disk drives, as seen in + VMs. The fix is to cherrypick a patch which was most likely introduced + in teh v1.35 release. Please note the v1.XX series upstream code base is + not public, so the patch i'm cherrypicking is a hunk from the diff + between xenial and yakkety releases. + + [Test Case] + + * Use chreipl in a qemu-kvm VM, it should work. + + [Regression Potential] + + * This changes the codepath, of detecting which drive to use. Other usage by user specified id are not affected, and default usage of chreipl in xenial so far has been on best effort basis (ie. guarded with || true, in d-i) because normally it is trivial to control IPL methods from the underlying hypervisor (HMC, z/VM, qemu/libvirt) + * However, this patch is needed to enable MAAS KVM pods to be able to deploy Xenial guests, as that deployment mechanism depends on working chreipl. + + [Other Info] + + * Original bug report: + + + When trying to deploy Xenial on a s390x KVM, the deployment will fail. (it works for B/C) Looks like it will fail with: chreipl: Could not find DASD CCW device "virtio0" curtin: Installation failed with exception: Unexpected error while running command. Command: chreipl node /dev/vda Exit code: 1 Reason: - Stdout: chreipl: Could not find DASD CCW device "virtio0" Complete output from the MaaS UI: curtin: Installation started. (18.1-59-g0f993084-0ubuntu1~18.04.1) third party drivers not installed or necessary. Hit:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates InRelease [109 kB] Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-security InRelease [109 kB] Get:4 http://ports.ubuntu.com/ubuntu-ports xenial-backports InRelease [107 kB] Get:5 http://ports.ubuntu.com/ubuntu-ports xenial/universe s390x Packages [7190 kB] Get:6 http://ports.ubuntu.com/ubuntu-ports xenial/multiverse s390x Packages [119 kB] Get:7 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x Packages [672 kB] Get:8 http://ports.ubuntu.com/ubuntu-ports xenial-updates/universe s390x Packages [613 kB] Get:9 http://ports.ubuntu.com/ubuntu-ports xenial-updates/multiverse s390x Packages [11.0 kB] Get:10 http://ports.ubuntu.com/ubuntu-ports xenial-security/main s390x Packages [432 kB] Get:11 http://ports.ubuntu.com/ubuntu-ports xenial-security/universe s390x Packages [340 kB] Get:12 http://ports.ubuntu.com/ubuntu-ports xenial-security/multiverse s390x Packages [1716 B] Get:13 http://ports.ubuntu.com/ubuntu-ports xenial-backports/main s390x Packages [7280 B] Get:14 http://ports.ubuntu.com/ubuntu-ports xenial-backports/universe s390x Packages [6536 B] Fetched 9719 kB in 2s (4674 kB/s) Reading package lists... zfs-dkms set on hold. Reading package lists... Building dependency tree... Reading state information... The following additional packages will be installed: crda iw libnl-3-200 libnl-genl-3-200 linux-firmware linux-headers-4.4.0-145 linux-headers-4.4.0-145-generic linux-headers-generic linux-image-4.4.0-145-generic linux-image-generic linux-modules-4.4.0-145-generic linux-modules-extra-4.4.0-145-generic wireless-regdb Suggested packages: fdutils linux-doc-4.4.0 | linux-source-4.4.0 linux-tools The following NEW packages will be installed: crda iw libnl-3-200 libnl-genl-3-200 linux-firmware linux-generic linux-headers-4.4.0-145 linux-headers-4.4.0-145-generic linux-headers-generic linux-image-4.4.0-145-generic linux-image-generic linux-modules-4.4.0-145-generic linux-modules-extra-4.4.0-145-generic wireless-regdb 0 upgraded, 14 newly installed, 0 to remove and 8 not upgraded. Need to get 74.5 MB of archives. After this operation, 375 MB of additional disk space will be used. Get:1 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x libnl-3-200 s390x 3.2.27-1ubuntu0.16.04.1 [49.7 kB] Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x libnl-genl-3-200 s390x 3.2.27-1ubuntu0.16.04.1 [11.0 kB] Get:3 http://ports.ubuntu.com/ubuntu-ports xen
[Group.of.nepali.translators] [Bug 1825099] Re: Unable to deploy Xenial on a s390x KVM
Adjusting bug tasks ** Also affects: s390-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: s390-tools (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: maas (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: maas (Ubuntu Xenial) Status: New => Invalid ** Changed in: maas (Ubuntu) Status: Won't Fix => Invalid ** Changed in: s390-tools (Ubuntu Xenial) Status: New => Confirmed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825099 Title: Unable to deploy Xenial on a s390x KVM Status in ubuntu-kernel-tests: New Status in maas package in Ubuntu: Invalid Status in s390-tools package in Ubuntu: New Status in maas source package in Xenial: Invalid Status in s390-tools source package in Xenial: Confirmed Bug description: When trying to deploy Xenial on a s390x KVM, the deployment will fail. (it works for B/C) Looks like it will fail with: chreipl: Could not find DASD CCW device "virtio0" curtin: Installation failed with exception: Unexpected error while running command. Command: chreipl node /dev/vda Exit code: 1 Reason: - Stdout: chreipl: Could not find DASD CCW device "virtio0" Complete output from the MaaS UI: curtin: Installation started. (18.1-59-g0f993084-0ubuntu1~18.04.1) third party drivers not installed or necessary. Hit:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates InRelease [109 kB] Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-security InRelease [109 kB] Get:4 http://ports.ubuntu.com/ubuntu-ports xenial-backports InRelease [107 kB] Get:5 http://ports.ubuntu.com/ubuntu-ports xenial/universe s390x Packages [7190 kB] Get:6 http://ports.ubuntu.com/ubuntu-ports xenial/multiverse s390x Packages [119 kB] Get:7 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x Packages [672 kB] Get:8 http://ports.ubuntu.com/ubuntu-ports xenial-updates/universe s390x Packages [613 kB] Get:9 http://ports.ubuntu.com/ubuntu-ports xenial-updates/multiverse s390x Packages [11.0 kB] Get:10 http://ports.ubuntu.com/ubuntu-ports xenial-security/main s390x Packages [432 kB] Get:11 http://ports.ubuntu.com/ubuntu-ports xenial-security/universe s390x Packages [340 kB] Get:12 http://ports.ubuntu.com/ubuntu-ports xenial-security/multiverse s390x Packages [1716 B] Get:13 http://ports.ubuntu.com/ubuntu-ports xenial-backports/main s390x Packages [7280 B] Get:14 http://ports.ubuntu.com/ubuntu-ports xenial-backports/universe s390x Packages [6536 B] Fetched 9719 kB in 2s (4674 kB/s) Reading package lists... zfs-dkms set on hold. Reading package lists... Building dependency tree... Reading state information... The following additional packages will be installed: crda iw libnl-3-200 libnl-genl-3-200 linux-firmware linux-headers-4.4.0-145 linux-headers-4.4.0-145-generic linux-headers-generic linux-image-4.4.0-145-generic linux-image-generic linux-modules-4.4.0-145-generic linux-modules-extra-4.4.0-145-generic wireless-regdb Suggested packages: fdutils linux-doc-4.4.0 | linux-source-4.4.0 linux-tools The following NEW packages will be installed: crda iw libnl-3-200 libnl-genl-3-200 linux-firmware linux-generic linux-headers-4.4.0-145 linux-headers-4.4.0-145-generic linux-headers-generic linux-image-4.4.0-145-generic linux-image-generic linux-modules-4.4.0-145-generic linux-modules-extra-4.4.0-145-generic wireless-regdb 0 upgraded, 14 newly installed, 0 to remove and 8 not upgraded. Need to get 74.5 MB of archives. After this operation, 375 MB of additional disk space will be used. Get:1 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x libnl-3-200 s390x 3.2.27-1ubuntu0.16.04.1 [49.7 kB] Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x libnl-genl-3-200 s390x 3.2.27-1ubuntu0.16.04.1 [11.0 kB] Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x wireless-regdb all 2018.05.09-0ubuntu1~16.04.1 [11.7 kB] Get:4 http://ports.ubuntu.com/ubuntu-ports xenial/main s390x iw s390x 3.17-1 [59.8 kB] Get:5 http://ports.ubuntu.com/ubuntu-ports xenial/main s390x crda s390x 3.13-1 [59.7 kB] Get:6 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x linux-firmware all 1.157.21 [49.8 MB] Get:7 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x linux-modules-4.4.0-145-generic s390x 4.4.0-145.171 [7359 kB] Get:8 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x linux-image-4.4.0-145-generic s390x 4.4.0-145.171 [3882 kB] Get:9 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main s390x linux-modules-extra-4.4.0-145-generic s390x 4.4.0-145.171 [2689 kB] Get:10 http://ports.ubuntu
[Group.of.nepali.translators] [Bug 1824864] Re: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Description changed: CONFIG_LOG_BUF_SHIFT policy<{ 'amd64' : '18', 'arm64' : '14', 'armhf' : '17', 'i386' : '17', 'ppc64el': '17', 's390x' : '17'}> Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64. Potentially bump all 64-bit arches to 18 (or higher!) as was done on amd64, meaning set 18 on arm64 s390x ppc64el. I have a systemd autopkgtest test that asserts that we see Linux kernel command line in the dmesg (journalctl -k -b). And it is consistently failing on arm64 scalingstack KVM EFI machines with messages of "missing 81 kernel messages". config LOG_BUF_SHIFT int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" range 12 25 default 17 depends on PRINTK help Select the minimal kernel log buffer size as a power of 2. The final size is affected by LOG_CPU_MAX_BUF_SHIFT config parameter, see below. Any higher size also might be forced by "log_buf_len" boot parameter. Examples: 17 => 128 KB 16 => 64 KB 15 => 32 KB 14 => 16 KB 13 => 8 KB 12 => 4 KB 14 sounds like redictiously low for arm64. given that 17 is default across 32-bit arches, and 18 is default on amd64. On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el': '13', 's390x': '13'}> I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not. + Please backport this to xenial and up. - Please backport this to xenial and up. + + + === systemd === + + systemd, boot-and-services test case can bump the ring buffer before + running the tests. -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1824864 Title: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64 Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Xenial: Confirmed Status in systemd source package in Xenial: New Status in linux source package in Bionic: Confirmed Status in systemd source package in Bionic: New Status in linux source package in Cosmic: Confirmed Status in systemd source package in Cosmic: New Status in linux source package in Disco: Confirmed Status in systemd source package in Disco: New Status in linux source package in EE-Series: Confirmed Status in systemd source package in EE-Series: New Bug description: CONFIG_LOG_BUF_SHIFT policy<{ 'amd64' : '18', 'arm64' : '14', 'armhf' : '17', 'i386' : '17', 'ppc64el': '17', 's390x' : '17'}> Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64. Potentially bump all 64-bit arches to 18 (or higher!) as was done on amd64, meaning set 18 on arm64 s390x ppc64el. I have a systemd autopkgtest test that asserts that we see Linux kernel command line in the dmesg (journalctl -k -b). And it is consistently failing on arm64 scalingstack KVM EFI machines with messages of "missing 81 kernel messages". config LOG_BUF_SHIFT int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" range 12 25 default 17 depends on PRINTK help Select the minimal kernel log buffer size as a power of 2. The final size is affected by LOG_CPU_MAX_BUF_SHIFT config parameter, see below. Any higher size also might be forced by "log_buf_len" boot parameter. Examples: 17 => 128 KB 16 => 64 KB 15 => 32 KB 14 => 16 KB 13 => 8 KB 12 => 4 KB 14 sounds like redictiously low for arm64. given that 17 is default across 32-bit arches, and 18 is default on amd64. On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el': '13', 's390x': '13'}> I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not. Please backport this to xenial and up. === systemd === systemd, boot-and-services test case can bump the ring buffer before running the tests. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824864/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help :
[Group.of.nepali.translators] [Bug 1818814] Re: systemd-tmpfiles-setup.services fails to create /var/run directories
*** This bug is a duplicate of bug 1804847 *** https://bugs.launchpad.net/bugs/1804847 OpenVZ has been proactive w.r.t. this issue and have issued an update that includes the required backports a long time ago. Please see this comment: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804847/comments/20 """ Updated OpenVz6 kernel was released: https://wiki.openvz.org/Download/kernel/rhel6/042stab134.7 We are very grateful for Ubuntu team for reverting of patches specially for OpenVz. For affected hosters: OpenVz6 is great but it is really old, and similar incidents can happen again and again. Please think about switch to RHEL7-based OpenVz7. Thank you, Vasily Averin """ Which was released in November 2018. All your provider needs to do, is to apply OpenVZ updates. >From Ubuntu point of view this is a wontfix, as providing systemd without using fchownat opens a security vulnerability CVE-2018-6954. Please upgrde to OpenVZ kernel 042stab134.7 or anything better. I believe currently the latest kernel is 042stab136.1. @ddstreet please delete your packages from the PPA, as you are intentially distributing security vulnerable systemd. Regards, Dimitri. ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-6954 ** Changed in: systemd (Ubuntu Xenial) Status: Invalid => Won't Fix ** Changed in: systemd (Ubuntu) Status: New => Won't Fix ** This bug has been marked a duplicate of bug 1804847 systemd=229-4ubuntu21.8 use of fchownat failes on some systems (openvz) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1818814 Title: systemd-tmpfiles-setup.services fails to create /var/run directories Status in systemd package in Ubuntu: Won't Fix Status in systemd source package in Xenial: Won't Fix Bug description: 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu Description:Ubuntu 16.04.6 LTS Release:16.04 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center systemd: Installed: 229-4ubuntu21.16 Candidate: 229-4ubuntu21.16 Version table: *** 229-4ubuntu21.16 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 229-4ubuntu4 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages 3) What you expected to happen 4) What happened instead Ubuntu server (running in OpenVZ VPS farm, thus the old kernel version) has been up and running happily, until I performed apt-get upgrade and rebooted the server. After reboot, I could not establish SSH connection to server, port 22 connection was refused. I opened a HTML console to my server instance and checked logs. From the logs, it was shown, that SSH server could not start, as it did not have the /var/run/sshd directory. After scrolling back the /var/log/syslog, I noticed that there were lots of other /var/run subdirectories, which were not created. Here is cut&paste from /var/log/syslog, related to systemd-tmpfiles: ---8<---8<--- Mar 6 12:32:54 vspk systemd-tmpfiles[81]: [/usr/lib/tmpfiles.d/00rsyslog.conf:6] Duplicate line for path "/v ar/log", ignoring. Mar 6 12:32:54 vspk systemd[1]: Starting Raise network interfaces... Mar 6 12:32:54 vspk systemd-tmpfiles[81]: fchownat() of /run/named failed: Invalid argument Mar 6 12:32:54 vspk systemd-tmpfiles[81]: Failed to validate path /var/run/fail2ban: Too many levels of symb olic links Mar 6 12:32:54 vspk systemd-tmpfiles[81]: Failed to validate path /var/run/screen: Too many levels of
[Group.of.nepali.translators] [Bug 1816753] Re: do-release-upgrade on WSL failed horribly due to grub and others
** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1816753 Title: do-release-upgrade on WSL failed horribly due to grub and others Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Status in systemd source package in Cosmic: New Status in systemd source package in Disco: New Bug description: Upon reading an Ubuntu page that said it was possible to upgrade my Ubuntu-under-Windows 10 install (WSL) from 16.04 LTS just by running do-release-upgrade, I excitedly went to my terminal and ran the command. First it refused to run because system was not fully updated. Fine, I ran: sudo apt update sudo apt dist-upgrade This process completed without any errors. I then ran do-release- upgrade again. This time it started okay and got through most of the process. But then at some point it decided to run grub even though I am running Ubuntu under WSL, so presumably grub should not be used. It did apparently detect that it wasn't needed, because it asked me if I was sure I didn't want to install it on the boot device. I answered yes. Then the install proceeded to LXD but soon after came an error related to grub. After that it went downhill fast with at least 2 other errors. Additionally, when the system attempted to roll back the upgrade I got an error from a kernel package. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: friendly-recovery 0.2.38ubuntu1 ProcVersionSignature: Microsoft 4.4.0-17763.253-Microsoft 4.4.35 Uname: Linux 4.4.0-17763-Microsoft x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Tue Feb 19 23:50:44 2019 Dmesg: [0.017808] Microsoft 4.4.0-17763.253-Microsoft 4.4.35 ErrorMessage: installed friendly-recovery package post-installation script subprocess returned error exit status 1 PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.7, python3-minimal, 3.6.7-1~18.04 PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2.1 apt 1.6.8 SourcePackage: grub2 Title: package friendly-recovery 0.2.38ubuntu1 failed to install/upgrade: installed friendly-recovery package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to bionic on 2019-02-20 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1816753/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1775018] Re: Fix for openssl 1.0.2 backport
openssl1.0 is removed from disco. ** Also affects: openssl (Ubuntu Disco) Importance: Undecided Assignee: Canonical Foundations Team (canonical-foundations) Status: Fix Released ** Also affects: openssl1.0 (Ubuntu Disco) Importance: Undecided Status: Confirmed ** Changed in: openssl1.0 (Ubuntu Disco) Status: Confirmed => Won't Fix ** Changed in: openssl1.0 (Ubuntu) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1775018 Title: Fix for openssl 1.0.2 backport Status in Ubuntu on IBM z Systems: Confirmed Status in openssl package in Ubuntu: Fix Released Status in openssl1.0 package in Ubuntu: Won't Fix Status in openssl source package in Xenial: Invalid Status in openssl1.0 source package in Xenial: Invalid Status in openssl source package in Bionic: Fix Released Status in openssl1.0 source package in Bionic: Confirmed Status in openssl source package in Cosmic: Fix Released Status in openssl1.0 source package in Cosmic: Confirmed Status in openssl source package in Disco: Fix Released Status in openssl1.0 source package in Disco: Won't Fix Bug description: [Impact] * Fix hw accelerated performance impact on s390x with non-default openssl1.0. [Test Case] * Test that performance of hw accelerated crypto is improved / i.e. ssl speed test * Test that openssh still works, just in case. [Regression Potential] * This only changes accelerated codepath on s390x, for specific algos when CPACF is enabled on the system cpu, which is usually on. * Same fix is already in use by 1.1.0 default openssl package, and well excercised on bionic and up. [Other Info] * original bug report. This is a fix for this feature's backport to openssl 1.0.2 ( 1.1.0 and upstream code are not affected ). Original LP ticket : https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1743750 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1775018/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1775018] Re: Fix for openssl 1.0.2 backport
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1743750 is [18.04 FEAT] Add support for CPACF enhancements to openssl also known as ltc-163655 and is only present in bionic. In xenial: we have src:openssl, 1.0.2 which does not have CPACF backport, and therefore the attached patch does not apply at all, and also there are no issues to fix there either. Unless, you mean openssl-ibmca is also affected in xenial? in that case do you have a patch for openssl-ibmca? In bionic: we have src:openssl, 1.1.0 which is not affected as you say, as the default openssl version. we also have src:openssl1.0 which does have CPACF backport and the attached patch applies to. Please note, that openssl1.0 is only used by a small amount of packages in bionic. We are preparing the update for that package. ** Description changed: - This is a fix for this feature's backport to openssl 1.0.2 ( 1.1.0 and - upstream code are not affected ). + [Impact] - Original LP ticket : + * Fix hw accelerated performance impact on s390x with non-default + openssl1.0. + + [Test Case] + + * Test that performance of hw accelerated crypto is improved / i.e. ssl + speed test + + * Test that openssh still works, just in case. + + [Regression Potential] + + * This only changes accelerated codepath on s390x, for specific algos when CPACF is enabled on the system cpu, which is usually on. + * Same fix is already in use by 1.1.0 default openssl package, and well excercised on bionic and up. + + [Other Info] + + * original bug report. + + + This is a fix for this feature's backport to openssl 1.0.2 ( 1.1.0 and upstream code are not affected ). + + Original LP ticket : https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1743750 ** Also affects: openssl1.0 (Ubuntu) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: openssl1.0 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: openssl1.0 (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: openssl (Ubuntu) Status: New => Incomplete ** Changed in: openssl (Ubuntu) Status: Incomplete => Fix Released ** Changed in: openssl (Ubuntu Xenial) Status: New => Invalid ** Changed in: openssl (Ubuntu Bionic) Status: New => Fix Released ** Also affects: openssl (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: openssl1.0 (Ubuntu Cosmic) Importance: Undecided Status: New ** Changed in: openssl (Ubuntu Cosmic) Status: New => Fix Released ** Changed in: openssl1.0 (Ubuntu) Status: New => Confirmed ** Changed in: openssl1.0 (Ubuntu Xenial) Status: New => Invalid ** Changed in: openssl1.0 (Ubuntu Bionic) Status: New => Confirmed ** Changed in: openssl1.0 (Ubuntu Cosmic) Status: New => Confirmed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1775018 Title: Fix for openssl 1.0.2 backport Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: Fix Released Status in openssl1.0 package in Ubuntu: Confirmed Status in openssl source package in Xenial: Invalid Status in openssl1.0 source package in Xenial: Invalid Status in openssl source package in Bionic: Fix Released Status in openssl1.0 source package in Bionic: Confirmed Status in openssl source package in Cosmic: Fix Released Status in openssl1.0 source package in Cosmic: Confirmed Bug description: [Impact] * Fix hw accelerated performance impact on s390x with non-default openssl1.0. [Test Case] * Test that performance of hw accelerated crypto is improved / i.e. ssl speed test * Test that openssh still works, just in case. [Regression Potential] * This only changes accelerated codepath on s390x, for specific algos when CPACF is enabled on the system cpu, which is usually on. * Same fix is already in use by 1.1.0 default openssl package, and well excercised on bionic and up. [Other Info] * original bug report. This is a fix for this feature's backport to openssl 1.0.2 ( 1.1.0 and upstream code are not affected ). Original LP ticket : https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1743750 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1775018/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
No, it would have been impossible for any desktop image (even pending) to contain the new systemd on the 31st of January. The first image that contains the new systemd is from 20190204 or later. ** Changed in: systemd (Ubuntu Disco) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1755863 Title: netbooting the bionic live CD over NFS goes straight to maintenance mode : Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: Fix Released Bug description: [Impact] Mounting manually a network share (NFS) and masking it breaks the state of other units (and their dependencies). Casper is masking a mounted NFS share, blocking the normal boot process as described in the original description, but the issue comes from systemd. [Test Case] - NFS mount point at /media root@iscsi-bionic:/home/ubuntu# mount | grep media 10.230.56.72:/tmp/mnt on /media type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72) - Test mount point (/test) defined in /etc/fstab: root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test tmpfs /test tmpfs nosuid,nodev 0 0 1. If media.mount is not masked, everything works fine: root@iscsi-bionic:/home/ubuntu# mount | grep test root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days ago root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago root@iscsi-bionic:/home/ubuntu# systemctl start test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test 2. If media.mount is masked, other mounts are failing: root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount Created symlink /etc/systemd/system/media.mount → /dev/null. root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) [Regression potential] Minimal. Originally, one failing mount point blocked the processing of the rest due to how the return codes were handled for every line in /proc/self/mountinfo. This patch removes this "dependency" and keeps the failure local to the affected mount point, allowing the rest to be processed normally. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10874 Fixed upstream with commit: https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3 [Original Description] netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=9
[Group.of.nepali.translators] [Bug 1804487] Re: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled
** Changed in: systemd (Ubuntu Disco) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1804487 Title: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Status in systemd package in Debian: Fix Released Bug description: [Impact] TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP returns a truncated reply for a new TCP query. For instance, - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 In the second case, no-EDNS, TCP should provide the complete answer, but it's capped at UDP's size. [Test Case] Query systemd-resolved with a domain name that resolves to multiple (lots.. 30+) A records. A client with EDNS support (dig) will receive all of them, a client without support (nslookup or dig +noedns) will have a truncated list. Using the example above: EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l [Regression potential] Minimal. This change only affects TCP requests, and the new size is already used in the code for other requests. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10816 Fixed upstream with commit: https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce [Original Description] Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1804487/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1804487] Re: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled
** Changed in: systemd (Ubuntu Disco) Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1804487 Title: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: Fix Committed Status in systemd package in Debian: Fix Released Bug description: [Impact] TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP returns a truncated reply for a new TCP query. For instance, - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 In the second case, no-EDNS, TCP should provide the complete answer, but it's capped at UDP's size. [Test Case] Query systemd-resolved with a domain name that resolves to multiple (lots.. 30+) A records. A client with EDNS support (dig) will receive all of them, a client without support (nslookup or dig +noedns) will have a truncated list. Using the example above: EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l [Regression potential] Minimal. This change only affects TCP requests, and the new size is already used in the code for other requests. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10816 Fixed upstream with commit: https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce [Original Description] Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1804487/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1806483] Re: Ubuntu 18.04.1 - OpenSSL RSA connection rate performance degradation using ibmca engine (openssl-ibmca)
** Also affects: openssl-ibmca (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: openssl-ibmca (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: openssl-ibmca (Ubuntu Disco) Importance: Undecided Assignee: Skipper Bug Screeners (skipper-screen-team) Status: New ** Also affects: openssl-ibmca (Ubuntu Cosmic) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1806483 Title: Ubuntu 18.04.1 - OpenSSL RSA connection rate performance degradation using ibmca engine (openssl-ibmca) Status in Ubuntu on IBM z Systems: Triaged Status in openssl-ibmca package in Ubuntu: New Status in openssl-ibmca source package in Xenial: New Status in openssl-ibmca source package in Bionic: New Status in openssl-ibmca source package in Cosmic: New Status in openssl-ibmca source package in Disco: New Bug description: ---Problem Description--- Recent performance evaluation has shown significant degradation in the TLS connections per second rate using the OpenSSL s_time benchmark with Ubuntu 18.04.1. While doing RSA sign/verify operations, the engine would preffer doing RSA-ME instead of RSA-CRT which is significantly better in terms of performance. Baseline for this comparison are measurements executed with another distro. Both measurements have been made on LPAR native, using the CEX6A adapter. Crypto stack on the host: OpenSSL ver: 1.1.0g IBMCA ver: 1.4.1.-0 Libica ver: 3.2.1 Problem present under following condititions: 1. IBMCA ver >= 2.0.0 2. OpenSSL version >= 1.1.0 && IBMCA ver >= 1.3.1. ---uname output--- Linux m42lp01 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:42:24 UTC 2018 s390x s390x s390x GNU/Linux Machine Type = Type/Model:3906-M04 LPAR ---Steps to Reproduce--- Server; openssl s_server -cert benchcert.pem -quiet -WWW -engine ibmca -accept 8050 Client: openssl s_time -key benchcert.pem -www /2k.html -time 90 -cipher AES256-SHA -new -bugs -connect 10.14.1.254:8050 -elapsed By scaling the number of processes, the issue becomes more and more visible. Userspace tool common name: openssl-ibmca The userspace tool has the following bit modes: 64 Userspace package: openssl-ibmca-1.4.1-0ubuntu1.s390x The attached patch is generated from the commit available here: https://github.com/opencryptoki/openssl-ibmca/commit/a0e23d4063bf897dd9136c491d2201de5fbba653 Generated with: git format-patch -1 a0e23d4063bf897dd9136c491d2201de5fbba653 To be applied with: patch /openssl-ibmca/src/ibmca_rsa.c ~/0001-Fix-doing-rsa-me-altough-rsa-crt-would-be-possible.patch Fix applies smoothly and shows expected performance improvement as visible on the chart. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1806483/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1798424] Re: Xenial Azure: Make generation of network config from IMDS hotplug scripts configurable opt-in
this should have had ubuntu task added. Has this been verified yet? ** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu Xenial) Status: New => Fix Committed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1798424 Title: Xenial Azure: Make generation of network config from IMDS hotplug scripts configurable opt-in Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: New Status in cloud-init source package in Xenial: Fix Committed Bug description: cloud-init v. 18.4-0ubuntu1~16.04.1 in -proposed automatically renders network configuration from Azure's IMDS by default instead of fallback config of dhcp on eth0. This represents a difference in behavior from current Xenial. On Xenial Azure, Ubuntu cloud images have udev scripts to handle network hotplug. Azure datasource has the ability to read full network config from their IMDS service and render hotplugged devices as well as remove the cloud-image default scripts. Make the cloud-init hotplug behavior configurable and default it to off in Xenial. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1798424/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1794308] Re: VM devices rdr, pun and prt are not activated after restart
** Also affects: s390-tools (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: s390-tools (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1794308 Title: VM devices rdr, pun and prt are not activated after restart Status in s390-tools: Unknown Status in Ubuntu on IBM z Systems: Fix Released Status in s390-tools package in Ubuntu: Fix Released Status in s390-tools source package in Xenial: New Status in s390-tools source package in Bionic: New Bug description: [Impact] * Cannot configure race-free generic-ccw devices to be onlined on boot. [Test Case] # on a z/VM $ sudo chzdev -d 0.0.000c 0.0.000d 0.0.000e $ sudo chzdev -e 0.0.000c 0.0.000d 0.0.000e $ sudo update-initramfs -u $ sudo reboot $ lszdev Expectations is for generic-ccw c-d-e devices to be "yes yes" meaning online and persistent online. Previously after a reboot they would be "no yes" meaning offline yet persistent configured online. [Regression Potential] * generic-ccw rules need to be `upgraded` / `regenerated` which is not done in maintainer scripts in this upload for now. [Other Info] * fix contributed upstream at https://github.com/ibm-s390-tools/s390-tools/pull/45/files * original bug report Linux s390x as VM guest can use the VM-specific reader (0.0.000c), puncher (0.0.000d) and printer devices (0.0.000e). They can be enabled as usual with chzdev like: lszdev | grep '000c\|000d\|000e' generic-ccw 0.0.000cno no generic-ccw 0.0.000dno no generic-ccw 0.0.000eno no sudo chzdev -e 000c 000d 000e Generic CCW device 0.0.000c configured Generic CCW device 0.0.000d configured Generic CCW device 0.0.000e configured lszdev | grep '000c\|000d\|000e' generic-ccw 0.0.000cyes yes vmrdr-0.0.000c generic-ccw 0.0.000dyes yes vmpun-0.0.000d generic-ccw 0.0.000eyes yes vmprt-0.0.000e Aa a result of that activation udev rules are generated: ls -la /etc/udev/rules.d/41-generic-ccw-0.0.000{c,d,e}.rules -rw-r--r-- 1 root root 238 Sep 21 06:24 41-generic-ccw-0.0.000c.rules -rw-r--r-- 1 root root 238 Sep 21 06:24 41-generic-ccw-0.0.000d.rules -rw-r--r-- 1 root root 238 Sep 25 10:15 41-generic-ccw-0.0.000e.rules cat /etc/udev/rules.d/41-generic-ccw-0.0.000{c,d,e}.rules # Generated by chzdev ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.000c", GOTO="cfg_generic_ccw_0.0.0 00c" GOTO="end_generic_ccw_0.0.000c" LABEL="cfg_generic_ccw_0.0.000c" ATTR{[ccw/0.0.000c]online}="1" LABEL="end_generic_ccw_0.0.000c" # Generated by chzdev ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.000d", GOTO="cfg_generic_ccw_0.0.0 00d" GOTO="end_generic_ccw_0.0.000d" LABEL="cfg_generic_ccw_0.0.000d" ATTR{[ccw/0.0.000d]online}="1" LABEL="end_generic_ccw_0.0.000d" # Generated by chzdev ACTION=="add", SUBSYSTEM=="ccw", KERNEL=="0.0.000e", GOTO="cfg_generic_ccw_0.0.0 00e" GOTO="end_generic_ccw_0.0.000e" LABEL="cfg_generic_ccw_0.0.000e" ATTR{[ccw/0.0.000e]online}="1" LABEL="end_generic_ccw_0.0.000e" Once this is done it's expected that this configuration is persistent and that these three devices are automatically activated after a reboot, which is not the case: lszdev | grep '000c\|000d\|000e' generic-ccw 0.0.000cno yes generic-ccw 0.0.000dno yes generic-ccw 0.0.000eno yes A 'sudo udevadm trigger' doesn't help to activate them again. Another 'sudo chzdev -e 000c 000d 000e' helps, but again for the current session only. [ The cio_ignore list is empty, hence this can't be the reason: cio_ignore -l Ignored devices: = $ ] To manage notifications about this bug go to: https://bugs.launchpad.net/s390-tools/+bug/1794308/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 651035] Re: excessive debug messages from "os-prober"
Bionic and later are fix released. Xenial & Trusty are still affected, as far as I believe based on debian bug report fixed versions metadata. ** Also affects: os-prober (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: os-prober (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: os-prober (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/651035 Title: excessive debug messages from "os-prober" Status in os-prober: Fix Released Status in os-prober package in Ubuntu: Fix Released Status in os-prober source package in Trusty: New Status in os-prober source package in Xenial: New Bug description: Binary package hint: grub2 grub2 invokes os-prober, but it seems debuggign is activated by default; from my log: Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running /usr/lib/os-probes/mounted/10freedos on mounted /dev/cciss/c0d0p2 Sep 29 10:13:08 proxy-cvk-1 10freedos: debug: /dev/cciss/c0d0p2 is not a FAT partition: exiting Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running /usr/lib/os-probes/mounted/10qnx on mounted /dev/cciss/c0d0p2 Sep 29 10:13:08 proxy-cvk-1 10qnx: debug: /dev/cciss/c0d0p2 is not a QNX4 partition: exiting Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running /usr/lib/os-probes/mounted/20macosx on mounted /dev/cciss/c0d0p2 Sep 29 10:13:08 proxy-cvk-1 macosx-prober: debug: /dev/cciss/c0d0p2 is not an HFS+ partition: exiting Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running /usr/lib/os-probes/mounted/20microsoft on mounted /dev/cciss/c0d0p2 Sep 29 10:13:08 proxy-cvk-1 20microsoft: debug: /dev/cciss/c0d0p2 is not a MS partition: exiting Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running /usr/lib/os-probes/mounted/30utility on mounted /dev/cciss/c0d0p2 Sep 29 10:13:08 proxy-cvk-1 30utility: debug: /dev/cciss/c0d0p2 is not a FAT partition: exiting Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running /usr/lib/os-probes/mounted/40lsb on mounted /dev/cciss/c0d0p2 Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running /usr/lib/os-probes/mounted/70hurd on mounted /dev/cciss/c0d0p2 Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running /usr/lib/os-probes/mounted/80minix on mounted /dev/cciss/c0d0p2 Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running /usr/lib/os-probes/mounted/90linux-distro on mounted /dev/cciss/c0d0p2 Sep 29 10:13:08 proxy-cvk-1 os-prober: debug: running /usr/lib/os-probes/mounted/90solaris on mounted /dev/cciss/c0d0p2 ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: grub-pc 1.98+20100804-5ubuntu2 ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4 Uname: Linux 2.6.35-22-generic i686 Architecture: i386 Date: Wed Sep 29 13:13:56 2010 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: grub2 To manage notifications about this bug go to: https://bugs.launchpad.net/os-prober/+bug/651035/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1738153] Re: need backport the new scancode of dell-wmi for Microphone mute hotkey to xenial
** Changed in: systemd (Ubuntu Artful) Status: Confirmed => Won't Fix ** Changed in: systemd (Ubuntu Xenial) Status: Confirmed => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1738153 Title: need backport the new scancode of dell-wmi for Microphone mute hotkey to xenial Status in OEM Priority Project: Confirmed Status in OEM Priority Project xenial series: Confirmed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Artful: Won't Fix Bug description: [Impact] dell-wmi expend the scan code of Microphone mute hotkey from 0x150 to 0x100150, so need to add a new mapping for it. related commit: https://github.com/systemd/systemd/pull/5012 [Test Case] 1. install the udev package which applied patch. 2. check if Microphone mute hotkey works. 3. if it not works, please provide the log of evtest. [Regression Potential] low regression potential, because it just add one more mapping. also affect: LP: #1736352 LP: #1740080 LP: #1734609 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1738153/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1727237] Re: systemd-resolved is not finding a domain
** Changed in: systemd (Ubuntu Artful) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1727237 Title: systemd-resolved is not finding a domain Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Triaged Status in systemd source package in Zesty: Won't Fix Status in systemd source package in Artful: Won't Fix Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * Certain WiFi captive portals do not support EDNS0 queries, as per RFC. * Instead of responding with the captive portal IP address, they resond with domain not found * This prevents the user from hitting the captive portal login page, able to authenticate, and gain access to the internets. [The Fix] * As per tcp dumps, the problem arrises from receiving NXDOMAIN when queried with EDNS0 * And receiving the right response without EDNS0 * The solution was to downgrade transactions, and retry EDNS0 + NXDOMAIN result without EDNS0 with a hope of getting the right answer. [Test Case] * systemd-resolve securelogin.example.com * journalctl -b -u systemd-resolve | grep DVE-2018 You should obverse that a warning message that transaction was retried with a reduced feature level e.g. UDP or TCP. After this test case is performed the result will be cached, therefore to revert to pristine state perform * systemd-resolve --flush-caches [Regression Potential] * The code retries, and then caches, NXDOMAIN results for certain queries (those that have 'secure' in them) with and without EDNS0. * Thus initial query for these domains may take longer, but hopefully will manage to receive the correct response. * Manufacturers are encouraged to correctly support EDNS0 queries, with flag D0 set to zero. [Other Info] * This issue is tracked as a dns-violation at https://github.com/dns-violations/dns-violations/blob/master/2018/DVE-2018-0001.md [Original Bug report] I have an odd network situation that I have so far managed to narrow down to the inability to resolve a domain via systemd-resolved which is resolvable with nslookup. If I use nslookup against the two nameservers on this network I get answers for the domain, but ping says it is unable to resolve the same domain (as do browsers and crucially the captive portal mechanism). Here are details: NSLOOKUP: ~$ nslookup securelogin.arubanetworks.com 208.67.220.220 Server: 208.67.220.220 Address: 208.67.220.220#53 Non-authoritative answer: Name: securelogin.arubanetworks.com Address: 172.22.240.242 ~$ nslookup securelogin.arubanetworks.com 208.67.222.222 Server: 208.67.222.222 Address: 208.67.222.222#53 Non-authoritative answer: Name: securelogin.arubanetworks.com Address: 172.22.240.242 PING: ~$ ping securelogin.arubanetworks.com ping: securelogin.arubanetworks.com: Name or service not known mark@mark-X1Y2:~$ DIG: ~$ dig @208.67.222.222 securelogin.arubanetworks.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @208.67.222.222 securelogin.arubanetworks.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9416 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;securelogin.arubanetworks.com. IN A ;; AUTHORITY SECTION: arubanetworks.com.1991IN SOA dns5.arubanetworks.com. hostmaster.arubanetworks.com. 1323935888 3600 200 1209600 86400 ;; Query time: 34 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Wed Oct 25 10:31:10 CEST 2017 ;; MSG SIZE rcvd: 144 MORE DIG: ~$ dig securelogin.arubanetworks.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> securelogin.arubanetworks.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3924 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;securelogin.arubanetworks.com. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Wed Oct 25 10:34:01 CEST 2017 ;; MSG SIZE rcvd: 58 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727237/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1773148] Re: /lib/systemd/systemd-journald:6:fsync:fsync_directory_of_file:journal_file_rotate:do_rotate:server_rotate
** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Bug watch added: github.com/systemd/systemd/issues #9079 https://github.com/systemd/systemd/issues/9079 ** Also affects: systemd via https://github.com/systemd/systemd/issues/9079 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1773148 Title: /lib/systemd/systemd- journald:6:fsync:fsync_directory_of_file:journal_file_rotate:do_rotate:server_rotate Status in systemd: Unknown Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Bionic: New Status in systemd source package in Cosmic: New Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding systemd. This problem was most recently seen with package version 237-3ubuntu10, the problem page at https://errors.ubuntu.com/problem/ff29f7ff39be0e227f0187ad72e5d458e95f6fcf contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1773148/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1795658] Re: xenial systemd reports 'inactive' instead of 'failed' for service units that repeatedly failed to restart / failed permanently
Note to self, everything after xenial has this patch already. ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Xenial) Status: New => Triaged ** Changed in: systemd (Ubuntu Xenial) Assignee: (unassigned) => Dimitri John Ledkov (xnox) ** Changed in: systemd (Ubuntu Xenial) Importance: Undecided => Medium -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1795658 Title: xenial systemd reports 'inactive' instead of 'failed' for service units that repeatedly failed to restart / failed permanently Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: Triaged Bug description: [Impact] * In case a service unit has repeatedly failed to restart, it should be reported as 'failed' permanently, but currently it's instead reported as 'inactive'. * System monitoring tools that evaluate the status of systemd service units and act upon it (for example: restart service, report permanent failure) are currently misled by information in 'systemctl status .service'. * System management tools based on such information may take wrong and/or sub-optimal actions in the managed systems regarding such service units. * This systemd patch [1] directly addresses this issue (see systemd github PR #3166 [2]), and its code is still effectice in upstream systemd today, without further fixes/changes (the only changes were in doc text and the busname files that were removed, but still without further fixes to this). [Test Case] * This is copied from systemd PR #3166 [2]. * This has been tested by a customer as well, and with its system monitoring and management solution, for interoperability verification. $ cat <https://github.com/systemd/systemd/commit/072993504e3e4206ae1019f5461a0372f7d82ddf [2] https://github.com/systemd/systemd/issues/3166 [3] https://launchpad.net/~mfo/+archive/ubuntu/sf199312 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795658/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH
Using this bug to fix systemd exported environment to the generators. ** Changed in: systemd (Ubuntu Cosmic) Status: Won't Fix => Fix Committed ** Changed in: systemd (Ubuntu Bionic) Status: Won't Fix => Confirmed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1771858 Title: /snap/bin not in default PATH for units, snapd should ship system- environment-generators to inject /snap/bin into $PATH Status in snapd package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in snapd source package in Xenial: Confirmed Status in systemd source package in Xenial: Confirmed Status in snapd source package in Bionic: Confirmed Status in systemd source package in Bionic: Confirmed Status in snapd source package in Cosmic: Confirmed Status in systemd source package in Cosmic: Fix Committed Bug description: This means that software installed via snap isn't transparently available for units to use. As snaps are first-class citizens in Ubuntu, we should update the PATH. Specifically, this is evident by e.g. $ systemd-run env. Or any other daemons that spawn shell scripts (e.g. cloud-init metadata acquired shell hooks, etc.). Since v232 systemd provides support for environment generators, snapd should package/ship a snippet that injects the correct snapd path into systemd environment. E.g.: $ sudo mkdir -p /usr/lib/systemd/system-environment-generators $ printf '#!/bin/sh\nPATH=$PATH:/snap/bin\n' | \ sudo tee /usr/lib/systemd/system-environment-generators/90-snapd Something similar can be done for user-environment-generators too. Note that user-environment-generators can generate unique variables per user. Note please use /usr/lib path, as it appears that /lib/systemd path is not working atm. Will check if that needs to be fixed up. systemd in xenial does not support system-environment-generators, thus we probably need to upload a patch to change the DEFAULT_PATH compiled in default there. [Testcase] $ systemd-run /usr/bin/env $ journalctl -e | grep PATH Output should contain /snap/bin To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1771858/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1662813] Re: Libjna-jni uses wrong path on package installation on s390x
Is this on Cosmic? Bionic? or Xenial? I see that system.so is used everywhere by default, on things that do intentionally use system jna. However, on xenial, there is one patch missing to ignore the override properties. Jenkins as shipped in the 3rd party repo does not use system deb:libjna- java and does not need it installed at all. ** Also affects: libjna-java (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1662813 Title: Libjna-jni uses wrong path on package installation on s390x Status in Ubuntu on IBM z Systems: Invalid Status in libjna-java package in Ubuntu: Invalid Status in libjna-java source package in Xenial: New Bug description: libjna-jni uses the wrong path for linking the library /usr/lib/s390x-linux-gnu/libjnidispatch.so on the z Systems s390x architecture, therefore applications relying on this library are unable to link to it, even if the package is installed. Creating the link manually fixes this problem. It should be linked from /usr/lib/s390x-linux- gnu/jni/libjnidispatch.system.so /sbin/ldconfig.real: Can't link /usr/lib/s390x-linux-gnu//build /libjna-java-D1S9TX/libjna-java-4.2.2/build/native-linux- s390x/libjnidispatch.system.so to libjnidispatch.so dpkg -S /usr/lib/s390x-linux-gnu/jni/libjnidispatch.system.so libjna-jni: /usr/lib/s390x-linux-gnu/jni/libjnidispatch.system.so To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1662813/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1561643] Re: initramfs-tools ignores the FRAMEBUFFER option
** Also affects: initramfs-tools (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1561643 Title: initramfs-tools ignores the FRAMEBUFFER option Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Xenial: New Status in initramfs-tools source package in Bionic: New Bug description: initramfs-tools ignores the FRAMEBUFFER option. This means that the framebuffer hook will always include the drm modules, regardless of whether it is dealing with an encrypted system or not. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: initramfs-tools 0.122ubuntu6 ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6 Uname: Linux 4.4.0-15-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 24 18:06:24 2016 InstallationDate: Installed on 2016-02-16 (37 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160209) PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1561643/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1670291] Re: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot
** Also affects: landscape-client (Ubuntu Cosmic) Importance: High Assignee: Dave Jones (waveform) Status: Fix Committed ** Also affects: systemd (Ubuntu Cosmic) Importance: High Assignee: Dimitri John Ledkov (xnox) Status: Confirmed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1670291 Title: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot Status in landscape-client package in Ubuntu: Fix Committed Status in systemd package in Ubuntu: Confirmed Status in landscape-client source package in Xenial: Confirmed Status in systemd source package in Xenial: Confirmed Status in landscape-client source package in Bionic: New Status in systemd source package in Bionic: Confirmed Status in landscape-client source package in Cosmic: Fix Committed Status in systemd source package in Cosmic: Confirmed Bug description: https://github.com/systemd/systemd/pull/10061 [Impact] * When logind is not available, shutdown command fails to schedule a shutdown, and despite its intentions to immediately shutdown, does not do so. [Test Case] sudo systemctl mask systemd-logind.service sudo systemctl stop systemd-logind.service shutdown +1 The expectation is that system goes to shutdown. It is buggy if the system remains up - i.e. command returns to shell with exit code 1. [Regression Potential] * It is a corner case to run against systemd-shim logind / or logind not otherwise available. The function still performs a clean-shutdown, and should not cause loss of work. [Other Info] * Original bug report, running against systemd-shim/systemd-service post trusty->xenial upgrade, pre-reboot. Used Landscape (Paid Canonical Subscription) to upgrade one of my machines. Landscape only shows "In Progress" for more than 8 hours now and asked for a reboot of the machine in a second alert. In the reboot attempt I get the message: = Failed to set wall message, ignoring: Method "SetWallMessage" with signature "sb" on interface "org.freedesktop.login1.Manager" doesn't exist Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Method "ScheduleShutdown" with signature "st" on interface "org.freedesktop.login1.Manager" doesn't exist = Steps to reproduce: * Fully updated 14.04.5 machine * Open Landscape * Choose the machine * Choose Packages * This computer can be upgraded to a newer release * Apply * Wait 2 hours * Alert comes in a seperate Landscape message Machine is ready for reboot * Choose Info... Power * Deliver to selected computers as soon as possible * Error message I found this thread on reddit about this issue maybe the solution can be built into the upgrade script https://www.reddit.com/r/linuxquestions/comments/4wy3go/trying_to_run_as_user_instance_but_the_system_has/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1670291/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1670291] Re: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot
** Also affects: landscape-client (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Xenial) Status: Incomplete => Confirmed ** Changed in: systemd (Ubuntu Xenial) Milestone: ubuntu-16.04.3 => xenial-updates ** Changed in: systemd (Ubuntu Bionic) Status: New => Confirmed ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => High -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1670291 Title: Landscape: Upgrade 14.04.5 to 16.04.2 fails unable to reboot Status in landscape-client package in Ubuntu: Fix Committed Status in systemd package in Ubuntu: Confirmed Status in landscape-client source package in Xenial: Confirmed Status in systemd source package in Xenial: Confirmed Status in landscape-client source package in Bionic: New Status in systemd source package in Bionic: Confirmed Bug description: Used Landscape (Paid Canonical Subscription) to upgrade one of my machines. Landscape only shows "In Progress" for more than 8 hours now and asked for a reboot of the machine in a second alert. In the reboot attempt I get the message: = Failed to set wall message, ignoring: Method "SetWallMessage" with signature "sb" on interface "org.freedesktop.login1.Manager" doesn't exist Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Method "ScheduleShutdown" with signature "st" on interface "org.freedesktop.login1.Manager" doesn't exist = Steps to reproduce: * Fully updated 14.04.5 machine * Open Landscape * Choose the machine * Choose Packages * This computer can be upgraded to a newer release * Apply * Wait 2 hours * Alert comes in a seperate Landscape message Machine is ready for reboot * Choose Info... Power * Deliver to selected computers as soon as possible * Error message I found this thread on reddit about this issue maybe the solution can be built into the upgrade script https://www.reddit.com/r/linuxquestions/comments/4wy3go/trying_to_run_as_user_instance_but_the_system_has/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1670291/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1781242] Re: as segfault with invalid -march= option
In unapproved queue, waiting review and approval. ** Description changed: The GNU assembler segfaults with an invalid -march= option - - Contact Information = n/a - + + Contact Information = n/a + ---uname output--- n/a - - Machine Type = n/a - + + Machine Type = n/a + ---Debugger--- A debugger is not configured - + ---Steps to Reproduce--- - $ as -march=foo + $ as -march=foo Segmentation fault - - Userspace tool common name: as - - The userspace tool has the following bit modes: 64 + + Expected result: + # as -march=foo + Assembler messages: + Error: invalid switch -march=foo + Error: unrecognized option -march=foo + + Userspace tool common name: as + + The userspace tool has the following bit modes: 64 Userspace rpm: binutils-2.26.1-1ubuntu1~16.04.6 - Userspace tool obtained from project website: na - + Userspace tool obtained from project website: na + *Additional Instructions for n/a: -Attach ltrace and strace of userspace application. - - The problem is not critical since usually 'as' is invoked through the gcc driver which itself errors out for wrong -march= options. It will only be a problem if somebody builds a more recent GCC from source and uses an -march= option for a machine not supported by the default binutils. + The problem is not critical since usually 'as' is invoked through the + gcc driver which itself errors out for wrong -march= options. It will + only be a problem if somebody builds a more recent GCC from source and + uses an -march= option for a machine not supported by the default + binutils. Please consider integrating the attached patch into 16.04 binutils. The problem has been fixed in later binutils already. Ubuntu 18.04 does not appear to be affected. --> Package has to set corectly by Canonical ** Changed in: binutils (Ubuntu) Status: New => Fix Released ** Changed in: binutils (Ubuntu Xenial) Status: New => In Progress ** Changed in: binutils (Ubuntu Xenial) Milestone: None => xenial-updates -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1781242 Title: as segfault with invalid -march= option Status in Ubuntu on IBM z Systems: Triaged Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Xenial: In Progress Bug description: The GNU assembler segfaults with an invalid -march= option Contact Information = n/a ---uname output--- n/a Machine Type = n/a ---Debugger--- A debugger is not configured ---Steps to Reproduce--- $ as -march=foo Segmentation fault Expected result: # as -march=foo Assembler messages: Error: invalid switch -march=foo Error: unrecognized option -march=foo Userspace tool common name: as The userspace tool has the following bit modes: 64 Userspace rpm: binutils-2.26.1-1ubuntu1~16.04.6 Userspace tool obtained from project website: na *Additional Instructions for n/a: -Attach ltrace and strace of userspace application. The problem is not critical since usually 'as' is invoked through the gcc driver which itself errors out for wrong -march= options. It will only be a problem if somebody builds a more recent GCC from source and uses an -march= option for a machine not supported by the default binutils. Please consider integrating the attached patch into 16.04 binutils. The problem has been fixed in later binutils already. Ubuntu 18.04 does not appear to be affected. --> Package has to set corectly by Canonical To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1781242/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1783252] Re: gcc on ppc64le has bogus r30 register handling, as exposed by greenlet 0.4.14 will not build on ppc64le
@sil2100 In practice we care about the default compiler only. In bionic it is gcc-7 and is fixed. Unfortunately, we do still have gcc-5 around as non default. The fix for this was cherrypicked into cosmic already - https://launchpad.net/ubuntu/+source/gcc-5/5.5.0-12ubuntu6 I will open a task to fix this in bionic as well, although gcc-5 should not be used on bionic! (or specifically not in the openstack CI with 16.04/bionic as base os) ** Also affects: python-greenlet (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gcc-5 (Ubuntu Bionic) Importance: Undecided Status: New ** No longer affects: python-greenlet (Ubuntu Bionic) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1783252 Title: gcc on ppc64le has bogus r30 register handling, as exposed by greenlet 0.4.14 will not build on ppc64le Status in The Ubuntu-power-systems project: Fix Committed Status in gcc-5 package in Ubuntu: Fix Released Status in python-greenlet package in Ubuntu: Fix Released Status in gcc-5 source package in Xenial: Fix Committed Status in gcc-5 source package in Bionic: New Bug description: [Impact] * GCC has a minor bug w.r.t. clobber r30 register in PIC binaries. * A patch to fix this has been upstream in 6+ * But it is not in gcc-5.4 as used on xenial * This prevents compiling future-proof and correct greenlet code, on Ubuntu 16.04 LTS as used by current and supported Openstack Queens release on ppc64el * Whilst backported greenlet is available via the cloud archive for binary usage, the toolchain is still technically incorrect, and thus hinders using Ubuntu 16.04 LTS as workers in upstream Openstack CI * As a wishlist it would be nice to backport this one small gcc patch as an SRU [Test Case] * git clone https://github.com/python-greenlet/greenlet * cd greenlet * ./setup.py build Expect success Current result failure: creating build/temp.linux-ppc64le-2.7 powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c greenlet.c -o build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts In file included from slp_platformselect.h:16:0, from greenlet.c:343: platform/switch_ppc64_linux.h: In function 'slp_switch': platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' in 'asm' __asm__ volatile ("" : : : REGS_TO_SAVE); ^ platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' in 'asm' __asm__ volatile ("" : : : REGS_TO_SAVE); ^ error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1 [Regression Potential] * Upstream cherrypick present in later releases including bionic https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361 [Other Info] * Original bug report == Comment: #0 - William M. Edmonds - 2018-07-23 16:21:41 == ---Problem Description--- greenlet 0.4.14 will not build on ppc64le Opened https://github.com/python-greenlet/greenlet/issues/136 because attempting to build bdist_wheel for greenlet 0.4.14 on ppc64le Ubuntu 16.04 LTS yields the following error: running build running build_ext building 'greenlet' extension creating build creating build/temp.linux-ppc64le-2.7 powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c greenlet.c -o build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts In file included from slp_platformselect.h:16:0, from greenlet.c:343: platform/switch_ppc64_linux.h: In function 'slp_switch': platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' in 'asm' __asm__ volatile ("" : : : REGS_TO_SAVE); ^ platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' in 'asm' __asm__ volatile ("" : : : REGS_TO_SAVE); ^ error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1``` But the greenlet community is saying this is a gcc bug and it would not be safe to revert the greenlet change that exposed this issue. I have no idea whether that is true or not. Supposedly this should be fixed by https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361 but that fix is not present in the latest version of gcc (5.4.0) available for Ubuntu 16.04 LTS. ---uname output--- unavailable due to lab outage Machine Type =
[Group.of.nepali.translators] [Bug 1781535] Re: qdio: don't retry EQBS after CCQ 96
$ git tag --contains dae55b6 Ubuntu-4.17.0-6.7 Ubuntu-4.17.0-6.7 And released. ** Changed in: linux (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1781535 Title: qdio: don't retry EQBS after CCQ 96 Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Bug description: Description: qdio: don't retry EQBS after CCQ 96 Symptom: Queue stalls, over-/underreporting of buffer errors. Problem: Immediate retry of EQBS after CCQ 96 means that we potentially misreport the state of buffers inspected during the first EQBS call. Solution: On CCQ 96, first process the discovered state. Afterwards, higher-level code will eventually trigger an EQBS/inspection of the remaining buffers. Their state is now processed independently from the state that was discovered during the first EQBS. Upstream-ID: dae55b6fef58530c13df074bcc182c096609339e To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1781535/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1781242] Re: as segfault with invalid -march= option
** Also affects: binutils (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1781242 Title: as segfault with invalid -march= option Status in Ubuntu on IBM z Systems: Triaged Status in binutils package in Ubuntu: New Status in binutils source package in Xenial: New Bug description: The GNU assembler segfaults with an invalid -march= option Contact Information = n/a ---uname output--- n/a Machine Type = n/a ---Debugger--- A debugger is not configured ---Steps to Reproduce--- $ as -march=foo Segmentation fault Userspace tool common name: as The userspace tool has the following bit modes: 64 Userspace rpm: binutils-2.26.1-1ubuntu1~16.04.6 Userspace tool obtained from project website: na *Additional Instructions for n/a: -Attach ltrace and strace of userspace application. The problem is not critical since usually 'as' is invoked through the gcc driver which itself errors out for wrong -march= options. It will only be a problem if somebody builds a more recent GCC from source and uses an -march= option for a machine not supported by the default binutils. Please consider integrating the attached patch into 16.04 binutils. The problem has been fixed in later binutils already. Ubuntu 18.04 does not appear to be affected. --> Package has to set corectly by Canonical To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1781242/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1783252] Re: greenlet 0.4.14 will not build on ppc64le
I think I get it all now. https://github.com/python- greenlet/greenlet/commit/9c8a65fddcffe161f38679a0b3289de9b25e2bc6.patch -> unbreaks with new gcc-7, but broken again with old gcc-5 again And hence you are stuck between a rock and a hard-place either hack- up a Frankenstein toolchain or somehow revert future-proof correct upstream code, for sake of older buggy gcc. I wonder if greenlet could somehow detect buggy compiler and still build with it... 😂 ** Also affects: python-greenlet (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: gcc-5 (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: gcc-5 (Ubuntu Xenial) Status: New => Triaged ** Changed in: gcc-5 (Ubuntu Xenial) Importance: Undecided => High ** Changed in: gcc-5 (Ubuntu Xenial) Importance: High => Wishlist ** Changed in: gcc-5 (Ubuntu) Status: Incomplete => Won't Fix ** No longer affects: python-greenlet (Ubuntu Xenial) ** Description changed: + [Impact] + + * GCC has a minor bug w.r.t. clobber r30 register in PIC binaries. + * A patch to fix this has been upstream in 6+ + * But it is not in gcc-5.4 as used on xenial + * This prevents compiling future-proof and correct greenlet code, on Ubuntu 16.04 LTS as used by current and supported Openstack Queens release on ppc64el + * Whilst backported greenlet is available via the cloud archive for binary usage, the toolchain is still technically incorrect, and thus hinders using Ubuntu 16.04 LTS as workers in upstream Openstack CI + * As a wishlist it would be nice to backport this one small gcc patch as an SRU + + [Test Case] + + * git clone https://github.com/python-greenlet/greenlet + * cd greenlet + * ./setup.py build + Expect success + + Current result failure: + + creating build/temp.linux-ppc64le-2.7 + powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c greenlet.c -o build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts + In file included from slp_platformselect.h:16:0, + from greenlet.c:343: + platform/switch_ppc64_linux.h: In function 'slp_switch': + platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' in 'asm' + __asm__ volatile ("" : : : REGS_TO_SAVE); + ^ + platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' in 'asm' + __asm__ volatile ("" : : : REGS_TO_SAVE); + ^ + error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1 + + + [Regression Potential] + + * Upstream cherrypick present in later releases including bionic + https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9213244550335bcb2b8590a0d7d58ac74c932361 + + + [Other Info] + + * Original bug report + + == Comment: #0 - William M. Edmonds - 2018-07-23 16:21:41 == ---Problem Description--- greenlet 0.4.14 will not build on ppc64le Opened https://github.com/python-greenlet/greenlet/issues/136 because attempting to build bdist_wheel for greenlet 0.4.14 on ppc64le Ubuntu 16.04 LTS yields the following error: running build running build_ext building 'greenlet' extension creating build creating build/temp.linux-ppc64le-2.7 powerpc64le-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c greenlet.c -o build/temp.linux-ppc64le-2.7/greenlet.o -fno-tree-dominator-opts In file included from slp_platformselect.h:16:0, - from greenlet.c:343: -platform/switch_ppc64_linux.h: In function 'slp_switch': -platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' in 'asm' - __asm__ volatile ("" : : : REGS_TO_SAVE); - ^ -platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' in 'asm' - __asm__ volatile ("" : : : REGS_TO_SAVE); - ^ -error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1``` + from greenlet.c:343: + platform/switch_ppc64_linux.h: In function 'slp_switch': + platform/switch_ppc64_linux.h:80:5: error: PIC register clobbered by 'r30' in 'asm' + __asm__ volatile ("" : : : REGS_TO_SAVE); + ^ + platform/switch_ppc64_linux.h:95:5: error: PIC register clobbered by 'r30' in 'asm' + __asm__ volatile ("" : : : REGS_TO_SAVE); + ^ + error: command 'powerpc64le-linux-gnu-gcc' failed with exit status 1``` - But the greenlet community is saying this is a gcc bug and it would not be safe to revert the greenlet change that exposed this issue. I have no idea whether that is true or not. Supposedly this should be fixed by https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;
[Group.of.nepali.translators] [Bug 1765364] Re: Backport spectre/meltdown fixes on qemu for ppc64 into 16.04 and possibly 14.04 LTS releases
marking qemu package tasks to affect xenial series only then. ** Also affects: qemu (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: qemu (Ubuntu) Status: New => Fix Released ** Changed in: qemu (Ubuntu Xenial) Importance: Undecided => Critical ** Changed in: qemu (Ubuntu) Assignee: Marc Deslauriers (mdeslaur) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1765364 Title: Backport spectre/meltdown fixes on qemu for ppc64 into 16.04 and possibly 14.04 LTS releases Status in The Ubuntu-power-systems project: Incomplete Status in The Ubuntu-power-systems project ubuntu-16.04 series: New Status in qemu package in Ubuntu: Fix Released Status in qemu source package in Xenial: New Bug description: == Comment: #0 - Satheesh Rajendran - 2018-04-19 04:26:51 == ---Problem Description--- Backport spectre/meltdown fixes on qemu for ppc64 into all LTS releases Contact Information = sathe...@in.ibm.com ---uname output--- - Machine Type = power8,power9 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- For pseries guests there are 3 tri-state -machine options/capabilities relating to Spectre/Meltdown mitigation: cap-cfpc, cap-sbbc, cap-ibs, which each correspond to a set of host machine capabilities advertised by the KVM kernel module in new/patched host kernels that can be used to mitigate various aspects of Spectre/Meltdown: cap-cfpc: Cache Flush on Privilege Change cap-sbbc: Speculation Barrier Bounds Checking cap-ibs: Indirect Branch Serialisation Details can be found here https://www.qemu.org/2018/02/14/qemu-2-11-1 -and-spectre-update/ Needed qemu commits: cb931c2108 target/ppc: Check mask when setting cap_ppc_safe_indirect_branch 4f5b039d2b ppc/spapr-caps: Disallow setting workaround for spapr-cap-ibs 8c5909c419 ppc/spapr-caps: Change migration macro to take full spapr-cap name c59704b254 target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS 4be8d4e7d9 target/ppc/spapr_caps: Add new tristate cap safe_indirect_branch 09114fd817 target/ppc/spapr_caps: Add new tristate cap safe_bounds_check 8f38eaf8f9 target/ppc/spapr_caps: Add new tristate cap safe_cache 6898aed77f target/ppc/spapr_caps: Add support for tristate spapr_capabilities 8acc2ae5e9 target/ppc/kvm: Add cap_ppc_safe_[cache/bounds_check/indirect_branch] Optional commits to introduce a machine type variant pseries--sxxm, when used would set/enable the three machine capabilities explained above automatically, if host is capable(host kernel is supported). Bug 166426 813f3cf655 ppc/spapr-caps: Define the pseries-2.12-sxxm machine type c76c0d3090 ppc/spapr-caps: Convert cap-ibs to custom spapr-cap aaf265ffde ppc/spapr-caps: Convert cap-sbbc to custom spapr-cap f27aa81e72 ppc/spapr-caps: Convert cap-cfpc to custom spapr-cap 87175d1bc5 ppc/spapr-caps: Add support for custom spapr_capabilities Userspace tool common name: qemu-kvm The userspace tool has the following bit modes: both Userspace rpm: qemu-kvm Userspace tool obtained from project website: na *Additional Instructions for sathe...@in.ibm.com: -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1765364/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1784454] Re: kernel panic on booting kernel 4.4 based d-i from 16.04.5 RC image
** Changed in: linux (Ubuntu) Status: Triaged => Invalid ** No longer affects: ubuntu-z-systems -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1784454 Title: kernel panic on booting kernel 4.4 based d-i from 16.04.5 RC image Status in debian-installer package in Ubuntu: New Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: Fix Committed Bug description: Booting d-i based on kernel 4.4 (from ./boot folder) from the 16.04.5 RC image on a z/VM guest leads to a kernel panic: /lib/debian-installer/start-udev: line 15: can't create /sys/module/scsi_mod/par ameters/scan: Permission denied ¬0.845071| Kernel panic - not syncing: Attempted to kill initÜ exitcode=0x00 000100 ¬0.845071| ¬0.845075| CPU: 0 PID: 1 Comm: /init Not tainted 4.4.0-131-generic #157-Ubun tu ¬0.845077|7d107c20 7d107cb0 0002 000 0 7d107d50 7d107cc8 7d107cc8 00114732 008b 009a304c 009f11d0 000b 7d107d10 7d107cb0 040001cdf800 00114732 7d107cb0 7d107d10 ¬0.845089| Call Trace: ¬0.845093| (¬<0011461a>| show_trace+0xfa/0x150) ¬0.845095| ¬<001146e2>| show_stack+0x72/0xf8 ¬0.845099| ¬<00555752>| dump_stack+0x82/0xb8 ¬0.845101| ¬<00286390>| panic+0x108/0x250 ¬0.845104| ¬<00166228>| do_exit+0xac0/0xba0 ¬0.845106| ¬<001663c8>| do_group_exit+0x50/0xe0 ¬0.845108| ¬<00166488>| __wake_up_parent+0x0/0x28 ¬0.845111| ¬<007eadda>| system_call+0xee/0x28c ¬0.845113| ¬<03ff8953983a>| 0x3ff8953983a 00: HCPGIR450W CP entered; disabled wait PSW 00020001 8000 0010F8CA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1784454/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1777600] Re: chzdev can't find modprobe
** No longer affects: s390-tools (Ubuntu Artful) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1777600 Title: chzdev can't find modprobe Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: Invalid Status in s390-tools package in Ubuntu: Fix Released Status in s390-tools source package in Xenial: New Status in s390-tools source package in Bionic: New Status in s390-tools source package in Cosmic: Fix Released Bug description: Description: only when trying to change some attributes chzdev fails because it cant find modprobe under Ubuntu 18.04 root@m83lp09:~# chzdev zfcp --type datarouter=0 dbflevel=5 sh: 1: /usr/sbin/modprobe: not found zfcp device type configure failed Error: Command failed (exit code 127): /usr/sbin/modprobe -r zfcp root@m83lp09:~# whereis modprobe modprobe: /sbin/modprobe /etc/modprobe.d /lib/modprobe.d /usr/share/man/man8/modprobe.8.gz Potential solution ? : adding a symlink is a workaround, is this path hardcoded? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1777600/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1780227] Re: locking sockets broken due to missing AppArmor socket mediation patches
** Changed in: linux (Ubuntu) Importance: High => Critical ** Also affects: apparmor (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1780227 Title: locking sockets broken due to missing AppArmor socket mediation patches Status in apparmor package in Ubuntu: New Status in linux package in Ubuntu: Triaged Status in apparmor source package in Xenial: New Status in linux source package in Xenial: Triaged Status in apparmor source package in Bionic: New Status in linux source package in Bionic: Triaged Bug description: Hey, Newer systemd makes use of locks placed on AF_UNIX sockets created with the socketpair() syscall to synchronize various bits and pieces when isolating services. On kernels prior to 4.18 that do not have backported the AppArmor socket mediation patchset this will cause the locks to be denied with EACCESS. This causes systemd to be broken in LXC and LXD containers that do not run unconfined which is a pretty big deal. We have seen various bug reports related to this. See for example [1] and [2]. If feasible it would be excellent if we could backport the socket mediation patchset to all LTS kernels. Afaict, this should be 4.4 and 4.15. This will unbreak a whole range of use-cases. The socket mediation patchset is available here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4 [1]: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779 [2]: https://github.com/systemd/systemd/issues/9493 Thanks! Christian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1780227/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1716999] Re: installer creates rather small /boot partition
** No longer affects: partman-auto (Ubuntu Xenial) ** Also affects: partman-auto (Ubuntu Xenial) Importance: Undecided Status: New ** No longer affects: partman-auto (Ubuntu Bionic) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1716999 Title: installer creates rather small /boot partition Status in partman-auto package in Ubuntu: Fix Released Status in partman-auto source package in Xenial: New Bug description: The installer (in 16.04 and 17.10) creates a separate /boot partition, when required, of only 487M. This ends up being rather small when you using the following equation to estimate a minimal size allowing for reasonable room for further growth. (2*(3*kernel + 4*plymouth-carrying initrd + bootloader)) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1716999/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1716999] Re: installer creates rather small /boot partition
** Also affects: partman-auto (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: partman-auto (Ubuntu Bionic) Milestone: None => ubuntu-18.04.1 -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1716999 Title: installer creates rather small /boot partition Status in partman-auto package in Ubuntu: Fix Released Status in partman-auto source package in Xenial: New Status in partman-auto source package in Bionic: New Bug description: The installer (in 16.04 and 17.10) creates a separate /boot partition, when required, of only 487M. This ends up being rather small when you using the following equation to estimate a minimal size allowing for reasonable room for further growth. (2*(3*kernel + 4*plymouth-carrying initrd + bootloader)) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1716999/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1775641] Re: [Comm] IBM JDK 8.0.5.16 integration into Ubuntu
** No longer affects: ubuntu-z-systems ** Package changed: ibm-java80 (Ubuntu) => ibm-java71 (Ubuntu) ** No longer affects: ibm-java71 (Ubuntu) ** No longer affects: ibm-java80 (Ubuntu) ** No longer affects: ibm-java71 (Ubuntu Xenial) ** No longer affects: ibm-java80 (Ubuntu Xenial) ** No longer affects: ibm-java71 (Ubuntu Bionic) ** No longer affects: ibm-java80 (Ubuntu Bionic) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1775641 Title: [Comm] IBM JDK 8.0.5.16 integration into Ubuntu Status in Ubuntu on IBM z Systems: New Bug description: foreman@cit7r02:~/sandbox/binary$ ftp archive.admin.canonical.com Connected to archive.admin.canonical.com. 220 youngberry.canonical.com FTP server (Poppy Upload Server) ready. Name (archive.admin.canonical.com:foreman): anonymous 331 Password required Password: 230 Login Successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> bin 200 Type set to Binary. ftp> prompt off Interactive mode off. ftp> put 80sr5fp16_20180524_01_ocdc.tar.gz local: 80sr5fp16_20180524_01_ocdc.tar.gz remote: 80sr5fp16_20180524_01_ocdc.tar.gz 200 PORT command successful. 150 Opening Binary connection for /80sr5fp16_20180524_01_ocdc.tar.gz 226 Transfer successful. 651496332 bytes sent in 377.03 secs (1687.5 kB/s) ftp> quit 221 Goodbye. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1775641/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1775641] Re: [Comm] IBM JDK 8.0.5.16 integration into Ubuntu
** Package changed: ibm-java71 (Ubuntu) => ibm-java80 (Ubuntu) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1775641 Title: [Comm] IBM JDK 8.0.5.16 integration into Ubuntu Status in Ubuntu on IBM z Systems: New Status in ibm-java80 source package in Bionic: New Bug description: foreman@cit7r02:~/sandbox/binary$ ftp archive.admin.canonical.com Connected to archive.admin.canonical.com. 220 youngberry.canonical.com FTP server (Poppy Upload Server) ready. Name (archive.admin.canonical.com:foreman): anonymous 331 Password required Password: 230 Login Successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> bin 200 Type set to Binary. ftp> prompt off Interactive mode off. ftp> put 80sr5fp16_20180524_01_ocdc.tar.gz local: 80sr5fp16_20180524_01_ocdc.tar.gz remote: 80sr5fp16_20180524_01_ocdc.tar.gz 200 PORT command successful. 150 Opening Binary connection for /80sr5fp16_20180524_01_ocdc.tar.gz 226 Transfer successful. 651496332 bytes sent in 377.03 secs (1687.5 kB/s) ftp> quit 221 Goodbye. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1775641/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1663280] Re: Serious performance degradation of math functions
zesty is EOL. artful+ are fix released. xenial is the only currently affected supported series. ** Also affects: glibc (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: glibc (Ubuntu Zesty) Status: Triaged => Won't Fix ** Changed in: glibc (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1663280 Title: Serious performance degradation of math functions Status in GLibC: Fix Released Status in glibc package in Ubuntu: Fix Released Status in glibc source package in Xenial: New Status in glibc source package in Zesty: Won't Fix Status in glibc package in Fedora: Fix Released Bug description: Bug [0] has been introduced in Glibc 2.23 [1] and fixed in Glibc 2.25 [2]. All Ubuntu versions starting from 16.04 are affected because they use either Glibc 2.23 or 2.24. Bug introduces serious (2x-4x) performance degradation of math functions (pow, exp/exp2/exp10, log/log2/log10, sin/cos/sincos/tan, asin/acos/atan/atan2, sinh/cosh/tanh, asinh/acosh/atanh) provided by libm. Bug can be reproduced on any AVX-capable x86-64 machine. @strikov: According to a quite reliable source [5] all AMD CPUs and latest Intel CPUs (Skylake and Knights Landing) don't suffer from AVX/SSE transition penalty. It means that the scope of this bug becomes smaller and includes only the following generations of Intel's CPUs: Sandy Bridge, Ivy Bridge, Haswell, and Broadwell. Scope still remains quite large though. @strikov: Ubuntu 16.10/17.04 which use Glibc 2.24 may recieve the fix from upstream 2.24 branch (as Marcel pointed out, fix has been backported to 2.24 branch where Fedora took it successfully) if such synchronization will take place. Ubuntu 16.04 (the main target of this bug) uses Glibc 2.23 which hasn't been patched upstream and will suffer from performance degradation until we fix it manually. This bug is all about AVX-SSE transition penalty [3]. 256-bit YMM registers used by AVX-256 instructions extend 128-bit registers used by SSE (XMM0 is a low half of YMM0 and so on). Every time CPU executes SSE instruction after AVX-256 instruction it has to store upper half of the YMM register to the internal buffer and then restore it when execution returns back to AVX instructions. Store/restore is required because old-fashioned SSE knows nothing about the upper halves of its registers and may damage them. This store/restore operation is time consuming (several tens of clock cycles for each operation). To deal with this issue, Intel introduced AVX-128 instructions which operate on the same 128-bit XMM register as SSE but take into account upper halves of YMM registers. Hence, no store/restore required. Practically speaking, AVX-128 instructions is a new smart form of SSE instructions which can be used together with full-size AVX-256 instructions without any penalty. Intel recommends to use AVX-128 instructions instead of SSE instructions wherever possible. To sum things up, it's okay to mix SSE with AVX-128 and AVX-128 with AVX-256. Mixing AVX-128 with AVX-256 is allowed because both types of instructions are aware of 256-bit YMM registers. Mixing SSE with AVX-128 is okay because CPU can guarantee that the upper halves of YMM registers don't contain any meaningful data (how one can put it there without using AVX-256 instructions) and avoid doing store/restore operation (why to care about random trash in the upper halves of the YMM registers). It's not okay to mix SSE with AVX-256 due to the transition penalty. Scalar floating-point instructions used by routines mentioned above are implemented as a subset of SSE and AVX-128 instructions. They operate on a small fraction of 128-bit register but still considered SSE/AVX-128 instruction. And they suffer from SSE/AVX transition penalty as well. Glibc inadvertently triggers a chain of AVX/SSE transition penalties due to inappropriate use of AVX-256 instructions inside _dl_runtime_resolve() procedure. By using AVX-256 instructions to push/pop YMM registers [4], Glibc makes CPU think that the upper halves of XMM registers contain meaningful data which needs to be preserved during execution of SSE instructions. With such a 'dirty' flag set every switch between SSE and AVX instructions (AVX-128 or AVX-256) leads to a time consuming store/restore procedure. This 'dirty' flag never gets cleared during the whole program execution which leads to a serious overall slowdown. Fixed implementation [2] of _dl_runtime_resolve() procedure tries to avoid using AVX-256 instructions if possible. Buggy _dl_runtime_resolve() gets called every time when dynamic linker tries to resolve a symbol (any symbol, not just ones mentioned above). It's eno
[Group.of.nepali.translators] [Bug 1748147] Re: [SRU] debhelper support override from /etc/tmpfiles.d for systemd
Proposed fix in systemd. Run systemd-tmpfiles, during postinst, the way it would be run on boot, such that all base files are correct, including any overrides shipped by any other package; systemd; in transient runtime dir. At the same time, the dh_installinit is silenced to not produce the systemd-tmpfiles snippet which this package does not need. This solves the issue of integration with rsyslog; generically; without requiring to backport debhelper, nor change rsyslog package. ** Changed in: rsyslog (Ubuntu) Status: Confirmed => Invalid ** Changed in: rsyslog (Ubuntu Xenial) Status: Confirmed => Invalid ** Changed in: rsyslog (Ubuntu Artful) Status: Confirmed => Invalid ** Changed in: rsyslog (Ubuntu Bionic) Status: Confirmed => Invalid ** Changed in: systemd (Ubuntu) Status: Confirmed => Fix Committed ** Patch added: "lp1748147.diff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1748147/+attachment/5155096/+files/lp1748147.diff ** Changed in: debhelper (Ubuntu Bionic) Status: In Progress => Won't Fix ** Changed in: debhelper (Ubuntu Bionic) Assignee: Seyeong Kim (xtrusia) => (unassigned) ** Changed in: debhelper (Ubuntu Artful) Status: In Progress => Won't Fix ** Changed in: debhelper (Ubuntu Artful) Assignee: Seyeong Kim (xtrusia) => (unassigned) ** Changed in: debhelper (Ubuntu Xenial) Status: In Progress => Won't Fix ** Changed in: debhelper (Ubuntu Xenial) Assignee: Seyeong Kim (xtrusia) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1748147 Title: [SRU] debhelper support override from /etc/tmpfiles.d for systemd Status in debhelper: Fix Released Status in debhelper package in Ubuntu: Fix Released Status in rsyslog package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Committed Status in debhelper source package in Xenial: Won't Fix Status in rsyslog source package in Xenial: Invalid Status in systemd source package in Xenial: Confirmed Status in debhelper source package in Artful: Won't Fix Status in rsyslog source package in Artful: Invalid Status in systemd source package in Artful: Confirmed Status in debhelper source package in Bionic: Won't Fix Status in rsyslog source package in Bionic: Invalid Status in systemd source package in Bionic: Confirmed Bug description: [Impact] /var/log's Permission is going back to 755 after upgrading systemd if there are rsyslog's configuration on /var/lib/tmpfiles.d/ Affected X, A, B, C This is because rsyslog's pkg has 00rsyslog.conf and copied it on /var/lib/tmpfiles.d/ when it is installing. after upgrading systemd, systemd only refresh it's own tmpfiles so disappear conf for 00rsyslog.conf ( it doesn't remove file itself ) so, systemd-tmpfiles --create /var/lib/tmpfiles.d/00rsyslog.conf back permission to 775 [Test Case] 1. deploy 16.04 vm 2. check ll /var (775) 3. apt install --reinstall systemd 4. check ll /var (755) [Regression Potential] This fix changes debhelper's override process by using absolute path to filename. so if the other pkgs using debhelper e.g systemd are there, It should be re-build with new debhelper after patching in theory, now only systemd is affected. but building is not affected. also, pkg like rsyslog which is using systemd's tmpfile system need to be changed to use /etc/tmpfiles.d/[SAME_FILENAME_IN_VAR_LIB_TMPFILES.D_FOR_OVERRIDING] instead of 00rsyslog.conf. [Others] For this issue, need to fix below pkgs debhelper systemd ( rebuilding with new debhelper is needed ) rsyslog ( 00rsyslog.conf to var.conf and location should be /etc/tmpfiles.d, to support override supported by debhelper ) [Original description] Upgrading or reinstalling the systemd package when using rsyslogd results in bad permissions (0755 instead of 0775) being set on /var/log/. As a consequence of this, rsyslogd can no longer create new files within this directory, resulting in lost log messages. The default configuration of rsyslogd provided by Ubuntu runs the daemon as syslog:syslog and sets ownership of /var/log to syslog:adm with mode 0775. Systemd's default tmpfiles configuration sets /var/log to 0755 in /usr/lib/tmpfiles.d/var.conf, however this is overridden in /usr/lib/tmpfiles.d/00rsyslog.conf which is provided by package rsyslog. It looks as though an upgrade of the systemd package fails to take /usr/lib/tmpfiles.d/00rsyslog.conf into account, as demonstrated below. This results in /var/log receiving mode 0755 instead of the expected 0775: nick @ log2.be1.ams1:~ $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.3 LTS Release: 16.04 Codename: xenial nick @ log2.be1.ams1:~
[Group.of.nepali.translators] [Bug 1777600] Re: chzdev can't find modprobe
https://github.com/ibm-s390-tools/s390-tools/pull/31 ** Also affects: s390-tools (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: s390-tools (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Cosmic) Importance: High Assignee: Joseph Salisbury (jsalisbury) Status: Triaged ** Also affects: s390-tools (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Artful) Importance: Undecided Status: New ** No longer affects: linux (Ubuntu Cosmic) ** No longer affects: linux (Ubuntu Bionic) ** No longer affects: linux (Ubuntu Artful) ** No longer affects: linux (Ubuntu Xenial) ** Changed in: linux (Ubuntu) Status: Triaged => Invalid ** Changed in: ubuntu-z-systems Assignee: Canonical Kernel Team (canonical-kernel-team) => Dimitri John Ledkov 🌈 (xnox) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1777600 Title: chzdev can't find modprobe Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: Invalid Status in s390-tools package in Ubuntu: New Status in s390-tools source package in Xenial: New Status in s390-tools source package in Artful: New Status in s390-tools source package in Bionic: New Status in s390-tools source package in Cosmic: New Bug description: Description: only when trying to change some attributes chzdev fails because it cant find modprobe under Ubuntu 18.04 root@m83lp09:~# chzdev zfcp --type datarouter=0 dbflevel=5 sh: 1: /usr/sbin/modprobe: not found zfcp device type configure failed Error: Command failed (exit code 127): /usr/sbin/modprobe -r zfcp root@m83lp09:~# whereis modprobe modprobe: /sbin/modprobe /etc/modprobe.d /lib/modprobe.d /usr/share/man/man8/modprobe.8.gz Potential solution ? : adding a symlink is a workaround, is this path hardcoded? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1777600/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1748147] Re: [SRU] debhelper support override from /etc/tmpfiles.d for systemd
There are multiple bugs here. I do not believe testcase of the rsyslog <-> systemd is wrong, and whilst debhelper support is good, is not what would fix rsyslog <-> systemd in Ubuntu. ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Dimitri John Ledkov (xnox) ** Changed in: systemd (Ubuntu) Status: New => Confirmed ** Also affects: rsyslog (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1748147 Title: [SRU] debhelper support override from /etc/tmpfiles.d for systemd Status in debhelper: Fix Released Status in debhelper package in Ubuntu: Fix Released Status in rsyslog package in Ubuntu: New Status in systemd package in Ubuntu: Confirmed Status in debhelper source package in Xenial: In Progress Status in rsyslog source package in Xenial: New Status in systemd source package in Xenial: New Status in debhelper source package in Artful: In Progress Status in rsyslog source package in Artful: New Status in systemd source package in Artful: New Status in debhelper source package in Bionic: In Progress Status in rsyslog source package in Bionic: New Status in systemd source package in Bionic: New Bug description: [Impact] /var/log's Permission is going back to 755 after upgrading systemd if there are rsyslog's configuration on /var/lib/tmpfiles.d/ Affected X, A, B, C This is because rsyslog's pkg has 00rsyslog.conf and copied it on /var/lib/tmpfiles.d/ when it is installing. after upgrading systemd, systemd only refresh it's own tmpfiles so disappear conf for 00rsyslog.conf ( it doesn't remove file itself ) so, systemd-tmpfiles --create /var/lib/tmpfiles.d/00rsyslog.conf back permission to 775 [Test Case] 1. deploy 16.04 vm 2. check ll /var (775) 3. apt install --reinstall systemd 4. check ll /var (755) [Regression Potential] This fix changes debhelper's override process by using absolute path to filename. so if the other pkgs using debhelper e.g systemd are there, It should be re-build with new debhelper after patching in theory, now only systemd is affected. but building is not affected. also, pkg like rsyslog which is using systemd's tmpfile system need to be changed to use /etc/tmpfiles.d/[SAME_FILENAME_IN_VAR_LIB_TMPFILES.D_FOR_OVERRIDING] instead of 00rsyslog.conf. [Others] For this issue, need to fix below pkgs debhelper systemd ( rebuilding with new debhelper is needed ) rsyslog ( 00rsyslog.conf to var.conf and location should be /etc/tmpfiles.d, to support override supported by debhelper ) [Original description] Upgrading or reinstalling the systemd package when using rsyslogd results in bad permissions (0755 instead of 0775) being set on /var/log/. As a consequence of this, rsyslogd can no longer create new files within this directory, resulting in lost log messages. The default configuration of rsyslogd provided by Ubuntu runs the daemon as syslog:syslog and sets ownership of /var/log to syslog:adm with mode 0775. Systemd's default tmpfiles configuration sets /var/log to 0755 in /usr/lib/tmpfiles.d/var.conf, however this is overridden in /usr/lib/tmpfiles.d/00rsyslog.conf which is provided by package rsyslog. It looks as though an upgrade of the systemd package fails to take /usr/lib/tmpfiles.d/00rsyslog.conf into account, as demonstrated below. This results in /var/log receiving mode 0755 instead of the expected 0775: nick @ log2.be1.ams1:~ $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.3 LTS Release: 16.04 Codename: xenial nick @ log2.be1.ams1:~ $ apt policy systemd systemd: Installed: 229-4ubuntu21.1 Candidate: 229-4ubuntu21.1 Version table: *** 229-4ubuntu21.1 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 229-4ubuntu4 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages nick @ log2.be1.ams1:~ $ apt policy rsyslog rsyslog: Installed: 8.16.0-1ubuntu3 Candidate: 8.16.0-1ubuntu3 Version table: *** 8.16.0-1ubuntu3 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status nick @ log2.be1.ams1:~ $ grep -F /var/log /usr/lib/tmpfiles.d/var.conf d /var/log 0755 - - - f /var/log/wtmp 0664 root utmp - f /var/log/btmp 0600 root utmp - nick @ log2.be1.ams1:~ $ cat /usr/lib/tmpfiles.d/00rsyslog.conf # Override systemd's default tmpfiles.d/var.
[Group.of.nepali.translators] [Bug 1726930] Re: System fails to start (boot) on battery due to read-only root file-system
Removing systemd, as I believe there is nothing to be changed in systemd for this fix to land. Are the affected users fixed with the proposed kernel? Please test proposed kernel asap! Otherwise the change will be dropped from the kernel again on xenial =( ** No longer affects: systemd (Ubuntu) ** No longer affects: systemd (Ubuntu Xenial) ** No longer affects: systemd (Ubuntu Bionic) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1726930 Title: System fails to start (boot) on battery due to read-only root file- system Status in laptop-mode-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Fix Released Status in laptop-mode-tools source package in Xenial: Confirmed Status in linux source package in Xenial: Fix Committed Status in laptop-mode-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Fix Released Bug description: This report is to capture the extended diagnostic efforts done on IRC #ubuntu for user maszlo, who has a Lenovo T450 with SSD that was upgraded from 17.04 to 17.10 and since fails to complete start-up of services when powered on battery. We'd previously applied the "acpi=os=! 'acpi_osi=Windows 2015'" workaround in case this was an ACPI DSDT issue. This appears to be due to a read-only root file-system. What is not clear is how the rootfs goes read-only. The file-system (sda6, ext4) is fsck-ed successfully in the initrd according to the /run/initramfs/fsck.log. From the start-up logs (with "systemd.log_level=debug") we see the ext4 driver report a remount operation not once but five times. $ grep 'EXT4-fs.*sda6' systemd-debug.log Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro Oct 23 18:10:46 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:47 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:49 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Those last five appear to be carrying options generated by laptop- mode-tools. User has disabled laptop-mode.service and laptop-mode.timer, and lmt- poll.service, but the issue remains. We see several reports of "read-only file-system": $ grep 'Read-only' systemd-debug.log Oct 23 18:10:46 T450s grub-common[1792]: grub-editenv: error: cannot open `/boot/grub/grubenv': Read-only file system. Oct 23 18:10:46 T450s systemd[1]: colord.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gpu-manager[1797]: Warning: writing to /var/log/gpu-manager.log failed (Read-only file system) Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gdm3[1932]: Failed to create LogDir /var/log/gdm3: Read-only file system ... Oct 23 18:11:26 T450s cupsd[1461]: Unable to change ownership of "/var/log/cups" - Read-only file system Oct 23 18:11:26 T450s cupsd[1461]: Unable to open log file "/var/log/cups/access_log" - Read-only file system Oct 23 18:12:52 T450s login[9248]: pam_lastlog(login:session): unable to open /var/log/lastlog: Read-only file system We also see several problems with systemd's connection to Dbus: $ grep 'Transport endpoint' systemd-debug.log Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for 773: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: systemd-logind.service: Failed to send unit change signal for systemd-logind.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 156: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: lmt-poll.service: Failed to send unit change signal for lmt-poll.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 182: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 95: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: polkit.service: Failed to send unit change signal for polkit.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: cups-browsed.service: Failed to send unit change signal for c