[Touch-packages] [Bug 2058003] [NEW] Keine Freigabe
Public bug reported: Wenn ich eine grosse Datei in Thunar oder Nautilus lösche wird es auf die Partition nicht um den Anteil gelöscht. ** Affects: tzdata (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu. https://bugs.launchpad.net/bugs/2058003 Title: Keine Freigabe Status in tzdata package in Ubuntu: New Bug description: Wenn ich eine grosse Datei in Thunar oder Nautilus lösche wird es auf die Partition nicht um den Anteil gelöscht. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2058003/+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 1970069] Re: Annoying boot messages interfering with splash screen
I think the delay I'm seeing is a feature of Plymouth, not a bug: "ignoring since we only handle SimpleDRM devices after timeout" As much as I dislike it perpetuating bug 1869655, this feature does prevent bug 2054769 from reoccurring. But this raises the question: is it worth putting i915, amdgpu etc in initrd just to try and solve bug 1869655? Possibly not. -- 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/1970069 Title: Annoying boot messages interfering with splash screen Status in initramfs-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: In Progress Bug description: [ Impact ] Kernel (and systemd) log messages appear during boot for many machines, when the user should be seeing only the BIOS logo and/or Plymouth splash screens. [ Workaround ] On most machines you can hide the problem by using these kernel parameters together: quiet splash loglevel=2 fastboot [ Test Plan ] 1. Boot Ubuntu on a number of laptops that have the problem and verify no console text messages appear during boot. 2. Verify you can switch VTs (e.g. Ctrl + Alt + F4) and log into them still. 3. Reboot Ubuntu and remove the "splash" kernel parameter, now messages should appear. [ Where problems could occur ] Since the fix works by deferring fbcon's takeover of the console, the main problem encountered during its development was the inability to VT switch. [ Original Description ] Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970069/+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 2029473] Re: Backport Ubuntu Pro to Xenial
Hi Andreas, thank you for having a look. 0.96.20.13 was queued to fix autopkgtest failures with 0.96.20.12. Do I need a new SRU bug for that? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2029473 Title: Backport Ubuntu Pro to Xenial Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: Fix Committed Bug description: * Impact We want desktop integration with Ubuntu Pro * Test case - ensure that the machine isn't attached to ubuntu pro (otherwise the screen would not be displayed) and is online $ pro status and `$ pro detach` if needed - $ software-properties-gtk -> the list of tabs should include an 'Ubuntu Pro' one The Ubuntu Pro tab should state 'This machine is not covered by an Ubuntu Pro subscription', display a 'Enable Ubuntu Pro' button and have other controls inactive - click 'Enable Ubuntu Pro' -> A dialog 'Enable Ubuntu Pro' opens -> the first option 'Enter code on ubuntu.com/pro/attach' is selected -> a pincode is displayed under the option - go to http//ubuntu.com/pro/attach and enter the pincode -> after some seconds the software-properties UI should update and display a green mark and 'Valid token' label on the right of the pincode - click 'Confirm' -> you should get an authentification prompt - enter your password -> a spinner starts animating instead of the 'Valid token' label -> once the attachment job is done the dialog is autoclosed -> the UI should now state 'Ubuntu Pro support is enabled', under Security 'ESM Infra', 'ESM Apps' and 'Kernel Livepatch' should be displayed an enabled (or without 'ESM Apps' if you don't have the current ubuntu-advantage-tools) - check that the '$ pro status' output matches the UI one - try enabling/disable options -> verify that the 'pro status' change accordingly - Click 'Disable Ubuntu Pro' -> you get asked for confirmation and password -> confirm that the UI is back to the original state and that 'pro status' confirm the system isn't attached to Ubuntu Pro anymore - Go through the testcase again but selecting the 'Or add token manually' option, the steps should be similar * Regression Potential There could be problems in the UI The new service could be not working as expected Strings are new and currently have no translations The livepatch checkbox is also inactive because the current update- notifier version in xenial doesn't include livepatch support - Ubuntu Pro enables extended support for 10 years for long term support Ubuntu series. Xenial is therefore currently also supported under Ubuntu Pro. Xenial's software-properties-gtk, however, doesn't have the Ubuntu Pro functionality that exists in Bionic, Focal etc. Thus this request to backport the Ubuntu Pro functionality to Xenial. This depends on LP:2029089. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2029473/+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 1869655] Re: Boot animations start too late to be useful
This will get the same initramfs-tools fix as bug 1970069. After that, the only way to make Plymouth start sooner will be to use kernel parameter 'plymouth.use-simpledrm', but we probably don't want that by default so as to avoid regressing on bug 2054769. ** Also affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Changed in: initramfs-tools (Ubuntu) Assignee: (unassigned) => Daniel van Vugt (vanvugt) ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => Low ** Changed in: initramfs-tools (Ubuntu) Status: New => In Progress ** Changed in: grub2 (Ubuntu) Status: Triaged => Invalid ** Changed in: plymouth (Ubuntu) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1869655 Title: Boot animations start too late to be useful Status in Plymouth: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: In Progress Status in plymouth package in Ubuntu: Won't Fix Bug description: Boot animations start too late to be useful Modern systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations. This could be fixed in: grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started and/or plymouth: By preferencing legacy framebuffer devices (like EFI) over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240 completely, and bug 1836858 mostly as the flicker moves to when the login screen starts. To manage notifications about this bug go to: https://bugs.launchpad.net/plymouth/+bug/1869655/+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 2055148] Re: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: netplan.io (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/2055148 Title: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan Status in netplan: New Status in netplan.io package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Bug description: From: https://discourse.ubuntu.com/t/blog-netplan-developer- diaries/35932/11 Hi all, NetworkManager connections with an explicit DoT (DNS over TLS) configuration are not supported with Netplan, but NetworkManager does feed back the DoT DNS info with server address and Server Name Indication (SNI) in the form server_address#SNI, e.g. 1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a result, subsequent Netplan config applications fail because DNS servers don’t have the expected dotted decimal (IPv4) or colon’ed hex (IPv6) form. ``` nmcli> describe ipv4.dns === [dns] === [NM property description] Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server name can be specified by appending "#example.com" to the IP address of the DNS server. This currently only has effect when using systemd-resolved. ``` To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2055148/+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 2055148] Re: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: network-manager (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/2055148 Title: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan Status in netplan: New Status in netplan.io package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Bug description: From: https://discourse.ubuntu.com/t/blog-netplan-developer- diaries/35932/11 Hi all, NetworkManager connections with an explicit DoT (DNS over TLS) configuration are not supported with Netplan, but NetworkManager does feed back the DoT DNS info with server address and Server Name Indication (SNI) in the form server_address#SNI, e.g. 1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a result, subsequent Netplan config applications fail because DNS servers don’t have the expected dotted decimal (IPv4) or colon’ed hex (IPv6) form. ``` nmcli> describe ipv4.dns === [dns] === [NM property description] Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server name can be specified by appending "#example.com" to the IP address of the DNS server. This currently only has effect when using systemd-resolved. ``` To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2055148/+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 1970069] Re: Annoying boot messages interfering with splash screen
Plymouth would still need patching in order to optimize the drm modules in debian/local/plymouth.hook ** Changed in: plymouth (Ubuntu) Status: Invalid => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1970069 Title: Annoying boot messages interfering with splash screen Status in initramfs-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: In Progress Status in systemd package in Ubuntu: In Progress Bug description: [ Impact ] Kernel (and systemd) log messages appear during boot for many machines, when the user should be seeing only the BIOS logo and/or Plymouth splash screens. [ Workaround ] On most machines you can hide the problem by using these kernel parameters together: quiet splash loglevel=2 fastboot [ Test Plan ] 1. Boot Ubuntu on a number of laptops that have the problem and verify no console text messages appear during boot. 2. Verify you can switch VTs (e.g. Ctrl + Alt + F4) and log into them still. 3. Reboot Ubuntu and remove the "splash" kernel parameter, now messages should appear. [ Where problems could occur ] Since the fix works by deferring fbcon's takeover of the console, the main problem encountered during its development was the inability to VT switch. [ Original Description ] Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970069/+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 1197754] Re: print lxc-start-ephemeral container name in a machine-readable way
With 0b4c5056925e7358374874c8bf4767290157e903 (in autopkgtest 5.33) lxc- start-ephemeral is not called anymore. ** Changed in: autopkgtest (Ubuntu) Assignee: (unassigned) => Paride Legovini (paride) ** Changed in: autopkgtest (Ubuntu) Status: Triaged => Fix Committed -- 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/1197754 Title: print lxc-start-ephemeral container name in a machine-readable way Status in autopkgtest package in Ubuntu: Fix Committed Status in lxc package in Ubuntu: Fix Released Bug description: A script cannot call lxc-start-ephemeral and get a named container in a reliable, race-free way. Having the caller specify a name directly is racy, since the name could have been taken in between checking that it doesn't exist already and calling lxc-start-ephemeral. Allowing lxc-start-ephemeral allows it to take care of the mkdir (and retries) to generate an LXC container name in a race free manner, but this needs -d to return the name in a machine-readable way, so that we can create ephemeral LXC containers from scripts. Please add a machine-readable mechanism to "lxc-start-ephemeral -d" and then we can modify adt-virt-lxc to use it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1197754/+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 2057671] Re: Rename the ubuntu-advantage-tools package
Hi Calvin, Thanks for filing the FFe but looking at it closely, this isn't really a new feature but more of a packaging fix. Given that status, please go ahead and upload. +1. :) ** Changed in: software-properties (Ubuntu Noble) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2057671 Title: Rename the ubuntu-advantage-tools package Status in software-properties package in Ubuntu: Triaged Status in software-properties source package in Noble: Triaged Bug description: From ubuntu-advantage-tools v31, it has been renamed to ubuntu-pro- client. The current package is now a transitional package pointing to ubuntu-pro-client. software-properties depends on ubuntu-advantage- tool thus we should rename the dependency to ubuntu-pro-client to avoid having the transitional package as a dependency. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2057671/+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 2058017] [NEW] openssl is not LTO-safe
Public bug reported: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but but we cannot rule out that we're already experiencing miscompilations and compilers are only pushing this further and further. This is impossible to know in advance and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. ** Affects: openssl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: New Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but but we cannot rule out that we're already experiencing miscompilations and compilers are only pushing this further and further. This is impossible to know in advance and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except
[Touch-packages] [Bug 1970069] Re: Annoying boot messages interfering with splash screen
Seems it's fairly easy to make a working solution in initramfs-tools alone, but there's a compromise. If I only include tiny/simple framebuffer drivers in initrd then i915 starts so late that Plymouth doesn't use it, and bug 2054769 can occur on some machines. If I include all the current drm drivers in initrd then it bloats to 100MB, but at least i915 starts early enough (only just) to avoid bug 2054769. I'm currently leaning toward only including tiny/simple framebuffer drivers and trying to solve bug 2054769 with additional heuristics in Plymouth itself (when the physical monitor dimensions are unknown under simpledrm). If nothing else, fixing this bug is more important than fixing bug 2054769 for all cases. -- 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/1970069 Title: Annoying boot messages interfering with splash screen Status in initramfs-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: In Progress Status in systemd package in Ubuntu: In Progress Bug description: [ Impact ] Kernel (and systemd) log messages appear during boot for many machines, when the user should be seeing only the BIOS logo and/or Plymouth splash screens. [ Workaround ] On most machines you can hide the problem by using these kernel parameters together: quiet splash loglevel=3 fastboot [ Original Description ] Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970069/+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 1970069] Re: Annoying boot messages interfering with splash screen
** Description changed: [ Impact ] Kernel (and systemd) log messages appear during boot for many machines, when the user should be seeing only the BIOS logo and/or Plymouth splash screens. [ Workaround ] On most machines you can hide the problem by using these kernel parameters together: - quiet splash loglevel=2 fastboot - - [ Test Plan ] - - 1. Boot Ubuntu on a number of laptops that have the problem and verify no console text messages appear during boot. - 2. Verify you can switch VTs (e.g. Ctrl + Alt + F4) and log into them still. - 3. Reboot Ubuntu and remove the "splash" kernel parameter, now messages should appear. - - [ Where problems could occur ] - - Since the fix works by deferring fbcon's takeover of the console, the - main problem encountered during its development was the inability to VT - switch. + quiet splash loglevel=3 fastboot [ Original Description ] Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1970069 Title: Annoying boot messages interfering with splash screen Status in initramfs-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: In Progress Status in systemd package in Ubuntu: In Progress Bug description: [ Impact ] Kernel (and systemd) log messages appear during boot for many machines, when the user should be seeing only the BIOS logo and/or Plymouth splash screens. [ Workaround ] On most machines you can hide the problem by using these kernel parameters together: quiet splash loglevel=3 fastboot [ Original Description ] Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970069/+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 2056187] Re: fails to configure BOOTIF when using iscsi
** Merge proposal linked:
https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/2056187
Title:
fails to configure BOOTIF when using iscsi
Status in initramfs-tools package in Ubuntu:
Fix Committed
Status in open-iscsi package in Ubuntu:
Invalid
Status in initramfs-tools source package in Jammy:
New
Status in open-iscsi source package in Jammy:
New
Bug description:
we have a bad interaction between initramfs-tools and open-iscsi,
resulting in the boot interface not being configured.
when the iscsi has a static address, the script `local-top/iscsi` from
open-iscsi creates a /run/net-$DEVICE.conf file for the iscsi
interface. The existence of this file makes configure_networking()
skip configuring the BOOTIF later due to this code in
`scripts/functions`:
for x in /run/net-"${DEVICE}".conf /run/net-*.conf ; do
if [ -e "$x" ]; then
IP=done
break
fi
done
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2056187/+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 2056194] Re: Networking broken in early boot on Oracle Native instances due to MTU settings
** Merge proposal linked:
https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/2056194
Title:
Networking broken in early boot on Oracle Native instances due to MTU
settings
Status in cloud-images:
New
Status in cloud-init package in Ubuntu:
Fix Released
Status in initramfs-tools package in Ubuntu:
Fix Committed
Bug description:
BACKGROUND:
cloud-init-local.service runs before networking has started. On non-
Oracle platforms, before networking has come up, cloud-init will
create an ephemeral connection to the cloud's IMDS using DHCP to
retrieve instance metadata. On Oracle, this normally isn't necessary
as we boot with connectivity to the IMDS out of the box. This can be
seen in the following Jammy instance using an SR-IOV NIC:
2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open
'http://169.254.169.254/opc/v2/instance/' with {'url':
'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects':
True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent'
: 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}}
configuration
2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts
2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup,
instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/',
'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5}
2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open
'http://169.254.169.254/opc/v2/instance/' with {'url':
'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects':
True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23
.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration
2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts
Notice the "Skip ephemeral DHCP setup, instance has connectivity".
This means that cloud-init has determined that it already has
connectivity and doesn't need to do any additional setup to retrieve
data from the IMDS.
We can also see the same behavior on a Noble paravirtualized instance:
2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open
'http://169.254.169.254/opc/v2/instance/' with {'url':
'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects':
True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent':
'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}}
configuration
2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts
2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup,
instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/',
'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5}
2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open
'http://169.254.169.254/opc/v2/instance/' with {'url':
'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects':
True, 'method': 'GET', 'headers': {'User-Agent':
'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}}
configuration
2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts
2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to
/run/cloud-init/cloud-id-oracle - wb: [644] 7 bytes
PROBLEM:
On a Noble instance using Hardware-assisted (SR-IOV) networking, this
is not working. cloud-init-local.service no longer has immediate
connectivity to the IMDS. Since it cannot connect, in then attempts to
create an ephemeral connection to the IMDS using DHCP. It is able to
obtain a DHCP lease, but then when it tries to connect to the IMDS,
the call just hangs. The call has no timeout, so this results in an
instance that cannot be logged into even via the serial console
because cloud-init is blocking the rest of boot. A simple cloud-init
workaround is to add something along the lines of `timeout=2` to
https://github.com/canonical/cloud-
init/blob/main/cloudinit/sources/DataSourceOracle.py#L349 . This
allows cloud-init to boot. Looking at the logs, we can see that cloud-
init is unable to connect to the IMDS:
2024-03-05 14:23:54,836 - ephemeral.py[DEBUG]: Received dhcp lease on ens3
for 10.0.0.133/255.255.255.0
2024-03-05 14:23:54,837 - url_helper.py[DEBUG]: [0/3] open
'http://169.254.169.254/opc/v2/instance/' with {'url':
'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects':
True, 'method': 'GET', 'timeout': 2.0, 'headers': {'User-Agent':
'Cloud-Init/24.1
[Touch-packages] [Bug 1970069] Re: Annoying boot messages interfering with splash screen
** Merge proposal linked: https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481 ** Merge proposal linked: https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462482 -- 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/1970069 Title: Annoying boot messages interfering with splash screen Status in initramfs-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: In Progress Status in systemd package in Ubuntu: In Progress Bug description: [ Impact ] Kernel (and systemd) log messages appear during boot for many machines, when the user should be seeing only the BIOS logo and/or Plymouth splash screens. [ Workaround ] On most machines you can hide the problem by using these kernel parameters together: quiet splash loglevel=3 fastboot [ Original Description ] Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970069/+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 2055148] Re: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan
I can confirm the problem. Here is a reproducer: # nmcli con add ifname dummy0 type dummy ipv4.dns 1.1.1.1#lxd Error: Failed to add 'dummy-dummy0' connection: Message recipient disconnected from message bus without replying This is the crash related to this issue: Mar 15 09:46:40 noble-vm NetworkManager[7091]: /etc/netplan/90-NM-2116bb84-fa09-461a-a923-e04bc2648898.yaml:8:9: Error in network definition: malformed address '1.1.1.1#lxd', must be X.X.X.X or X:X:X:X:X:X:X:X Mar 15 09:46:40 noble-vm NetworkManager[7091]: - 1.1.1.1#lxd Mar 15 09:46:40 noble-vm NetworkManager[7091]: ^ Mar 15 09:46:40 noble-vm NetworkManager[7051]: [1710496000.8273] BUG: the profile cannot be stored in keyfile format without becoming unusable: cannot access file: No such file or directory Mar 15 09:46:40 noble-vm NetworkManager[7051]: ** Mar 15 09:46:40 noble-vm NetworkManager[7051]: nm:ERROR:src/core/settings/plugins/keyfile/nms-keyfile-writer.c:551:_internal_write_connection: assertion failed: (unreachable) Mar 15 09:46:40 noble-vm NetworkManager[7051]: Bail out! nm:ERROR:src/core/settings/plugins/keyfile/nms-keyfile-writer.c:551:_internal_write_connection: assertion failed: (unreachable) Mar 15 09:46:40 noble-vm systemd[1]: NetworkManager.service: Main process exited, code=dumped, status=6/ABRT Mar 15 09:46:40 noble-vm systemd[1]: NetworkManager.service: Failed with result 'core-dump'. Mar 15 09:46:41 noble-vm systemd[1]: NetworkManager.service: Scheduled restart job, restart counter is at 1. Mar 15 09:46:41 noble-vm systemd[1]: Starting NetworkManager.service - Network Manager... I also noticed another crash already reported here https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2057490 Mar 15 09:45:30 noble-vm systemd[1]: Stopping NetworkManager.service - Network Manager... Mar 15 09:45:30 noble-vm NetworkManager[6790]: [1710495930.0746] caught SIGTERM, shutting down normally. Mar 15 09:45:30 noble-vm NetworkManager[6790]: ** Mar 15 09:45:30 noble-vm NetworkManager[6790]: nm:ERROR:src/core/nm-policy.c:2937:dispose: assertion failed: (!c_list_is_empty(&priv->policy_auto_activate_lst_head)) Mar 15 09:45:30 noble-vm NetworkManager[6790]: Bail out! nm:ERROR:src/core/nm-policy.c:2937:dispose: assertion failed: (!c_list_is_empty(&priv->policy_auto_activate_lst_head)) Mar 15 09:45:30 noble-vm NetworkManager[6790]: [1710495930.0751] exiting (success) Mar 15 09:45:31 noble-vm systemd[1]: NetworkManager.service: Main process exited, code=dumped, status=6/ABRT Mar 15 09:45:31 noble-vm systemd[1]: NetworkManager.service: Failed with result 'core-dump'. Mar 15 09:45:31 noble-vm systemd[1]: Starting NetworkManager.service - Network Manager... ** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/2055148 Title: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan Status in netplan: New Status in netplan.io package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Bug description: From: https://discourse.ubuntu.com/t/blog-netplan-developer- diaries/35932/11 Hi all, NetworkManager connections with an explicit DoT (DNS over TLS) configuration are not supported with Netplan, but NetworkManager does feed back the DoT DNS info with server address and Server Name Indication (SNI) in the form server_address#SNI, e.g. 1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a result, subsequent Netplan config applications fail because DNS servers don’t have the expected dotted decimal (IPv4) or colon’ed hex (IPv6) form. ``` nmcli> describe ipv4.dns === [dns] === [NM property description] Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server name can be specified by appending "#example.com" to the IP address of the DNS server. This currently only has effect when using systemd-resolved. ``` To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2055148/+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 1869655] Re: Boot animations start too late to be useful
** Merge proposal linked: https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481 ** Merge proposal linked: https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462482 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1869655 Title: Boot animations start too late to be useful Status in Plymouth: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: In Progress Status in plymouth package in Ubuntu: Won't Fix Bug description: Boot animations start too late to be useful Modern systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations. This could be fixed in: grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started and/or plymouth: By preferencing legacy framebuffer devices (like EFI) over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240 completely, and bug 1836858 mostly as the flicker moves to when the login screen starts. To manage notifications about this bug go to: https://bugs.launchpad.net/plymouth/+bug/1869655/+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 2056194] Re: Networking broken in early boot on Oracle Native instances due to MTU settings
** Merge proposal unlinked:
https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/2056194
Title:
Networking broken in early boot on Oracle Native instances due to MTU
settings
Status in cloud-images:
New
Status in cloud-init package in Ubuntu:
Fix Released
Status in initramfs-tools package in Ubuntu:
Fix Committed
Bug description:
BACKGROUND:
cloud-init-local.service runs before networking has started. On non-
Oracle platforms, before networking has come up, cloud-init will
create an ephemeral connection to the cloud's IMDS using DHCP to
retrieve instance metadata. On Oracle, this normally isn't necessary
as we boot with connectivity to the IMDS out of the box. This can be
seen in the following Jammy instance using an SR-IOV NIC:
2024-03-05 14:09:05,351 - url_helper.py[DEBUG]: [0/1] open
'http://169.254.169.254/opc/v2/instance/' with {'url':
'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects':
True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent'
: 'Cloud-Init/23.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}}
configuration
2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts
2024-03-05 14:09:05,362 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup,
instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/',
'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5}
2024-03-05 14:09:05,362 - url_helper.py[DEBUG]: [0/3] open
'http://169.254.169.254/opc/v2/instance/' with {'url':
'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects':
True, 'method': 'GET', 'headers': {'User-Agent': 'Cloud-Init/23
.3.3-0ubuntu0~22.04.1', 'Authorization': 'Bearer Oracle'}} configuration
2024-03-05 14:09:05,368 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/opc/v2/instance/ (200, 2663b) after 1 attempts
Notice the "Skip ephemeral DHCP setup, instance has connectivity".
This means that cloud-init has determined that it already has
connectivity and doesn't need to do any additional setup to retrieve
data from the IMDS.
We can also see the same behavior on a Noble paravirtualized instance:
2024-03-01 20:51:33,482 - url_helper.py[DEBUG]: [0/1] open
'http://169.254.169.254/opc/v2/instance/' with {'url':
'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects':
True, 'method': 'GET', 'timeout': 5.0, 'headers': {'User-Agent':
'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}}
configuration
2024-03-01 20:51:33,488 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts
2024-03-01 20:51:33,488 - ephemeral.py[DEBUG]: Skip ephemeral DHCP setup,
instance has connectivity to {'url': 'http://169.254.169.254/opc/v2/instance/',
'headers': {'Authorization': 'Bearer Oracle'}, 'timeout': 5}
2024-03-01 20:51:33,489 - url_helper.py[DEBUG]: [0/3] open
'http://169.254.169.254/opc/v2/instance/' with {'url':
'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects':
True, 'method': 'GET', 'headers': {'User-Agent':
'Cloud-Init/24.1~7g54599148-0ubuntu1', 'Authorization': 'Bearer Oracle'}}
configuration
2024-03-01 20:51:33,500 - url_helper.py[DEBUG]: Read from
http://169.254.169.254/opc/v2/instance/ (200, 3067b) after 1 attempts
2024-03-01 20:51:33,501 - util.py[DEBUG]: Writing to
/run/cloud-init/cloud-id-oracle - wb: [644] 7 bytes
PROBLEM:
On a Noble instance using Hardware-assisted (SR-IOV) networking, this
is not working. cloud-init-local.service no longer has immediate
connectivity to the IMDS. Since it cannot connect, in then attempts to
create an ephemeral connection to the IMDS using DHCP. It is able to
obtain a DHCP lease, but then when it tries to connect to the IMDS,
the call just hangs. The call has no timeout, so this results in an
instance that cannot be logged into even via the serial console
because cloud-init is blocking the rest of boot. A simple cloud-init
workaround is to add something along the lines of `timeout=2` to
https://github.com/canonical/cloud-
init/blob/main/cloudinit/sources/DataSourceOracle.py#L349 . This
allows cloud-init to boot. Looking at the logs, we can see that cloud-
init is unable to connect to the IMDS:
2024-03-05 14:23:54,836 - ephemeral.py[DEBUG]: Received dhcp lease on ens3
for 10.0.0.133/255.255.255.0
2024-03-05 14:23:54,837 - url_helper.py[DEBUG]: [0/3] open
'http://169.254.169.254/opc/v2/instance/' with {'url':
'http://169.254.169.254/opc/v2/instance/', 'stream': False, 'allow_redirects':
True, 'method': 'GET', 'timeout': 2.0, 'headers': {'User-Agent':
'Cloud-Init/24
[Touch-packages] [Bug 2056187] Re: fails to configure BOOTIF when using iscsi
** Merge proposal unlinked:
https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/2056187
Title:
fails to configure BOOTIF when using iscsi
Status in initramfs-tools package in Ubuntu:
Fix Committed
Status in open-iscsi package in Ubuntu:
Invalid
Status in initramfs-tools source package in Jammy:
New
Status in open-iscsi source package in Jammy:
New
Bug description:
we have a bad interaction between initramfs-tools and open-iscsi,
resulting in the boot interface not being configured.
when the iscsi has a static address, the script `local-top/iscsi` from
open-iscsi creates a /run/net-$DEVICE.conf file for the iscsi
interface. The existence of this file makes configure_networking()
skip configuring the BOOTIF later due to this code in
`scripts/functions`:
for x in /run/net-"${DEVICE}".conf /run/net-*.conf ; do
if [ -e "$x" ]; then
IP=done
break
fi
done
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2056187/+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 1970069] Re: Annoying boot messages interfering with splash screen
https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs- tools/+git/initramfs-tools/+merge/462482 ** Merge proposal unlinked: https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481 -- 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/1970069 Title: Annoying boot messages interfering with splash screen Status in initramfs-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: In Progress Status in systemd package in Ubuntu: In Progress Bug description: [ Impact ] Kernel (and systemd) log messages appear during boot for many machines, when the user should be seeing only the BIOS logo and/or Plymouth splash screens. [ Workaround ] On most machines you can hide the problem by using these kernel parameters together: quiet splash loglevel=3 fastboot [ Original Description ] Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970069/+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 1869655] Re: Boot animations start too late to be useful
** Merge proposal unlinked: https://code.launchpad.net/~vanvugt/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/462481 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1869655 Title: Boot animations start too late to be useful Status in Plymouth: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: In Progress Status in plymouth package in Ubuntu: Won't Fix Bug description: Boot animations start too late to be useful Modern systems spend all their boot time (a couple of seconds) decompressing the kernel. During that time the user only sees the static BIOS logo (ACPI BGRT). Then when Plymouth can finally start animating, the startup process is already finished and there's virtually no time left to show any useful animations. This could be fixed in: grub: By adding a splash under the BIOS logo to show some progress _before_ a Linux kernel is even started and/or plymouth: By preferencing legacy framebuffer devices (like EFI) over DRM, if we find those are available a few seconds sooner. That would also fix bug 1868240 completely, and bug 1836858 mostly as the flicker moves to when the login screen starts. To manage notifications about this bug go to: https://bugs.launchpad.net/plymouth/+bug/1869655/+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 2058017] Re: [FFe] openssl is not LTO-safe
** Summary changed: - openssl is not LTO-safe + [FFe] openssl is not LTO-safe -- 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/2058017 Title: [FFe] openssl is not LTO-safe Status in openssl package in Ubuntu: New Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but but we cannot rule out that we're already experiencing miscompilations and compilers are only pushing this further and further. This is impossible to know in advance and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+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 2058017] Re: [FFe] openssl is not LTO-safe
** Description changed: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. - We don't have specific reports on launchpad at the moment but but we - cannot rule out that we're already experiencing miscompilations and - compilers are only pushing this further and further. This is impossible - to know in advance and even security updates could trigger issues. + We don't have specific reports on launchpad at the moment but there has + been at least one issue experienced by the FIPS: the compiler decided a + 0-filled array could be removed and proceeded to do so. In addition to + that, compilers are only pushing this further and further. Issues are + impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled) + - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. + + I will add results of "openssl speed" soon (in a few hours). -- 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/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: New Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at a
[Touch-packages] [Bug 2058017] Re: openssl is not LTO-safe
** Summary changed: - [FFe] openssl is not LTO-safe + openssl is not LTO-safe -- 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/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: New Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. I will add results of "openssl speed" soon (in a few hours). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+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 2058017] Re: openssl is not LTO-safe
** Merge proposal linked: https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+merge/462486 -- 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/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: New Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. I will add results of "openssl speed" soon (in a few hours). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+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 2056593] Re: [FFE] FIPS compatibility patches
I did some additional tests too in a noble container. With/without the env var to set the file location, including with the file missing, with/without the env var to force FIPS mode, and using values 0, 1, 42, -42, a. By the way, note that access to these environment variables uses secure_getenv(). -- 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/2056593 Title: [FFE] FIPS compatibility patches Status in openssl package in Ubuntu: New Bug description: We have an open MR with a handful of FIPS compatibilty changes we wore hoping to get into 24.04. The main purpose of the changes is to detect whether the kernel is running in FIPS mode and adjust the behavior of the library accordingly by loading the correct provider backend and using defaults that are FIPS compliant (no md5, DES etc) instead trying to use non-compliant code paths and crashing. The proposed patches were taken from the OpenSSL version shipped in the FIPS archive at esm.ubuntu.com for 22.04. Having them in the regular archive will reduce the maintenance work significantly. None of the changes should have any impact on running OpenSSL in regular (non-fips) mode. Below is a detailed list of the changes: - d/p/fips/crypto-Add-kernel-FIPS-mode-detection.patch: This adds a new internal API to determine whether the kernel has been booted in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify an alternative path for the fips_enabled file and is used in tests. The FIPS_MODULE switch can be used to enable build of the the FIPS provider module specific parts which are not needed in the OpenSSL library itself. - d/p/fips/crypto-Automatically-use-the-FIPS-provider-when-the-kerne.patch: This automatically configures all library contexts to use the FIPS provider when the kernel is booted in FIPS mode by: - Setting "fips=yes" as the default property for algorithm fetches - Loading and activating the FIPS provider as the fallback provider. If applications load providers via a configuration either because the default configuration is modified or they override the default configuration, this disables loading of the fallback providers. In this case, the configuration must load the FIPS provider when FIPS mode is enabled, else algorithm fetches will fail Applications can choose to use non-FIPS approved algorithms by specifying the "-fips" or "fips=no" property for algorithm fetches and loading the default provider. - d/p/fips/apps-speed-Omit-unavailable-algorithms-in-FIPS-mode.patch: Omit unavailable algorithms in FIPS mode - d/p/fips/apps-pass-propquery-arg-to-the-libctx-DRBG-fetches.patch The -propquery argument might be used to define a preference for which provider an algorithm is fetched from. Set the query properties for the library context DRBG fetches as well so that they are fetched with the same properties. - d/p/fips/test-Ensure-encoding-runs-with-the-correct-context-during.patch: This test uses 2 library contexts - one context for creating initial test keys, and then another context (or the default context) for running tests. There is an issue that during the encoding tests, the OSSL_ENCODER_CTX is created from the created EVP_PKEYs, which are associated with the library context used to create the keys. This means that encoding tests run with the wrong library context, which always uses the default provider. These changes are now included in a larger MR with other changes in the same package version: https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+merge/462486 The now-superseded MR is at https://code.launchpad.net/~tobhe/ubuntu/+source/openssl/+git/openssl/+merge/460953 Since OpenSSL just received another big update to 3.0.13 we had to rebase our changes and will have to rerun our install/upgrade tests. A test build is also available at https://launchpad.net/~tobhe/+archive/ubuntu/openssl-test/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2056593/+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 2058017] Re: openssl is not LTO-safe
** Changed in: openssl (Ubuntu) Milestone: None => ubuntu-24.04 ** Changed in: openssl (Ubuntu) Assignee: (unassigned) => Adrien Nader (adrien-n) ** Changed in: openssl (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: In Progress Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but there has been at least one issue experienced by the FIPS: the compiler decided a 0-filled array could be removed and proceeded to do so. In addition to that, compilers are only pushing this further and further. Issues are impossible to predict and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these got miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. I will add results of "openssl speed" soon (in a few hours). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+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 2056593] Re: [FFE] FIPS compatibility patches
** Description changed: We have an open MR with a handful of FIPS compatibilty changes we wore hoping to get into 24.04. The main purpose of the changes is to detect whether the kernel is running in FIPS mode and adjust the behavior of the library accordingly by loading the correct provider backend and using defaults that are FIPS compliant (no md5, DES etc) instead trying to use non-compliant code paths and crashing. The proposed patches were taken from the OpenSSL version shipped in the FIPS archive at esm.ubuntu.com for 22.04. Having them in the regular archive will reduce the maintenance work significantly. None of the changes should have any impact on running OpenSSL in regular (non-fips) mode. Below is a detailed list of the changes: - d/p/fips/crypto-Add-kernel-FIPS-mode-detection.patch: - This adds a new internal API to determine whether the kernel has been booted - in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE - environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify an - alternative path for the fips_enabled file and is used in tests. - The FIPS_MODULE switch can be used to enable build of the the FIPS provider - module specific parts which are not needed in the OpenSSL library itself. + This adds a new internal API to determine whether the kernel has been booted + in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE + environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify an + alternative path for the fips_enabled file and is used in tests. + The FIPS_MODULE switch can be used to enable build of the the FIPS provider + module specific parts which are not needed in the OpenSSL library itself. - d/p/fips/crypto-Automatically-use-the-FIPS-provider-when-the-kerne.patch: - This automatically configures all library contexts to use the FIPS provider when - the kernel is booted in FIPS mode by: - - Setting "fips=yes" as the default property for algorithm fetches - - Loading and activating the FIPS provider as the fallback provider. + This automatically configures all library contexts to use the FIPS provider when + the kernel is booted in FIPS mode by: + - Setting "fips=yes" as the default property for algorithm fetches + - Loading and activating the FIPS provider as the fallback provider. - If applications load providers via a configuration either because the default - configuration is modified or they override the default configuration, this - disables loading of the fallback providers. In this case, the configuration - must load the FIPS provider when FIPS mode is enabled, else algorithm fetches - will fail + If applications load providers via a configuration either because the default + configuration is modified or they override the default configuration, this + disables loading of the fallback providers. In this case, the configuration + must load the FIPS provider when FIPS mode is enabled, else algorithm fetches + will fail - Applications can choose to use non-FIPS approved algorithms by specifying the - "-fips" or "fips=no" property for algorithm fetches and loading the default - provider. + Applications can choose to use non-FIPS approved algorithms by specifying the + "-fips" or "fips=no" property for algorithm fetches and loading the default + provider. - d/p/fips/apps-speed-Omit-unavailable-algorithms-in-FIPS-mode.patch: - Omit unavailable algorithms in FIPS mode + Omit unavailable algorithms in FIPS mode - d/p/fips/apps-pass-propquery-arg-to-the-libctx-DRBG-fetches.patch - The -propquery argument might be used to define a preference for which provider - an algorithm is fetched from. Set the query properties for the library context - DRBG fetches as well so that they are fetched with the same properties. + The -propquery argument might be used to define a preference for which provider + an algorithm is fetched from. Set the query properties for the library context + DRBG fetches as well so that they are fetched with the same properties. - d/p/fips/test-Ensure-encoding-runs-with-the-correct-context-during.patch: - This test uses 2 library contexts - one context for creating initial test keys, - and then another context (or the default context) for running tests. There is an - issue that during the encoding tests, the OSSL_ENCODER_CTX is created from the - created EVP_PKEYs, which are associated with the library context used to create - the keys. This means that encoding tests run with the wrong library context, - which always uses the default provider. + This test uses 2 library contexts - one context for creating initial test keys, + and then another context (or the default context) for running tests. There is an + issue that during the encoding tests, the OSSL_ENCODER_CTX is created from the + created EVP_PKEYs, which are asso
[Touch-packages] [Bug 2055148] Re: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan
So, I believe the best solution here would be to add options to DNS addresses, similar to what we do with IP addresses. Something like this nameservers: addresses: - 1.2.3.4: sni: domain port: 1234 interface: eth123 - 1.1.1.1 with this we'd fully support both Network Manager and networkd backends. Right now NM seems to support only the SNI parameter (1.2.3.4#domain) but networkd supports more: "111.222.333.444:9953%ifname#example.com" for IPv4 and "[:::]:9953%ifname#example.com" for IPv6. Alternatively, to keep things simpler, we could just accept the string 1.2.3.4#domain (and possibly the full notation used by networkd too). What do you think, Lukas? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/2055148 Title: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan Status in netplan: New Status in netplan.io package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Bug description: From: https://discourse.ubuntu.com/t/blog-netplan-developer- diaries/35932/11 Hi all, NetworkManager connections with an explicit DoT (DNS over TLS) configuration are not supported with Netplan, but NetworkManager does feed back the DoT DNS info with server address and Server Name Indication (SNI) in the form server_address#SNI, e.g. 1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a result, subsequent Netplan config applications fail because DNS servers don’t have the expected dotted decimal (IPv4) or colon’ed hex (IPv6) form. ``` nmcli> describe ipv4.dns === [dns] === [NM property description] Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server name can be specified by appending "#example.com" to the IP address of the DNS server. This currently only has effect when using systemd-resolved. ``` To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2055148/+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 2029473] Re: Backport Ubuntu Pro to Xenial
Queued where? I don't see it in xenial unapproved. If it's just fixing the autopkgtests, not the software-properties code or anything else in debian/*, then no need for a new SRU bug. Just make sure to build it with the appropriate -v parameter to include all changes since 0.96.20.10 (IIRC). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2029473 Title: Backport Ubuntu Pro to Xenial Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: Fix Committed Bug description: * Impact We want desktop integration with Ubuntu Pro * Test case - ensure that the machine isn't attached to ubuntu pro (otherwise the screen would not be displayed) and is online $ pro status and `$ pro detach` if needed - $ software-properties-gtk -> the list of tabs should include an 'Ubuntu Pro' one The Ubuntu Pro tab should state 'This machine is not covered by an Ubuntu Pro subscription', display a 'Enable Ubuntu Pro' button and have other controls inactive - click 'Enable Ubuntu Pro' -> A dialog 'Enable Ubuntu Pro' opens -> the first option 'Enter code on ubuntu.com/pro/attach' is selected -> a pincode is displayed under the option - go to http//ubuntu.com/pro/attach and enter the pincode -> after some seconds the software-properties UI should update and display a green mark and 'Valid token' label on the right of the pincode - click 'Confirm' -> you should get an authentification prompt - enter your password -> a spinner starts animating instead of the 'Valid token' label -> once the attachment job is done the dialog is autoclosed -> the UI should now state 'Ubuntu Pro support is enabled', under Security 'ESM Infra', 'ESM Apps' and 'Kernel Livepatch' should be displayed an enabled (or without 'ESM Apps' if you don't have the current ubuntu-advantage-tools) - check that the '$ pro status' output matches the UI one - try enabling/disable options -> verify that the 'pro status' change accordingly - Click 'Disable Ubuntu Pro' -> you get asked for confirmation and password -> confirm that the UI is back to the original state and that 'pro status' confirm the system isn't attached to Ubuntu Pro anymore - Go through the testcase again but selecting the 'Or add token manually' option, the steps should be similar * Regression Potential There could be problems in the UI The new service could be not working as expected Strings are new and currently have no translations The livepatch checkbox is also inactive because the current update- notifier version in xenial doesn't include livepatch support - Ubuntu Pro enables extended support for 10 years for long term support Ubuntu series. Xenial is therefore currently also supported under Ubuntu Pro. Xenial's software-properties-gtk, however, doesn't have the Ubuntu Pro functionality that exists in Bionic, Focal etc. Thus this request to backport the Ubuntu Pro functionality to Xenial. This depends on LP:2029089. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2029473/+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 2029473] Re: Backport Ubuntu Pro to Xenial
Ah, software-properties, sorry, I still had update-manager in my mind. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2029473 Title: Backport Ubuntu Pro to Xenial Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: Fix Committed Bug description: * Impact We want desktop integration with Ubuntu Pro * Test case - ensure that the machine isn't attached to ubuntu pro (otherwise the screen would not be displayed) and is online $ pro status and `$ pro detach` if needed - $ software-properties-gtk -> the list of tabs should include an 'Ubuntu Pro' one The Ubuntu Pro tab should state 'This machine is not covered by an Ubuntu Pro subscription', display a 'Enable Ubuntu Pro' button and have other controls inactive - click 'Enable Ubuntu Pro' -> A dialog 'Enable Ubuntu Pro' opens -> the first option 'Enter code on ubuntu.com/pro/attach' is selected -> a pincode is displayed under the option - go to http//ubuntu.com/pro/attach and enter the pincode -> after some seconds the software-properties UI should update and display a green mark and 'Valid token' label on the right of the pincode - click 'Confirm' -> you should get an authentification prompt - enter your password -> a spinner starts animating instead of the 'Valid token' label -> once the attachment job is done the dialog is autoclosed -> the UI should now state 'Ubuntu Pro support is enabled', under Security 'ESM Infra', 'ESM Apps' and 'Kernel Livepatch' should be displayed an enabled (or without 'ESM Apps' if you don't have the current ubuntu-advantage-tools) - check that the '$ pro status' output matches the UI one - try enabling/disable options -> verify that the 'pro status' change accordingly - Click 'Disable Ubuntu Pro' -> you get asked for confirmation and password -> confirm that the UI is back to the original state and that 'pro status' confirm the system isn't attached to Ubuntu Pro anymore - Go through the testcase again but selecting the 'Or add token manually' option, the steps should be similar * Regression Potential There could be problems in the UI The new service could be not working as expected Strings are new and currently have no translations The livepatch checkbox is also inactive because the current update- notifier version in xenial doesn't include livepatch support - Ubuntu Pro enables extended support for 10 years for long term support Ubuntu series. Xenial is therefore currently also supported under Ubuntu Pro. Xenial's software-properties-gtk, however, doesn't have the Ubuntu Pro functionality that exists in Bionic, Focal etc. Thus this request to backport the Ubuntu Pro functionality to Xenial. This depends on LP:2029089. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2029473/+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 2029473] Re: Backport Ubuntu Pro to Xenial
I just looked at the changes, and I would prefer to have a new SRU bug for those, yes please. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2029473 Title: Backport Ubuntu Pro to Xenial Status in software-properties package in Ubuntu: Fix Released Status in software-properties source package in Xenial: Fix Committed Bug description: * Impact We want desktop integration with Ubuntu Pro * Test case - ensure that the machine isn't attached to ubuntu pro (otherwise the screen would not be displayed) and is online $ pro status and `$ pro detach` if needed - $ software-properties-gtk -> the list of tabs should include an 'Ubuntu Pro' one The Ubuntu Pro tab should state 'This machine is not covered by an Ubuntu Pro subscription', display a 'Enable Ubuntu Pro' button and have other controls inactive - click 'Enable Ubuntu Pro' -> A dialog 'Enable Ubuntu Pro' opens -> the first option 'Enter code on ubuntu.com/pro/attach' is selected -> a pincode is displayed under the option - go to http//ubuntu.com/pro/attach and enter the pincode -> after some seconds the software-properties UI should update and display a green mark and 'Valid token' label on the right of the pincode - click 'Confirm' -> you should get an authentification prompt - enter your password -> a spinner starts animating instead of the 'Valid token' label -> once the attachment job is done the dialog is autoclosed -> the UI should now state 'Ubuntu Pro support is enabled', under Security 'ESM Infra', 'ESM Apps' and 'Kernel Livepatch' should be displayed an enabled (or without 'ESM Apps' if you don't have the current ubuntu-advantage-tools) - check that the '$ pro status' output matches the UI one - try enabling/disable options -> verify that the 'pro status' change accordingly - Click 'Disable Ubuntu Pro' -> you get asked for confirmation and password -> confirm that the UI is back to the original state and that 'pro status' confirm the system isn't attached to Ubuntu Pro anymore - Go through the testcase again but selecting the 'Or add token manually' option, the steps should be similar * Regression Potential There could be problems in the UI The new service could be not working as expected Strings are new and currently have no translations The livepatch checkbox is also inactive because the current update- notifier version in xenial doesn't include livepatch support - Ubuntu Pro enables extended support for 10 years for long term support Ubuntu series. Xenial is therefore currently also supported under Ubuntu Pro. Xenial's software-properties-gtk, however, doesn't have the Ubuntu Pro functionality that exists in Bionic, Focal etc. Thus this request to backport the Ubuntu Pro functionality to Xenial. This depends on LP:2029089. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2029473/+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 2058003] Re: Keine Freigabe
Normalerweise landen gelöschte Dateien im Papierkorb. Hast du geprüft, ob diese Dateien noch im Papierkorb liegen? Erst nach dem Löschen aus dem Papierkorb wird der Platz auf der Festplatte frei. ** Changed in: tzdata (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu. https://bugs.launchpad.net/bugs/2058003 Title: Keine Freigabe Status in tzdata package in Ubuntu: Incomplete Bug description: Wenn ich eine grosse Datei in Thunar oder Nautilus lösche wird es auf die Partition nicht um den Anteil gelöscht. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2058003/+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 2051895] Re: Lenovo XT99 BT headset can't work in HFP profile
Hello Hui, or anyone else affected, Accepted pulseaudio into mantic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/pulseaudio/1:16.1+dfsg1-2ubuntu4.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- mantic to verification-done-mantic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-mantic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: pulseaudio (Ubuntu Mantic) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-mantic ** Changed in: pulseaudio (Ubuntu Jammy) Status: In Progress => Fix Committed ** Tags added: verification-needed-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2051895 Title: Lenovo XT99 BT headset can't work in HFP profile Status in HWE Next: New Status in pulseaudio package in Ubuntu: Fix Committed Status in pulseaudio source package in Jammy: Fix Committed Status in pulseaudio source package in Mantic: Fix Committed Status in pulseaudio source package in Noble: Fix Committed Bug description: [Summary] When use the ThinkPluse xt99 bluetooth head set to run the test com.canonical.certification::bluetooth/audio_record_playback, it cannot record the sound and playback. It seems this device cannot switch to Hand free mode in this platform. [Steps to reproduce] Connect the ThinkPluse xt99, use the Handfree mode, then try to record some voice. [Expected result] The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound. [Actual result] The bluetooth headset xt99 cannot work in the Handfree mode. [Failure rate] 100% [Impact] With the current Ubuntu 22.04 oem image, we try to connect the LENOVO XT99 bt headset and let it work in HFP mode, we select HFP profile from gnome sound-setting, but the microphone will not auto change to bt microphone and the bt output could not work too. So this BT headset could only work in A2DP mode with the current 22.04 OEM image. And we tried ubuntu 22.04 generic image, mantic image and noble image, none of them could make the headset work in HFP mode. [Fix] Cherry-pick a pulseaudio commit from upstream. [Test] I installed ubuntu 22.04 and 23.10 on 2 different Thinkpad laptops, then upgraded the pulseaudio from my ppa (ppa:hui.wang/pa-testing), in theory my change only affects bluetooth audio devices, it will not bring any impact to non-audio bluetooth devices, here I did the test with 7 bluetooth audio devices and 2 non-audio devices: BT audio devices (pairing, connection, re-connection, playback and capture all worked well): PLT_BBTGO2 (headset) Xiaomi Air3 SE (headset) Crusher Wireless (headset) SOAIY S18 (sound box) HK Soho Wireless (headset) Thinkplus XT99 (headset) Wl-1000X (headset) BT non-audio devices (pairing, connection, re-connection, key input all worked well): BT3.0 Keyboard The Pinao 2 keyboard [Where problems could occur] This change will impact bt headset negotiation process in the pulseaudio, so the possiblity of regression is limited to bt headset, it could make the bt headset fail to connect, but this possibility is very low, we tested the patch with different bt headset and bt speaker, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2051895/+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 2051895] Please test proposed package
Hello Hui, or anyone else affected, Accepted pulseaudio into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/pulseaudio/1:15.99.1+dfsg1-1ubuntu2.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-jammy. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2051895 Title: Lenovo XT99 BT headset can't work in HFP profile Status in HWE Next: New Status in pulseaudio package in Ubuntu: Fix Committed Status in pulseaudio source package in Jammy: Fix Committed Status in pulseaudio source package in Mantic: Fix Committed Status in pulseaudio source package in Noble: Fix Committed Bug description: [Summary] When use the ThinkPluse xt99 bluetooth head set to run the test com.canonical.certification::bluetooth/audio_record_playback, it cannot record the sound and playback. It seems this device cannot switch to Hand free mode in this platform. [Steps to reproduce] Connect the ThinkPluse xt99, use the Handfree mode, then try to record some voice. [Expected result] The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound. [Actual result] The bluetooth headset xt99 cannot work in the Handfree mode. [Failure rate] 100% [Impact] With the current Ubuntu 22.04 oem image, we try to connect the LENOVO XT99 bt headset and let it work in HFP mode, we select HFP profile from gnome sound-setting, but the microphone will not auto change to bt microphone and the bt output could not work too. So this BT headset could only work in A2DP mode with the current 22.04 OEM image. And we tried ubuntu 22.04 generic image, mantic image and noble image, none of them could make the headset work in HFP mode. [Fix] Cherry-pick a pulseaudio commit from upstream. [Test] I installed ubuntu 22.04 and 23.10 on 2 different Thinkpad laptops, then upgraded the pulseaudio from my ppa (ppa:hui.wang/pa-testing), in theory my change only affects bluetooth audio devices, it will not bring any impact to non-audio bluetooth devices, here I did the test with 7 bluetooth audio devices and 2 non-audio devices: BT audio devices (pairing, connection, re-connection, playback and capture all worked well): PLT_BBTGO2 (headset) Xiaomi Air3 SE (headset) Crusher Wireless (headset) SOAIY S18 (sound box) HK Soho Wireless (headset) Thinkplus XT99 (headset) Wl-1000X (headset) BT non-audio devices (pairing, connection, re-connection, key input all worked well): BT3.0 Keyboard The Pinao 2 keyboard [Where problems could occur] This change will impact bt headset negotiation process in the pulseaudio, so the possiblity of regression is limited to bt headset, it could make the bt headset fail to connect, but this possibility is very low, we tested the patch with different bt headset and bt speaker, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2051895/+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 2058035] [NEW] [SRU] Create directories for apt configuration files if they are absent
Public bug reported: Impact -- The autopkgtest for 0.96.20.12, which introduces Ubuntu Pro in Xenial's software-properties, failed on Dbus tests[1]. The failure is because, at some point in time, the .keep file were removed from the otherwise empty tests/aptroot/etc/apt/apt.conf.d/. This caused the Git repository to drop tests/aptroot/etc/apt/apt.conf.d/ and also its parent, which also became empty, and the tests try to directly create files in those directories, raising the error. It seems that previous uploaders did not use the Git checkout, as the offending commit was introduced in Jun 2019 and there were subsequent uploads that did contain those empty directories. Test case - Trigger an autopkgtest against the proposed package version. It must succeed. Regression Potential Although the introduced change is idempotent, there could be other part of the code assuming the directories didn't exist and trying to create them with a "fail if already exists" approach, causing a runtime regression. [1] https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest- xenial/xenial/amd64/s/software-properties/20240301_100314_9e242@/log.gz ** Affects: software-properties (Ubuntu) Importance: Low Assignee: Nathan Teodosio (nteodosio) Status: In Progress ** Affects: software-properties (Ubuntu Xenial) Importance: High Assignee: Nathan Teodosio (nteodosio) Status: New ** Also affects: software-properties (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: software-properties (Ubuntu Xenial) Importance: Undecided => High ** Changed in: software-properties (Ubuntu Xenial) Assignee: (unassigned) => Nathan Teodosio (nteodosio) ** Merge proposal linked: https://code.launchpad.net/~nteodosio/software-properties/+git/software-properties/+merge/461724 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2058035 Title: [SRU] Create directories for apt configuration files if they are absent Status in software-properties package in Ubuntu: In Progress Status in software-properties source package in Xenial: New Bug description: Impact -- The autopkgtest for 0.96.20.12, which introduces Ubuntu Pro in Xenial's software-properties, failed on Dbus tests[1]. The failure is because, at some point in time, the .keep file were removed from the otherwise empty tests/aptroot/etc/apt/apt.conf.d/. This caused the Git repository to drop tests/aptroot/etc/apt/apt.conf.d/ and also its parent, which also became empty, and the tests try to directly create files in those directories, raising the error. It seems that previous uploaders did not use the Git checkout, as the offending commit was introduced in Jun 2019 and there were subsequent uploads that did contain those empty directories. Test case - Trigger an autopkgtest against the proposed package version. It must succeed. Regression Potential Although the introduced change is idempotent, there could be other part of the code assuming the directories didn't exist and trying to create them with a "fail if already exists" approach, causing a runtime regression. [1] https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest- xenial/xenial/amd64/s/software- properties/20240301_100314_9e242@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2058035/+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 2047447] Re: No valid source.list found while upgrading from mantic to noble
I can confirm that putting aside vscode.list allowed me to do the upgrade Thanks Xavier -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/2047447 Title: No valid source.list found while upgrading from mantic to noble Status in python-apt package in Ubuntu: Fix Released Status in ubuntu-release-upgrader package in Ubuntu: Invalid Status in python-apt source package in Mantic: Confirmed Status in ubuntu-release-upgrader source package in Mantic: Invalid Bug description: Checking package manager Reading package lists... Done Building dependency tree... Done Reading state information... Done Hit http://fr.archive.ubuntu.com/ubuntu mantic InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-updates InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-security InRelease Hit http://fr.archive.ubuntu.com/ubuntu mantic-backports InRelease Hit https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu lunar InRelease Fetched 0 B in 0s (0 B/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done Checking for installed snaps Calculating snap size requirements Updating repository information No valid sources.list entry found While scanning your repository information no entry about mantic could be found. An upgrade might not succeed. Do you want to continue anyway? Continue [yN] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/2047447/+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 2058035] Re: [SRU] Create directories for apt configuration files if they are absent
** Merge proposal linked: https://code.launchpad.net/~nteodosio/software-properties/+git/software-properties/+merge/462501 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2058035 Title: [SRU] Create directories for apt configuration files if they are absent Status in software-properties package in Ubuntu: In Progress Status in software-properties source package in Xenial: New Bug description: Impact -- The autopkgtest for 0.96.20.12, which introduces Ubuntu Pro in Xenial's software-properties, failed on Dbus tests[1]. The failure is because, at some point in time, the .keep file were removed from the otherwise empty tests/aptroot/etc/apt/apt.conf.d/. This caused the Git repository to drop tests/aptroot/etc/apt/apt.conf.d/ and also its parent, which also became empty, and the tests try to directly create files in those directories, raising the error. It seems that previous uploaders did not use the Git checkout, as the offending commit was introduced in Jun 2019 and there were subsequent uploads that did contain those empty directories. Test case - Trigger an autopkgtest against the proposed package version. It must succeed. Regression Potential Although the introduced change is idempotent, there could be other part of the code assuming the directories didn't exist and trying to create them with a "fail if already exists" approach, causing a runtime regression. [1] https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest- xenial/xenial/amd64/s/software- properties/20240301_100314_9e242@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2058035/+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 2057687] Re: systemctl hibernate error: "Call to Hibernate failed: Invalid argument"
Somehow this was fixed for me by the following (almost random) sequence of steps: 1. remove resume/resume_offset kernel parameters from /etc/default/grub 2. update-grub, reboot: hibernate options appear in ubuntu shutdown menu 3. hibernate: works, no more "invalid argument" error. 4. resume(power on): not works - just regular power on. Tried several times. 5. return resume/resume_offset kernel parameters back to /etc/default/grub. 6. initramfs -c -k all : maybe this fixed it? (should not be necessary to do) 7. update-grub 8. hibernate 9. resume: works (!) -- 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/2057687 Title: systemctl hibernate error: "Call to Hibernate failed: Invalid argument" Status in systemd package in Ubuntu: Confirmed Bug description: After upgrading systemd to 255(255.2-3ubuntu2) hibernate stopped working. Trying to hibernate: systemctl hibernate I get: Call to Hibernate failed: Invalid argument systemctl status systemd-hibernate.service - × systemd-hibernate.service - Hibernate Loaded: loaded (/usr/lib/systemd/system/systemd-hibernate.service; static) Active: failed (Result: exit-code) since Tue 2024-03-12 18:48:12 MSK; 1min 33s ago Docs: man:systemd-hibernate.service(8) Process: 4473 ExecStart=/usr/lib/systemd/systemd-sleep hibernate (code=exited, status=1/FAILURE) Main PID: 4473 (code=exited, status=1/FAILURE) CPU: 5ms мар 12 18:48:12 ASUSPRO-P3540FA systemd[1]: Starting systemd-hibernate.service - Hibernate... мар 12 18:48:12 ASUSPRO-P3540FA systemd-sleep[4473]: Failed to find location to hibernate to: Invalid argument мар 12 18:48:12 ASUSPRO-P3540FA systemd[1]: systemd-hibernate.service: Main process exited, code=exited, status=1/FAILURE мар 12 18:48:12 ASUSPRO-P3540FA systemd[1]: systemd-hibernate.service: Failed with result 'exit-code'. мар 12 18:48:12 ASUSPRO-P3540FA systemd[1]: Failed to start systemd-hibernate.service - Hibernate. -- Previous version (254.x) worked: swapfile(on EXT4 fs) is used to hibernate/resume, resume with resume_offset kernel parameters. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2057687/+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 2057996] Re: ubuntu-24.04 version: cmd-curthooks/:Fail:Installing packages on target system:efibootmgr, grub-efi-amd64-signed, nvme-cli, nvme-stas, shim-signed
** Also affects: ubuntu-meta (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/2057996
Title:
ubuntu-24.04 version: cmd-curthooks/:Fail:Installing packages on
target system:efibootmgr, grub-efi-amd64-signed,nvme-cli,nvme-
stas,shim-signed
Status in subiquity package in Ubuntu:
New
Status in ubuntu-meta package in Ubuntu:
New
Bug description:
verison：ubuntu 24.04 subiquity version
OS:noble-live-server-amd64-0222.iso
CPU:AMD EPYC 9634 84-Core Processor*1
MEMORY: M321R2GA3BB6-CQKVG*2
ThinkSystem E1.S 5.9mm 7450 PRO 3.84TB Read Intensive NVMe PCIe 4.0 x4 HS SSD
UEFI MODE
lsb_release -rd: Description:Untun Noble Numbat(development branch)
Release: 24.04
What you expected to happen:
Install os on nvme,expected to install succefully.
What happened instead:
Install os on nvme, install always failed.
Before installation, we cleaned up all our nvme disk by dd if=/dev/zero
of=/dev/sda bs=1M count=5
The error log:
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: finish:
cmd-install/stage-curthooks/builtin/cmd-curthooks: FAIL: Installing packages on
target system: ['efibootmgr', 'grub-efi-amd64', 'grub-efi-amd64-signed',
'nvme-cli', 'nvme-stas', 'shim-signed']
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: finish:
cmd-install/stage-curthooks/builtin/cmd-curthooks/installing-missing-packages:
FAIL: installing missing packages
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: finish:
cmd-install/stage-curthooks/builtin/cmd-curthooks: FAIL: curtin command
curthooks
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: Traceback
(most recent call last):
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: File
"/snap/subiquity/5511/lib/python3.10/site-packages/curtin/commands/main.py",
line 202, in main
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: ret =
args.func(args)
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: File
"/snap/subiquity/5511/lib/python3.10/site-packages/curtin/commands/curthooks.py",
line 1998, in curthooks
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]:
builtin_curthooks(cfg, target, state)
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: File
"/snap/subiquity/5511/lib/python3.10/site-packages/curtin/commands/curthooks.py",
line 1803, in builtin_curthooks
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]:
install_missing_packages(cfg, target, osfamily=osfamily)
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: File
"/snap/subiquity/5511/lib/python3.10/site-packages/curtin/commands/curthooks.py",
line 1362, in install_missing_packages
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]:
distro.install_packages(to_add, target=target, osfamily=osfamily)
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: File
"/snap/subiquity/5511/lib/python3.10/site-packages/curtin/distro.py", line 472,
in install_packages
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: return
install_cmd('install', args=pkglist, opts=opts, target=target,
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: File
"/snap/subiquity/5511/lib/python3.10/site-packages/curtin/distro.py", line 254,
in run_apt_command
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: cmd_rv =
apt_install(mode, args, opts=opts, env=env, target=target,
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: File
"/snap/subiquity/5511/lib/python3.10/site-packages/curtin/distro.py", line 302,
in apt_install
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: cmd_rv =
inchroot.subp(cmd + dl_opts + packages, env=env,
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: File
"/snap/subiquity/5511/lib/python3.10/site-packages/curtin/util.py", line 791,
in subp
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: return
subp(*args, **kwargs)
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: File
"/snap/subiquity/5511/lib/python3.10/site-packages/curtin/util.py", line 283,
in subp
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: return
_subp(*args, **kwargs)
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: File
"/snap/subiquity/5511/lib/python3.10/site-packages/curtin/util.py", line 147,
in _subp
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]: raise
ProcessExecutionError(stdout=out, stderr=err,
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[6373]:
curtin.util.ProcessExecutionError: Unexpected error while running command.
Mar 15 03:03:05 ubuntu-server subiquity_log.4279[637
[Touch-packages] [Bug 2046844] Re: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP
Erich Eickmeyer, I don't have a Tuxedo Computer to test, so could you
please check if the following profile works for you?
$ echo "# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"
abi ,
include
profile tuxedo-control-center /opt/tuxedo-control-center/tuxedo-control-center
flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}" | sudo tee /etc/apparmor.d/tuxedo-control-center
$ sudo apparmor_parser /etc/apparmor.d/tuxedo-control-center
and restart tuxedo-control-center.
--
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/2046844
Title:
AppArmor user namespace creation restrictions cause many applications
to crash with SIGTRAP
Status in AppArmor:
New
Status in akonadiconsole package in Ubuntu:
Fix Released
Status in akregator package in Ubuntu:
Fix Released
Status in angelfish package in Ubuntu:
Fix Released
Status in apparmor package in Ubuntu:
Fix Released
Status in bubblewrap package in Ubuntu:
Confirmed
Status in cantor package in Ubuntu:
Fix Released
Status in devhelp package in Ubuntu:
Fix Released
Status in digikam package in Ubuntu:
Fix Released
Status in epiphany-browser package in Ubuntu:
Fix Released
Status in evolution package in Ubuntu:
Fix Released
Status in falkon package in Ubuntu:
Fix Released
Status in firefox package in Ubuntu:
Confirmed
Status in freecad package in Ubuntu:
Confirmed
Status in geary package in Ubuntu:
Confirmed
Status in ghostwriter package in Ubuntu:
Fix Released
Status in gnome-packagekit package in Ubuntu:
Confirmed
Status in goldendict-webengine package in Ubuntu:
Confirmed
Status in kalgebra package in Ubuntu:
Fix Released
Status in kchmviewer package in Ubuntu:
Confirmed
Status in kdeplasma-addons package in Ubuntu:
Fix Released
Status in kgeotag package in Ubuntu:
Fix Released
Status in kiwix package in Ubuntu:
Confirmed
Status in kmail package in Ubuntu:
Fix Released
Status in konqueror package in Ubuntu:
Fix Released
Status in kontact package in Ubuntu:
Fix Released
Status in loupe package in Ubuntu:
Confirmed
Status in marble package in Ubuntu:
Fix Released
Status in notepadqq package in Ubuntu:
Confirmed
Status in opam package in Ubuntu:
Fix Released
Status in pageedit package in Ubuntu:
Confirmed
Status in plasma-desktop package in Ubuntu:
Fix Released
Status in plasma-welcome package in Ubuntu:
Fix Released
Status in privacybrowser package in Ubuntu:
Confirmed
Status in qmapshack package in Ubuntu:
Confirmed
Status in qutebrowser package in Ubuntu:
Confirmed
Status in rssguard package in Ubuntu:
Confirmed
Status in steam package in Ubuntu:
Fix Released
Status in supercollider package in Ubuntu:
Confirmed
Status in tellico package in Ubuntu:
Fix Released
Bug description:
Hi, I run Ubuntu development branch 24.04 and I have a problem with
Epiphany browser 45.1-1 (Gnome Web): program doesn't launch, and I get
this error
$ epiphany
bwrap: Creating new namespace failed: Permission denied
** (epiphany:12085): ERROR **: 14:44:35.023: Failed to fully launch
dbus-proxy: Le processus fils s’est terminé avec le code 1
Trappe pour point d'arrêt et de trace (core dumped)
$ epiphany
bwrap: Creating new namespace failed: Permission denied
** (epiphany:30878): ERROR **: 22:22:26.926: Failed to fully launch
dbus-proxy: Le processus fils s’est terminé avec le code 1
Trappe pour point d'arrêt et de trace (core dumped)
Thanks for your help!
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/2046844/+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 2049995] Re: System volume doesn't change volume
** Changed in: alsa-driver (Ubuntu) Status: Confirmed => Fix Released -- 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/2049995 Title: System volume doesn't change volume Status in alsa-driver package in Ubuntu: Fix Released Bug description: Hi, as described here https://askubuntu.com/questions/1487030/system- volume-doesnt-change-app-volume, I also have this problem. I've already tried to boot with a Manjaro USB live with Gnome and there the volume works as expected. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 6.5.0-14.14-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: japimentel 8590 F wireplumber /dev/snd/controlC0: japimentel 8590 F wireplumber /dev/snd/seq:japimentel 8580 F pipewire CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Jan 21 10:28:26 2024 InstallationDate: Installed on 2023-11-21 (61 days ago) InstallationMedia: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/12/2023 dmi.bios.release: 1.21 dmi.bios.vendor: LENOVO dmi.bios.version: MLCN21WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: No DPK dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Yoga Pro 7 14APH8 dmi.ec.firmware.release: 1.21 dmi.modalias: dmi:bvnLENOVO:bvrMLCN21WW:bd07/12/2023:br1.21:efr1.21:svnLENOVO:pn82Y8:pvrYogaPro714APH8:rvnLENOVO:rnLNVNB161216:rvrNoDPK:cvnLENOVO:ct10:cvrYogaPro714APH8:skuLENOVO_MT_82Y8_BU_idea_FM_YogaPro714APH8: dmi.product.family: Yoga Pro 7 14APH8 dmi.product.name: 82Y8 dmi.product.sku: LENOVO_MT_82Y8_BU_idea_FM_Yoga Pro 7 14APH8 dmi.product.version: Yoga Pro 7 14APH8 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2049995/+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 2052137] Re: bonded link goes down on reconfigure
Bump this is also affecting us causing quite a lot of downtime just to add a vlan interface -- 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/2052137 Title: bonded link goes down on reconfigure Status in systemd: Fix Released Status in netplan.io package in Ubuntu: Invalid Status in systemd package in Ubuntu: Triaged Bug description: systemd-networkd brings down member interfaces of a bond when they get reconfigured Jan 31 15:43:46 unique-slug systemd-networkd[2430]: pn1: Bringing link down This has a result that a server has complete downtime for a few seconds, this has also been reported upstream https://github.com/systemd/systemd/issues/31165. A pull request has been opened to fix this https://github.com/systemd/systemd/pull/31172 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/2052137/+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 2058053] [NEW] Change sudo compile options from --with-all-insults to --with-pc-insults
Public bug reported: Tame as they might be, I'd like to continue using "Defaults insults" without any risk of upsetting anyone (and without having to maintain our own package version.) Would the safe insults version at compile time "--with-pc-insults" be a sensible default for all? Current as of Jammy, but looks like it's still the default compile option across the board Version: 1.9.9-1ubuntu2 Current behaviour : Enabling includes the "not PC" insults Expected behaviour : Insults would default to "PC" ** Affects: sudo (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/2058053 Title: Change sudo compile options from --with-all-insults to --with-pc- insults Status in sudo package in Ubuntu: New Bug description: Tame as they might be, I'd like to continue using "Defaults insults" without any risk of upsetting anyone (and without having to maintain our own package version.) Would the safe insults version at compile time "--with-pc-insults" be a sensible default for all? Current as of Jammy, but looks like it's still the default compile option across the board Version: 1.9.9-1ubuntu2 Current behaviour : Enabling includes the "not PC" insults Expected behaviour : Insults would default to "PC" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/2058053/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
** Merge proposal linked:
https://code.launchpad.net/~ahasenack/ubuntu/+source/openssh/+git/openssh/+merge/462514
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Status in openssh source package in Jammy:
In Progress
Status in openssh source package in Mantic:
In Progress
Status in openssh source package in Noble:
In Progress
Bug description:
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and
the Technical Board
* and address these questions in advance
[ Original Description ]
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
** Description changed:
- The Authmethod struct now have 4 entries but the initialization of the
- method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
+ [ Impact ]
+
+ * An explanation of the effects of the bug on users and
+
+ * justification for backporting the fix to the stable release.
+
+ * In addition, it is helpful, but not required, to include an
+explanation of how the upload fixes this bug.
+
+ [ Test Plan ]
+
+ * detailed instructions how to reproduce the bug
+
+ * these should allow someone who is not familiar with the affected
+package to reproduce the bug and verify that the updated package fixes
+the problem.
+
+ * if other testing is appropriate to perform before landing this update,
+this should also be described here.
+
+ [ Where problems could occur ]
+
+ * Think about what the upload changes in the software. Imagine the change is
+wrong or breaks something else: how would this show up?
+
+ * It is assumed that any SRU candidate patch is well-tested before
+upload and has a low overall risk of regression, but it's important
+to make the effort to think about what ''could'' happen in the
+event of a regression.
+
+ * This must '''never''' be "None" or "Low", or entirely an argument as to why
+your upload is low risk.
+
+ * This both shows the SRU team that the risks have been considered,
+and provides guidance to testers in regression-testing the SRU.
+
+ [ Other Info ]
+
+ * Anything else you think is useful to include
+ * Anticipate questions from users, SRU, +1 maintenance, security teams and
the Technical Board
+ * and address these questions in advance
+
+
+ [ Original Description ]
+
+
+ The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
-
- struct Authmethod {
- char*name;
+
+ struct Authmethod {
+ char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
- int *enabled;
- };
+ int *enabled;
+ };
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
-
This is now (change from Focal) causing gssapi-keyex to be disabled.
-
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
- Installed: 1:8.9p1-3ubuntu0.6
- Candidate: 1:8.9p1-3ubuntu0.6
- Version table:
- *** 1:8.9p1-3ubuntu0.6 500
- 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
- 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
- 100 /var/lib/dpkg/status
- 1:8.9p1-3 500
- 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
+ Installed: 1:8.9p1-3ubuntu0.6
+ Candidate: 1:8.9p1-3ubuntu0.6
+ Version table:
+ *** 1:8.9p1-3ubuntu0.6 500
+ 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
+ 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
+ 100 /var/lib/dpkg/status
+ 1:8.9p1-3 500
+ 500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Status in openssh source package in Jammy:
In Progress
Status in openssh source package in Mantic:
In Progress
Status in openssh source package in Noble:
In Progress
Bug description:
[ Impact ]
The gssapi-keyex authentication mechanism has been inadvertently
broken in openssh. It comes from a distro patch[1], and while the
patch still applied, it was no longer correct.
Without the fix, sshd will fail to start if gssapi-keyex is listed in
the AuthenticationMethods of the server, and if not, sshd will still
start, but gssapi-keyex will not be available.
[ Test Plan ]
This update adds a new autopkgtest to the package, which tests both
gssapi-with-mic ("normal" gssapi, which is not affected by this bug),
and gssapi-keyex, which, before this update, does not work.
The test plan is to run the new ssh-gssapi autopkgtest and verify it
succeeds.
[ Where problems could
[Touch-packages] [Bug 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
** Description changed:
[ Impact ]
- * An explanation of the effects of the bug on users and
+ The gssapi-keyex authentication mechanism has been inadvertently broken
+ in openssh. It comes from a distro patch[1], and while the patch still
+ applied, it was no longer correct.
- * justification for backporting the fix to the stable release.
+ Without the fix, sshd will fail to start if gssapi-keyex is listed in
+ the AuthenticationMethods of the server, and if not, sshd will still
+ start, but gssapi-keyex will not be available.
- * In addition, it is helpful, but not required, to include an
-explanation of how the upload fixes this bug.
[ Test Plan ]
- * detailed instructions how to reproduce the bug
+ This update adds a new autopkgtest to the package, which tests both
+ gssapi-with-mic ("normal" gssapi, which is not affected by this bug),
+ and gssapi-keyex, which, before this update, does not work.
- * these should allow someone who is not familiar with the affected
-package to reproduce the bug and verify that the updated package fixes
-the problem.
+ The test plan is to run the new ssh-gssapi autopkgtest and verify it
+ succeeds.
- * if other testing is appropriate to perform before landing this update,
-this should also be described here.
[ Where problems could occur ]
- * Think about what the upload changes in the software. Imagine the change is
-wrong or breaks something else: how would this show up?
+ ssh is a critical piece of infrastructure, and problems with it could
+ have catastrophic consequences. The service itself has a test command
+ before it starts up to verify the syntax of the config file, but that
+ test is not applied on shutdown, so a restart with an invalid config
+ file could still leave sshd dead.
- * It is assumed that any SRU candidate patch is well-tested before
-upload and has a low overall risk of regression, but it's important
-to make the effort to think about what ''could'' happen in the
-event of a regression.
+ The patch adds a change to an authentication structure, but that change
+ is already present in the upstream code, and we are just updating it in
+ the new gssapi-keyex code (introduced by the distro[1] patch, already
+ present). Therefore, mistakes here should manifest themselves just in
+ the gssapi-keyex code, which wasn't working anyway. Effectively, though,
+ we are enabling a new authentication mechanism in sshd, one that was not
+ supposed to have been removed, but was broken by mistake.
- * This must '''never''' be "None" or "Low", or entirely an argument as to why
-your upload is low risk.
-
- * This both shows the SRU team that the risks have been considered,
-and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
-
- * Anything else you think is useful to include
- * Anticipate questions from users, SRU, +1 maintenance, security teams and
the Technical Board
- * and address these questions in advance
+ The fact no-one noticed this problem for more than two years could be
+ telling that there are not many users of this authentication mechanism
+ out there. The same applies to debian: it has also been broken for a
+ while there. Maybe we should drop it for future ubuntu releases, since
+ upstream refuses to take it in.
[ Original Description ]
-
- The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
+ The Authmethod struct now have 4 entries but the initialization of the
+ method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
[Touch-packages] [Bug 2058053] Re: Change sudo compile options from --with-all-insults to --with-pc-insults
I'm not sure I understand this bug, the --with-pc-insults option is deprecated since 2017-09-18 as it is the default option. The noble package doesn't use --enable-offensive-insults. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/2058053 Title: Change sudo compile options from --with-all-insults to --with-pc- insults Status in sudo package in Ubuntu: New Bug description: Tame as they might be, I'd like to continue using "Defaults insults" without any risk of upsetting anyone (and without having to maintain our own package version.) Would the safe insults version at compile time "--with-pc-insults" be a sensible default for all? Current as of Jammy, but looks like it's still the default compile option across the board Version: 1.9.9-1ubuntu2 Current behaviour : Enabling includes the "not PC" insults Expected behaviour : Insults would default to "PC" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/2058053/+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 2053146] Re: openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is slightly wrong
** Changed in: openssh (Ubuntu Noble)
Importance: Critical => High
** Changed in: openssh (Ubuntu Mantic)
Importance: Undecided => High
** Changed in: openssh (Ubuntu Jammy)
Importance: Undecided => High
** Changed in: openssh (Ubuntu Jammy)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Changed in: openssh (Ubuntu Mantic)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146
Title:
openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
slightly wrong
Status in openssh package in Ubuntu:
In Progress
Status in openssh source package in Jammy:
In Progress
Status in openssh source package in Mantic:
In Progress
Status in openssh source package in Noble:
In Progress
Bug description:
[ Impact ]
The gssapi-keyex authentication mechanism has been inadvertently
broken in openssh. It comes from a distro patch[1], and while the
patch still applied, it was no longer correct.
Without the fix, sshd will fail to start if gssapi-keyex is listed in
the AuthenticationMethods of the server, and if not, sshd will still
start, but gssapi-keyex will not be available.
[ Test Plan ]
This update adds a new autopkgtest to the package, which tests both
gssapi-with-mic ("normal" gssapi, which is not affected by this bug),
and gssapi-keyex, which, before this update, does not work.
The test plan is to run the new ssh-gssapi autopkgtest and verify it
succeeds.
[ Where problems could occur ]
ssh is a critical piece of infrastructure, and problems with it could
have catastrophic consequences. The service itself has a test command
before it starts up to verify the syntax of the config file, but that
test is not applied on shutdown, so a restart with an invalid config
file could still leave sshd dead.
The patch adds a change to an authentication structure, but that
change is already present in the upstream code, and we are just
updating it in the new gssapi-keyex code (introduced by the distro[1]
patch, already present). Therefore, mistakes here should manifest
themselves just in the gssapi-keyex code, which wasn't working anyway.
Effectively, though, we are enabling a new authentication mechanism in
sshd, one that was not supposed to have been removed, but was broken
by mistake.
[ Other Info ]
The fact no-one noticed this problem for more than two years could be
telling that there are not many users of this authentication mechanism
out there. The same applies to debian: it has also been broken for a
while there. Maybe we should drop it for future ubuntu releases, since
upstream refuses to take it in.
[ Original Description ]
The Authmethod struct now have 4 entries but the initialization of the
method_gsskeyex in the debian/patches/gssapi.patch only have 3
entries.
The struct was changed in upstream commit
dbb339f015c33d63484261d140c84ad875a9e548 as
===
@@ -104,7 +104,8 @@ struct Authctxt {
struct Authmethod {
char*name;
- int (*userauth)(struct ssh *);
+ char*synonym;
+ int (*userauth)(struct ssh *, const char *);
int *enabled;
};
===
The incorrect code does
===
+Authmethod method_gsskeyex = {
+ "gssapi-keyex",
+ userauth_gsskeyex,
+ &options.gss_authentication
+};
===
but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
This is now (change from Focal) causing gssapi-keyex to be disabled.
===
lsb_release -rd
Description: Ubuntu 22.04.3 LTS
Release: 22.04
===
apt-cache policy openssh-server
openssh-server:
Installed: 1:8.9p1-3ubuntu0.6
Candidate: 1:8.9p1-3ubuntu0.6
Version table:
*** 1:8.9p1-3ubuntu0.6 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-updates/main amd64 Packages
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu
jammy-security/main amd64 Packages
100 /var/lib/dpkg/status
1:8.9p1-3 500
500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main
amd64 Packages
===
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+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 2055776] Re: After updating ubuntu, the network to which the subnet address is assigned does not become active in KVM.
Adding the lines:
listen-on port 53 { localhost; 192.168.122.0/24; };
allow-query { localhost; 192.168.122.0/24; };
to /etc/bind/named.conf.options helped
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/2055776
Title:
After updating ubuntu, the network to which the subnet address is
assigned does not become active in KVM.
Status in dnsmasq package in Ubuntu:
Invalid
Bug description:
phenomenon:
After updating ubuntu, the network to which the subnet address is assigned
does not become active in KVM.
Cause:
This is because the following dnsmasq update operation performed by apt's
automatic update causes an error. It worked properly with dnsmasq 2.80, but
does not work properly with 2.90.
$ cat /var/log/apt/history.log
(snip)
Start-Date: 2024-02-27 06:17:31
Commandline: /usr/bin/unattended-upgrade
Upgrade: dnsmasq-base:amd64 (2.80-1.1ubuntu1.7, 2.90-0ubuntu0.20.04.1)
End-Date: 2024-02-27 06:17:44
(snip)
$
Cause details:
As a premise, bind-dynamic is set in the dnsmasq config file for KVM. Below
is an example.
$ cat default.conf
##WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
##OVERWRITTEN AND LOST. Changes to this configuration should be made using:
##virsh net-edit default
## or other application using the libvirt API.
##
## dnsmasq conf file created by libvirt
strict-order
user=libvirt-dnsmasq
pid-file=/run/libvirt/network/default.pid
except-interface=lo
bind-dynamic
interface=virbr0
dhcp-range=192.168.122.2,192.168.122.254,255.255.255.0
dhcp-no-override
dhcp-authoritative
dhcp-lease-max=253
dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile
addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts
$
When starting the network with KVM (virsh net-start), dnsmasq started from
KVM executes the make_sock function twice as shown below.
$ cat network.c
(snip)
1087 static struct listener *create_listeners(union mysockaddr *addr, int
do_
1087 tftp, int dienow)
1088 {
1089 struct listener *l = NULL;
1090 int fd = -1, tcpfd = -1, tftpfd = -1;
1091
1092 (void)do_tftp;
1093
1094 if (daemon->port != 0)
1095 {
1096 fd = make_sock(addr, SOCK_DGRAM, dienow);
1097 tcpfd = make_sock(addr, SOCK_STREAM, dienow);
1098 }
(snip)
The following code causes an issue with the update made in dnsmasq
2.90.
$ cat network.c
(snip)
895 static int make_sock(union mysockaddr *addr, int type, int dienow)
896 {
(snip)
934 if (!option_bool(OPT_CLEVERBIND) || errno != EADDRNOTAVAIL)
935 {
936 if (dienow)
937 die(s, daemon->addrbuff, EC_BADNET);
938 else
939 my_syslog(LOG_WARNING, s, daemon->addrbuff,
strerror(errno))939 ;
940 }
(snip)
function "make_sock" in network.c:1096 binds the socket to 192.168.122.1/24,
and then make_sock in network.c:1097 tries to bind to the same address.
However, in network.c:934, when errno==98 occurs, network.c:937 is executed, so
dnsmasq does not cause a startup error. As a result, virsh net-start fails.
As a temporary workaround, it will work if you try not to die.
$ diff -u network_c_back network.c
--- network_c_back 2024-02-29 15:36:05.156467935 +
+++ network.c 2024-02-29 15:36:38.733324350 +
@@ -934,7 +934,8 @@
if (!option_bool(OPT_CLEVERBIND) || errno != EADDRNOTAVAIL)
{
if (dienow)
- die(s, daemon->addrbuff, EC_BADNET);
+ my_syslog(LOG_WARNING, s, daemon->addrbuff, strerror(errno));
+ //die(s, daemon->addrbuff, EC_BADNET);
else
my_syslog(LOG_WARNING, s, daemon->addrbuff, strerror(errno));
}
$
If bind-dynamic is set, it should be modified so that it works even if
errno==98.
For reference, in the case of dnsmasq 2.80, the code is as follows, so
no error occurs.
network.c
699 static int make_sock(union mysockaddr *addr, int type, int dienow)
700 {
701 int family = addr->sa.sa_family;
702 int fd, rc, opt = 1;
(snip)
715 err:
716 errsave = errno;
717 port = prettyprint_addr(addr, daemon->addrbuff);
718 if (!option_bool(OPT_NOWILD) && !option_bool(OPT_CLEVERBIND))
719 sprintf(daemon->addrbuff, "port %d", port);
720 s = _("failed to create listening socket for %s: %s");
721
722 if (fd != -1)
723 close (fd);
724
725 errno = errsave;
726
727 if (dienow)
728 {
729 /* failure to bind addresses given by --listen-address at
this
729 point
730 is
Re: [Touch-packages] [Bug 2058053] Re: Change sudo compile options from --with-all-insults to --with-pc-insults
I may have put 2+2 together and made 5 here then. Pulling strings from the library i could see one of the insults that i thought was only included inside the elseif statement for PC being set. I'll double check as i may have been looking at an old git revision, or perhaps there was a config option i overlooked for offensive vs tame insults which left it included in the library On Fri, 15 Mar 2024, 18:00 Marc Deslauriers, <2058...@bugs.launchpad.net> wrote: > I'm not sure I understand this bug, the --with-pc-insults option is > deprecated since 2017-09-18 as it is the default option. > > The noble package doesn't use --enable-offensive-insults. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/2058053 > > Title: > Change sudo compile options from --with-all-insults to --with-pc- > insults > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/2058053/+subscriptions > > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/2058053 Title: Change sudo compile options from --with-all-insults to --with-pc- insults Status in sudo package in Ubuntu: New Bug description: Tame as they might be, I'd like to continue using "Defaults insults" without any risk of upsetting anyone (and without having to maintain our own package version.) Would the safe insults version at compile time "--with-pc-insults" be a sensible default for all? Current as of Jammy, but looks like it's still the default compile option across the board Version: 1.9.9-1ubuntu2 Current behaviour : Enabling includes the "not PC" insults Expected behaviour : Insults would default to "PC" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/2058053/+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 2058053] Re: Change sudo compile options from --with-all-insults to --with-pc-insults
Great, I'll leave this bug open for now. Please let us know if there is anything that is enabled that shouldn't be. Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/2058053 Title: Change sudo compile options from --with-all-insults to --with-pc- insults Status in sudo package in Ubuntu: New Bug description: Tame as they might be, I'd like to continue using "Defaults insults" without any risk of upsetting anyone (and without having to maintain our own package version.) Would the safe insults version at compile time "--with-pc-insults" be a sensible default for all? Current as of Jammy, but looks like it's still the default compile option across the board Version: 1.9.9-1ubuntu2 Current behaviour : Enabling includes the "not PC" insults Expected behaviour : Insults would default to "PC" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/2058053/+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 2046477] Re: Enable unprivileged user namespace restrictions by default
apparmor 4.0.0~beta2-0ubuntu3 installed today from proposed solves problem of
bug https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/2047256, does it
solve other problems too?
Thanks
--
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/2046477
Title:
Enable unprivileged user namespace restrictions by default
Status in apparmor package in Ubuntu:
Triaged
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, and for that
to happen, the restrictions need to be enabled for 24.04
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, as well as some out-of-archive applications that are known
to use unprivileged user namespaces.
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/ch-run
abi ,
include
profile ch-run /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 24.04 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.
In 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. They were also added
in the AppArmor upstream project.
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 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046477/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : http
[Touch-packages] [Bug 2056593] Re: [FFE] FIPS compatibility patches
FFe granted. ** Changed in: openssl (Ubuntu) Status: New => Triaged -- 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/2056593 Title: [FFE] FIPS compatibility patches Status in openssl package in Ubuntu: Triaged Bug description: We have an open MR with a handful of FIPS compatibilty changes we wore hoping to get into 24.04. The main purpose of the changes is to detect whether the kernel is running in FIPS mode and adjust the behavior of the library accordingly by loading the correct provider backend and using defaults that are FIPS compliant (no md5, DES etc) instead trying to use non-compliant code paths and crashing. The proposed patches were taken from the OpenSSL version shipped in the FIPS archive at esm.ubuntu.com for 22.04. Having them in the regular archive will reduce the maintenance work significantly. None of the changes should have any impact on running OpenSSL in regular (non-fips) mode. Below is a detailed list of the changes: - d/p/fips/crypto-Add-kernel-FIPS-mode-detection.patch: This adds a new internal API to determine whether the kernel has been booted in FIPS mode. This can be overridden with the OPENSSL_FORCE_FIPS_MODE environment variable. OPENSSL_FIPS_MODE_SWITCH_PATH can be used to specify an alternative path for the fips_enabled file and is used in tests. The FIPS_MODULE switch can be used to enable build of the the FIPS provider module specific parts which are not needed in the OpenSSL library itself. - d/p/fips/crypto-Automatically-use-the-FIPS-provider-when-the-kerne.patch: This automatically configures all library contexts to use the FIPS provider when the kernel is booted in FIPS mode by: - Setting "fips=yes" as the default property for algorithm fetches - Loading and activating the FIPS provider as the fallback provider. If applications load providers via a configuration either because the default configuration is modified or they override the default configuration, this disables loading of the fallback providers. In this case, the configuration must load the FIPS provider when FIPS mode is enabled, else algorithm fetches will fail Applications can choose to use non-FIPS approved algorithms by specifying the "-fips" or "fips=no" property for algorithm fetches and loading the default provider. - d/p/fips/apps-speed-Omit-unavailable-algorithms-in-FIPS-mode.patch: Omit unavailable algorithms in FIPS mode - d/p/fips/apps-pass-propquery-arg-to-the-libctx-DRBG-fetches.patch The -propquery argument might be used to define a preference for which provider an algorithm is fetched from. Set the query properties for the library context DRBG fetches as well so that they are fetched with the same properties. - d/p/fips/test-Ensure-encoding-runs-with-the-correct-context-during.patch: This test uses 2 library contexts - one context for creating initial test keys, and then another context (or the default context) for running tests. There is an issue that during the encoding tests, the OSSL_ENCODER_CTX is created from the created EVP_PKEYs, which are associated with the library context used to create the keys. This means that encoding tests run with the wrong library context, which always uses the default provider. These changes are now included in a larger MR with other changes in the same package version: https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+merge/462486 The now-superseded MR is at https://code.launchpad.net/~tobhe/ubuntu/+source/openssl/+git/openssl/+merge/460953 Since OpenSSL just received another big update to 3.0.13 we had to rebase our changes and will have to rerun our install/upgrade tests. A test build is also available at https://launchpad.net/~tobhe/+archive/ubuntu/openssl-test/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2056593/+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 2058070] [NEW] Disable DNS Recursion after AA Answer
Public bug reported: Resolved (253 on Ubuntu Server 23.10) seems to continue DNS recursion after responding with an authoritative answer. i.e. DNS blacklist is configured in /etc/hosts... see https://github.com/systemd/systemd/issues/31223 Fixed in https://github.com/systemd/systemd/commit/4b91896226b4285da94aad4b38b670036c7f23be ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: systemd-resolved 253.5-1ubuntu6.1 ProcVersionSignature: Ubuntu 6.5.0-21.21-generic 6.5.8 Uname: Linux 6.5.0-21-generic x86_64 ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 CasperMD5CheckResult: pass Date: Fri Mar 15 16:56:00 2024 InstallationDate: Installed on 2023-11-27 (110 days ago) InstallationMedia: Ubuntu-Server 23.10 "Mantic Minotaur" - Release amd64 (20231011) ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.systemd.resolved.conf: 2023-12-02T20:29:34.791388 ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug mantic -- 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/2058070 Title: Disable DNS Recursion after AA Answer Status in systemd package in Ubuntu: New Bug description: Resolved (253 on Ubuntu Server 23.10) seems to continue DNS recursion after responding with an authoritative answer. i.e. DNS blacklist is configured in /etc/hosts... see https://github.com/systemd/systemd/issues/31223 Fixed in https://github.com/systemd/systemd/commit/4b91896226b4285da94aad4b38b670036c7f23be ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: systemd-resolved 253.5-1ubuntu6.1 ProcVersionSignature: Ubuntu 6.5.0-21.21-generic 6.5.8 Uname: Linux 6.5.0-21-generic x86_64 ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 CasperMD5CheckResult: pass Date: Fri Mar 15 16:56:00 2024 InstallationDate: Installed on 2023-11-27 (110 days ago) InstallationMedia: Ubuntu-Server 23.10 "Mantic Minotaur" - Release amd64 (20231011) ProcEnviron: LANG=C.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.systemd.resolved.conf: 2023-12-02T20:29:34.791388 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2058070/+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 2033165] Re: 310 empty dirs created by hicolor-icon-theme
** Tags removed: mantic ** Tags added: noble -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to hicolor-icon-theme in Ubuntu. https://bugs.launchpad.net/bugs/2033165 Title: 310 empty dirs created by hicolor-icon-theme Status in hicolor-icon-theme package in Ubuntu: New Bug description: 310 empty dirs created by hicolor-icon-theme 0.17-2 in Mantic. 0.17-2 was first published 2018-03-19 11:33:46 UTC for Bionic. find /usr/share/icons/hicolor/ -type d -empty && find /usr/share/icons/hicolor/ -type d -empty | grep -c '' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hicolor-icon-theme/+bug/2033165/+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 2046477] Re: Enable unprivileged user namespace restrictions by default
It solves several problems, but not all.
With regard to unprivileged user namespace mediation it should fix
- mscode
- nautilis
- devhelp
- element-desktop
- piphany
- evolution
- keybase
- opam
the element-desktop is still known to have some issues, which are on the snapd
side. It needs to add some interfaces etc.
there is a beta3 coming early next week with additional fixes coming.
The full set won't be finalized until beta3 is rolled this weekend.
--
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/2046477
Title:
Enable unprivileged user namespace restrictions by default
Status in apparmor package in Ubuntu:
Triaged
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, and for that
to happen, the restrictions need to be enabled for 24.04
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, as well as some out-of-archive applications that are known
to use unprivileged user namespaces.
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/ch-run
abi ,
include
profile ch-run /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 24.04 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.
In 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. They were also added
in the AppArmor upstream project.
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 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.
To manage notifications
[Touch-packages] [Bug 2057768] Re: Unit and its Alias appear to be separate entities when enabling the unit by filepath
This affects all current releases AFAICT. ** Changed in: systemd (Ubuntu) Status: New => Confirmed ** Changed in: systemd (Ubuntu) Importance: Undecided => Wishlist ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Nick Rosbrook (enr0n) -- 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/2057768 Title: Unit and its Alias appear to be separate entities when enabling the unit by filepath Status in systemd package in Ubuntu: Confirmed Bug description: ### systemd version the issue has been seen with 245 ### Used distribution Linux Mint 20.1 and Ubuntu 20.04 ### Linux kernel version used 5.4.0-135-generic ### CPU architectures issue was seen on None ### Component systemctl ### Expected behaviour you didn't see When including an alias in a unit file that is enabled by referring to its filepath, its alias should refer to the unit - the two should refer to the exact same service. This is the case when the unit file is enabled inside one of the systemd directories. I expect alias and unit to refer to one identical service also when enabling via filepath. In particular, the output of `systemctl status ...` should be identical for a Unit and its Alias. ### Unexpected behaviour you saw After passing a systemd unit including an alias to `systemctl enable PATH...` by path, systemctl treated the unit and its alias as separate units. Specifically, `systemctl status` reports different results (running/inactive, PID if applicable) for the unit name and its alias. When I start the unit by its original name, only the status of the unit is reported as running while the status of the alias remains inactive, and vice versa. After starting the Alias too, two services with different PIDs are running. (When copying the unit into /etc/systemd/system/ and running `systemctl enable UNIT...` this issue does not occur and alias and unit behave the same.) ### Steps to reproduce the problem ``` ~$ cat dummy.service [Service] ExecStart=tail -f /dev/null [Install] Alias=dumb.service ~$ sudo systemctl enable ~/dummy.service Created symlink /etc/systemd/system/dumb.service → /home/lukas/dummy.service. Created symlink /etc/systemd/system/dummy.service → /home/lukas/dummy.service. ~$ sudo systemctl start dummy ~$ systemctl status dummy ● dummy.service Loaded: loaded (/etc/systemd/system/dummy.service; enabled; vendor preset:> Active: active (running) since Tue 2024-03-12 15:36:58 CET; 8s ago Main PID: 159809 (tail) Tasks: 1 (limit: 76978) Memory: 160.0K CGroup: /system.slice/dummy.service └─159809 /usr/bin/tail -f /dev/null Mär 12 15:36:58 MyMachine systemd[1]: Started dummy.service. ~$ systemctl status dumb ● dumb.service Loaded: loaded (/etc/systemd/system/dumb.service; enabled; vendor preset: > Active: inactive (dead) Mär 12 15:30:53 MyMachine systemd[1]: Started dumb.service. Mär 12 15:31:16 MyMachine systemd[1]: Stopping dumb.service... Mär 12 15:31:16 MyMachine systemd[1]: dumb.service: Succeeded. Mär 12 15:31:16 MyMachine systemd[1]: Stopped dumb.service. ~$ ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2057768/+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 2046477] Re: Enable unprivileged user namespace restrictions by default
@pitti: yes this intended. At this stage we are essentially enumerating
the known users of unprivileged user namespaces. We can ship the profile
for you or you are welcome to ship it.
In the future this is going to gradually tighten, some of the
"unconfined" profiles will be developed into real profiles, unconfined
(including these profiles) will get tied into integrity checks, or
require user exceptions in the security center, etc.
--
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/2046477
Title:
Enable unprivileged user namespace restrictions by default
Status in apparmor package in Ubuntu:
Triaged
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, and for that
to happen, the restrictions need to be enabled for 24.04
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, as well as some out-of-archive applications that are known
to use unprivileged user namespaces.
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/ch-run
abi ,
include
profile ch-run /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 24.04 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.
In 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. They were also added
in the AppArmor upstream project.
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 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.
To manage notifications about this bug go to:
https://
[Touch-packages] [Bug 2046844] Re: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP
@guyster, @eldmannen+launchpad, @valeryan-24 Firefox dailies now have a work around, by detecting and disabling the user namespace. The proper fix that should allow firefox to still use the user namespace for its sandbox will land in Beta3, landing early next week. -- 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/2046844 Title: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP Status in AppArmor: New Status in akonadiconsole package in Ubuntu: Fix Released Status in akregator package in Ubuntu: Fix Released Status in angelfish package in Ubuntu: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in bubblewrap package in Ubuntu: Confirmed Status in cantor package in Ubuntu: Fix Released Status in devhelp package in Ubuntu: Fix Released Status in digikam package in Ubuntu: Fix Released Status in epiphany-browser package in Ubuntu: Fix Released Status in evolution package in Ubuntu: Fix Released Status in falkon package in Ubuntu: Fix Released Status in firefox package in Ubuntu: Confirmed Status in freecad package in Ubuntu: Confirmed Status in geary package in Ubuntu: Confirmed Status in ghostwriter package in Ubuntu: Fix Released Status in gnome-packagekit package in Ubuntu: Confirmed Status in goldendict-webengine package in Ubuntu: Confirmed Status in kalgebra package in Ubuntu: Fix Released Status in kchmviewer package in Ubuntu: Confirmed Status in kdeplasma-addons package in Ubuntu: Fix Released Status in kgeotag package in Ubuntu: Fix Released Status in kiwix package in Ubuntu: Confirmed Status in kmail package in Ubuntu: Fix Released Status in konqueror package in Ubuntu: Fix Released Status in kontact package in Ubuntu: Fix Released Status in loupe package in Ubuntu: Confirmed Status in marble package in Ubuntu: Fix Released Status in notepadqq package in Ubuntu: Confirmed Status in opam package in Ubuntu: Fix Released Status in pageedit package in Ubuntu: Confirmed Status in plasma-desktop package in Ubuntu: Fix Released Status in plasma-welcome package in Ubuntu: Fix Released Status in privacybrowser package in Ubuntu: Confirmed Status in qmapshack package in Ubuntu: Confirmed Status in qutebrowser package in Ubuntu: Confirmed Status in rssguard package in Ubuntu: Confirmed Status in steam package in Ubuntu: Fix Released Status in supercollider package in Ubuntu: Confirmed Status in tellico package in Ubuntu: Fix Released Bug description: Hi, I run Ubuntu development branch 24.04 and I have a problem with Epiphany browser 45.1-1 (Gnome Web): program doesn't launch, and I get this error $ epiphany bwrap: Creating new namespace failed: Permission denied ** (epiphany:12085): ERROR **: 14:44:35.023: Failed to fully launch dbus-proxy: Le processus fils s’est terminé avec le code 1 Trappe pour point d'arrêt et de trace (core dumped) $ epiphany bwrap: Creating new namespace failed: Permission denied ** (epiphany:30878): ERROR **: 22:22:26.926: Failed to fully launch dbus-proxy: Le processus fils s’est terminé avec le code 1 Trappe pour point d'arrêt et de trace (core dumped) Thanks for your help! To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/2046844/+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 2046844] Re: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP
@eeickmeyer geary should be fixed in Beta3 -- 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/2046844 Title: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP Status in AppArmor: New Status in akonadiconsole package in Ubuntu: Fix Released Status in akregator package in Ubuntu: Fix Released Status in angelfish package in Ubuntu: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in bubblewrap package in Ubuntu: Confirmed Status in cantor package in Ubuntu: Fix Released Status in devhelp package in Ubuntu: Fix Released Status in digikam package in Ubuntu: Fix Released Status in epiphany-browser package in Ubuntu: Fix Released Status in evolution package in Ubuntu: Fix Released Status in falkon package in Ubuntu: Fix Released Status in firefox package in Ubuntu: Confirmed Status in freecad package in Ubuntu: Confirmed Status in geary package in Ubuntu: Confirmed Status in ghostwriter package in Ubuntu: Fix Released Status in gnome-packagekit package in Ubuntu: Confirmed Status in goldendict-webengine package in Ubuntu: Confirmed Status in kalgebra package in Ubuntu: Fix Released Status in kchmviewer package in Ubuntu: Confirmed Status in kdeplasma-addons package in Ubuntu: Fix Released Status in kgeotag package in Ubuntu: Fix Released Status in kiwix package in Ubuntu: Confirmed Status in kmail package in Ubuntu: Fix Released Status in konqueror package in Ubuntu: Fix Released Status in kontact package in Ubuntu: Fix Released Status in loupe package in Ubuntu: Confirmed Status in marble package in Ubuntu: Fix Released Status in notepadqq package in Ubuntu: Confirmed Status in opam package in Ubuntu: Fix Released Status in pageedit package in Ubuntu: Confirmed Status in plasma-desktop package in Ubuntu: Fix Released Status in plasma-welcome package in Ubuntu: Fix Released Status in privacybrowser package in Ubuntu: Confirmed Status in qmapshack package in Ubuntu: Confirmed Status in qutebrowser package in Ubuntu: Confirmed Status in rssguard package in Ubuntu: Confirmed Status in steam package in Ubuntu: Fix Released Status in supercollider package in Ubuntu: Confirmed Status in tellico package in Ubuntu: Fix Released Bug description: Hi, I run Ubuntu development branch 24.04 and I have a problem with Epiphany browser 45.1-1 (Gnome Web): program doesn't launch, and I get this error $ epiphany bwrap: Creating new namespace failed: Permission denied ** (epiphany:12085): ERROR **: 14:44:35.023: Failed to fully launch dbus-proxy: Le processus fils s’est terminé avec le code 1 Trappe pour point d'arrêt et de trace (core dumped) $ epiphany bwrap: Creating new namespace failed: Permission denied ** (epiphany:30878): ERROR **: 22:22:26.926: Failed to fully launch dbus-proxy: Le processus fils s’est terminé avec le code 1 Trappe pour point d'arrêt et de trace (core dumped) Thanks for your help! To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/2046844/+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 2046844] Re: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP
@sudipmuk loupe should be fixed in Beta3 -- 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/2046844 Title: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP Status in AppArmor: New Status in akonadiconsole package in Ubuntu: Fix Released Status in akregator package in Ubuntu: Fix Released Status in angelfish package in Ubuntu: Fix Released Status in apparmor package in Ubuntu: Fix Released Status in bubblewrap package in Ubuntu: Confirmed Status in cantor package in Ubuntu: Fix Released Status in devhelp package in Ubuntu: Fix Released Status in digikam package in Ubuntu: Fix Released Status in epiphany-browser package in Ubuntu: Fix Released Status in evolution package in Ubuntu: Fix Released Status in falkon package in Ubuntu: Fix Released Status in firefox package in Ubuntu: Confirmed Status in freecad package in Ubuntu: Confirmed Status in geary package in Ubuntu: Confirmed Status in ghostwriter package in Ubuntu: Fix Released Status in gnome-packagekit package in Ubuntu: Confirmed Status in goldendict-webengine package in Ubuntu: Confirmed Status in kalgebra package in Ubuntu: Fix Released Status in kchmviewer package in Ubuntu: Confirmed Status in kdeplasma-addons package in Ubuntu: Fix Released Status in kgeotag package in Ubuntu: Fix Released Status in kiwix package in Ubuntu: Confirmed Status in kmail package in Ubuntu: Fix Released Status in konqueror package in Ubuntu: Fix Released Status in kontact package in Ubuntu: Fix Released Status in loupe package in Ubuntu: Confirmed Status in marble package in Ubuntu: Fix Released Status in notepadqq package in Ubuntu: Confirmed Status in opam package in Ubuntu: Fix Released Status in pageedit package in Ubuntu: Confirmed Status in plasma-desktop package in Ubuntu: Fix Released Status in plasma-welcome package in Ubuntu: Fix Released Status in privacybrowser package in Ubuntu: Confirmed Status in qmapshack package in Ubuntu: Confirmed Status in qutebrowser package in Ubuntu: Confirmed Status in rssguard package in Ubuntu: Confirmed Status in steam package in Ubuntu: Fix Released Status in supercollider package in Ubuntu: Confirmed Status in tellico package in Ubuntu: Fix Released Bug description: Hi, I run Ubuntu development branch 24.04 and I have a problem with Epiphany browser 45.1-1 (Gnome Web): program doesn't launch, and I get this error $ epiphany bwrap: Creating new namespace failed: Permission denied ** (epiphany:12085): ERROR **: 14:44:35.023: Failed to fully launch dbus-proxy: Le processus fils s’est terminé avec le code 1 Trappe pour point d'arrêt et de trace (core dumped) $ epiphany bwrap: Creating new namespace failed: Permission denied ** (epiphany:30878): ERROR **: 22:22:26.926: Failed to fully launch dbus-proxy: Le processus fils s’est terminé avec le code 1 Trappe pour point d'arrêt et de trace (core dumped) Thanks for your help! To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/2046844/+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 2058093] [NEW] NetworkManager crashed with SIGABRT in g_assertion_message_expr()
Public bug reported: unexpected crashed ProblemType: Crash DistroRelease: Ubuntu 24.04 Package: network-manager 1.45.90-1ubuntu1 ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4 Uname: Linux 6.8.0-11-generic x86_64 NonfreeKernelModules: zfs nvidia_modeset nvidia ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: pass Date: Fri Mar 15 16:40:02 2024 ExecutablePath: /usr/sbin/NetworkManager InstallationDate: Installed on 2023-07-08 (252 days ago) InstallationMedia: Ubuntu 23.10 "Mantic Minotaur" - Daily amd64 (20230705) IpRoute: default via 192.168.0.1 dev wlp0s20f3 proto dhcp src 192.168.0.227 metric 600 10.99.203.0/24 dev mpqemubr0 proto kernel scope link src 10.99.203.1 linkdown 10.236.76.0/24 dev lxdbr0 proto kernel scope link src 10.236.76.1 linkdown 192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.227 metric 600 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown JournalErrors: -- No entries -- NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true ProcCmdline: /usr/sbin/NetworkManager --no-daemon ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) Signal: 6 SignalName: SIGABRT SourcePackage: network-manager StacktraceTop: ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 g_assertion_message_expr () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ?? () g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 Title: NetworkManager crashed with SIGABRT in g_assertion_message_expr() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.45.90 connected started full enabled enabled enabled missing enabled separator: ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-crash need-amd64-retrace noble ** 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 network-manager in Ubuntu. https://bugs.launchpad.net/bugs/2058093 Title: NetworkManager crashed with SIGABRT in g_assertion_message_expr() Status in network-manager package in Ubuntu: New Bug description: unexpected crashed ProblemType: Crash DistroRelease: Ubuntu 24.04 Package: network-manager 1.45.90-1ubuntu1 ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4 Uname: Linux 6.8.0-11-generic x86_64 NonfreeKernelModules: zfs nvidia_modeset nvidia ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: pass Date: Fri Mar 15 16:40:02 2024 ExecutablePath: /usr/sbin/NetworkManager InstallationDate: Installed on 2023-07-08 (252 days ago) InstallationMedia: Ubuntu 23.10 "Mantic Minotaur" - Daily amd64 (20230705) IpRoute: default via 192.168.0.1 dev wlp0s20f3 proto dhcp src 192.168.0.227 metric 600 10.99.203.0/24 dev mpqemubr0 proto kernel scope link src 10.99.203.1 linkdown 10.236.76.0/24 dev lxdbr0 proto kernel scope link src 10.236.76.1 linkdown 192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.227 metric 600 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown JournalErrors: -- No entries -- NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true ProcCmdline: /usr/sbin/NetworkManager --no-daemon ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) Signal: 6 SignalName: SIGABRT SourcePackage: network-manager StacktraceTop: ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 g_assertion_message_expr () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ?? () g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 Title: NetworkManager crashed with SIGABRT in g_assertion_message_expr() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.45.90 connected started full enabled enabled enabled missing enabled separator: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2058093/+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 2058093] Re: NetworkManager crashed with SIGABRT in g_assertion_message_expr()
Thank you for your report! However, processing it in order to get sufficient information for the developers failed as the report has a core dump which is invalid. The corruption may have happened on the system which the crash occurred or during transit. Thank you for your understanding, and sorry for the inconvenience! ** Changed in: network-manager (Ubuntu) Status: New => Invalid ** Attachment removed: "CoreDump.gz" https://bugs.launchpad.net/bugs/2058093/+attachment/5756357/+files/CoreDump.gz ** Tags removed: need-amd64-retrace -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/2058093 Title: NetworkManager crashed with SIGABRT in g_assertion_message_expr() Status in network-manager package in Ubuntu: Invalid Bug description: unexpected crashed ProblemType: Crash DistroRelease: Ubuntu 24.04 Package: network-manager 1.45.90-1ubuntu1 ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4 Uname: Linux 6.8.0-11-generic x86_64 NonfreeKernelModules: zfs nvidia_modeset nvidia ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CasperMD5CheckResult: pass Date: Fri Mar 15 16:40:02 2024 ExecutablePath: /usr/sbin/NetworkManager InstallationDate: Installed on 2023-07-08 (252 days ago) InstallationMedia: Ubuntu 23.10 "Mantic Minotaur" - Daily amd64 (20230705) IpRoute: default via 192.168.0.1 dev wlp0s20f3 proto dhcp src 192.168.0.227 metric 600 10.99.203.0/24 dev mpqemubr0 proto kernel scope link src 10.99.203.1 linkdown 10.236.76.0/24 dev lxdbr0 proto kernel scope link src 10.236.76.1 linkdown 192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.227 metric 600 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown JournalErrors: -- No entries -- NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true ProcCmdline: /usr/sbin/NetworkManager --no-daemon ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) Signal: 6 SignalName: SIGABRT SourcePackage: network-manager StacktraceTop: ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 g_assertion_message_expr () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ?? () g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 Title: NetworkManager crashed with SIGABRT in g_assertion_message_expr() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: N/A nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.45.90 connected started full enabled enabled enabled missing enabled separator: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2058093/+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 2046844] Re: AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP
I have tried freecad and unprivileged user namespace restrictions are
not the problem. freecad snap works, freecad ppa does not have a noble
build yet but the mantic build can be made to work.
freecad daily appimage: works
freecad appimage: stable fails with mesa or qt errors depending on how/where it
is started. Below is a paste of the error
MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so: cannot open shared
object file: No such file or directory (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
failed to load driver: zink
MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open
shared object file: No such file or directory (search paths
/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
failed to load driver: swrast
** Changed in: freecad (Ubuntu)
Status: Confirmed => Invalid
--
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/2046844
Title:
AppArmor user namespace creation restrictions cause many applications
to crash with SIGTRAP
Status in AppArmor:
New
Status in akonadiconsole package in Ubuntu:
Fix Released
Status in akregator package in Ubuntu:
Fix Released
Status in angelfish package in Ubuntu:
Fix Released
Status in apparmor package in Ubuntu:
Fix Released
Status in bubblewrap package in Ubuntu:
Confirmed
Status in cantor package in Ubuntu:
Fix Released
Status in devhelp package in Ubuntu:
Fix Released
Status in digikam package in Ubuntu:
Fix Released
Status in epiphany-browser package in Ubuntu:
Fix Released
Status in evolution package in Ubuntu:
Fix Released
Status in falkon package in Ubuntu:
Fix Released
Status in firefox package in Ubuntu:
Confirmed
Status in freecad package in Ubuntu:
Invalid
Status in geary package in Ubuntu:
Confirmed
Status in ghostwriter package in Ubuntu:
Fix Released
Status in gnome-packagekit package in Ubuntu:
Confirmed
Status in goldendict-webengine package in Ubuntu:
Confirmed
Status in kalgebra package in Ubuntu:
Fix Released
Status in kchmviewer package in Ubuntu:
Confirmed
Status in kdeplasma-addons package in Ubuntu:
Fix Released
Status in kgeotag package in Ubuntu:
Fix Released
Status in kiwix package in Ubuntu:
Confirmed
Status in kmail package in Ubuntu:
Fix Released
Status in konqueror package in Ubuntu:
Fix Released
Status in kontact package in Ubuntu:
Fix Released
Status in loupe package in Ubuntu:
Confirmed
Status in marble package in Ubuntu:
Fix Released
Status in notepadqq package in Ubuntu:
Confirmed
Status in opam package in Ubuntu:
Fix Released
Status in pageedit package in Ubuntu:
Confirmed
Status in plasma-desktop package in Ubuntu:
Fix Released
Status in plasma-welcome package in Ubuntu:
Fix Released
Status in privacybrowser package in Ubuntu:
Confirmed
Status in qmapshack package in Ubuntu:
Confirmed
Status in qutebrowser package in Ubuntu:
Confirmed
Status in rssguard package in Ubuntu:
Confirmed
Status in steam package in Ubuntu:
Fix Released
Status in supercollider package in Ubuntu:
Confirmed
Status in tellico package in Ubuntu:
Fix Released
Bug description:
Hi, I run Ubuntu development branch 24.04 and I have a problem with
Epiphany browser 45.1-1 (Gnome Web): program doesn't launch, and I get
this error
$ epiphany
bwrap: Creating new namespace failed: Permission denied
** (epiphany:12085): ERROR **: 14:44:35.023: Failed to fully launch
dbus-proxy: Le processus fils s’est terminé avec le code 1
Trappe pour point d'arrêt et de trace (core dumped)
$ epiphany
bwrap: Creating new namespace failed: Permission denied
** (epiphany:30878): ERROR **: 22:22:26.926: Failed to fully launch
dbus-proxy: Le processus fils s’est terminé avec le code 1
Trappe pour point d'arrêt et de trace (core dumped)
Thanks for your help!
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/2046844/+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
