[Touch-packages] [Bug 1978079] Re: EFI pstore not cleared on boot
** Description changed: + [Impact] + Systemd has a systemd-pstore component that scans the pstore on boot and if non-empty, takes all previously created dumps, transfers them into its journal and removes the pstore elements. This is very important on UEFI systems, which only have a limited amount of space for variables. In Ubuntu, the kernel is configured with CONFIG_EFI_VARS_PSTORE=m which means the EFI pstore support gets loaded dynamically. In all of my boots, this dynamic module loading happened *after* systemd tried to check for pstore variables. So systemd-pstore never starts and never clears the UEFI variable store. I see this happening in AWS on Graviton instances, which eventually run out of space to store the dumps. On real hardware, this behavior may lead to unbootable systems. ``` $ systemctl status systemd-pstore ○ systemd-pstore.service - Platform Persistent Storage Archival - Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; vendor preset: enabled) - Active: inactive (dead) - Condition: start condition failed at Thu 2022-06-09 09:11:41 UTC; 29min ago - └─ ConditionDirectoryNotEmpty=/sys/fs/pstore was not met -Docs: man:systemd-pstore(8) + Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; vendor preset: enabled) + Active: inactive (dead) + Condition: start condition failed at Thu 2022-06-09 09:11:41 UTC; 29min ago + └─ ConditionDirectoryNotEmpty=/sys/fs/pstore was not met + Docs: man:systemd-pstore(8) Jun 09 09:11:41 ip-172-31-0-61 systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. $ ls -la /sys/fs/pstore total 0 drwxr-x--- 2 root root0 Jun 9 09:11 . drwxr-xr-x 8 root root0 Jun 9 09:11 .. -r--r--r-- 1 root root 1803 Jun 9 09:07 dmesg-efi-165476562001001 -r--r--r-- 1 root root 1777 Jun 9 09:07 dmesg-efi-165476562002001 -r--r--r-- 1 root root 1773 Jun 9 09:07 dmesg-efi-165476562003001 -r--r--r-- 1 root root 1815 Jun 9 09:07 dmesg-efi-165476562004001 -r--r--r-- 1 root root 1826 Jun 9 09:07 dmesg-efi-165476562005001 -r--r--r-- 1 root root 1754 Jun 9 09:07 dmesg-efi-165476562006001 -r--r--r-- 1 root root 1821 Jun 9 09:07 dmesg-efi-165476562007001 -r--r--r-- 1 root root 1767 Jun 9 09:07 dmesg-efi-165476562008001 -r--r--r-- 1 root root 1729 Jun 9 09:07 dmesg-efi-165476562009001 -r--r--r-- 1 root root 1819 Jun 9 09:07 dmesg-efi-165476562010001 -r--r--r-- 1 root root 1767 Jun 9 09:07 dmesg-efi-165476562011001 -r--r--r-- 1 root root 1775 Jun 9 09:07 dmesg-efi-165476562012001 -r--r--r-- 1 root root 1802 Jun 9 09:07 dmesg-efi-165476562013001 -r--r--r-- 1 root root 1812 Jun 9 09:07 dmesg-efi-165476562014001 -r--r--r-- 1 root root 1764 Jun 9 09:07 dmesg-efi-165476562015001 -r--r--r-- 1 root root 1795 Jun 9 09:11 dmesg-efi-165476589801001 -r--r--r-- 1 root root 1785 Jun 9 09:11 dmesg-efi-165476589802001 -r--r--r-- 1 root root 1683 Jun 9 09:11 dmesg-efi-165476589803001 -r--r--r-- 1 root root 1785 Jun 9 09:11 dmesg-efi-165476589804001 -r--r--r-- 1 root root 1771 Jun 9 09:11 dmesg-efi-165476589805001 -r--r--r-- 1 root root 1797 Jun 9 09:11 dmesg-efi-165476589806001 -r--r--r-- 1 root root 1805 Jun 9 09:11 dmesg-efi-165476589807001 -r--r--r-- 1 root root 1781 Jun 9 09:11 dmesg-efi-165476589808001 -r--r--r-- 1 root root 1806 Jun 9 09:11 dmesg-efi-165476589809001 -r--r--r-- 1 root root 1821 Jun 9 09:11 dmesg-efi-165476589810001 -r--r--r-- 1 root root 1763 Jun 9 09:11 dmesg-efi-165476589811001 -r--r--r-- 1 root root 1783 Jun 9 09:11 dmesg-efi-165476589812001 -r--r--r-- 1 root root 1788 Jun 9 09:11 dmesg-efi-165476589813001 -r--r--r-- 1 root root 1788 Jun 9 09:11 dmesg-efi-165476589814001 -r--r--r-- 1 root root 1786 Jun 9 09:11 dmesg-efi-165476589815001 ``` This problem affects (at least) Ubuntu 20.04 and 22.04. A quick fix would be to configure CONFIG_EFI_VARS_PSTORE=y so that it's always available. A long term fix would make systemd rescan the directory after all module probing settled. + + [Test Plan] + + In order to be able to reproduce this issue, the system must have EFI- + backed pstore. + + To check which kind of backend that pstore, use `cat + /sys/module/pstore/parameters/backend` + + If it says `efi`, the steps below are applicable. Otherwise, find an + environment that has EFI backed pstore. + + # Enable the pstore service. This service is supposed to move the data in /sys/fs/pstore + # to the `/var/lib/systemd/pstore` path on boot. + systemctl enable systemd-pstore.service # (or can be vendor enabled) + + # Crash the kernel + echo 1 > /proc/sys/kernel/sysrq + echo 1 > /proc/sys/kernel/panic # this is usually set to zero, causing kernel to loop over the panic and freeze + echo "c" > /proc/sysrq-trigger + + # The system will reboot itself. Check `/sys/fs/pstore` path first: + ls
[Touch-packages] [Bug 1979199] [NEW] package initramfs-tools 0.140ubuntu13 failed to install/upgrade: podproces zainstalowany pakiet initramfs-tools skrypt post-installation zwrócił kod błędu 1
Public bug reported: :) ProblemType: Package DistroRelease: Ubuntu 22.04 Package: initramfs-tools 0.140ubuntu13 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 NonfreeKernelModules: wl nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 AptOrdering: intel-microcode:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: unknown Date: Mon Jun 20 12:06:16 2022 ErrorMessage: podproces zainstalowany pakiet initramfs-tools skrypt post-installation zwrócił kod błędu 1 InstallationDate: Installed on 2020-09-18 (639 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) PackageArchitecture: all Python3Details: /usr/bin/python3.10, Python 3.10.4, python3-minimal, 3.10.4-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.21.1ubuntu2.1 apt 2.4.5 SourcePackage: initramfs-tools Title: package initramfs-tools 0.140ubuntu13 failed to install/upgrade: podproces zainstalowany pakiet initramfs-tools skrypt post-installation zwrócił kod błędu 1 UpgradeStatus: Upgraded to jammy on 2022-06-12 (8 days ago) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1979199 Title: package initramfs-tools 0.140ubuntu13 failed to install/upgrade: podproces zainstalowany pakiet initramfs-tools skrypt post- installation zwrócił kod błędu 1 Status in initramfs-tools package in Ubuntu: New Bug description: :) ProblemType: Package DistroRelease: Ubuntu 22.04 Package: initramfs-tools 0.140ubuntu13 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 NonfreeKernelModules: wl nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 AptOrdering: intel-microcode:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: unknown Date: Mon Jun 20 12:06:16 2022 ErrorMessage: podproces zainstalowany pakiet initramfs-tools skrypt post-installation zwrócił kod błędu 1 InstallationDate: Installed on 2020-09-18 (639 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) PackageArchitecture: all Python3Details: /usr/bin/python3.10, Python 3.10.4, python3-minimal, 3.10.4-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.21.1ubuntu2.1 apt 2.4.5 SourcePackage: initramfs-tools Title: package initramfs-tools 0.140ubuntu13 failed to install/upgrade: podproces zainstalowany pakiet initramfs-tools skrypt post-installation zwrócił kod błędu 1 UpgradeStatus: Upgraded to jammy on 2022-06-12 (8 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1979199/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1978079] Re: EFI pstore not cleared on boot
** Tags added: ubuntu-sponsors -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1978079 Title: EFI pstore not cleared on boot Status in systemd package in Ubuntu: In Progress Bug description: Systemd has a systemd-pstore component that scans the pstore on boot and if non-empty, takes all previously created dumps, transfers them into its journal and removes the pstore elements. This is very important on UEFI systems, which only have a limited amount of space for variables. In Ubuntu, the kernel is configured with CONFIG_EFI_VARS_PSTORE=m which means the EFI pstore support gets loaded dynamically. In all of my boots, this dynamic module loading happened *after* systemd tried to check for pstore variables. So systemd-pstore never starts and never clears the UEFI variable store. I see this happening in AWS on Graviton instances, which eventually run out of space to store the dumps. On real hardware, this behavior may lead to unbootable systems. ``` $ systemctl status systemd-pstore ○ systemd-pstore.service - Platform Persistent Storage Archival Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Thu 2022-06-09 09:11:41 UTC; 29min ago └─ ConditionDirectoryNotEmpty=/sys/fs/pstore was not met Docs: man:systemd-pstore(8) Jun 09 09:11:41 ip-172-31-0-61 systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. $ ls -la /sys/fs/pstore total 0 drwxr-x--- 2 root root0 Jun 9 09:11 . drwxr-xr-x 8 root root0 Jun 9 09:11 .. -r--r--r-- 1 root root 1803 Jun 9 09:07 dmesg-efi-165476562001001 -r--r--r-- 1 root root 1777 Jun 9 09:07 dmesg-efi-165476562002001 -r--r--r-- 1 root root 1773 Jun 9 09:07 dmesg-efi-165476562003001 -r--r--r-- 1 root root 1815 Jun 9 09:07 dmesg-efi-165476562004001 -r--r--r-- 1 root root 1826 Jun 9 09:07 dmesg-efi-165476562005001 -r--r--r-- 1 root root 1754 Jun 9 09:07 dmesg-efi-165476562006001 -r--r--r-- 1 root root 1821 Jun 9 09:07 dmesg-efi-165476562007001 -r--r--r-- 1 root root 1767 Jun 9 09:07 dmesg-efi-165476562008001 -r--r--r-- 1 root root 1729 Jun 9 09:07 dmesg-efi-165476562009001 -r--r--r-- 1 root root 1819 Jun 9 09:07 dmesg-efi-165476562010001 -r--r--r-- 1 root root 1767 Jun 9 09:07 dmesg-efi-165476562011001 -r--r--r-- 1 root root 1775 Jun 9 09:07 dmesg-efi-165476562012001 -r--r--r-- 1 root root 1802 Jun 9 09:07 dmesg-efi-165476562013001 -r--r--r-- 1 root root 1812 Jun 9 09:07 dmesg-efi-165476562014001 -r--r--r-- 1 root root 1764 Jun 9 09:07 dmesg-efi-165476562015001 -r--r--r-- 1 root root 1795 Jun 9 09:11 dmesg-efi-165476589801001 -r--r--r-- 1 root root 1785 Jun 9 09:11 dmesg-efi-165476589802001 -r--r--r-- 1 root root 1683 Jun 9 09:11 dmesg-efi-165476589803001 -r--r--r-- 1 root root 1785 Jun 9 09:11 dmesg-efi-165476589804001 -r--r--r-- 1 root root 1771 Jun 9 09:11 dmesg-efi-165476589805001 -r--r--r-- 1 root root 1797 Jun 9 09:11 dmesg-efi-165476589806001 -r--r--r-- 1 root root 1805 Jun 9 09:11 dmesg-efi-165476589807001 -r--r--r-- 1 root root 1781 Jun 9 09:11 dmesg-efi-165476589808001 -r--r--r-- 1 root root 1806 Jun 9 09:11 dmesg-efi-165476589809001 -r--r--r-- 1 root root 1821 Jun 9 09:11 dmesg-efi-165476589810001 -r--r--r-- 1 root root 1763 Jun 9 09:11 dmesg-efi-165476589811001 -r--r--r-- 1 root root 1783 Jun 9 09:11 dmesg-efi-165476589812001 -r--r--r-- 1 root root 1788 Jun 9 09:11 dmesg-efi-165476589813001 -r--r--r-- 1 root root 1788 Jun 9 09:11 dmesg-efi-165476589814001 -r--r--r-- 1 root root 1786 Jun 9 09:11 dmesg-efi-165476589815001 ``` This problem affects (at least) Ubuntu 20.04 and 22.04. A quick fix would be to configure CONFIG_EFI_VARS_PSTORE=y so that it's always available. A long term fix would make systemd rescan the directory after all module probing settled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1978079/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1958267] Re: wpa can't connect to servers using TLS 1.1 or older
** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1958267 Title: wpa can't connect to servers using TLS 1.1 or older Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Jammy: Fix Committed Status in wpa package in Debian: New Bug description: * Impact wpa built with in openssl3 fails to connect to TLS 1.1 or lower server * Test case try to connect to a TLS <= 1.1 access point * Regression potential the patch lowers the security level in some situation for compatibility, it shouldn't prevent connecting to newer hardware, still try to connect to different type of wifi with different security levels --- those uses MD5-SHA1 as digest in its signature algorithm which no longer meets OpenSSL default level of security of 80 bits http://lists.infradead.org/pipermail/hostap/2022-May/040563.html Workaround are described in #22 and #36 by basically using CipherString = DEFAULT@SECLEVEL=0 which lowers the security level --- With the current jammy version of wpasupplicant (2:2.10-1), I cannot connect to the WPA Enterprise network eduroam, which is used by Universities worldwide. I get a "Connection failed" message or a request to re-enter the password. - I've re-tried the credentials: no fix ;-) - Tried a 21.10 live session on the same machine: works fine! - Manually downgraded wpasupplicant to the impish version (2:2.9.0-21build1): connected normally. - Upgraded wpasupplicant to the latest version: fails to connect again. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: wpasupplicant 2:2.10-1 ProcVersionSignature: Ubuntu 5.15.0-17.17-generic 5.15.12 Uname: Linux 5.15.0-17-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu75 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Jan 18 09:56:23 2022 InstallationDate: Installed on 2021-11-30 (48 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20211130) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 691050] Re: Daily cron job doesn't report failures
** Patch added: "Report exit status to systemd after daily activities" https://bugs.launchpad.net/ubuntu/+source/apt/+bug/691050/+attachment/5598352/+files/apt.systemd.daily.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/691050 Title: Daily cron job doesn't report failures Status in apt package in Ubuntu: Confirmed Bug description: Binary package hint: apt Hi I'm using unattended-upgrades in a lucid vm, setup for security updates to be installed automatically. I realized recently that this stopped working for some time, but I didn't get any error whatsoever: there were available security updates when I would launch aptitude, but they would not get installed overnight anymore. To find out what was going on, I've set APT::Periodic::Verbose 2; in the apt config; I got this output in the next day's cron: /etc/cron.daily/apt: verbose level 2 sleeping for 537 seconds apt-key net-update (success) download updated metadata (error) download upgradable (not run) unattended-upgrade (not run) check_stamp: interval=0 autoclean (not run) aged: ctime <30 and mtime <30 and ctime>2 and mtime>2 end remove by archive size: size=508 < 512000 (I found it hard to force a run, there is no flag to e.g. ignore the timestamp checks and force this cron job to do what it would do nightly; you have to edit it and disable a bunch of tests, but then it's not obvious that the right thing is being changed etc.) The problem was that one of the APT repository I was tracking had gone away, it had been removed, resulting in apt-get update failing to complete: E: Some index files failed to download, they have been ignored, or old ones used instead. but this went on unnoticed for weeks. I think this cron job should report failures by: - outputting something meaningful to stderr when an error condition appears - returning with a non-zero exit status when some error condition occurs and ideally, it would be possible to run it manually during day, even if it ran overnight, perhaps a "force" flag allowing to ignore timestamp checks? Cheers, To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/691050/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 691050] Re: Daily cron job doesn't report failures
Also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972872 ** Bug watch added: Debian Bug tracker #972872 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972872 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/691050 Title: Daily cron job doesn't report failures Status in apt package in Ubuntu: Confirmed Bug description: Binary package hint: apt Hi I'm using unattended-upgrades in a lucid vm, setup for security updates to be installed automatically. I realized recently that this stopped working for some time, but I didn't get any error whatsoever: there were available security updates when I would launch aptitude, but they would not get installed overnight anymore. To find out what was going on, I've set APT::Periodic::Verbose 2; in the apt config; I got this output in the next day's cron: /etc/cron.daily/apt: verbose level 2 sleeping for 537 seconds apt-key net-update (success) download updated metadata (error) download upgradable (not run) unattended-upgrade (not run) check_stamp: interval=0 autoclean (not run) aged: ctime <30 and mtime <30 and ctime>2 and mtime>2 end remove by archive size: size=508 < 512000 (I found it hard to force a run, there is no flag to e.g. ignore the timestamp checks and force this cron job to do what it would do nightly; you have to edit it and disable a bunch of tests, but then it's not obvious that the right thing is being changed etc.) The problem was that one of the APT repository I was tracking had gone away, it had been removed, resulting in apt-get update failing to complete: E: Some index files failed to download, they have been ignored, or old ones used instead. but this went on unnoticed for weeks. I think this cron job should report failures by: - outputting something meaningful to stderr when an error condition appears - returning with a non-zero exit status when some error condition occurs and ideally, it would be possible to run it manually during day, even if it ran overnight, perhaps a "force" flag allowing to ignore timestamp checks? Cheers, To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/691050/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 691050] Re: Daily cron job doesn't report failures
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778878 relevant, though thread seems to have been hijacked. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/691050 Title: Daily cron job doesn't report failures Status in apt package in Ubuntu: Confirmed Bug description: Binary package hint: apt Hi I'm using unattended-upgrades in a lucid vm, setup for security updates to be installed automatically. I realized recently that this stopped working for some time, but I didn't get any error whatsoever: there were available security updates when I would launch aptitude, but they would not get installed overnight anymore. To find out what was going on, I've set APT::Periodic::Verbose 2; in the apt config; I got this output in the next day's cron: /etc/cron.daily/apt: verbose level 2 sleeping for 537 seconds apt-key net-update (success) download updated metadata (error) download upgradable (not run) unattended-upgrade (not run) check_stamp: interval=0 autoclean (not run) aged: ctime <30 and mtime <30 and ctime>2 and mtime>2 end remove by archive size: size=508 < 512000 (I found it hard to force a run, there is no flag to e.g. ignore the timestamp checks and force this cron job to do what it would do nightly; you have to edit it and disable a bunch of tests, but then it's not obvious that the right thing is being changed etc.) The problem was that one of the APT repository I was tracking had gone away, it had been removed, resulting in apt-get update failing to complete: E: Some index files failed to download, they have been ignored, or old ones used instead. but this went on unnoticed for weeks. I think this cron job should report failures by: - outputting something meaningful to stderr when an error condition appears - returning with a non-zero exit status when some error condition occurs and ideally, it would be possible to run it manually during day, even if it ran overnight, perhaps a "force" flag allowing to ignore timestamp checks? Cheers, To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/691050/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 691050] Re: Daily cron job doesn't report failures
Ironically, 12 years later in 22.04, /usr/lib/apt/apt.systemd.daily doesn't seem to indicate success or failure to systemd either, which means you can't use e.g. journalctl -p err as a "one stop shop" to find things that are failing on system :( ** Bug watch added: Debian Bug tracker #778878 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778878 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/691050 Title: Daily cron job doesn't report failures Status in apt package in Ubuntu: Confirmed Bug description: Binary package hint: apt Hi I'm using unattended-upgrades in a lucid vm, setup for security updates to be installed automatically. I realized recently that this stopped working for some time, but I didn't get any error whatsoever: there were available security updates when I would launch aptitude, but they would not get installed overnight anymore. To find out what was going on, I've set APT::Periodic::Verbose 2; in the apt config; I got this output in the next day's cron: /etc/cron.daily/apt: verbose level 2 sleeping for 537 seconds apt-key net-update (success) download updated metadata (error) download upgradable (not run) unattended-upgrade (not run) check_stamp: interval=0 autoclean (not run) aged: ctime <30 and mtime <30 and ctime>2 and mtime>2 end remove by archive size: size=508 < 512000 (I found it hard to force a run, there is no flag to e.g. ignore the timestamp checks and force this cron job to do what it would do nightly; you have to edit it and disable a bunch of tests, but then it's not obvious that the right thing is being changed etc.) The problem was that one of the APT repository I was tracking had gone away, it had been removed, resulting in apt-get update failing to complete: E: Some index files failed to download, they have been ignored, or old ones used instead. but this went on unnoticed for weeks. I think this cron job should report failures by: - outputting something meaningful to stderr when an error condition appears - returning with a non-zero exit status when some error condition occurs and ideally, it would be possible to run it manually during day, even if it ran overnight, perhaps a "force" flag allowing to ignore timestamp checks? Cheers, To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/691050/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1979098] Re: detached ua key and and attached back, now on extensive security maintenance until 31/12/9999
Thank you for your bug report. The information displayed there is indeed incorrect, it is using the value returned by $ ua status --format=json so reassing to this component ** Package changed: software-properties (Ubuntu) => ubuntu-advantage- tools (Ubuntu) ** Changed in: ubuntu-advantage-tools (Ubuntu) Importance: Undecided => Low ** Changed in: ubuntu-advantage-tools (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1979098 Title: detached ua key and and attached back, now on extensive security maintenance until 31/12/ Status in ubuntu-advantage-tools package in Ubuntu: Confirmed Bug description: I have detached Ubuntu Advantage key and attached again, to make livepatch work. When I realized the updates tab changed to Extensive Security Maintenance until 31/12/ (essentially until Y10K) I tried re-opening the app, didn't work. Restarted the PC, didn't work. A partial upgrade, didn't work. I have a screenshot, it has been attached. Ubuntu Release: 22.04 Version of software-properties-gtk: 0.99.22.2 What I expected to happen: Livepatch working again, on the free subscription of LTS until 2027. What happened instead: Somehow got support until 31/12/ (again, Y10K.) ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: software-properties-gtk 0.99.22.2 ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35 Uname: Linux 5.15.0-40-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Jun 17 19:03:59 2022 InstallationDate: Installed on 2022-06-14 (2 days ago) InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223) PackageArchitecture: all ProcEnviron: LANGUAGE=pt_BR:pt:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=pt_BR.UTF-8 SHELL=/bin/bash SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1979098/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1968922] Re: libnss3 is affected by CVE-2022-22747
Version 2:3.49.1-1ubuntu1.7 was released after this bug was reported and does not contain a fix for this CVE. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nss in Ubuntu. https://bugs.launchpad.net/bugs/1968922 Title: libnss3 is affected by CVE-2022-22747 Status in nss package in Ubuntu: Confirmed Bug description: libnss3 2:3.49.1-1ubuntu1.6 is affected by CVE-2022-22747. The entry for this CVE in the Ubuntu CVE tracker does not list this source package. This CVE was fixed in Debian 11 on January 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1968922/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1978079] Re: EFI pstore not cleared on boot
** Tags added: seg sts sts-sponsor -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1978079 Title: EFI pstore not cleared on boot Status in systemd package in Ubuntu: In Progress Bug description: Systemd has a systemd-pstore component that scans the pstore on boot and if non-empty, takes all previously created dumps, transfers them into its journal and removes the pstore elements. This is very important on UEFI systems, which only have a limited amount of space for variables. In Ubuntu, the kernel is configured with CONFIG_EFI_VARS_PSTORE=m which means the EFI pstore support gets loaded dynamically. In all of my boots, this dynamic module loading happened *after* systemd tried to check for pstore variables. So systemd-pstore never starts and never clears the UEFI variable store. I see this happening in AWS on Graviton instances, which eventually run out of space to store the dumps. On real hardware, this behavior may lead to unbootable systems. ``` $ systemctl status systemd-pstore ○ systemd-pstore.service - Platform Persistent Storage Archival Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Thu 2022-06-09 09:11:41 UTC; 29min ago └─ ConditionDirectoryNotEmpty=/sys/fs/pstore was not met Docs: man:systemd-pstore(8) Jun 09 09:11:41 ip-172-31-0-61 systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. $ ls -la /sys/fs/pstore total 0 drwxr-x--- 2 root root0 Jun 9 09:11 . drwxr-xr-x 8 root root0 Jun 9 09:11 .. -r--r--r-- 1 root root 1803 Jun 9 09:07 dmesg-efi-165476562001001 -r--r--r-- 1 root root 1777 Jun 9 09:07 dmesg-efi-165476562002001 -r--r--r-- 1 root root 1773 Jun 9 09:07 dmesg-efi-165476562003001 -r--r--r-- 1 root root 1815 Jun 9 09:07 dmesg-efi-165476562004001 -r--r--r-- 1 root root 1826 Jun 9 09:07 dmesg-efi-165476562005001 -r--r--r-- 1 root root 1754 Jun 9 09:07 dmesg-efi-165476562006001 -r--r--r-- 1 root root 1821 Jun 9 09:07 dmesg-efi-165476562007001 -r--r--r-- 1 root root 1767 Jun 9 09:07 dmesg-efi-165476562008001 -r--r--r-- 1 root root 1729 Jun 9 09:07 dmesg-efi-165476562009001 -r--r--r-- 1 root root 1819 Jun 9 09:07 dmesg-efi-165476562010001 -r--r--r-- 1 root root 1767 Jun 9 09:07 dmesg-efi-165476562011001 -r--r--r-- 1 root root 1775 Jun 9 09:07 dmesg-efi-165476562012001 -r--r--r-- 1 root root 1802 Jun 9 09:07 dmesg-efi-165476562013001 -r--r--r-- 1 root root 1812 Jun 9 09:07 dmesg-efi-165476562014001 -r--r--r-- 1 root root 1764 Jun 9 09:07 dmesg-efi-165476562015001 -r--r--r-- 1 root root 1795 Jun 9 09:11 dmesg-efi-165476589801001 -r--r--r-- 1 root root 1785 Jun 9 09:11 dmesg-efi-165476589802001 -r--r--r-- 1 root root 1683 Jun 9 09:11 dmesg-efi-165476589803001 -r--r--r-- 1 root root 1785 Jun 9 09:11 dmesg-efi-165476589804001 -r--r--r-- 1 root root 1771 Jun 9 09:11 dmesg-efi-165476589805001 -r--r--r-- 1 root root 1797 Jun 9 09:11 dmesg-efi-165476589806001 -r--r--r-- 1 root root 1805 Jun 9 09:11 dmesg-efi-165476589807001 -r--r--r-- 1 root root 1781 Jun 9 09:11 dmesg-efi-165476589808001 -r--r--r-- 1 root root 1806 Jun 9 09:11 dmesg-efi-165476589809001 -r--r--r-- 1 root root 1821 Jun 9 09:11 dmesg-efi-165476589810001 -r--r--r-- 1 root root 1763 Jun 9 09:11 dmesg-efi-165476589811001 -r--r--r-- 1 root root 1783 Jun 9 09:11 dmesg-efi-165476589812001 -r--r--r-- 1 root root 1788 Jun 9 09:11 dmesg-efi-165476589813001 -r--r--r-- 1 root root 1788 Jun 9 09:11 dmesg-efi-165476589814001 -r--r--r-- 1 root root 1786 Jun 9 09:11 dmesg-efi-165476589815001 ``` This problem affects (at least) Ubuntu 20.04 and 22.04. A quick fix would be to configure CONFIG_EFI_VARS_PSTORE=y so that it's always available. A long term fix would make systemd rescan the directory after all module probing settled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1978079/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 74139] Re: shutdown missing -F (force fsck) option
Hello I am interested in the -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/74139 Title: shutdown missing -F (force fsck) option Status in upstart : Won't Fix Status in upstart package in Ubuntu: Invalid Bug description: Binary package hint: upstart Hello, The -F option of the /sbin/shutdown command is useful: it allows you to force the operating system to check all partitions (fsck) at the next reboot. In Ubuntu 6.10, this option has disappeared ! The command "shutdown -rF now" reboots the system, but does not force the checking of the filesystems. Also, the -F option is no longer in the shutdown manpage. It appears the -F option was still there in Ubuntu 6.06. As an aside, since Ubuntu is supposed to be based on Debian GNU/Linux, shutdown does have the -F flag in both Debian 3.1 (sarge) and Debian 4.0 (etch). So, where did -F go ? Package information from apt: Package: upstart Section: base Installed-Size: 300 Maintainer: Scott James Remnant Architecture: i386 Version: 0.2.7-7 Replaces: sysvinit To manage notifications about this bug go to: https://bugs.launchpad.net/upstart/+bug/74139/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 74139] Re: shutdown missing -F (force fsck) option
Hello -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/74139 Title: shutdown missing -F (force fsck) option Status in upstart : Won't Fix Status in upstart package in Ubuntu: Invalid Bug description: Binary package hint: upstart Hello, The -F option of the /sbin/shutdown command is useful: it allows you to force the operating system to check all partitions (fsck) at the next reboot. In Ubuntu 6.10, this option has disappeared ! The command "shutdown -rF now" reboots the system, but does not force the checking of the filesystems. Also, the -F option is no longer in the shutdown manpage. It appears the -F option was still there in Ubuntu 6.06. As an aside, since Ubuntu is supposed to be based on Debian GNU/Linux, shutdown does have the -F flag in both Debian 3.1 (sarge) and Debian 4.0 (etch). So, where did -F go ? Package information from apt: Package: upstart Section: base Installed-Size: 300 Maintainer: Scott James Remnant Architecture: i386 Version: 0.2.7-7 Replaces: sysvinit To manage notifications about this bug go to: https://bugs.launchpad.net/upstart/+bug/74139/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1979096] Re: gnome-shell search can't launch apps if dock auto-hide is enabled
** Summary changed: - X.org or Gnome-shell + gnome-shell search can't launch apps if dock auto-hide is enabled ** Package changed: xorg (Ubuntu) => gnome-shell-extension-ubuntu-dock (Ubuntu) ** Also affects: gnome-shell (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1979096 Title: gnome-shell search can't launch apps if dock auto-hide is enabled Status in gnome-shell package in Ubuntu: New Status in gnome-shell-extension-ubuntu-dock package in Ubuntu: New Bug description: The problem happens, when I enable the dock to hide automatically. With this enabled, it is not possible to run the programs through the search. But when disabled, it is possible to search and run the programs. Here's the video of the problem. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Jun 17 18:21:45 2022 DistUpgraded: 2022-04-21 13:52:59,951 DEBUG Running PostInstallScript: '/usr/lib/ubuntu-advantage/upgrade_lts_contract.py' DistroCodename: jammy DistroVariant: ubuntu DkmsStatus: v4l2loopback/0.12.5, 5.15.0-37-generic, x86_64: installed v4l2loopback/0.12.5, 5.15.0-39-generic, x86_64: installed ExtraDebuggingInterest: I just need to know a workaround GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000] [1002:9616] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. RS780L [Radeon 3000] [1043:8388] InstallationDate: Installed on 2021-04-15 (428 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) MachineType: System manufacturer System Product Name ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-39-generic root=UUID=7e3c483e-6d02-4fc2-be0e-48207eb147eb ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to jammy on 2022-04-21 (57 days ago) dmi.bios.date: 03/04/2017 dmi.bios.release: 8.15 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1201 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: M5A78L-M LX/BR dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1201:bd03/04/2017:br8.15:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM5A78L-MLX/BR:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:skuToBeFilledByO.E.M.: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: System Product Name dmi.product.sku: To Be Filled By O.E.M. dmi.product.version: System Version dmi.sys.vendor: System manufacturer version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.1-1ubuntu2.1 version.libgl1-mesa-glx: libgl1-mesa-glx 22.0.1-1ubuntu2.1 version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build3 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1979096/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1979139] Re: apt-get update fails inside docker container
You also do not have the latest docker installed. Be aware that if the host system is older than the guest, various things can fail due to seccomp issues, the latest docker should always be used. So please check with all updates installed in the host, the official ubuntu:jammy image, and using a chroot. I'm reasonably sure that you are just missing updates to docker and runc or whatever that allowlist the syscalls used by jammy glibc. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1979139 Title: apt-get update fails inside docker container Status in apt package in Ubuntu: Incomplete Bug description: A docker image built with "debootstrap jammy" fails when running "apt- get update". 1) lsb_release -rd Description:Ubuntu 20.04 LTS Release:20.04 2) # apt-cache policy docker.io docker.io: Installed: 19.03.8-0ubuntu1.20.04.1 Candidate: 20.10.7-0ubuntu5~20.04.2 Version table: 20.10.7-0ubuntu5~20.04.2 500 500 http://mirror.localnet:8055/ubuntu-security focal-security/universe amd64 Packages *** 19.03.8-0ubuntu1.20.04.1 100 100 /var/lib/dpkg/status 19.03.8-0ubuntu1 500 500 http://mirror.localnet:8055/ubuntu focal/universe amd64 Packages # docker run --rm -ti ubuntu:jammy apt-cache policy apt apt: Installed: 2.4.5 Candidate: 2.4.5 Version table: *** 2.4.5 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status 3) I would expect, that "apt-get update" updates the package lists, as in # docker run --rm -ti ubuntu:focal apt-get update Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease Get:2 http://archive.ubuntu.com/ubuntu focal/main Translation-en [506 kB] Fetched 506 kB in 1s (464 kB/s) Reading package lists... Done 4) Instead, it fails with # docker run --rm -ti ubuntu:jammy apt-get update Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease Err:1 http://archive.ubuntu.com/ubuntu jammy InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C Reading package lists... Done W: http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg are ignored as the file is not readable by user '_apt' executing apt-key. W: http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key. W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://archive.ubuntu.com/ubuntu jammy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C W: Some index files failed to download. They have been ignored, or old ones used instead. 5) To reproduce: # mkdir jammy-jellyfish # debootstrap jammy jammy-jellyfish ... # tar -C jammy-jellyfish -c . | docker import - ubuntu:jammy # docker run --rm -ti ubuntu:jammy apt-get update Doing the same with focal, works as expected: # mkdir focal-fossa # debootstrap focal focal-fossa ... # tar -C focal-fossa -c . | docker import - ubuntu:focal # docker run --rm -ti ubuntu:focal apt-get update Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease Get:2 http://archive.ubuntu.com/ubuntu focal/main Translation-en [506 kB] Fetched 506 kB in 1s (963 kB/s) Reading package lists... Done To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1979139/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1979139] Re: apt-get update fails inside docker container
Please actually follow the error message and check that the keyring permissions are correct. ** Changed in: apt (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1979139 Title: apt-get update fails inside docker container Status in apt package in Ubuntu: Incomplete Bug description: A docker image built with "debootstrap jammy" fails when running "apt- get update". 1) lsb_release -rd Description:Ubuntu 20.04 LTS Release:20.04 2) # apt-cache policy docker.io docker.io: Installed: 19.03.8-0ubuntu1.20.04.1 Candidate: 20.10.7-0ubuntu5~20.04.2 Version table: 20.10.7-0ubuntu5~20.04.2 500 500 http://mirror.localnet:8055/ubuntu-security focal-security/universe amd64 Packages *** 19.03.8-0ubuntu1.20.04.1 100 100 /var/lib/dpkg/status 19.03.8-0ubuntu1 500 500 http://mirror.localnet:8055/ubuntu focal/universe amd64 Packages # docker run --rm -ti ubuntu:jammy apt-cache policy apt apt: Installed: 2.4.5 Candidate: 2.4.5 Version table: *** 2.4.5 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status 3) I would expect, that "apt-get update" updates the package lists, as in # docker run --rm -ti ubuntu:focal apt-get update Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease Get:2 http://archive.ubuntu.com/ubuntu focal/main Translation-en [506 kB] Fetched 506 kB in 1s (464 kB/s) Reading package lists... Done 4) Instead, it fails with # docker run --rm -ti ubuntu:jammy apt-get update Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease Err:1 http://archive.ubuntu.com/ubuntu jammy InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C Reading package lists... Done W: http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg are ignored as the file is not readable by user '_apt' executing apt-key. W: http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key. W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://archive.ubuntu.com/ubuntu jammy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C W: Some index files failed to download. They have been ignored, or old ones used instead. 5) To reproduce: # mkdir jammy-jellyfish # debootstrap jammy jammy-jellyfish ... # tar -C jammy-jellyfish -c . | docker import - ubuntu:jammy # docker run --rm -ti ubuntu:jammy apt-get update Doing the same with focal, works as expected: # mkdir focal-fossa # debootstrap focal focal-fossa ... # tar -C focal-fossa -c . | docker import - ubuntu:focal # docker run --rm -ti ubuntu:focal apt-get update Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease Get:2 http://archive.ubuntu.com/ubuntu focal/main Translation-en [506 kB] Fetched 506 kB in 1s (963 kB/s) Reading package lists... Done To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1979139/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1979166] Re: hostapd not compiled with 802.11ax support
** Package changed: wpa (Ubuntu) => hostapd (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1979166 Title: hostapd not compiled with 802.11ax support Status in hostapd package in Ubuntu: New Bug description: setting ieee80211ax=1 in the hostapd.conf results in a unknown configuration error. 802.11ax is supported in V2.10 of hostap, so it's likely that the make config flag is not set properly to enable this. Need to update CONFIG_IEEE80211AX=y and recompile. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hostapd/+bug/1979166/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1965518] Re: [USB-Audio - USB Audio, recording] Recording problem
Issue exists also on Ubuntu 22.04 last time when I was checking. I think it was around this month. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1965518 Title: [USB-Audio - USB Audio, recording] Recording problem Status in alsa-driver package in Ubuntu: Confirmed Bug description: Microphone when using built in mbo MSI Z690 Edge WiFi DDR4 audio Realtek ALC4080 is not recording audio. What I did found out, that the bar which indicates that something is recording is going up, when I play some sound on ubuntu, so input "thinks" it is output I think. If raport is somehow saying I was not using that mic at the moment, that is because I was using other card which I need to buy, for mic to temporarly work. I rechecked it before sending report, and yes, that original from MBO audio input is still not working. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.13.0-35.40-generic 5.13.19 Uname: Linux 5.13.0-35-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: Unity Date: Fri Mar 18 10:39:26 2022 InstallationDate: Installed on 2022-03-12 (5 days ago) InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaRecordingTest: ALSA recording test through plughw:Audio failed Symptom_Card: USB Audio - USB Audio Symptom_Type: None of the above Title: [USB-Audio - USB Audio, recording] Recording problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/13/2021 dmi.bios.release: 5.24 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: 1.10 dmi.board.asset.tag: Default string dmi.board.name: MPG Z690 EDGE WIFI DDR4 (MS-7D31) dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: 1.0 dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr1.10:bd12/13/2021:br5.24:svnMicro-StarInternationalCo.,Ltd.:pnMS-7D31:pvr1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMPGZ690EDGEWIFIDDR4(MS-7D31):rvr1.0:cvnMicro-StarInternationalCo.,Ltd.:ct3:cvr1.0:skuDefaultstring: dmi.product.family: Default string dmi.product.name: MS-7D31 dmi.product.sku: Default string dmi.product.version: 1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1965518/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1965518] Re: [USB-Audio - USB Audio, recording] Recording problem
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: alsa-driver (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1965518 Title: [USB-Audio - USB Audio, recording] Recording problem Status in alsa-driver package in Ubuntu: Confirmed Bug description: Microphone when using built in mbo MSI Z690 Edge WiFi DDR4 audio Realtek ALC4080 is not recording audio. What I did found out, that the bar which indicates that something is recording is going up, when I play some sound on ubuntu, so input "thinks" it is output I think. If raport is somehow saying I was not using that mic at the moment, that is because I was using other card which I need to buy, for mic to temporarly work. I rechecked it before sending report, and yes, that original from MBO audio input is still not working. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.13.0-35.40-generic 5.13.19 Uname: Linux 5.13.0-35-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: Unity Date: Fri Mar 18 10:39:26 2022 InstallationDate: Installed on 2022-03-12 (5 days ago) InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaRecordingTest: ALSA recording test through plughw:Audio failed Symptom_Card: USB Audio - USB Audio Symptom_Type: None of the above Title: [USB-Audio - USB Audio, recording] Recording problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/13/2021 dmi.bios.release: 5.24 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: 1.10 dmi.board.asset.tag: Default string dmi.board.name: MPG Z690 EDGE WIFI DDR4 (MS-7D31) dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: 1.0 dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr1.10:bd12/13/2021:br5.24:svnMicro-StarInternationalCo.,Ltd.:pnMS-7D31:pvr1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMPGZ690EDGEWIFIDDR4(MS-7D31):rvr1.0:cvnMicro-StarInternationalCo.,Ltd.:ct3:cvr1.0:skuDefaultstring: dmi.product.family: Default string dmi.product.name: MS-7D31 dmi.product.sku: Default string dmi.product.version: 1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1965518/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
