[Touch-packages] [Bug 1956102] Re: Time for the US is shown in 24h format. It should be 12h with AM/PM
It missed the 45.0 tag and gnome-45 branch so currently only exists in future release 46. Hopefully it will get cherry picked into 45. ** Tags added: fixed-upstream ** Tags added: fixed-in-gsettings-desktop-schemas-46 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gsettings-desktop-schemas in Ubuntu. https://bugs.launchpad.net/bugs/1956102 Title: Time for the US is shown in 24h format. It should be 12h with AM/PM Status in GSettings Desktop Schemas: Fix Released Status in gsettings-desktop-schemas package in Ubuntu: Fix Committed Status in gsettings-desktop-schemas package in Debian: New Bug description: Source- https://time.gov/ To manage notifications about this bug go to: https://bugs.launchpad.net/gsettings-desktop-schemas/+bug/1956102/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036128] Re: [FFe] enable unprivileged user namespace restrictions by default for mantic
** Changed in: apparmor (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2036128 Title: [FFe] enable unprivileged user namespace restrictions by default for mantic Status in apparmor package in Ubuntu: New Bug description: As per https://discourse.ubuntu.com/t/spec-unprivileged-user- namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626, unprivileged user namespace restrictions for Ubuntu 23.10 are to be enabled by default via a sysctl.d conf file in apparmor. In https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2035315 new apparmor profiles were added to the apparmor package for various applications which require unprivileged user namespaces, using a new unconfined profile mode. To support this an additional change was added to the mantic kernel in https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/mantic/commit?h=master- next=7327726a2dbf571e05f7c095916dcce0347790b4 which is still currently unreleased. Without this kernel change, if userns restrictions are enabled the existing policies added above will not actually work to allow them to be used by the various applications. As such we need to ensure that userns restrictions are not enabled via sysctl when this feature is not present / enabled. Whilst it may be possible to capture the dependency logic via `Breaks:` or similar, this would not help in the case that a user booted into an older kernel with the new apparmor userspace package. As such, as well as enabling the sysctl via the sysctl.d conf file, it is proposed to add logic into the apparmor.service systemd unit to check that the kernel supports the aforementioned unconfined profile mode and that it is enabled - and if not then to force disable the userns restrictions sysctl via the following logic: userns_restricted=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns) unconfined_userns=$([ -f /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ] && cat /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns || echo 0) if [ -n "$userns_restricted" ] && [ "$userns_restricted" -eq 1 ]; then if [ "$unconfined_userns" -eq 0 ]; then # userns restrictions rely on unconfined userns to be supported echo "disabling unprivileged userns restrictions since unconfined userns is not supported / enabled" sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 fi fi this allows a local admin to disable the sysctl via the regular sysctl.d conf approach, but to also make sure we don't inadvertently enable it when it is not supported by the kernel. This proposed change has been tested via the QA Regression Testing project, in particular with the specific test added in https://git.launchpad.net/qa-regression- testing/commit/?id=6f2c5ab7c8659174adac772ce0e894328bb5045d This produces the following output, confirming the fallback works as expected on the current mantic kernel (which does not fully support the userns restrictions): --- Running test: './test-apparmor.py' distro: 'Ubuntu 23.10' kernel: '6.5.0-5.5 (Ubuntu 6.5.0-5.5-generic 6.5.0)' arch: 'amd64' init: 'systemd' uid: 0/0 SUDO_USER: 'ubuntu') test_unconfined_userns (__main__.ApparmorTest.test_unconfined_userns) Test that unconfined userns restrictions are applied ... Skipping private tests WARN: kernel rate limiting in effect Disabling ratelimiting until the next reboot. To renable, run: # sysctl -w kernel.printk_ratelimit=5 (enabling userns restrictions) (restarting apparmor) (checking userns restrictions got disabled) ok -- Ran 1 test in 0.232s OK --- Also we can see on a fresh-boot with this new version installed that apparmor.service shows it has disabled the sysctl before loading any profiles even though the conf file has it enabled - and finally we can see that unshare -U works as expected: root@sec-mantic-amd64:~# uptime 07:04:48 up 0 min, 0 user, load average: 0.00, 0.00, 0.00 root@sec-mantic-amd64:~# journalctl -b0 --unit apparmor.service --no-pager Sep 15 07:04:47 sec-mantic-amd64 systemd[1]: Starting apparmor.service - Load AppArmor profiles... Sep 15 07:04:47 sec-mantic-amd64 apparmor.systemd[308]: Restarting AppArmor Sep 15 07:04:47 sec-mantic-amd64 apparmor.systemd[308]: disabling unprivileged userns restrictions since unconfined userns is not supported / enabled Sep 15 07:04:47 sec-mantic-amd64 apparmor.systemd[320]: kernel.apparmor_restrict_unprivileged_userns = 0 Sep 15 07:04:47
[Touch-packages] [Bug 2036128] Re: [FFe] enable unprivileged user namespace restrictions by default for mantic
@vorlon - the FFe you approved was to upload a whole new release apparmor-4.0.0~alpha2 with supporting infrastructure for this feature, but crucially it did not enable it at that time (as we wanted more time to add additional profiles for all the packages in the archive so that when then feature gets turned on they would work as before). This new FFe does enable it *and* also adds some logic so that we only enable it when the kernel supports all the required features. This is to ensure that during an upgrade from lunar -> mantic, or when booting an older kernel which doesn't have all the features, we don't enable the sysctl and break applications which expect to be able to use userns. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2036128 Title: [FFe] enable unprivileged user namespace restrictions by default for mantic Status in apparmor package in Ubuntu: Incomplete Bug description: As per https://discourse.ubuntu.com/t/spec-unprivileged-user- namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626, unprivileged user namespace restrictions for Ubuntu 23.10 are to be enabled by default via a sysctl.d conf file in apparmor. In https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2035315 new apparmor profiles were added to the apparmor package for various applications which require unprivileged user namespaces, using a new unconfined profile mode. To support this an additional change was added to the mantic kernel in https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/mantic/commit?h=master- next=7327726a2dbf571e05f7c095916dcce0347790b4 which is still currently unreleased. Without this kernel change, if userns restrictions are enabled the existing policies added above will not actually work to allow them to be used by the various applications. As such we need to ensure that userns restrictions are not enabled via sysctl when this feature is not present / enabled. Whilst it may be possible to capture the dependency logic via `Breaks:` or similar, this would not help in the case that a user booted into an older kernel with the new apparmor userspace package. As such, as well as enabling the sysctl via the sysctl.d conf file, it is proposed to add logic into the apparmor.service systemd unit to check that the kernel supports the aforementioned unconfined profile mode and that it is enabled - and if not then to force disable the userns restrictions sysctl via the following logic: userns_restricted=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns) unconfined_userns=$([ -f /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ] && cat /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns || echo 0) if [ -n "$userns_restricted" ] && [ "$userns_restricted" -eq 1 ]; then if [ "$unconfined_userns" -eq 0 ]; then # userns restrictions rely on unconfined userns to be supported echo "disabling unprivileged userns restrictions since unconfined userns is not supported / enabled" sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 fi fi this allows a local admin to disable the sysctl via the regular sysctl.d conf approach, but to also make sure we don't inadvertently enable it when it is not supported by the kernel. This proposed change has been tested via the QA Regression Testing project, in particular with the specific test added in https://git.launchpad.net/qa-regression- testing/commit/?id=6f2c5ab7c8659174adac772ce0e894328bb5045d This produces the following output, confirming the fallback works as expected on the current mantic kernel (which does not fully support the userns restrictions): --- Running test: './test-apparmor.py' distro: 'Ubuntu 23.10' kernel: '6.5.0-5.5 (Ubuntu 6.5.0-5.5-generic 6.5.0)' arch: 'amd64' init: 'systemd' uid: 0/0 SUDO_USER: 'ubuntu') test_unconfined_userns (__main__.ApparmorTest.test_unconfined_userns) Test that unconfined userns restrictions are applied ... Skipping private tests WARN: kernel rate limiting in effect Disabling ratelimiting until the next reboot. To renable, run: # sysctl -w kernel.printk_ratelimit=5 (enabling userns restrictions) (restarting apparmor) (checking userns restrictions got disabled) ok -- Ran 1 test in 0.232s OK --- Also we can see on a fresh-boot with this new version installed that apparmor.service shows it has disabled the sysctl before loading any profiles even though the conf file has it enabled - and finally we can see that unshare -U works as expected:
[Touch-packages] [Bug 1956102] Re: Time for the US is shown in 24h format. It should be 12h with AM/PM
** Changed in: gsettings-desktop-schemas Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gsettings-desktop-schemas in Ubuntu. https://bugs.launchpad.net/bugs/1956102 Title: Time for the US is shown in 24h format. It should be 12h with AM/PM Status in GSettings Desktop Schemas: Fix Released Status in gsettings-desktop-schemas package in Ubuntu: Fix Committed Status in gsettings-desktop-schemas package in Debian: New Bug description: Source- https://time.gov/ To manage notifications about this bug go to: https://bugs.launchpad.net/gsettings-desktop-schemas/+bug/1956102/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036440] Re: Choosing "Try Ubuntu" on daily-legacy image produced a crash
Signal 6 is SIGABRT which usually means an assertion failed, which means the system log will contain an explanation. Next time it happens please run: journalctl -b0 > journal.txt and attach the resulting text file here. ** Changed in: gnome-shell (Ubuntu) Status: Invalid => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2036440 Title: Choosing "Try Ubuntu" on daily-legacy image produced a crash Status in apport package in Ubuntu: New Status in gnome-shell package in Ubuntu: Incomplete Bug description: I was booting up a daily-legacy image from 20230918 and received a crash report after choosing "Try Ubuntu". ProblemType: Crash DistroRelease: Ubuntu 23.10 Package: gnome-shell 45~rc-0ubuntu3 Uname: Linux 6.5.0-5-generic x86_64 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Sep 18 15:20:58 2023 ExecutablePath: /usr/bin/gnome-shell ExecutableTimestamp: 1694375959 ProcCmdline: gnome-shell --sm-disable --mode=ubiquity ProcCwd: /home/ubuntu ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) XDG_RUNTIME_DIR= Signal: 6 SourcePackage: gnome-shell UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2036440/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1956102] Re: Time for the US is shown in 24h format. It should be 12h with AM/PM
** No longer affects: subiquity (Ubuntu) ** No longer affects: hundredpapercuts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gsettings-desktop-schemas in Ubuntu. https://bugs.launchpad.net/bugs/1956102 Title: Time for the US is shown in 24h format. It should be 12h with AM/PM Status in GSettings Desktop Schemas: New Status in gsettings-desktop-schemas package in Ubuntu: Fix Committed Status in gsettings-desktop-schemas package in Debian: New Bug description: Source- https://time.gov/ To manage notifications about this bug go to: https://bugs.launchpad.net/gsettings-desktop-schemas/+bug/1956102/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036473] [NEW] [82Y7, Realtek ALC287, Speaker, Internal] volume either 100% or off
Public bug reported: The audio on my laptop, specifically when booting on ubuntu, is not working properly. The volume slider either turns my audio off or it turns it up to 100%. Anything else than muted is 100% on the volume slider. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 6.2.0-32.32~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-32-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: erik 1872 F pulseaudio CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Sep 19 00:42:13 2023 InstallationDate: Installed on 2023-09-07 (11 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_Card: sof-hda-dsp - sof-hda-dsp Symptom_Jack: Speaker, Internal Symptom_PulseAudioLog: sep 19 00:35:47 erik-Yoga-Pro-7-14IRH8 pulseaudio[1239]: After module unload, module 'module-null-sink' was still loaded! Symptom_Type: Volume slider, or mixer problems Title: [82Y7, Realtek ALC287, Speaker, Internal] volume slider problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/07/2023 dmi.bios.release: 1.22 dmi.bios.vendor: LENOVO dmi.bios.version: LWCN22WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76461 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Yoga Pro 7 14IRH8 dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrLWCN22WW:bd03/07/2023:br1.22:efr1.22:svnLENOVO:pn82Y7:pvrYogaPro714IRH8:rvnLENOVO:rnLNVNB161216:rvrSDK0T76461WIN:cvnLENOVO:ct10:cvrYogaPro714IRH8:skuLENOVO_MT_82Y7_BU_idea_FM_YogaPro714IRH8: dmi.product.family: Yoga Pro 7 14IRH8 dmi.product.name: 82Y7 dmi.product.sku: LENOVO_MT_82Y7_BU_idea_FM_Yoga Pro 7 14IRH8 dmi.product.version: Yoga Pro 7 14IRH8 dmi.sys.vendor: LENOVO ** Affects: alsa-driver (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy wayland-session -- 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/2036473 Title: [82Y7, Realtek ALC287, Speaker, Internal] volume either 100% or off Status in alsa-driver package in Ubuntu: New Bug description: The audio on my laptop, specifically when booting on ubuntu, is not working properly. The volume slider either turns my audio off or it turns it up to 100%. Anything else than muted is 100% on the volume slider. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 6.2.0-32.32~22.04.1-generic 6.2.16 Uname: Linux 6.2.0-32-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: erik 1872 F pulseaudio CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Sep 19 00:42:13 2023 InstallationDate: Installed on 2023-09-07 (11 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_Card: sof-hda-dsp - sof-hda-dsp Symptom_Jack: Speaker, Internal Symptom_PulseAudioLog: sep 19 00:35:47 erik-Yoga-Pro-7-14IRH8 pulseaudio[1239]: After module unload, module 'module-null-sink' was still loaded! Symptom_Type: Volume slider, or mixer problems Title: [82Y7, Realtek ALC287, Speaker, Internal] volume slider problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/07/2023 dmi.bios.release: 1.22 dmi.bios.vendor: LENOVO dmi.bios.version: LWCN22WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76461 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Yoga Pro 7 14IRH8 dmi.ec.firmware.release: 1.22 dmi.modalias: dmi:bvnLENOVO:bvrLWCN22WW:bd03/07/2023:br1.22:efr1.22:svnLENOVO:pn82Y7:pvrYogaPro714IRH8:rvnLENOVO:rnLNVNB161216:rvrSDK0T76461WIN:cvnLENOVO:ct10:cvrYogaPro714IRH8:skuLENOVO_MT_82Y7_BU_idea_FM_YogaPro714IRH8: dmi.product.family: Yoga Pro 7 14IRH8 dmi.product.name: 82Y7 dmi.product.sku: LENOVO_MT_82Y7_BU_idea_FM_Yoga Pro 7 14IRH8 dmi.product.version: Yoga Pro 7 14IRH8 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2036473/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe :
[Touch-packages] [Bug 2036467] [NEW] superblock checksum mismatch in resize2fs
Public bug reported: Hi, We run ext4 on EBS volumes on EC2. During provisioning, cloud-init will occasionally report that resize2fs has failed due to a superblock checksum mismatch. We debugged this internally, and were able to come up with the following reproducer: #!/usr/bin/bash set -euxo pipefail while true do parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s sleep .5 mkfs.ext4 /dev/nvme1n1p1 mount -t ext4 /dev/nvme1n1p1 /mnt stress-ng --temp-path /mnt -D 4 & STRESS_PID=$! sleep 1 growpart /dev/nvme1n1 1 resize2fs /dev/nvme1n1p1 kill $STRESS_PID wait $STRESS_PID umount /mnt wipefs -a /dev/nvme1n1p1 wipefs -a /dev/nvme1n1 done (This was on a 60gb gp3 volume attached to a c5.4xlarge) We were able to find a fix that works and get the patch accepted upstream. The short explanation is that by switching the superblock read to direct io, we no longer see the problem. The patch is available here, but hasn't been published in a released version of e2fsprogs: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84 A longer thread with the maintainer is available here: https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/ This bug report is to request that Ubuntu backport this patch to the versions of e2fsprogs that are in releases that are available in images on AWS, preferably Focal and Jammy. ** Affects: e2fsprogs (Ubuntu) Importance: Undecided Status: New ** Tags: patch patch-accepted-upstream -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2036467 Title: superblock checksum mismatch in resize2fs Status in e2fsprogs package in Ubuntu: New Bug description: Hi, We run ext4 on EBS volumes on EC2. During provisioning, cloud-init will occasionally report that resize2fs has failed due to a superblock checksum mismatch. We debugged this internally, and were able to come up with the following reproducer: #!/usr/bin/bash set -euxo pipefail while true do parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s sleep .5 mkfs.ext4 /dev/nvme1n1p1 mount -t ext4 /dev/nvme1n1p1 /mnt stress-ng --temp-path /mnt -D 4 & STRESS_PID=$! sleep 1 growpart /dev/nvme1n1 1 resize2fs /dev/nvme1n1p1 kill $STRESS_PID wait $STRESS_PID umount /mnt wipefs -a /dev/nvme1n1p1 wipefs -a /dev/nvme1n1 done (This was on a 60gb gp3 volume attached to a c5.4xlarge) We were able to find a fix that works and get the patch accepted upstream. The short explanation is that by switching the superblock read to direct io, we no longer see the problem. The patch is available here, but hasn't been published in a released version of e2fsprogs: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84 A longer thread with the maintainer is available here: https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/ This bug report is to request that Ubuntu backport this patch to the versions of e2fsprogs that are in releases that are available in images on AWS, preferably Focal and Jammy. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036128] Re: [FFe] enable unprivileged user namespace restrictions by default for mantic
I am confused because I thought I had already approved an FFe for this feature. Did I imagine this? Did that FFe not cover the whole scope? The hour is getting late now. ** Changed in: apparmor (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2036128 Title: [FFe] enable unprivileged user namespace restrictions by default for mantic Status in apparmor package in Ubuntu: Incomplete Bug description: As per https://discourse.ubuntu.com/t/spec-unprivileged-user- namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626, unprivileged user namespace restrictions for Ubuntu 23.10 are to be enabled by default via a sysctl.d conf file in apparmor. In https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2035315 new apparmor profiles were added to the apparmor package for various applications which require unprivileged user namespaces, using a new unconfined profile mode. To support this an additional change was added to the mantic kernel in https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/mantic/commit?h=master- next=7327726a2dbf571e05f7c095916dcce0347790b4 which is still currently unreleased. Without this kernel change, if userns restrictions are enabled the existing policies added above will not actually work to allow them to be used by the various applications. As such we need to ensure that userns restrictions are not enabled via sysctl when this feature is not present / enabled. Whilst it may be possible to capture the dependency logic via `Breaks:` or similar, this would not help in the case that a user booted into an older kernel with the new apparmor userspace package. As such, as well as enabling the sysctl via the sysctl.d conf file, it is proposed to add logic into the apparmor.service systemd unit to check that the kernel supports the aforementioned unconfined profile mode and that it is enabled - and if not then to force disable the userns restrictions sysctl via the following logic: userns_restricted=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns) unconfined_userns=$([ -f /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ] && cat /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns || echo 0) if [ -n "$userns_restricted" ] && [ "$userns_restricted" -eq 1 ]; then if [ "$unconfined_userns" -eq 0 ]; then # userns restrictions rely on unconfined userns to be supported echo "disabling unprivileged userns restrictions since unconfined userns is not supported / enabled" sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 fi fi this allows a local admin to disable the sysctl via the regular sysctl.d conf approach, but to also make sure we don't inadvertently enable it when it is not supported by the kernel. This proposed change has been tested via the QA Regression Testing project, in particular with the specific test added in https://git.launchpad.net/qa-regression- testing/commit/?id=6f2c5ab7c8659174adac772ce0e894328bb5045d This produces the following output, confirming the fallback works as expected on the current mantic kernel (which does not fully support the userns restrictions): --- Running test: './test-apparmor.py' distro: 'Ubuntu 23.10' kernel: '6.5.0-5.5 (Ubuntu 6.5.0-5.5-generic 6.5.0)' arch: 'amd64' init: 'systemd' uid: 0/0 SUDO_USER: 'ubuntu') test_unconfined_userns (__main__.ApparmorTest.test_unconfined_userns) Test that unconfined userns restrictions are applied ... Skipping private tests WARN: kernel rate limiting in effect Disabling ratelimiting until the next reboot. To renable, run: # sysctl -w kernel.printk_ratelimit=5 (enabling userns restrictions) (restarting apparmor) (checking userns restrictions got disabled) ok -- Ran 1 test in 0.232s OK --- Also we can see on a fresh-boot with this new version installed that apparmor.service shows it has disabled the sysctl before loading any profiles even though the conf file has it enabled - and finally we can see that unshare -U works as expected: root@sec-mantic-amd64:~# uptime 07:04:48 up 0 min, 0 user, load average: 0.00, 0.00, 0.00 root@sec-mantic-amd64:~# journalctl -b0 --unit apparmor.service --no-pager Sep 15 07:04:47 sec-mantic-amd64 systemd[1]: Starting apparmor.service - Load AppArmor profiles... Sep 15 07:04:47 sec-mantic-amd64 apparmor.systemd[308]: Restarting AppArmor Sep 15 07:04:47 sec-mantic-amd64 apparmor.systemd[308]: disabling unprivileged userns restrictions since
[Touch-packages] [Bug 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
> If you are using NetworkManager, then systemd-networkd.service (and associated units like systemd-networkd-wait-online.service) should NOT be enabled. With the caveat that I am not sure why you have systemd- networkd enabled in the first place, I would recommend that you simply disable it: > $ systemctl disable --now systemd-networkd.service > This will also have the effect of disabling systemd-networkd-wait- online.service. Ok, I've done this. It is easy enough to re-enable if I need to test anything wrt the bug. This resolved the issue for me. -- 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/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: Confirmed Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
>> On Ubuntu 22.04 desktop system using network-manager > To be clear, does this mean you have no network interfaces that are configured to use networkd? Hey Steve :) So, this system is quite old. I think the first install was 16.04 and it went through a bunch of upgrades (mostly interim until 20.04 and then to 22.04). It would not surprise me if things weren't pristine. I'll give some info and you can tell me what else to provide: $ cat /etc/netplan/01-network-manager-all.yaml # Let NetworkManager manage all devices on this system network: version: 2 renderer: NetworkManager $ sudo netplan get all network: version: 2 renderer: NetworkManager $ ls /etc/systemd/network $ $ cat /etc/systemd/networkd.conf # This file is part of systemd. ... # See networkd.conf(5) for details. [Network] #SpeedMeter=no #SpeedMeterIntervalSec=10sec #ManageForeignRoutingPolicyRules=yes #ManageForeignRoutes=yes #RouteTable= [DHCPv4] #DUIDType=vendor #DUIDRawData= [DHCPv6] #DUIDType=vendor #DUIDRawData= $ sudo systemctl status systemd-networkd ● systemd-networkd.service - Network Configuration Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2023-09-17 12:13:48 CDT; 1 day 2h ago TriggeredBy: ● systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 1442 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 18857) Memory: 2.7M CPU: 1.387s CGroup: /system.slice/systemd-networkd.service └─1442 /lib/systemd/systemd-networkd Sep 17 14:33:42 systemd-networkd[1442]: wlp58s0: Lost carrier Sep 17 14:33:43 systemd-networkd[1442]: wlp58s0: Gained carrier Sep 17 16:44:57 systemd-networkd[1442]: lxd0: Link UP Sep 17 16:45:02 systemd-networkd[1442]: veth8afa41ff: Link UP Sep 17 16:45:02 systemd-networkd[1442]: veth8afa41ff: Gained carrier Sep 17 16:45:02 systemd-networkd[1442]: lxd0: Gained carrier Sep 17 16:45:02 systemd-networkd[1442]: lxd0: Gained IPv6LL Sep 17 17:32:49 systemd-networkd[1442]: wlp58s0: Lost carrier Sep 17 17:32:50 systemd-networkd[1442]: wlp58s0: Connected WiFi access point: () Sep 17 17:32:50 systemd-networkd[1442]: wlp58s0: Gained carrier I don't recall enabling systemd-networkd, but a lot has happened over the last 7 years, 4.5 of those while developing Ubuntu. :) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: Confirmed Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2035061] Re: uptime -p reports incorrect output after 52 weeks
Could we have a justification for why this is important for SRU, please? As written, the Impact statement describes a bug, but doesn't present any explanation of why it is important for Ubuntu to fix it in its stable releases. If it is just that the output might be wrong and we'd like it to be correct, then it should be sufficient to be fixed in the next release. There is a cost to every SRU in terms of review, sponsorship and SRU review time, and then for millions of users to download and install yet another update. I'm sure most users do not want to download many megabytes just for this type of stable release update (this binary is small, but doing this kind of thing across many packages adds up), so there needs to be a strong justification for doing it. We can stage this change to be bundled with another fix should it ever come, but note that we've been doing this kind of thing for a while and many such changes never land before the release EOLs, meaning that such review efforts were wasted and better spent on other reviews instead. I'm setting this Won't Fix for now since, as described, the Impact statement does not provide sufficient justification for an SRU. We can reconsider if we have a report of a real user story that demonstrates why this is of high enough impact to users to be worth fixing it. ** Changed in: procps (Ubuntu Focal) Status: New => Won't Fix ** Changed in: procps (Ubuntu Jammy) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/2035061 Title: uptime -p reports incorrect output after 52 weeks Status in procps package in Ubuntu: Fix Released Status in procps source package in Focal: Won't Fix Status in procps source package in Jammy: Won't Fix Bug description: [ Impact ] uptime -p will provide incorrect data for 24 hours after exactly 52 weeks. Users and tools utilizing this command will receive example output "up 2 hours" instead of "up 52 weeks, 2 hours". After 24 hours since 52 weeks, uptime -p will report "up 1 year" which is correct output. Issue is already fixed in upstream https://gitlab.com/procps-ng/procps/-/commit/0496b39876d569fe1cecb76ad5ef212cd14c0374. Latest procps releases already include this patch (procps 4.0.3 lunar/mantic) The fix is needed for following set of packages: procps | 2:3.3.17-6ubuntu2 | jammy procps | 2:3.3.16-1ubuntu2 | focal [ Test Plan ] Reproduction: UPTIME="31528920 31528800"; mkfifo uptime_fifo; while true; do cat <<<$UPTIME > uptime_fifo; done & sudo mount -obind uptime_fifo /proc/uptime uptime -p Running above commands will result in incorrect uptime output. Testing: In attached uptime_test_results file there is modified print_uptime function which has been used to test multiple corner cases. [ Where problems could occur ] Proposed changes modifies output format of "uptime -p". Issue has been already fixed in latest version of procps package available in lunar/mantic however older releases are based on different code base and patch cannot be directly cherry-picked. Due to backport requirements some code of "uptime" (without -p) has been also changed but this should not impact logic for that usage. As the change focuses on modifying "uptime -p" output format any potential issues will impact this command. I have also looked for a reverse dependencies on procps package to check for potential uses of uptime -p, however I was not able to find any. Internally within procps package this functionality is used in "top" application, however for that case "uptime" (without -p) is used. [ Other Info ] Bug upstream: https://gitlab.com/procps-ng/procps/-/issues/217 Following patch is needed for older releases: https://gitlab.com/procps-ng/procps/-/commit/0496b39876d569fe1cecb76ad5ef212cd14c0374 Old commit on which upstream patch is based: https://gitlab.com/procps-ng/procps/-/commit/8827c6763f79f77a126968e200b0e402de7cb749 Small change on top of proposed patch (already included in debdiff): https://gitlab.com/procps-ng/procps/-/commit/10824b0655f3eeaeac87ae6e4e3881429a237f3e To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/2035061/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036333] Re: signon-ui no longer works for Google authentication
** Summary changed: - signon-ui no longer works for Goolge authentication + signon-ui no longer works for Google authentication -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to signon-ui in Ubuntu. https://bugs.launchpad.net/bugs/2036333 Title: signon-ui no longer works for Google authentication Status in signon-ui package in Ubuntu: New Status in signon-ui package in Fedora: Unknown Bug description: The version of signon-ui from Launchpad no longer works for adding Google services in Kubuntu. The login hangs indefinitely after entering an email address. Apparently, a slightly newer version from its current home on git reportedly works, and is what others have been using: https://gitlab.com/accounts-sso/signon-ui To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/signon-ui/+bug/2036333/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2035061] Re: uptime -p reports incorrect output after 52 weeks
(unsubscribing ~ubuntu-sponsors as given my previous comment there is now nothing remaining to sponsor) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/2035061 Title: uptime -p reports incorrect output after 52 weeks Status in procps package in Ubuntu: Fix Released Status in procps source package in Focal: Won't Fix Status in procps source package in Jammy: Won't Fix Bug description: [ Impact ] uptime -p will provide incorrect data for 24 hours after exactly 52 weeks. Users and tools utilizing this command will receive example output "up 2 hours" instead of "up 52 weeks, 2 hours". After 24 hours since 52 weeks, uptime -p will report "up 1 year" which is correct output. Issue is already fixed in upstream https://gitlab.com/procps-ng/procps/-/commit/0496b39876d569fe1cecb76ad5ef212cd14c0374. Latest procps releases already include this patch (procps 4.0.3 lunar/mantic) The fix is needed for following set of packages: procps | 2:3.3.17-6ubuntu2 | jammy procps | 2:3.3.16-1ubuntu2 | focal [ Test Plan ] Reproduction: UPTIME="31528920 31528800"; mkfifo uptime_fifo; while true; do cat <<<$UPTIME > uptime_fifo; done & sudo mount -obind uptime_fifo /proc/uptime uptime -p Running above commands will result in incorrect uptime output. Testing: In attached uptime_test_results file there is modified print_uptime function which has been used to test multiple corner cases. [ Where problems could occur ] Proposed changes modifies output format of "uptime -p". Issue has been already fixed in latest version of procps package available in lunar/mantic however older releases are based on different code base and patch cannot be directly cherry-picked. Due to backport requirements some code of "uptime" (without -p) has been also changed but this should not impact logic for that usage. As the change focuses on modifying "uptime -p" output format any potential issues will impact this command. I have also looked for a reverse dependencies on procps package to check for potential uses of uptime -p, however I was not able to find any. Internally within procps package this functionality is used in "top" application, however for that case "uptime" (without -p) is used. [ Other Info ] Bug upstream: https://gitlab.com/procps-ng/procps/-/issues/217 Following patch is needed for older releases: https://gitlab.com/procps-ng/procps/-/commit/0496b39876d569fe1cecb76ad5ef212cd14c0374 Old commit on which upstream patch is based: https://gitlab.com/procps-ng/procps/-/commit/8827c6763f79f77a126968e200b0e402de7cb749 Small change on top of proposed patch (already included in debdiff): https://gitlab.com/procps-ng/procps/-/commit/10824b0655f3eeaeac87ae6e4e3881429a237f3e To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/2035061/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036440] Re: Choosing "Try Ubuntu" on daily-legacy image produced a crash
Since this crash is about gnome-shell, maybe this is just another case of bug #2015857? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2036440 Title: Choosing "Try Ubuntu" on daily-legacy image produced a crash Status in apport package in Ubuntu: New Status in gnome-shell package in Ubuntu: Invalid Bug description: I was booting up a daily-legacy image from 20230918 and received a crash report after choosing "Try Ubuntu". ProblemType: Crash DistroRelease: Ubuntu 23.10 Package: gnome-shell 45~rc-0ubuntu3 Uname: Linux 6.5.0-5-generic x86_64 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Sep 18 15:20:58 2023 ExecutablePath: /usr/bin/gnome-shell ExecutableTimestamp: 1694375959 ProcCmdline: gnome-shell --sm-disable --mode=ubiquity ProcCwd: /home/ubuntu ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) XDG_RUNTIME_DIR= Signal: 6 SourcePackage: gnome-shell UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2036440/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1956102] Re: Time for the US is shown in 24h format. It should be 12h with AM/PM
** Changed in: gsettings-desktop-schemas (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gsettings-desktop-schemas in Ubuntu. https://bugs.launchpad.net/bugs/1956102 Title: Time for the US is shown in 24h format. It should be 12h with AM/PM Status in GSettings Desktop Schemas: New Status in One Hundred Papercuts: New Status in gsettings-desktop-schemas package in Ubuntu: Fix Committed Status in subiquity package in Ubuntu: Won't Fix Status in gsettings-desktop-schemas package in Debian: New Bug description: Source- https://time.gov/ To manage notifications about this bug go to: https://bugs.launchpad.net/gsettings-desktop-schemas/+bug/1956102/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2035061] Re: uptime -p reports incorrect output after 52 weeks
marking resolved for the devel series, per description. ** Changed in: procps (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/2035061 Title: uptime -p reports incorrect output after 52 weeks Status in procps package in Ubuntu: Fix Released Status in procps source package in Focal: New Status in procps source package in Jammy: New Bug description: [ Impact ] uptime -p will provide incorrect data for 24 hours after exactly 52 weeks. Users and tools utilizing this command will receive example output "up 2 hours" instead of "up 52 weeks, 2 hours". After 24 hours since 52 weeks, uptime -p will report "up 1 year" which is correct output. Issue is already fixed in upstream https://gitlab.com/procps-ng/procps/-/commit/0496b39876d569fe1cecb76ad5ef212cd14c0374. Latest procps releases already include this patch (procps 4.0.3 lunar/mantic) The fix is needed for following set of packages: procps | 2:3.3.17-6ubuntu2 | jammy procps | 2:3.3.16-1ubuntu2 | focal [ Test Plan ] Reproduction: UPTIME="31528920 31528800"; mkfifo uptime_fifo; while true; do cat <<<$UPTIME > uptime_fifo; done & sudo mount -obind uptime_fifo /proc/uptime uptime -p Running above commands will result in incorrect uptime output. Testing: In attached uptime_test_results file there is modified print_uptime function which has been used to test multiple corner cases. [ Where problems could occur ] Proposed changes modifies output format of "uptime -p". Issue has been already fixed in latest version of procps package available in lunar/mantic however older releases are based on different code base and patch cannot be directly cherry-picked. Due to backport requirements some code of "uptime" (without -p) has been also changed but this should not impact logic for that usage. As the change focuses on modifying "uptime -p" output format any potential issues will impact this command. I have also looked for a reverse dependencies on procps package to check for potential uses of uptime -p, however I was not able to find any. Internally within procps package this functionality is used in "top" application, however for that case "uptime" (without -p) is used. [ Other Info ] Bug upstream: https://gitlab.com/procps-ng/procps/-/issues/217 Following patch is needed for older releases: https://gitlab.com/procps-ng/procps/-/commit/0496b39876d569fe1cecb76ad5ef212cd14c0374 Old commit on which upstream patch is based: https://gitlab.com/procps-ng/procps/-/commit/8827c6763f79f77a126968e200b0e402de7cb749 Small change on top of proposed patch (already included in debdiff): https://gitlab.com/procps-ng/procps/-/commit/10824b0655f3eeaeac87ae6e4e3881429a237f3e To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/2035061/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
I'm also affected by this: I'm on Ubuntu 22.04.3 for Raspberry Pi and after updating to 249.11-0ubuntu3.10 on boot I get: Sep 18 19:16:33 pi4-ubuntu systemd[1]: Starting Wait for Network to be Configured... Sep 18 19:19:29 pi4-ubuntu systemd-networkd-wait-online[1319]: Timeout occurred while waiting for network connectivity. Sep 18 19:19:29 pi4-ubuntu systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE Sep 18 19:19:29 pi4-ubuntu systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. Sep 18 19:19:29 pi4-ubuntu systemd[1]: Failed to start Wait for Network to be Configured. Output of networkctl: IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 etherroutableconfigured 2 links listed. Running `SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd-wait- online --timeout=5 --any` yields: Found link 2 Found link 1 eth0: link is ignored lo: link is ignored Timeout occurred while waiting for network connectivity. Which makes no sense, given eth0 is up and running. I've made no changes to the default network settings and everything worked up until the update. This also doesn't bother me TOO much, since after the timeout of about 2 minutes, things continue as usual. Just a bit annoying and I was honestly wondering whether I was going crazy before I (luckily) stumbled upon this. -- 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/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: Confirmed Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036440] Re: Choosing "Try Ubuntu" on daily-legacy image produced a crash
I'm manually able to retrace the crash file from comment #4, although that fails, with the apport. Perhaps there is a period of time where the core dump is not attached to the crash file? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2036440 Title: Choosing "Try Ubuntu" on daily-legacy image produced a crash Status in apport package in Ubuntu: New Status in gnome-shell package in Ubuntu: Invalid Bug description: I was booting up a daily-legacy image from 20230918 and received a crash report after choosing "Try Ubuntu". ProblemType: Crash DistroRelease: Ubuntu 23.10 Package: gnome-shell 45~rc-0ubuntu3 Uname: Linux 6.5.0-5-generic x86_64 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Sep 18 15:20:58 2023 ExecutablePath: /usr/bin/gnome-shell ExecutableTimestamp: 1694375959 ProcCmdline: gnome-shell --sm-disable --mode=ubiquity ProcCwd: /home/ubuntu ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) XDG_RUNTIME_DIR= Signal: 6 SourcePackage: gnome-shell UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2036440/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036441] Re: whoopsie cannot report crash reports from live environment
** Changed in: whoopsie (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/2036441 Title: whoopsie cannot report crash reports from live environment Status in whoopsie package in Ubuntu: New Bug description: The .uploaded file corresponding to a crash report had NULL for its contents so I used journalctl to find information about whoopsie and saw the following: Sep 18 15:28:42 ubuntu systemd[1]: Started whoopsie.service - crash report submission. Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Using lock path: /var/lock/whoopsie/lock Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Parsing /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash. Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Unable to parse report (/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash): /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash could not be opened. Sep 18 15:28:42 ubuntu systemd[1]: whoopsie.service: Deactivated successfully. This was on an Ubuntu daily-legacy image dated 20230918. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: whoopsie 0.2.77 ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0 Uname: Linux 6.5.0-5-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CasperVersion: 1.482 CrashReports: 600:109:116:5:2023-09-18 15:28:42.434625080 +:2023-09-18 15:30:28.058067902 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.uploaded 644:1000:1000:0:2023-09-18 15:28:11.774841581 +:2023-09-18 15:28:11.774841581 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.upload 640:1000:1000:650635:2023-09-18 15:25:02.717362880 +:2023-09-18 15:28:42.410625168 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash 640:1000:116:181411:2023-09-18 15:21:05.423967599 +:2023-09-18 15:21:06.423967599 +:/var/crash/_usr_bin_gnome-shell.1000.crash CurrentDesktop: ubuntu:GNOME Date: Mon Sep 18 15:31:48 2023 LiveMediaBuild: Ubuntu Legacy 23.10 "Mantic Minotaur" - Daily amd64 (20230918) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= RelatedPackageVersions: apport-noui N/A SourcePackage: whoopsie UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/2036441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036440] Re: Choosing "Try Ubuntu" on daily-legacy image produced a crash
This bears some investigation into whether or not the core dump is actually a part of the crash file and if not why it isn't. We want to be able to provide crash reports from the live environment. ** Tags added: rls-mm-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2036440 Title: Choosing "Try Ubuntu" on daily-legacy image produced a crash Status in apport package in Ubuntu: New Status in gnome-shell package in Ubuntu: Invalid Bug description: I was booting up a daily-legacy image from 20230918 and received a crash report after choosing "Try Ubuntu". ProblemType: Crash DistroRelease: Ubuntu 23.10 Package: gnome-shell 45~rc-0ubuntu3 Uname: Linux 6.5.0-5-generic x86_64 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Sep 18 15:20:58 2023 ExecutablePath: /usr/bin/gnome-shell ExecutableTimestamp: 1694375959 ProcCmdline: gnome-shell --sm-disable --mode=ubiquity ProcCwd: /home/ubuntu ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) XDG_RUNTIME_DIR= Signal: 6 SourcePackage: gnome-shell UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2036440/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036440] Re: Choosing "Try Ubuntu" on daily-legacy image produced a crash
I'm attaching the crash file which does have a CoreDump section. ** Attachment added: "_usr_bin_gnome-shell.1000.crash" https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2036440/+attachment/5701823/+files/_usr_bin_gnome-shell.1000.crash ** Also affects: apport (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2036440 Title: Choosing "Try Ubuntu" on daily-legacy image produced a crash Status in apport package in Ubuntu: New Status in gnome-shell package in Ubuntu: Invalid Bug description: I was booting up a daily-legacy image from 20230918 and received a crash report after choosing "Try Ubuntu". ProblemType: Crash DistroRelease: Ubuntu 23.10 Package: gnome-shell 45~rc-0ubuntu3 Uname: Linux 6.5.0-5-generic x86_64 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Sep 18 15:20:58 2023 ExecutablePath: /usr/bin/gnome-shell ExecutableTimestamp: 1694375959 ProcCmdline: gnome-shell --sm-disable --mode=ubiquity ProcCwd: /home/ubuntu ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) XDG_RUNTIME_DIR= Signal: 6 SourcePackage: gnome-shell UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2036440/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1923052] Re: screen reader does not read ubiquity window
I tested this again today with an Ubuntu desktop legacy image dated 20230918 and encountered the same bug where the screenreader works with ubiquity if you do not choose "Try Ubuntu" and launch the installer again. If this isn't going to be fixed or isn't fixable then I suggest we close this out as "Won't Fix" and release the issue. ** Tags added: rls-mm-incoming ** Also affects: orca (Ubuntu Mantic) Importance: Undecided Status: Incomplete ** Also affects: ubiquity (Ubuntu Mantic) Importance: High Status: Confirmed ** Also affects: at-spi2-core (Ubuntu Mantic) Importance: Undecided Status: Incomplete ** Summary changed: - screen reader does not read ubiquity window + screen reader does not read ubiquity window after it is launched in "Try Ubuntu" session -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to at-spi2-core in Ubuntu. https://bugs.launchpad.net/bugs/1923052 Title: screen reader does not read ubiquity window after it is launched in "Try Ubuntu" session Status in at-spi2-core package in Ubuntu: Incomplete Status in orca package in Ubuntu: Incomplete Status in ubiquity package in Ubuntu: Confirmed Status in at-spi2-core source package in Jammy: Incomplete Status in orca source package in Jammy: Incomplete Status in ubiquity source package in Jammy: Confirmed Status in at-spi2-core source package in Mantic: Incomplete Status in orca source package in Mantic: Incomplete Status in ubiquity source package in Mantic: Confirmed Bug description: Steps to reproduce: 1. Run Ubuntu MATE 21.04 installation media 2. Try to follow http://iso.qa.ubuntu.com/qatracker/testcases/1309/info testcase by pressing ++ to activate screenreader with shown Ubiquity window, press to select some button Expected result: * screen reader reads ubiquity window Actual result: * screen reader does not read ubiquity window Note: screen reader actually works, it reads other windows - for example the terminal opened by ++. ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: ubiquity 21.04.14 ProcVersionSignature: Ubuntu 5.11.0-13.14-generic 5.11.7 Uname: Linux 5.11.0-13-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu61 Architecture: amd64 CasperMD5CheckResult: pass CasperVersion: 1.461 Date: Thu Apr 8 13:01:30 2021 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu-mate.seed maybe-ubiquity quiet splash --- LiveMediaBuild: Ubuntu-MATE 21.04 "Hirsute Hippo" - Beta amd64 (20210407.1) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SourcePackage: ubiquity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/at-spi2-core/+bug/1923052/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2017209] Re: [Raspberry Pi/lunar] systemd-oomd fails with "ConditionControlGroupController=memory was not met"
This bug was fixed in the package linux-raspi - 6.5.0-1002.2 --- linux-raspi (6.5.0-1002.2) mantic; urgency=medium * mantic/linux-raspi: 6.5.0-1002.2 -proposed tracker (LP: #2033637) * Packaging resync (LP: #1786013) - [Packaging] update update.conf * Miscellaneous Ubuntu changes - [Config] raspi: Add notes to configs that differ from master - [Config] raspi: Set CONFIG_ARM_ERRATA_=n - [Config] raspi: Set PREEMPT_DYNAMIC=y - [Config] raspi: Set STAGING_MEDIA_DEPRECATED=n - [Config] raspi: Set EFI=n - [Config] raspi: Set POWER_RESET_GPIO_RESTART=n - [Config] raspi: Set HID_BPF=n - [Config] raspi: Set COMMON_CLK_FIXED_MMIO=n - [Config] raspi: Set PWM_STMPE=n - [Config] raspi: Set LEDS_SYSCON=n - [Packaging] raspi: Include bcm2835_smi module in linux-modules - SAUCE: (no-up) Disable FIQ split-transaction FSM in dwc_otg * Miscellaneous upstream changes - drivers: media: imx296: Updated imx296 driver for external trigger - char: broadcom: vc_mem: Fix preprocessor conditional - drivers: dwc_otg: Fix fallthrough warnings - vc04_services/vc-sm-cma: Switch one-bit bitfields to bool - media: i2c: ov2311: Fix uninitialized variable usage - drm/panel: Fix default values for Waveshare 7.9 inch DSI touchscreen (#5565) - dtoverlays: Add i2c bus overrides to edt-ft5406 overlay - dtoverlays: Fix README text for i2c-fan - drivers: irqchip: irq-bcm2835: Concurrency fix - defconfigs: Add TINYDRM_ILI9486 to defconfigs - dtoverlays: Add drm option to piscreen overlay - drm/ili9486: Resolve clash in spi_device_id names - input: ads7846: Add missing spi_device_id strings - staging: bcm2835-codec: Downgrade the level for a debug message - configs: Raise 8250 UART limit to 5 on BCM2711 [ Ubuntu: 6.5.0-5.5 ] * mantic/linux: 6.5.0-5.5 -proposed tracker (LP: #2034546) * Packaging resync (LP: #1786013) - [Packaging] update helper scripts - debian/dkms-versions -- update from kernel-versions (main/d2023.08.23) [ Ubuntu: 6.5.0-4.4 ] * mantic/linux: 6.5.0-4.4 -proposed tracker (LP: #2034042) * Packaging resync (LP: #1786013) - debian/dkms-versions -- update from kernel-versions (main/d2023.08.23) [ Ubuntu: 6.5.0-3.3 ] * mantic/linux: 6.5.0-3.3 -proposed tracker (LP: #2033904) * Packaging resync (LP: #1786013) - debian/dkms-versions -- update from kernel-versions (main/d2023.08.23) * [23.10] Please test secure-boot and lockdown on the early 6.5 kernel (s390x) (LP: #2026833) - [Packaging] re-enable signing for s390x * Miscellaneous upstream changes - module/decompress: use vmalloc() for zstd decompression workspace [ Ubuntu: 6.5.0-2.2 ] * mantic/linux: 6.5.0-2.2 -proposed tracker (LP: #2033240) * Soundwire support for Dell SKU0C87 devices (LP: #2029281) - SAUCE: ASoC: Intel: soc-acpi: add support for Dell SKU0C87 devices * Fix numerous AER related issues (LP: #2033025) - SAUCE: PCI/AER: Disable AER service during suspend, again - SAUCE: PCI/DPC: Disable DPC service during suspend, again * Support Realtek RTL8852CE WiFi 6E/BT Combo (LP: #2025672) - wifi: rtw89: debug: Fix error handling in rtw89_debug_priv_btc_manual_set() - Bluetooth: btrtl: Load FW v2 otherwise FW v1 for RTL8852C * Rebase to v6.5 [ Ubuntu: 6.5.0-1.1 ] * mantic/linux: 6.5.0-1.1 -proposed tracker (LP: #2032750) * Packaging resync (LP: #1786013) - [Packaging] resync update-dkms-versions helper - [Packaging] update variants - debian/dkms-versions -- update from kernel-versions (main/d2023.07.26) * ceph: support idmapped mounts (LP: #2032959) - SAUCE: libceph: add spinlock around osd->o_requests - SAUCE: libceph: define struct ceph_sparse_extent and add some helpers - SAUCE: libceph: new sparse_read op, support sparse reads on msgr2 crc codepath - SAUCE: libceph: support sparse reads on msgr2 secure codepath - SAUCE: libceph: add sparse read support to msgr1 - SAUCE: libceph: add sparse read support to OSD client - SAUCE: ceph: add new mount option to enable sparse reads - SAUCE: ceph: preallocate inode for ops that may create one - SAUCE: ceph: make ceph_msdc_build_path use ref-walk - SAUCE: libceph: add new iov_iter-based ceph_msg_data_type and ceph_osd_data_type - SAUCE: ceph: use osd_req_op_extent_osd_iter for netfs reads - SAUCE: ceph: fscrypt_auth handling for ceph - SAUCE: ceph: implement -o test_dummy_encryption mount option - SAUCE: ceph: add fscrypt ioctls and ceph.fscrypt.auth vxattr - SAUCE: ceph: make ioctl cmds more readable in debug log - SAUCE: ceph: add base64 endcoding routines for encrypted names - SAUCE: ceph: encode encrypted name in ceph_mdsc_build_path and dentry release - SAUCE: ceph: send alternate_name in MClientRequest - SAUCE: ceph: decode alternate_name in lease info - SAUCE: ceph: set DCACHE_NOKEY_NAME
[Touch-packages] [Bug 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: systemd (Ubuntu) Status: New => Confirmed -- 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/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: Confirmed Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036427] Re: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module
It is not a desktop system. Disabling systemd-networkd seems to fix that problem, modemmanager still does not find the Huawei modem but the interface wwan0 is available and after a minute of waiting it gets an ip address and is working again. Thank You! -- 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/2036427 Title: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module Status in systemd package in Ubuntu: Incomplete Bug description: Description: Ubuntu 22.04.3 LTS Release: 22.04 After the latest upgrade our Huawei LTE modem is not working anymore. We can see the modem wie lsusb, but no interfaces gets activated and systemd-networkd-wait-online gets a timeout. The following packages have been upgraded: Upgrade: udev:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-timesyncd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libpam-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libsystemd0:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libnss-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libudev1:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-sysv:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), thermald:amd64 (2.4.9-1ubuntu0.3, 2.4.9-1ubuntu0.4) When we switch back to an older version the modem is working again! Downgrade: systemd-timesyncd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libpam-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libsystemd0:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libnss-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd-sysv:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7) So the latest update breaks anything with that modem. The output of lsusb stays the same with both versions: Bus 001 Device 003: ID 12d1:15c1 Huawei Technologies Co., Ltd. ME906s LTE M.2 Module With old packages "ip link" looks like that: 9: wwan0: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 2e:c4:ac:0a:11:f2 brd ff:ff:ff:ff:ff:ff With new packages "ip link" does not show any wwan0 or similar interface. Other network interfaces are avaiable. The network interfaces are configured with /etc/network/interfaces: allow-hotplug wwan0 iface wwan0 inet dhcp apn a1.net metric 100 We use modemmanager to connect: /usr/bin/mmcli --modem 0 --simple-connect="apn=a1.net" "mmcli -L" can't find any modems on a upgraded system. With the previous version we see the Huawei modem: /org/freedesktop/ModemManager1/Modem/0 [Huawei Technologies Co., Ltd.] HUAWEI Mobile V7R11 We have a lot of systems with Huawei LTE modems and that's a serious problem for us! Do you need more information to debug that problem? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036427/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036441] Re: whoopsie cannot report crash reports from live environment
If I read CrashReports correctly /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash is owned by 1000:1000 and has permission 640. So only user 1000 can read it. Isn't whoopsie running as root? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/2036441 Title: whoopsie cannot report crash reports from live environment Status in whoopsie package in Ubuntu: New Bug description: The .uploaded file corresponding to a crash report had NULL for its contents so I used journalctl to find information about whoopsie and saw the following: Sep 18 15:28:42 ubuntu systemd[1]: Started whoopsie.service - crash report submission. Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Using lock path: /var/lock/whoopsie/lock Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Parsing /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash. Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Unable to parse report (/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash): /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash could not be opened. Sep 18 15:28:42 ubuntu systemd[1]: whoopsie.service: Deactivated successfully. This was on an Ubuntu daily-legacy image dated 20230918. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: whoopsie 0.2.77 ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0 Uname: Linux 6.5.0-5-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CasperVersion: 1.482 CrashReports: 600:109:116:5:2023-09-18 15:28:42.434625080 +:2023-09-18 15:30:28.058067902 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.uploaded 644:1000:1000:0:2023-09-18 15:28:11.774841581 +:2023-09-18 15:28:11.774841581 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.upload 640:1000:1000:650635:2023-09-18 15:25:02.717362880 +:2023-09-18 15:28:42.410625168 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash 640:1000:116:181411:2023-09-18 15:21:05.423967599 +:2023-09-18 15:21:06.423967599 +:/var/crash/_usr_bin_gnome-shell.1000.crash CurrentDesktop: ubuntu:GNOME Date: Mon Sep 18 15:31:48 2023 LiveMediaBuild: Ubuntu Legacy 23.10 "Mantic Minotaur" - Daily amd64 (20230918) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= RelatedPackageVersions: apport-noui N/A SourcePackage: whoopsie UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/2036441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036441] [NEW] whoopsie cannot report crash reports from live environment
Public bug reported: The .uploaded file corresponding to a crash report had NULL for its contents so I used journalctl to find information about whoopsie and saw the following: Sep 18 15:28:42 ubuntu systemd[1]: Started whoopsie.service - crash report submission. Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Using lock path: /var/lock/whoopsie/lock Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Parsing /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash. Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Unable to parse report (/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash): /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash could not be opened. Sep 18 15:28:42 ubuntu systemd[1]: whoopsie.service: Deactivated successfully. This was on an Ubuntu daily-legacy image dated 20230918. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: whoopsie 0.2.77 ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0 Uname: Linux 6.5.0-5-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CasperVersion: 1.482 CrashReports: 600:109:116:5:2023-09-18 15:28:42.434625080 +:2023-09-18 15:30:28.058067902 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.uploaded 644:1000:1000:0:2023-09-18 15:28:11.774841581 +:2023-09-18 15:28:11.774841581 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.upload 640:1000:1000:650635:2023-09-18 15:25:02.717362880 +:2023-09-18 15:28:42.410625168 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash 640:1000:116:181411:2023-09-18 15:21:05.423967599 +:2023-09-18 15:21:06.423967599 +:/var/crash/_usr_bin_gnome-shell.1000.crash CurrentDesktop: ubuntu:GNOME Date: Mon Sep 18 15:31:48 2023 LiveMediaBuild: Ubuntu Legacy 23.10 "Mantic Minotaur" - Daily amd64 (20230918) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= RelatedPackageVersions: apport-noui N/A SourcePackage: whoopsie UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: whoopsie (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug autoreport-false cuqa-manual-testing mantic rls-mm-incoming ** Tags added: cuqa-manual-testing rls-mm-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/2036441 Title: whoopsie cannot report crash reports from live environment Status in whoopsie package in Ubuntu: New Bug description: The .uploaded file corresponding to a crash report had NULL for its contents so I used journalctl to find information about whoopsie and saw the following: Sep 18 15:28:42 ubuntu systemd[1]: Started whoopsie.service - crash report submission. Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Using lock path: /var/lock/whoopsie/lock Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Parsing /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash. Sep 18 15:28:42 ubuntu whoopsie[14510]: [15:28:42] Unable to parse report (/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash): /var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash could not be opened. Sep 18 15:28:42 ubuntu systemd[1]: whoopsie.service: Deactivated successfully. This was on an Ubuntu daily-legacy image dated 20230918. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: whoopsie 0.2.77 ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0 Uname: Linux 6.5.0-5-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CasperVersion: 1.482 CrashReports: 600:109:116:5:2023-09-18 15:28:42.434625080 +:2023-09-18 15:30:28.058067902 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.uploaded 644:1000:1000:0:2023-09-18 15:28:11.774841581 +:2023-09-18 15:28:11.774841581 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.upload 640:1000:1000:650635:2023-09-18 15:25:02.717362880 +:2023-09-18 15:28:42.410625168 +:/var/crash/_usr_lib_ubiquity_bin_ubiquity.0.crash 640:1000:116:181411:2023-09-18 15:21:05.423967599 +:2023-09-18 15:21:06.423967599 +:/var/crash/_usr_bin_gnome-shell.1000.crash CurrentDesktop: ubuntu:GNOME Date: Mon Sep 18 15:31:48 2023 LiveMediaBuild: Ubuntu Legacy 23.10 "Mantic Minotaur" - Daily amd64 (20230918) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= RelatedPackageVersions: apport-noui N/A SourcePackage: whoopsie UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/2036441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages
[Touch-packages] [Bug 2036302] Re: apparmor 4.0.0~alpha2-0ubuntu3 ships same file as liblxc-common
** Changed in: lxc (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/2036302 Title: apparmor 4.0.0~alpha2-0ubuntu3 ships same file as liblxc-common Status in apparmor package in Ubuntu: Fix Committed Status in lxc package in Ubuntu: Fix Released Bug description: When running apt-get distupgrade I saw this message: Preparing to unpack .../apparmor_4.0.0~alpha2-0ubuntu3_amd64.deb ... Unpacking apparmor (4.0.0~alpha2-0ubuntu3) over (4.0.0~alpha2-0ubuntu2) ... dpkg: error processing archive /var/cache/apt/archives/apparmor_4.0.0~alpha2-0ubuntu3_amd64.deb (--unpack): trying to overwrite '/etc/apparmor.d/usr.bin.lxc-start', which is also in package liblxc-common 1:5.0.1-0ubuntu6 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) The problem could be overcome with: sudo apt-get install liblxc-common --reinstall which resulted in output Preparing to unpack .../liblxc-common_1%3a5.0.1-0ubuntu6_amd64.deb ... Unpacking liblxc-common (1:5.0.1-0ubuntu6) over (1:5.0.1-0ubuntu6) ... I have seen the same type of problem before with other packages. I would have expected apt-get to correctly sequence all necessary actions on its own. These are related events in my apt history: Start-Date: 2022-10-30 05:33:09 Commandline: apt-get install lxc Requested-By: ubuntu (1000) Install: liblxc-common:amd64 (1:5.0.0~git2209-g5a7b9ce67-0ubuntu3, automatic) Start-Date: 2023-01-28 11:06:34 Commandline: apt-get dist-upgrade Requested-By: ubuntu (1000) Upgrade: liblxc-common:amd64 (1:5.0.0~git2209-g5a7b9ce67-0ubuntu3, 1:5.0.1-0ubuntu6) ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: apt 2.7.3 ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0 Uname: Linux 6.5.0-5-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Sat Sep 16 11:12:36 2023 InstallationDate: Installed on 2021-07-01 (807 days ago) InstallationMedia: Kubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2036302/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
Also appears to be affecting the Pi server images (which have no network manager and only use networkd for networking); I've only checked lunar so far. -- 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/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: New Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
Thanks a lot for taking the time to test and provide feedback. I'll continue with the SRU process which should take a few more weeks (I'd say between two and four but that's a very rough guess). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1990216 Title: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: OpenSSL upstream implemented a fix for their issue #18359 "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" https://github.com/openssl/openssl/issues/18359 as of libssl3 3.0.4 (and thus it is included in recent libssl3 versions in Kinetic). Could this fix be backported to libssl3 in Jammy? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1990216/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result
Thanks a lot for taking the time to test and provide feedback. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1994165 Title: CMS_final: do not ignore CMS_dataFinal result Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Kinetic: Won't Fix Status in openssl source package in Lunar: Fix Released Bug description: https://github.com/openssl/openssl/pull/18876 The CMS_dataFinal result is important as signature may fail, however, it is ignored while returning success from CMS_final. Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)" Thanks Upstream commit: ``` commit 67c0460b89cc1b0644a1a59af78284dfd8d720af Author: Alon Bar-Lev Date: Tue Jul 26 15:17:06 2022 +0300 Handle SMIME_crlf_copy return code Currently the SMIME_crlf_copy result is ignored in all usages. It does return failure when memory allocation fails. This patch handles the SMIME_crlf_copy return code in all occurrences. Signed-off-by: Alon Bar-Lev Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale Reviewed-by: Hugo Landau (Merged from https://github.com/openssl/openssl/pull/18876) ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate
Thanks a lot for taking the time to test and provide feedback. I'll continue with the SRU process; landing will probably take a few weeks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2023545 Title: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate Status in Ubuntu on IBM z Systems: In Progress Status in openssl package in Ubuntu: In Progress Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: ---Problem Description--- OpenSSL with ibmca engine configured dumps core when creating a new certificate. # openssl engine (dynamic) Dynamic engine loading support (ibmca) Ibmca hardware engine support # openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem -keyout __key.pem --subj '/CN=US' Segmentation fault (core dumped) # journalctl Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b ilc:2 in libc.so.6[3ffae08+1ca000] Jun 07 13:06:08 SYSTEM kernel: Failing address: TEID: 0800 Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user ASCE. Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024 Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded Not tainted 5.15.0-73-generic #80-Ubuntu Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0) Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708 Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:0 PM:0 RI:0 EA:3 Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 02aa3289f9d0 Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 02aa328a4300 Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 02aa03ff Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 03ffae437c22 03ffec2fe000 Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2 lgr%r11,%r2 03ffae11c700: 4700bc0,0 #03ffae11c704: b24f00a0ear%r10,%a0 >03ffae11c708: 58102018l%r1,24(%r2) 03ffae11c70c: ebaa002dsllg%r10,%r10,32 03ffae11c712: b24f00a1ear%r10,%a1 03ffae11c716: 5910a0d0c%r1,208(%r10) 03ffae11c71a: a7840033brc8,03ffae11c780 Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address: Jun 07 13:06:08 SYSTEM kernel: [<03ffae33242c>] 0x3ffae33242c Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0). Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 0 dumped core. Found module linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e Found module libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731 Found module ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08 Found module ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c Found module libc.so.6 with build-id: 74250317950da91d3345f258cb2dd12d22c3f2e5 Found module libcrypto.so.3 with build-id: a27f20e6cf293f214d459530ce2c0b2b52fdbdb4 Found module libssl.so.3 with build-id: e2c031c3dac06b5ce43bdea022aee7989f78dde4 Found module openssl with build-id: ed0fe325182e99d135ee6b08e6d90a9d1c42af7f Stack trace of thread 2344: #0 0x03ffae11c708 __pthread_rwlock_wrlock_full64 (libc.so.6 + 0x9c708) #1 0x03ffae437c22 CRYPTO_THREAD_write_lock (libcrypto.so.3 +
[Touch-packages] [Bug 2035315] Re: Unprivileged user namespace restrictions break various applications
This bug was fixed in the package lxc - 1:5.0.1-0ubuntu7
---
lxc (1:5.0.1-0ubuntu7) mantic; urgency=medium
* Update apparmor profile to support new userns feature (LP: #2035315)
- d/p/apparmor-userns.patch: Add userns permission to
start-container abstraction and declare new 4.0 ABI in
the usr.bin.lxc-start apparmor profile
- debian/control: Declare Breaks on anything less than apparmor
4.0.0~alpha2-0ubuntu4 for liblxc-common to ensure if apparmor is
installed that it supports the new 4.0 ABI and add systemd-dev to
Build-Depends to fix local build failure.
-- Alex Murray Mon, 18 Sep 2023 13:28:16
+0930
** Changed in: lxc (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2035315
Title:
Unprivileged user namespace restrictions break various applications
Status in apparmor package in Ubuntu:
Fix Released
Status in lxc package in Ubuntu:
Fix Released
Bug description:
When the unprivileged user namespace restrictions are enabled, various
applications within and outside the Ubuntu archive fail to function,
as they use unprivileged user namespaces as part of their normal
operation.
A search of the Ubuntu archive for the 23.10 release was performed
looking for all applications that make legitimate use of the
CLONE_NEWUSER argument, the details of which can be seen in
https://docs.google.com/spreadsheets/d/1MOPVoTW0BROF1TxYqoWeJ3c6w2xKElI4w-VjdCG0m9s/edit#gid=2102562502
For each package identified in that list, an investigation was made to
determine if the application actually used this as an unprivileged
user, and if so which of the binaries within the package were
affected.
The full investigation can be seen in
https://warthogs.atlassian.net/browse/SEC-1898 (which is unfortunately
private) but is summarised to the following list of Ubuntu source
packages, with the affected binaries as noted. NOTE that due to time
constraints for some packages it was not possible to finish the
complete investigation and so for those *all* the binaries from the
package are listed below.
For each of these binaries, an apparmor profile is required so that
the binary can be granted use of unprivileged user namespaces - an
example profile for the ch-run binary within the charliecloud package
is shown:
$ cat /etc/apparmor.d/usr.bin.ch-run
abi ,
include
/usr/bin/ch-run flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
However, in a few select cases, it has been decided not to ship an apparmor
profile, since this would effectively allow this mitigation to be bypassed. In
particular, the unshare and setns binaries within the util-linux package are
installed on every Ubuntu system, and allow an unprivileged user the ability to
launch an arbitrary application within a new user namespace. Any malicious
application then that wished to exploit an unprivileged user namespace to
conduct an attack on the kernel would simply need to spawn itself via `unshare
-U` or similar to be granted this permission. Therefore, due to the ubiquitous
nature of the unshare (and setns) binaries, profiles are not planned to be
provided for these by default. Similarly, the bwrap binary within bubblewrap is
also installed by default on Ubuntu Desktop 23.10 and can also be used to
launch arbitrary binaries within a new user namespace and so no profile is
planned to be provided for this either.
Those packages for which either a profile is not required or which a
profile is not planned are listed below, whilst the list of packages
that require a profile (and their associated binaries) is listed at
the end:
Packages that use user namespaces but for which a profile is not
required or not planned:
- bubblewrap
- /usr/bin/bwrap (NOT PLANNED AS NOTED ABOVE)
- cifs-utils
- /usr/sbin/cifs.upcall (NOT REQUIRED AS IS EXECUTED AS root)
- consfigurator # NOT REQUIRED, NO BINARIES OR reverse-depends
- criu
- /usr/sbin/criu (NOT REQUIRED SINCE ONLY FUNCTIONS AS root)
- docker.io-app
- /usr/bin/dockerd (NOT REQUIRED SINCE RUNS AS root)
- firejail
- /usr/bin/firejail (NOT REQUIRED SINCE is suid root)
- golang-github-containers-storage
- /usr/bin/containers-storage (NOT REQUIRED SINCE ONLY FUNCTIONS AS root)
- golang-gvisor-gvisor
- /usr/bin/runsc (NOT REQUIRED SINCE ONLY FUNCTIONS AS root)
- guix
- /usr/bin/guix-daemon (NOT REQURIED SINCE RUNS AS root)
- libvdestack # NOT REQUIRED, NO BINARIES OR reverse-depends
- libvirt # NOT REQUIRED SINCE USES lxc WHICH WILL HAVE A PROFILE
- network-manager # NOT REQUIRED SINCE CODE IS UNUSED
- nix # APPEARS UNNEEDED IN DEFAULT
[Touch-packages] [Bug 2036427] Re: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module
I am guessing this system is running Ubuntu Desktop? If so, systemd- networkd should not be enabled (and therefore neither should systemd- networkd-wait-online.service). If I am correct that this is a desktop, and that you expect NetworkManager to manage the interfaces (along with ModemManager for the wwan device), then I recommend that you simply disable systemd-networkd: $ systemctl disable --now systemd-networkd.service This will also disable associated units such as systemd-networkd-wait- online.target. ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Nick Rosbrook (enr0n) ** Changed in: systemd (Ubuntu) Status: Confirmed => Incomplete ** Changed in: systemd (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2036427 Title: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module Status in systemd package in Ubuntu: Incomplete Bug description: Description: Ubuntu 22.04.3 LTS Release: 22.04 After the latest upgrade our Huawei LTE modem is not working anymore. We can see the modem wie lsusb, but no interfaces gets activated and systemd-networkd-wait-online gets a timeout. The following packages have been upgraded: Upgrade: udev:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-timesyncd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libpam-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libsystemd0:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libnss-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libudev1:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-sysv:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), thermald:amd64 (2.4.9-1ubuntu0.3, 2.4.9-1ubuntu0.4) When we switch back to an older version the modem is working again! Downgrade: systemd-timesyncd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libpam-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libsystemd0:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libnss-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd-sysv:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7) So the latest update breaks anything with that modem. The output of lsusb stays the same with both versions: Bus 001 Device 003: ID 12d1:15c1 Huawei Technologies Co., Ltd. ME906s LTE M.2 Module With old packages "ip link" looks like that: 9: wwan0: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 2e:c4:ac:0a:11:f2 brd ff:ff:ff:ff:ff:ff With new packages "ip link" does not show any wwan0 or similar interface. Other network interfaces are avaiable. The network interfaces are configured with /etc/network/interfaces: allow-hotplug wwan0 iface wwan0 inet dhcp apn a1.net metric 100 We use modemmanager to connect: /usr/bin/mmcli --modem 0 --simple-connect="apn=a1.net" "mmcli -L" can't find any modems on a upgraded system. With the previous version we see the Huawei modem: /org/freedesktop/ModemManager1/Modem/0 [Huawei Technologies Co., Ltd.] HUAWEI Mobile V7R11 We have a lot of systems with Huawei LTE modems and that's a serious problem for us! Do you need more information to debug that problem? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036427/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036427] Re: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: systemd (Ubuntu) Status: New => Confirmed -- 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/2036427 Title: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module Status in systemd package in Ubuntu: Confirmed Bug description: Description: Ubuntu 22.04.3 LTS Release: 22.04 After the latest upgrade our Huawei LTE modem is not working anymore. We can see the modem wie lsusb, but no interfaces gets activated and systemd-networkd-wait-online gets a timeout. The following packages have been upgraded: Upgrade: udev:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-timesyncd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libpam-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libsystemd0:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libnss-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libudev1:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-sysv:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), thermald:amd64 (2.4.9-1ubuntu0.3, 2.4.9-1ubuntu0.4) When we switch back to an older version the modem is working again! Downgrade: systemd-timesyncd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libpam-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libsystemd0:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libnss-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd-sysv:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7) So the latest update breaks anything with that modem. The output of lsusb stays the same with both versions: Bus 001 Device 003: ID 12d1:15c1 Huawei Technologies Co., Ltd. ME906s LTE M.2 Module With old packages "ip link" looks like that: 9: wwan0: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 2e:c4:ac:0a:11:f2 brd ff:ff:ff:ff:ff:ff With new packages "ip link" does not show any wwan0 or similar interface. Other network interfaces are avaiable. The network interfaces are configured with /etc/network/interfaces: allow-hotplug wwan0 iface wwan0 inet dhcp apn a1.net metric 100 We use modemmanager to connect: /usr/bin/mmcli --modem 0 --simple-connect="apn=a1.net" "mmcli -L" can't find any modems on a upgraded system. With the previous version we see the Huawei modem: /org/freedesktop/ModemManager1/Modem/0 [Huawei Technologies Co., Ltd.] HUAWEI Mobile V7R11 We have a lot of systems with Huawei LTE modems and that's a serious problem for us! Do you need more information to debug that problem? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036427/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036427] Re: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module
** Description changed: Description: Ubuntu 22.04.3 LTS Release: 22.04 - After the latest upgrade our Huawei LTE modem is not working anymore. + After the latest upgrade our Huawei LTE modem is not working anymore. We can see the modem wie lsusb, but no interfaces gets activated and systemd-networkd-wait-online gets a timeout. The following packages have been upgraded: Upgrade: udev:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-timesyncd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libpam-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libsystemd0:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libnss-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libudev1:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-sysv:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), thermald:amd64 (2.4.9-1ubuntu0.3, 2.4.9-1ubuntu0.4) When we switch back to an older version the modem is working again! Downgrade: systemd-timesyncd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libpam-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libsystemd0:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libnss-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd-sysv:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7) So the latest update breaks anything with that modem. The output of lsusb stays the same with both versions: Bus 001 Device 003: ID 12d1:15c1 Huawei Technologies Co., Ltd. ME906s LTE M.2 Module With old packages "ip link" looks like that: 9: wwan0: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000 - link/ether 2e:c4:ac:0a:11:f2 brd ff:ff:ff:ff:ff:ff + link/ether 2e:c4:ac:0a:11:f2 brd ff:ff:ff:ff:ff:ff With new packages "ip link" does not show any wwan0 or similar interface. Other network interfaces are avaiable. + The network interfaces are configured with /etc/network/interfaces: + allow-hotplug wwan0 + iface wwan0 inet dhcp + apn a1.net + metric 100 + + We use modemmanager to connect: + /usr/bin/mmcli --modem 0 --simple-connect="apn=a1.net" + + "mmcli -L" can't find any modems on a upgraded system. + With the previous version we see the Huawei modem: + /org/freedesktop/ModemManager1/Modem/0 [Huawei Technologies Co., Ltd.] HUAWEI Mobile V7R11 + + We have a lot of systems with Huawei LTE modems and that's a serious problem for us! Do you need more information to debug that problem? -- 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/2036427 Title: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module Status in systemd package in Ubuntu: New Bug description: Description: Ubuntu 22.04.3 LTS Release: 22.04 After the latest upgrade our Huawei LTE modem is not working anymore. We can see the modem wie lsusb, but no interfaces gets activated and systemd-networkd-wait-online gets a timeout. The following packages have been upgraded: Upgrade: udev:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-timesyncd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libpam-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libsystemd0:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libnss-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libudev1:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-sysv:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), thermald:amd64 (2.4.9-1ubuntu0.3, 2.4.9-1ubuntu0.4) When we switch back to an older version the modem is working again! Downgrade: systemd-timesyncd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libpam-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libsystemd0:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libnss-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd-sysv:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7) So the latest update breaks anything with that modem. The output of lsusb stays the same with both versions: Bus 001 Device 003: ID 12d1:15c1 Huawei Technologies Co., Ltd. ME906s LTE M.2 Module With old packages "ip link" looks like that: 9: wwan0: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 2e:c4:ac:0a:11:f2 brd ff:ff:ff:ff:ff:ff With new packages "ip link" does not show any wwan0 or similar interface. Other network interfaces are avaiable. The network interfaces are configured with /etc/network/interfaces: allow-hotplug wwan0 iface wwan0 inet dhcp apn a1.net metric 100 We use modemmanager to connect: /usr/bin/mmcli --modem 0 --simple-connect="apn=a1.net" "mmcli -L" can't find any modems
[Touch-packages] [Bug 2036427] Re: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module
this bug affects us too -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2036427 Title: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module Status in systemd package in Ubuntu: New Bug description: Description: Ubuntu 22.04.3 LTS Release: 22.04 After the latest upgrade our Huawei LTE modem is not working anymore. We can see the modem wie lsusb, but no interfaces gets activated and systemd-networkd-wait-online gets a timeout. The following packages have been upgraded: Upgrade: udev:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-timesyncd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libpam-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libsystemd0:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libnss-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libudev1:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-sysv:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), thermald:amd64 (2.4.9-1ubuntu0.3, 2.4.9-1ubuntu0.4) When we switch back to an older version the modem is working again! Downgrade: systemd-timesyncd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libpam-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libsystemd0:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libnss-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd-sysv:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7) So the latest update breaks anything with that modem. The output of lsusb stays the same with both versions: Bus 001 Device 003: ID 12d1:15c1 Huawei Technologies Co., Ltd. ME906s LTE M.2 Module With old packages "ip link" looks like that: 9: wwan0: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 2e:c4:ac:0a:11:f2 brd ff:ff:ff:ff:ff:ff With new packages "ip link" does not show any wwan0 or similar interface. Other network interfaces are avaiable. The network interfaces are configured with /etc/network/interfaces: allow-hotplug wwan0 iface wwan0 inet dhcp apn a1.net metric 100 We use modemmanager to connect: /usr/bin/mmcli --modem 0 --simple-connect="apn=a1.net" "mmcli -L" can't find any modems on a upgraded system. With the previous version we see the Huawei modem: /org/freedesktop/ModemManager1/Modem/0 [Huawei Technologies Co., Ltd.] HUAWEI Mobile V7R11 We have a lot of systems with Huawei LTE modems and that's a serious problem for us! Do you need more information to debug that problem? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036427/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036427] [NEW] Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module
Public bug reported: Description:Ubuntu 22.04.3 LTS Release:22.04 After the latest upgrade our Huawei LTE modem is not working anymore. We can see the modem wie lsusb, but no interfaces gets activated and systemd-networkd-wait-online gets a timeout. The following packages have been upgraded: Upgrade: udev:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-timesyncd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libpam-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libsystemd0:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libnss-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libudev1:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-sysv:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), thermald:amd64 (2.4.9-1ubuntu0.3, 2.4.9-1ubuntu0.4) When we switch back to an older version the modem is working again! Downgrade: systemd-timesyncd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libpam-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libsystemd0:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libnss-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd-sysv:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7) So the latest update breaks anything with that modem. The output of lsusb stays the same with both versions: Bus 001 Device 003: ID 12d1:15c1 Huawei Technologies Co., Ltd. ME906s LTE M.2 Module With old packages "ip link" looks like that: 9: wwan0: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 2e:c4:ac:0a:11:f2 brd ff:ff:ff:ff:ff:ff With new packages "ip link" does not show any wwan0 or similar interface. Other network interfaces are avaiable. We have a lot of systems with Huawei LTE modems and that's a serious problem for us! Do you need more information to debug that problem? ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2036427 Title: Upgrade to version 249.11-0ubuntu3.10 breaks 12d1:15c1 Huawei ME906s LTE M.2 Module Status in systemd package in Ubuntu: New Bug description: Description: Ubuntu 22.04.3 LTS Release: 22.04 After the latest upgrade our Huawei LTE modem is not working anymore. We can see the modem wie lsusb, but no interfaces gets activated and systemd-networkd-wait-online gets a timeout. The following packages have been upgraded: Upgrade: udev:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-timesyncd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libpam-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libsystemd0:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libnss-systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), libudev1:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), systemd-sysv:amd64 (249.11-0ubuntu3.9, 249.11-0ubuntu3.10), thermald:amd64 (2.4.9-1ubuntu0.3, 2.4.9-1ubuntu0.4) When we switch back to an older version the modem is working again! Downgrade: systemd-timesyncd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libpam-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libsystemd0:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), libnss-systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7), systemd-sysv:amd64 (249.11-0ubuntu3.10, 249.11-0ubuntu3.7) So the latest update breaks anything with that modem. The output of lsusb stays the same with both versions: Bus 001 Device 003: ID 12d1:15c1 Huawei Technologies Co., Ltd. ME906s LTE M.2 Module With old packages "ip link" looks like that: 9: wwan0: mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 2e:c4:ac:0a:11:f2 brd ff:ff:ff:ff:ff:ff With new packages "ip link" does not show any wwan0 or similar interface. Other network interfaces are avaiable. We have a lot of systems with Huawei LTE modems and that's a serious problem for us! Do you need more information to debug that problem? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036427/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
If you are using NetworkManager, then systemd-networkd.service (and associated units like systemd-networkd-wait-online.service) should NOT be enabled. With the caveat that I am not sure why you have systemd- networkd enabled in the first place, I would recommend that you simply disable it: $ systemctl disable --now systemd-networkd.service This will also have the effect of disabling systemd-networkd-wait- online.service. -- 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/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: New Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036128] Re: [FFe] enable unprivileged user namespace restrictions by default for mantic
FYI I redid this change again on top of the fix from https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2036302 and have uploaded it to the aforementioned PPA (debdiff is almost identical, except for the different context in debian/changelog) ** Patch added: "apparmor_4.0.0~alpha2-0ubuntu5.debdiff" https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2036128/+attachment/5701789/+files/apparmor_4.0.0~alpha2-0ubuntu5.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2036128 Title: [FFe] enable unprivileged user namespace restrictions by default for mantic Status in apparmor package in Ubuntu: New Bug description: As per https://discourse.ubuntu.com/t/spec-unprivileged-user- namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626, unprivileged user namespace restrictions for Ubuntu 23.10 are to be enabled by default via a sysctl.d conf file in apparmor. In https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2035315 new apparmor profiles were added to the apparmor package for various applications which require unprivileged user namespaces, using a new unconfined profile mode. To support this an additional change was added to the mantic kernel in https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/mantic/commit?h=master- next=7327726a2dbf571e05f7c095916dcce0347790b4 which is still currently unreleased. Without this kernel change, if userns restrictions are enabled the existing policies added above will not actually work to allow them to be used by the various applications. As such we need to ensure that userns restrictions are not enabled via sysctl when this feature is not present / enabled. Whilst it may be possible to capture the dependency logic via `Breaks:` or similar, this would not help in the case that a user booted into an older kernel with the new apparmor userspace package. As such, as well as enabling the sysctl via the sysctl.d conf file, it is proposed to add logic into the apparmor.service systemd unit to check that the kernel supports the aforementioned unconfined profile mode and that it is enabled - and if not then to force disable the userns restrictions sysctl via the following logic: userns_restricted=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns) unconfined_userns=$([ -f /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ] && cat /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns || echo 0) if [ -n "$userns_restricted" ] && [ "$userns_restricted" -eq 1 ]; then if [ "$unconfined_userns" -eq 0 ]; then # userns restrictions rely on unconfined userns to be supported echo "disabling unprivileged userns restrictions since unconfined userns is not supported / enabled" sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 fi fi this allows a local admin to disable the sysctl via the regular sysctl.d conf approach, but to also make sure we don't inadvertently enable it when it is not supported by the kernel. This proposed change has been tested via the QA Regression Testing project, in particular with the specific test added in https://git.launchpad.net/qa-regression- testing/commit/?id=6f2c5ab7c8659174adac772ce0e894328bb5045d This produces the following output, confirming the fallback works as expected on the current mantic kernel (which does not fully support the userns restrictions): --- Running test: './test-apparmor.py' distro: 'Ubuntu 23.10' kernel: '6.5.0-5.5 (Ubuntu 6.5.0-5.5-generic 6.5.0)' arch: 'amd64' init: 'systemd' uid: 0/0 SUDO_USER: 'ubuntu') test_unconfined_userns (__main__.ApparmorTest.test_unconfined_userns) Test that unconfined userns restrictions are applied ... Skipping private tests WARN: kernel rate limiting in effect Disabling ratelimiting until the next reboot. To renable, run: # sysctl -w kernel.printk_ratelimit=5 (enabling userns restrictions) (restarting apparmor) (checking userns restrictions got disabled) ok -- Ran 1 test in 0.232s OK --- Also we can see on a fresh-boot with this new version installed that apparmor.service shows it has disabled the sysctl before loading any profiles even though the conf file has it enabled - and finally we can see that unshare -U works as expected: root@sec-mantic-amd64:~# uptime 07:04:48 up 0 min, 0 user, load average: 0.00, 0.00, 0.00 root@sec-mantic-amd64:~# journalctl -b0 --unit apparmor.service --no-pager Sep 15 07:04:47 sec-mantic-amd64 systemd[1]: Starting apparmor.service - Load AppArmor profiles...
[Touch-packages] [Bug 2036274] Re: Cyrillic characters not spaced correctly when printing with Ubuntu Bold font
** Summary changed: - Printing Ubuntu Bold font - strange symbol + Cyrillic characters not spaced correctly when printing with Ubuntu Bold font ** Changed in: fonts-ubuntu (Ubuntu) Status: Incomplete => New ** Also affects: cups (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/2036274 Title: Cyrillic characters not spaced correctly when printing with Ubuntu Bold font Status in cups package in Ubuntu: New Status in fonts-ubuntu package in Ubuntu: New Bug description: When printing Ubuntu bold font, I got some strange symbols. Ubuntu regular (not bold) is printing as it should. It is the same in .odt, .docx, .pdf., .jpg On the display it is shown as it should. --- ProblemType: Bug ApportVersion: 2.26.1-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Dependencies: DistroRelease: Ubuntu 23.04 InstallationDate: Installed on 2023-09-14 (4 days ago) InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Release amd64 (20230418) Package: fonts-ubuntu 0.863-0ubuntu3 PackageArchitecture: all ProcVersionSignature: Ubuntu 6.2.0-32.32-generic 6.2.16 Tags: wayland-session lunar Uname: Linux 6.2.0-32-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sudo users _MarkForUpload: True --- ProblemType: Bug ApportVersion: 2.26.1-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Dependencies: DistroRelease: Ubuntu 23.04 InstallationDate: Installed on 2023-09-14 (4 days ago) InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Release amd64 (20230418) Package: fonts-ubuntu 0.863-0ubuntu3 PackageArchitecture: all ProcVersionSignature: Ubuntu 6.2.0-32.32-generic 6.2.16 Tags: wayland-session lunar Uname: Linux 6.2.0-32-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sudo users _MarkForUpload: True --- ProblemType: Bug ApportVersion: 2.26.1-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Dependencies: DistroRelease: Ubuntu 23.04 InstallationDate: Installed on 2023-09-14 (4 days ago) InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Release amd64 (20230418) Package: fonts-ubuntu 0.863-0ubuntu3 PackageArchitecture: all ProcVersionSignature: Ubuntu 6.2.0-32.32-generic 6.2.16 Tags: wayland-session lunar Uname: Linux 6.2.0-32-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sudo users _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/2036274/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2035061] Re: uptime -p reports incorrect output after 52 weeks
Hi Andreas,
Regarding output,
non-human-readable output of uptime is not modified.
I had to modify code flow a little bit to not change upminutes and uphours
after initial calculation in case of "-p", thus I hid it under
if(!human_readable).
Code flow for !human_readable should stay exactly as before.
Regarding 60s fix, it looks like it should be a fairly one line change. I
proposed following change
if (upminutes || (!upminutes && uptime_secs < 60)) { // change < to <=
pos += sprintf(buf + pos, "%s%d %s", comma > 0 ? ", " : "", upminutes,
upminutes != 1 ? "minutes" : "minute");
comma += 1;
}
I'll wait for a feedback from upstream
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/2035061
Title:
uptime -p reports incorrect output after 52 weeks
Status in procps package in Ubuntu:
New
Status in procps source package in Focal:
New
Status in procps source package in Jammy:
New
Bug description:
[ Impact ]
uptime -p will provide incorrect data for 24 hours after exactly 52 weeks.
Users and tools utilizing this command will receive example output "up 2 hours"
instead of "up 52 weeks, 2 hours". After 24 hours since 52 weeks, uptime -p
will report "up 1 year" which is correct output.
Issue is already fixed in upstream
https://gitlab.com/procps-ng/procps/-/commit/0496b39876d569fe1cecb76ad5ef212cd14c0374.
Latest procps releases already include this patch (procps 4.0.3 lunar/mantic)
The fix is needed for following set of packages:
procps | 2:3.3.17-6ubuntu2 | jammy
procps | 2:3.3.16-1ubuntu2 | focal
[ Test Plan ]
Reproduction:
UPTIME="31528920 31528800"; mkfifo uptime_fifo; while true; do cat <<<$UPTIME
> uptime_fifo; done & sudo mount -obind uptime_fifo /proc/uptime
uptime -p
Running above commands will result in incorrect uptime output.
Testing:
In attached uptime_test_results file there is modified print_uptime function
which has been used to test multiple corner cases.
[ Where problems could occur ]
Proposed changes modifies output format of "uptime -p". Issue has been
already fixed in latest version of procps package available in lunar/mantic
however older releases are based on different code base and patch cannot be
directly cherry-picked. Due to backport requirements some code of "uptime"
(without -p) has been also changed but this should not impact logic for that
usage.
As the change focuses on modifying "uptime -p" output format any potential
issues will impact this command.
I have also looked for a reverse dependencies on procps package to check for
potential uses of uptime -p, however I was not able to find any. Internally
within procps package this functionality is used in "top" application, however
for that case "uptime" (without -p) is used.
[ Other Info ]
Bug upstream: https://gitlab.com/procps-ng/procps/-/issues/217
Following patch is needed for older releases:
https://gitlab.com/procps-ng/procps/-/commit/0496b39876d569fe1cecb76ad5ef212cd14c0374
Old commit on which upstream patch is based:
https://gitlab.com/procps-ng/procps/-/commit/8827c6763f79f77a126968e200b0e402de7cb749
Small change on top of proposed patch (already included in debdiff):
https://gitlab.com/procps-ng/procps/-/commit/10824b0655f3eeaeac87ae6e4e3881429a237f3e
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/2035061/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2034672] Re: gnome-shell crashed with GLXBadDrawable on startup in a Xorg session
** Changed in: mesa (Ubuntu) Status: In Progress => Fix Committed ** Tags added: fixed-in-mesa-23.3 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2034672 Title: gnome-shell crashed with GLXBadDrawable on startup in a Xorg session Status in Mutter: Fix Released Status in mesa package in Ubuntu: Fix Committed Status in mutter package in Ubuntu: Fix Released Bug description: Mantic 20230907 on Latitude 3320 Crash on boot of the live session ProblemType: Crash DistroRelease: Ubuntu 23.10 Package: gnome-shell 45~rc-0ubuntu1 ProcVersionSignature: Ubuntu 6.3.0-7.7-generic 6.3.5 Uname: Linux 6.3.0-7-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CasperVersion: 1.482 CrashCounter: 1 CurrentDesktop: ubuntu:GNOME Date: Thu Sep 7 08:02:08 2023 DisplayManager: gdm3 ExecutablePath: /usr/bin/gnome-shell ExecutableTimestamp: 1694028853 LiveMediaBuild: Ubuntu 23.10 "Mantic Minotaur" - Daily amd64 (20230907) ProcCmdline: /usr/bin/gnome-shell ProcCwd: /home/ubuntu ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) SHELL=/bin/bash XDG_RUNTIME_DIR= RelatedPackageVersions: mutter-common 45~rc-0ubuntu1 Signal: 5 SourcePackage: gnome-shell StacktraceTop: g_log_structured_array () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 g_log_default_handler () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ?? () from /usr/lib/x86_64-linux-gnu/mutter-13/libmutter-mtk-13.so.0 Title: gnome-shell crashed with signal 5 in g_log_structured_array() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo users separator: To manage notifications about this bug go to: https://bugs.launchpad.net/mutter/+bug/2034672/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2035090] Re: AppArmor Denials when running a task via cron
** Changed in: apparmor (Ubuntu) Status: New => Invalid ** Converted to question: https://answers.launchpad.net/ubuntu/+source/apparmor/+question/707965 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2035090 Title: AppArmor Denials when running a task via cron Status in apparmor package in Ubuntu: Invalid Bug description: Hello, I have a job scheduled via an in-house task scheduler(using cron). The task runs perfectly when it's run manually. But fails when run on the cron. The root user is used to run the task in both scenarios(Manually and Cron). We get the below apparmor denial when the task fails. type=AVC msg=audit(1694139115.620:2843): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="/etc/opt/AntiVir us/AntiVirus" name="docker/lib/overlay2/3b9cad843afb801cac4e4db319b1a764bd2387d2351cedfb1a4da23bcfa6ff6a/diff" pid=30238 comm="clamscan" requested_mask="r" d enied_mask="r" fsuid=0 ouid=0^]FSUID="root" OUID="root" After we add the above denial in the respective profile the task runs seamlessly via cron as well. I would like to understand what could be the cause of this denial. Because in both scenarios we have the same process as well as the same scripts. We are using Debian 10. We have updated the packages i.e., apt-get update to the latest. Also, I added the env command to check the environments used in both scenarios..and below is the output. When run manually: = SHELL=/bin/bash SUDO_GID=33 SUDO_COMMAND=su -s /bin/bash -c python3 -m script.sched_exec --exec --task-id 1234 >/dev/null 2>&1 root SUDO_USER=www-data PWD=/ LOGNAME=root _=/usr/bin/env APACHE_LOG_DIR=/var/log/apache2 HOME=/root USERNAME=root LANG=en_US.UTF-8 APACHE_PID_FILE=/var/run/apache2/apache2.pid USER=root APACHE_RUN_GROUP=www-data APACHE_LOCK_DIR=/var/lock/apache2 SHLVL=2 APACHE_RUN_DIR=/var/run/apache2 APACHE_RUN_USER=www-data PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin SUDO_UID=33 MAIL=/var/mail/root When the task is run, as per task scheduler(cron) below env is used: SHELL=/bin/sh PWD=/root LOGNAME=root _=/usr/bin/env HOME=/root LANG=en_US.UTF-8 SHLVL=1 MAILTO= PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin There is a difference if env... So we wanted to understand the apparmor denial that came here.. Could you guys help us here ? Regards, Shaheena K To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2035090/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
