[Touch-packages] [Bug 1964100] Re: Cannot connect to open WLAN with 1.36.0-1ubuntu2 on Jammy
** Changed in: network-manager (Ubuntu) Status: Expired => New -- 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/1964100 Title: Cannot connect to open WLAN with 1.36.0-1ubuntu2 on Jammy Status in network-manager package in Ubuntu: New Bug description: I'm trying to connect to an open (i.e. no ecryption) WLAN with network-manager 1.36.0-1ubuntu2 on 22.04 but it's failing with the following error message (after selecting the network from the network- manager applet prompt): Mär 08 10:50:04 Isaac-Laptop NetworkManager[31754]: [1646733004.4425] audit: op="connection-add-activate" pid=12122 uid=1000 result="fail" reason="802-11-wireless-security.key-mgmt: Access point does not support PSK but setting requires it" I haven't changed any of the default settings for network-manager and this network worked on 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1964100/+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 2022927] Re: Busybox mount fails to mount Snaps
Resubscribing ubuntu-sponsors as I've had no response from the mailing list -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/2022927 Title: Busybox mount fails to mount Snaps Status in busybox package in Ubuntu: New Bug description: Snapd tries to mount squashfs Snaps with non-standard mount flags like "x-gdu.hide" and "x-gvfs-hide", both of which are used to indicate to userspace programs that a given mount should not be shown in a list of mounted partitions/filesystems. Busybox does not support these flags, and so fails with "Invalid argument". $ sudo busybox mount -t tmpfs -o x-gdu-hide test /tmp/test mount: mounting test on /tmp/test failed: Invalid argument These flags can likely be be safely ignored, as they don't actually affect the functionality of the mount. This goes for all mount options starting with "x-", as these generally denote non-standard mount option "extensions". I've created a patch against Busybox which adds an optional configuration item to ignore all mount options beginning with "x-". An additional verbose option has also been added to enable the ability to report that the mount flags have been ignored, rather than silently ignoring them. This is a requirement for a customer project, where we are limited to using Busybox (due to coreutils' GPL-3.0 licence) but would also require using Snaps like checkbox for testing and verification. This was posted on the Busybox mailing list a few months ago (http://lists.busybox.net/pipermail/busybox/2023-March/090202.html) but patch acceptance there seems to take quite a long time, and we need this for the customer. A PPA containing the patched Busybox version is available on the project's Launchpad team: https://launchpad.net/~nemos- team/+archive/ubuntu/ppa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2022927/+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 2039083] Re: "optional: true" flag introduces problem it's meant to fix in certain circumstances
As far as I can tell we are facing this issue: https://github.com/systemd/systemd/issues/25813 This was fixed in systemd 253 with the following patch https://github.com/systemd/systemd/commit/ab3aed4a0349bbaa26f53340770c1b59b463e05d (and https://github.com/systemd/systemd/commit/2f96a29c2c55bdd67cdd8e0b0cfd6971968e4bca to fix a regression introduced by the first patch). If all managed interfaces have RequiredForOnline=no, and the rest are unmanaged, this issue pops up. ** Bug watch added: github.com/systemd/systemd/issues #25813 https://github.com/systemd/systemd/issues/25813 -- 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/2039083 Title: "optional: true" flag introduces problem it's meant to fix in certain circumstances Status in netplan: Triaged Status in systemd package in Ubuntu: Confirmed Bug description: Hello! This bug is in relation to the situation where the "systemd-networkd- wait-online.service" hangs for several minutes on boot before eventually failing. I guess I don't know if this flag was introduced specifically for this situation, but I do know that one of the fixes for this issue is to add "optional: true" to any non-critical interfaces (as per the docs[1]). While this may be the case, it just so happens that adding this flag to an interface when it's the only configured interface in netplan can actually INTRODUCE the issue as well. Example: --- :~# grep -Ev "^#" /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: enp5s0: dhcp4: true optional: true --- The above config will cause the service hang/failure, and the removal of the flag will resolve the issue. I primarily opened this bug report with the idea that we might update aforementioned documentation to include a caveat that you want to avoid adding this flag to the only configured interface. However, it was also discussed that we might consider having the netplan config parser complain about such a setup and consider it invalid, which it kinda is. I believe in a situation where you may have a server that should have NO network connectivity, you would simply leave netplan unconfigured and/or stop any relevant services, rather than try to configure all interfaces as optional. My original test was on Jammy, though I tested this also on Focal and Bionic, and neither of those appear to be affected by this - setting the only interface as optional in either of those does not cause the "systemd-networkd-wait-online" service to hang and the system boots normally. Let me know if you'd like/need any more info from me! Thank you! [1] https://netplan.io/faq#prevent-waiting-for-interface To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2039083/+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 2039083] Re: "optional: true" flag introduces problem it's meant to fix in certain circumstances
>From https://www.man7.org/linux/man-pages/man5/systemd.network.5.html If RequiredForOnline=no is set, systemd-networkd-wait-online should skip the interface: The network will be brought up normally (as configured by ActivationPolicy=), but in the event that there is no address being assigned by DHCP or the cable is not plugged in, the link will simply remain offline and be skipped automatically by systemd-networkd-wait-online if "RequiredForOnline=no". -- 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/2039083 Title: "optional: true" flag introduces problem it's meant to fix in certain circumstances Status in netplan: Triaged Status in systemd package in Ubuntu: Confirmed Bug description: Hello! This bug is in relation to the situation where the "systemd-networkd- wait-online.service" hangs for several minutes on boot before eventually failing. I guess I don't know if this flag was introduced specifically for this situation, but I do know that one of the fixes for this issue is to add "optional: true" to any non-critical interfaces (as per the docs[1]). While this may be the case, it just so happens that adding this flag to an interface when it's the only configured interface in netplan can actually INTRODUCE the issue as well. Example: --- :~# grep -Ev "^#" /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: enp5s0: dhcp4: true optional: true --- The above config will cause the service hang/failure, and the removal of the flag will resolve the issue. I primarily opened this bug report with the idea that we might update aforementioned documentation to include a caveat that you want to avoid adding this flag to the only configured interface. However, it was also discussed that we might consider having the netplan config parser complain about such a setup and consider it invalid, which it kinda is. I believe in a situation where you may have a server that should have NO network connectivity, you would simply leave netplan unconfigured and/or stop any relevant services, rather than try to configure all interfaces as optional. My original test was on Jammy, though I tested this also on Focal and Bionic, and neither of those appear to be affected by this - setting the only interface as optional in either of those does not cause the "systemd-networkd-wait-online" service to hang and the system boots normally. Let me know if you'd like/need any more info from me! Thank you! [1] https://netplan.io/faq#prevent-waiting-for-interface To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2039083/+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 2039083] Re: "optional: true" flag introduces problem it's meant to fix in certain circumstances
Copying from my comment https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/comments/43 systemd 249.11-0ubuntu3.11 doesn't resolve the issue I'm facing (this one). The long delay seems to be caused by systemd-networkd-wait-online not respecting "RequiredForOnline=no". ubuntu@ubuntu:~$ cat /run/systemd/network/10-netplan-eth0.network [Match] Name=eth0 [Link] RequiredForOnline=no [Network] DHCP=yes LinkLocalAddressing=ipv6 [DHCP] RouteMetric=100 UseMTU=true -- 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/2039083 Title: "optional: true" flag introduces problem it's meant to fix in certain circumstances Status in netplan: Triaged Status in systemd package in Ubuntu: Confirmed Bug description: Hello! This bug is in relation to the situation where the "systemd-networkd- wait-online.service" hangs for several minutes on boot before eventually failing. I guess I don't know if this flag was introduced specifically for this situation, but I do know that one of the fixes for this issue is to add "optional: true" to any non-critical interfaces (as per the docs[1]). While this may be the case, it just so happens that adding this flag to an interface when it's the only configured interface in netplan can actually INTRODUCE the issue as well. Example: --- :~# grep -Ev "^#" /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: enp5s0: dhcp4: true optional: true --- The above config will cause the service hang/failure, and the removal of the flag will resolve the issue. I primarily opened this bug report with the idea that we might update aforementioned documentation to include a caveat that you want to avoid adding this flag to the only configured interface. However, it was also discussed that we might consider having the netplan config parser complain about such a setup and consider it invalid, which it kinda is. I believe in a situation where you may have a server that should have NO network connectivity, you would simply leave netplan unconfigured and/or stop any relevant services, rather than try to configure all interfaces as optional. My original test was on Jammy, though I tested this also on Focal and Bionic, and neither of those appear to be affected by this - setting the only interface as optional in either of those does not cause the "systemd-networkd-wait-online" service to hang and the system boots normally. Let me know if you'd like/need any more info from me! Thank you! [1] https://netplan.io/faq#prevent-waiting-for-interface To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/2039083/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
systemd 249.11-0ubuntu3.11 does *not* solve the issue for me. I seem to be running into the same situation as Werner in #32 where `optional: true` from the netplan config is not being respected. systemd-networkd-wait-online seems to ignore `RequiredForOnline=no` in the .network config. Netplan config: ubuntu@ubuntu:~$ sudo netplan get network: version: 2 ethernets: eth0: optional: true dhcp4: true dhcp6: true pfe: match: name: "pfe*" optional: true dhcp4: true dhcp6: true systemd-networkd configs: ubuntu@ubuntu:~$ grep '' /run/systemd/network/10-netplan-* /run/systemd/network/10-netplan-eth0.network:[Match] /run/systemd/network/10-netplan-eth0.network:Name=eth0 /run/systemd/network/10-netplan-eth0.network: /run/systemd/network/10-netplan-eth0.network:[Link] /run/systemd/network/10-netplan-eth0.network:RequiredForOnline=no /run/systemd/network/10-netplan-eth0.network: /run/systemd/network/10-netplan-eth0.network:[Network] /run/systemd/network/10-netplan-eth0.network:DHCP=yes /run/systemd/network/10-netplan-eth0.network:LinkLocalAddressing=ipv6 /run/systemd/network/10-netplan-eth0.network: /run/systemd/network/10-netplan-eth0.network:[DHCP] /run/systemd/network/10-netplan-eth0.network:RouteMetric=100 /run/systemd/network/10-netplan-eth0.network:UseMTU=true /run/systemd/network/10-netplan-pfe.network:[Match] /run/systemd/network/10-netplan-pfe.network:Name=pfe* /run/systemd/network/10-netplan-pfe.network: /run/systemd/network/10-netplan-pfe.network:[Link] /run/systemd/network/10-netplan-pfe.network:RequiredForOnline=no /run/systemd/network/10-netplan-pfe.network: /run/systemd/network/10-netplan-pfe.network:[Network] /run/systemd/network/10-netplan-pfe.network:DHCP=yes /run/systemd/network/10-netplan-pfe.network:LinkLocalAddressing=ipv6 /run/systemd/network/10-netplan-pfe.network: /run/systemd/network/10-netplan-pfe.network:[DHCP] /run/systemd/network/10-netplan-pfe.network:RouteMetric=100 /run/systemd/network/10-netplan-pfe.network:UseMTU=true eth0 is configured: ubuntu@ubuntu:~$ networkctl list IDX LINK TYPE OPERATIONAL SETUP 1 loloopback carrier unmanaged 2 eth0 etherroutableconfigured 3 can0 can off unmanaged 4 can1 can off unmanaged 5 llcecan0 can off unmanaged 6 llcecan1 can off unmanaged 7 llcecan2 can off unmanaged 8 llcecan3 can off unmanaged 9 llcecan4 can off unmanaged 10 llcecan5 can off unmanaged 11 llcecan6 can off unmanaged 12 llcecan7 can off unmanaged 13 llcecan8 can off unmanaged 14 llcecan9 can off unmanaged 15 llcecan10 can off unmanaged 16 llcecan11 can off unmanaged 17 llcecan13 can off unmanaged 18 llcecan14 can off unmanaged 19 llcecan15 can off unmanaged 20 pfe0 etherdegradedconfiguring 21 pfe1 etherno-carrier configuring 22 pfe2 etherno-carrier configuring 22 links listed. systemd-networkd-wait-online times out: ubuntu@ubuntu:~$ sudo SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd-wait-online --timeout=10 Found link 22 Found link 21 Found link 20 Found link 19 Found link 18 Found link 17 Found link 16 Found link 15 Found link 14 Found link 13 Found link 12 Found link 11 Found link 10 Found link 9 Found link 8 Found link 7 Found link 6 Found link 5 Found link 4 Found link 3 Found link 2 Found link 1 llcecan2: link is not managed by networkd (yet?). llcecan0: link is not managed by networkd (yet?). llcecan7: link is not managed by networkd (yet?). llcecan9: link is not managed by networkd (yet?). llcecan4: link is not managed by networkd (yet?). llcecan10: link is not managed by networkd (yet?). pfe1: link is ignored can0: link is not managed by networkd (yet?). pfe0: link is ignored llcecan3: link is not managed by networkd (yet?). eth0: link is ignored llcecan11: link is not managed by networkd (yet?). llcecan6: link is not managed by networkd (yet?). lo: link is ignored llcecan13: link is not managed by networkd (yet?). llcecan1: link is not managed by networkd (yet?). can1: link is not managed by networkd (yet?). pfe2: link is ignored llcecan14: link is not managed by networkd (yet?). llcecan8: link is not managed by networkd (yet?). llcecan15: link is not managed by networkd (yet?). llcecan5: link is not managed by networkd (yet?). Timeout occurred while waiting for network connectivity. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: Invalid Status in systemd source package in Jammy: Fix Committed Status in systemd source
[Touch-packages] [Bug 2022927] Re: Busybox mount fails to mount Snaps
@paelzer unfortunately I've had no response yet from the mailing list regarding this... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/2022927 Title: Busybox mount fails to mount Snaps Status in busybox package in Ubuntu: New Bug description: Snapd tries to mount squashfs Snaps with non-standard mount flags like "x-gdu.hide" and "x-gvfs-hide", both of which are used to indicate to userspace programs that a given mount should not be shown in a list of mounted partitions/filesystems. Busybox does not support these flags, and so fails with "Invalid argument". $ sudo busybox mount -t tmpfs -o x-gdu-hide test /tmp/test mount: mounting test on /tmp/test failed: Invalid argument These flags can likely be be safely ignored, as they don't actually affect the functionality of the mount. This goes for all mount options starting with "x-", as these generally denote non-standard mount option "extensions". I've created a patch against Busybox which adds an optional configuration item to ignore all mount options beginning with "x-". An additional verbose option has also been added to enable the ability to report that the mount flags have been ignored, rather than silently ignoring them. This is a requirement for a customer project, where we are limited to using Busybox (due to coreutils' GPL-3.0 licence) but would also require using Snaps like checkbox for testing and verification. This was posted on the Busybox mailing list a few months ago (http://lists.busybox.net/pipermail/busybox/2023-March/090202.html) but patch acceptance there seems to take quite a long time, and we need this for the customer. A PPA containing the patched Busybox version is available on the project's Launchpad team: https://launchpad.net/~nemos- team/+archive/ubuntu/ppa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2022927/+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 2022927] Re: Busybox mount fails to mount Snaps
Thanks @paelzer I'll try to follow it up on the BB mailing list -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/2022927 Title: Busybox mount fails to mount Snaps Status in busybox package in Ubuntu: New Bug description: Snapd tries to mount squashfs Snaps with non-standard mount flags like "x-gdu.hide" and "x-gvfs-hide", both of which are used to indicate to userspace programs that a given mount should not be shown in a list of mounted partitions/filesystems. Busybox does not support these flags, and so fails with "Invalid argument". $ sudo busybox mount -t tmpfs -o x-gdu-hide test /tmp/test mount: mounting test on /tmp/test failed: Invalid argument These flags can likely be be safely ignored, as they don't actually affect the functionality of the mount. This goes for all mount options starting with "x-", as these generally denote non-standard mount option "extensions". I've created a patch against Busybox which adds an optional configuration item to ignore all mount options beginning with "x-". An additional verbose option has also been added to enable the ability to report that the mount flags have been ignored, rather than silently ignoring them. This is a requirement for a customer project, where we are limited to using Busybox (due to coreutils' GPL-3.0 licence) but would also require using Snaps like checkbox for testing and verification. This was posted on the Busybox mailing list a few months ago (http://lists.busybox.net/pipermail/busybox/2023-March/090202.html) but patch acceptance there seems to take quite a long time, and we need this for the customer. A PPA containing the patched Busybox version is available on the project's Launchpad team: https://launchpad.net/~nemos- team/+archive/ubuntu/ppa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2022927/+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 2022927] Re: Busybox mount fails to mount Snaps
Hi Lucas, thanks for the assistance. Here's the .debdiff without the ~ppa2 suffix. I opted to go with ubuntu2 because it's not really a security fix, so I wasn't sure if it's really appropriate to add the security .1 suffix. The .debdiff is valid for both lunar and mantic, as mantic is still using the same version as lunar (see https://git.launchpad.net/ubuntu/+source/busybox/tree/debian/changelog?h=ubuntu/mantic), and still has the same series. Our customer doesn't need jammy, so we don't need to go through the SRU process for this - just getting it into the latest development release is fine. ** Patch added: "busybox-1.35.0-4ubuntu2.debdiff" https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2022927/+attachment/5680138/+files/busybox-1.35.0-4ubuntu2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/2022927 Title: Busybox mount fails to mount Snaps Status in busybox package in Ubuntu: New Bug description: Snapd tries to mount squashfs Snaps with non-standard mount flags like "x-gdu.hide" and "x-gvfs-hide", both of which are used to indicate to userspace programs that a given mount should not be shown in a list of mounted partitions/filesystems. Busybox does not support these flags, and so fails with "Invalid argument". $ sudo busybox mount -t tmpfs -o x-gdu-hide test /tmp/test mount: mounting test on /tmp/test failed: Invalid argument These flags can likely be be safely ignored, as they don't actually affect the functionality of the mount. This goes for all mount options starting with "x-", as these generally denote non-standard mount option "extensions". I've created a patch against Busybox which adds an optional configuration item to ignore all mount options beginning with "x-". An additional verbose option has also been added to enable the ability to report that the mount flags have been ignored, rather than silently ignoring them. This is a requirement for a customer project, where we are limited to using Busybox (due to coreutils' GPL-3.0 licence) but would also require using Snaps like checkbox for testing and verification. This was posted on the Busybox mailing list a few months ago (http://lists.busybox.net/pipermail/busybox/2023-March/090202.html) but patch acceptance there seems to take quite a long time, and we need this for the customer. A PPA containing the patched Busybox version is available on the project's Launchpad team: https://launchpad.net/~nemos- team/+archive/ubuntu/ppa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2022927/+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 2022927] Re: Busybox mount fails to mount Snaps
.debdiff for the new version "1:1.35.0-4ubuntu2~ppa2" attached. I've also updated the configs to include the change by default. The built packages are available here: https://launchpad.net/~nemos- team/+archive/ubuntu/ppa Test results: (lunar-amd64)itrue@Isaac-Laptop:~/tmp$ sudo busybox mount -t tmpfs -o size=128M,x-test,x-hide x tmp mount: ignoring unsupported option: x-test mount: ignoring unsupported option: x-hide (lunar-amd64)itrue@Isaac-Laptop:~/tmp$ sudo busybox mount ... snip ... x on /home/itrue/tmp/tmp type tmpfs (rw,relatime,size=131072k,inode64) ** Patch added: "busybox-1.35.0-4ubuntu2~ppa2.debdiff" https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2022927/+attachment/5678474/+files/busybox-1.35.0-4ubuntu2~ppa2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/2022927 Title: Busybox mount fails to mount Snaps Status in busybox package in Ubuntu: New Bug description: Snapd tries to mount squashfs Snaps with non-standard mount flags like "x-gdu.hide" and "x-gvfs-hide", both of which are used to indicate to userspace programs that a given mount should not be shown in a list of mounted partitions/filesystems. Busybox does not support these flags, and so fails with "Invalid argument". $ sudo busybox mount -t tmpfs -o x-gdu-hide test /tmp/test mount: mounting test on /tmp/test failed: Invalid argument These flags can likely be be safely ignored, as they don't actually affect the functionality of the mount. This goes for all mount options starting with "x-", as these generally denote non-standard mount option "extensions". I've created a patch against Busybox which adds an optional configuration item to ignore all mount options beginning with "x-". An additional verbose option has also been added to enable the ability to report that the mount flags have been ignored, rather than silently ignoring them. This is a requirement for a customer project, where we are limited to using Busybox (due to coreutils' GPL-3.0 licence) but would also require using Snaps like checkbox for testing and verification. This was posted on the Busybox mailing list a few months ago (http://lists.busybox.net/pipermail/busybox/2023-March/090202.html) but patch acceptance there seems to take quite a long time, and we need this for the customer. A PPA containing the patched Busybox version is available on the project's Launchpad team: https://launchpad.net/~nemos- team/+archive/ubuntu/ppa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2022927/+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 2022927] Re: Busybox mount fails to mount Snaps
Hi Bryce, Great, thanks for the advice. I've made the changes you requested (and updated the patch after I realised it was an older version...) and I'm testing it now. I'll upload the .debdiff once I'm done. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/2022927 Title: Busybox mount fails to mount Snaps Status in busybox package in Ubuntu: New Bug description: Snapd tries to mount squashfs Snaps with non-standard mount flags like "x-gdu.hide" and "x-gvfs-hide", both of which are used to indicate to userspace programs that a given mount should not be shown in a list of mounted partitions/filesystems. Busybox does not support these flags, and so fails with "Invalid argument". $ sudo busybox mount -t tmpfs -o x-gdu-hide test /tmp/test mount: mounting test on /tmp/test failed: Invalid argument These flags can likely be be safely ignored, as they don't actually affect the functionality of the mount. This goes for all mount options starting with "x-", as these generally denote non-standard mount option "extensions". I've created a patch against Busybox which adds an optional configuration item to ignore all mount options beginning with "x-". An additional verbose option has also been added to enable the ability to report that the mount flags have been ignored, rather than silently ignoring them. This is a requirement for a customer project, where we are limited to using Busybox (due to coreutils' GPL-3.0 licence) but would also require using Snaps like checkbox for testing and verification. This was posted on the Busybox mailing list a few months ago (http://lists.busybox.net/pipermail/busybox/2023-March/090202.html) but patch acceptance there seems to take quite a long time, and we need this for the customer. A PPA containing the patched Busybox version is available on the project's Launchpad team: https://launchpad.net/~nemos- team/+archive/ubuntu/ppa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2022927/+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 2022927] [NEW] Busybox mount fails to mount Snaps
Public bug reported: Snapd tries to mount squashfs Snaps with non-standard mount flags like "x-gdu.hide" and "x-gvfs-hide", both of which are used to indicate to userspace programs that a given mount should not be shown in a list of mounted partitions/filesystems. Busybox does not support these flags, and so fails with "Invalid argument". $ sudo busybox mount -t tmpfs -o x-gdu-hide test /tmp/test mount: mounting test on /tmp/test failed: Invalid argument These flags can likely be be safely ignored, as they don't actually affect the functionality of the mount. This goes for all mount options starting with "x-", as these generally denote non-standard mount option "extensions". I've created a patch against Busybox which adds an optional configuration item to ignore all mount options beginning with "x-". An additional verbose option has also been added to enable the ability to report that the mount flags have been ignored, rather than silently ignoring them. This is a requirement for a customer project, where we are limited to using Busybox (due to coreutils' GPL-3.0 licence) but would also require using Snaps like checkbox for testing and verification. This was posted on the Busybox mailing list a few months ago (http://lists.busybox.net/pipermail/busybox/2023-March/090202.html) but patch acceptance there seems to take quite a long time, and we need this for the customer. A PPA containing the patched Busybox version is available on the project's Launchpad team: https://launchpad.net/~nemos- team/+archive/ubuntu/ppa ** Affects: busybox (Ubuntu) Importance: Undecided Status: New ** Patch added: "busybox-1.35.0-4ubuntu1ppa5.debdiff" https://bugs.launchpad.net/bugs/2022927/+attachment/5677880/+files/busybox-1.35.0-4ubuntu1ppa5.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/2022927 Title: Busybox mount fails to mount Snaps Status in busybox package in Ubuntu: New Bug description: Snapd tries to mount squashfs Snaps with non-standard mount flags like "x-gdu.hide" and "x-gvfs-hide", both of which are used to indicate to userspace programs that a given mount should not be shown in a list of mounted partitions/filesystems. Busybox does not support these flags, and so fails with "Invalid argument". $ sudo busybox mount -t tmpfs -o x-gdu-hide test /tmp/test mount: mounting test on /tmp/test failed: Invalid argument These flags can likely be be safely ignored, as they don't actually affect the functionality of the mount. This goes for all mount options starting with "x-", as these generally denote non-standard mount option "extensions". I've created a patch against Busybox which adds an optional configuration item to ignore all mount options beginning with "x-". An additional verbose option has also been added to enable the ability to report that the mount flags have been ignored, rather than silently ignoring them. This is a requirement for a customer project, where we are limited to using Busybox (due to coreutils' GPL-3.0 licence) but would also require using Snaps like checkbox for testing and verification. This was posted on the Busybox mailing list a few months ago (http://lists.busybox.net/pipermail/busybox/2023-March/090202.html) but patch acceptance there seems to take quite a long time, and we need this for the customer. A PPA containing the patched Busybox version is available on the project's Launchpad team: https://launchpad.net/~nemos- team/+archive/ubuntu/ppa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2022927/+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 1994146] Re: [SRU] apparmor - Focal, Jammy
Hi Łukasz, Thanks for the update. What's the status of the focal SRU? That's the time-critical one for our customer. Cheers, Isaac -- 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/1994146 Title: [SRU] apparmor - Focal, Jammy Status in apparmor package in Ubuntu: Confirmed Status in apparmor source package in Focal: Fix Committed Status in apparmor source package in Jammy: Fix Committed Bug description: [ Impact ] This is a SRU proposal for apparmor in Focal and Jammy. For focal, we want to SRU fixes for Bug 1964636 which introduces the capability upstream patches. We are also fixing Bug 1728130 and Bug 1993353 which are introducing full backport of abi from apparmor-3.0 and support for POSIX message queue rules, which are both a request from Honeywell. Note that specifically for message queue rules, we are overriding the abi behavior. Message queue mediation is not a part of the 2.13 abi we are pinning. Honeywell has a kernel that has message queue mediation, but their policy does not contain an abi specified, so when we pin the abi for a kernel that does not mediate message queue, it will break Honeywell's AppArmor policies. So we are making an exception: when abi is not specified in the policy, and the policy contain mqueue rules, we are enforcing mqueue rules. When the policy does not contain mqueue rules, then they are not being enforced. This is so we do not break Honeywell policies and we also are not breaking policies that were developed when there was no mqueue or abi support. For jammy, we are SRUing fixes for Bug 1993353 which adds message queue rules support. [ Test Plan ] This has been extensively tested by using QA Regression Tests[1] for AppArmor. All tests have passed and demonstrated AppArmor to be working as expected. We are also adding regression tests for message queue rules[2] which guarantees it is working as expected. [1] https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py [2] https://gitlab.com/apparmor/apparmor/-/merge_requests/858 [ Where problems could occur ] The message queue rules support could cause issues for AppArmor policies that were developed before there was support for mqueues, that's why we are also backporting abi support and pinning the abi on parser.conf on focal. Jammy already has the abi pinned for a kernel that does not have support for mqueue mediation. [ Other Info ] The patches for both focal and jammy can be found at: https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1994146/+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 1994146] Re: [SRU] apparmor - Focal, Jammy
Hi Ijlal, That's correct - the SRU to focal (and thus core 20) is the important one for the customer. Cheers, Isaac -- 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/1994146 Title: [SRU] apparmor - Focal, Jammy Status in apparmor package in Ubuntu: Confirmed Status in apparmor source package in Focal: In Progress Status in apparmor source package in Jammy: Incomplete Bug description: [ Impact ] This is a SRU proposal for apparmor in Focal and Jammy. For focal, we want to SRU fixes for Bug 1964636 which introduces the capability upstream patches. We are also fixing Bug 1728130 and Bug 1993353 which are introducing full backport of abi from apparmor-3.0 and support for POSIX message queue rules, which are both a request from Honeywell. Note that specifically for message queue rules, we are overriding the abi behavior. Message queue mediation is not a part of the 2.13 abi we are pinning. Honeywell has a kernel that has message queue mediation, but their policy does not contain an abi specified, so when we pin the abi for a kernel that does not mediate message queue, it will break Honeywell's AppArmor policies. So we are making an exception: when abi is not specified in the policy, and the policy contain mqueue rules, we are enforcing mqueue rules. When the policy does not contain mqueue rules, then they are not being enforced. This is so we do not break Honeywell policies and we also are not breaking policies that were developed when there was no mqueue or abi support. For jammy, we are SRUing fixes for Bug 1993353 which adds message queue rules support. [ Test Plan ] This has been extensively tested by using QA Regression Tests[1] for AppArmor. All tests have passed and demonstrated AppArmor to be working as expected. We are also adding regression tests for message queue rules[2] which guarantees it is working as expected. [1] https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py [2] https://gitlab.com/apparmor/apparmor/-/merge_requests/858 [ Where problems could occur ] The message queue rules support could cause issues for AppArmor policies that were developed before there was support for mqueues, that's why we are also backporting abi support and pinning the abi on parser.conf on focal. Jammy already has the abi pinned for a kernel that does not have support for mqueue mediation. [ Other Info ] The patches for both focal and jammy can be found at: https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1994146/+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 1994146] Re: [SRU] apparmor - Focal, Jammy
Hi Steve, Just wanted to mention that this is a very time-critical feature requirement for one of our customers on Core 20, so we would really appreciate this if you could please treat this as very high priority. Please feel free to reach out to me on MM if you have any questions. Cheers, Isaac -- 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/1994146 Title: [SRU] apparmor - Focal, Jammy Status in apparmor package in Ubuntu: Confirmed Status in apparmor source package in Focal: In Progress Status in apparmor source package in Jammy: Incomplete Bug description: [ Impact ] This is a SRU proposal for apparmor in Focal and Jammy. For focal, we want to SRU fixes for Bug 1964636 which introduces the capability upstream patches. We are also fixing Bug 1728130 and Bug 1993353 which are introducing full backport of abi from apparmor-3.0 and support for POSIX message queue rules, which are both a request from Honeywell. Note that specifically for message queue rules, we are overriding the abi behavior. Message queue mediation is not a part of the 2.13 abi we are pinning. Honeywell has a kernel that has message queue mediation, but their policy does not contain an abi specified, so when we pin the abi for a kernel that does not mediate message queue, it will break Honeywell's AppArmor policies. So we are making an exception: when abi is not specified in the policy, and the policy contain mqueue rules, we are enforcing mqueue rules. When the policy does not contain mqueue rules, then they are not being enforced. This is so we do not break Honeywell policies and we also are not breaking policies that were developed when there was no mqueue or abi support. For jammy, we are SRUing fixes for Bug 1993353 which adds message queue rules support. [ Test Plan ] This has been extensively tested by using QA Regression Tests[1] for AppArmor. All tests have passed and demonstrated AppArmor to be working as expected. We are also adding regression tests for message queue rules[2] which guarantees it is working as expected. [1] https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py [2] https://gitlab.com/apparmor/apparmor/-/merge_requests/858 [ Where problems could occur ] The message queue rules support could cause issues for AppArmor policies that were developed before there was support for mqueues, that's why we are also backporting abi support and pinning the abi on parser.conf on focal. Jammy already has the abi pinned for a kernel that does not have support for mqueue mediation. [ Other Info ] The patches for both focal and jammy can be found at: https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1994146/+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 1995137] Re: Add "sun4i-drm_dri.so" to libg1-mesa-dri and fix compilation on riscv64
Prebuilt packages for riscv64 are available in this PPA: https://launchpad.net/~itrue/+archive/ubuntu/mesa-riscv64 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1995137 Title: Add "sun4i-drm_dri.so" to libg1-mesa-dri and fix compilation on riscv64 Status in mesa package in Ubuntu: New Bug description: "sun4i-drm_dri.so" is needed for some RISC-V platforms such as the Allwinner D1. This file is missing from the riscv64 packages, but present on others. This affects (at least) 20.04 and 22.04. itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_arm64.deb | grep _dri.so *snip* hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/sun4i-drm_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so *snip* itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_riscv64.deb | grep _dri.so -rw-r--r-- root/root 16498024 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so -rw-r--r-- root/root 4692400 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r200_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r300_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r600_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeon_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeonsi_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/swrast_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/virtio_gpu_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/zink_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1995137/+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 1995137] Re: Add "sun4i-drm_dri.so" and fix compilation of libg1-mesa-dri on riscv64
** Summary changed: - "sun4i-drm_dri.so" is missing from libg1-mesa-dri on riscv64 + Add "sun4i-drm_dri.so" and fix compilation of libg1-mesa-dri on riscv64 ** Summary changed: - Add "sun4i-drm_dri.so" and fix compilation of libg1-mesa-dri on riscv64 + Add "sun4i-drm_dri.so" to libg1-mesa-dri and fix compilation on riscv64 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1995137 Title: Add "sun4i-drm_dri.so" to libg1-mesa-dri and fix compilation on riscv64 Status in mesa package in Ubuntu: New Bug description: "sun4i-drm_dri.so" is needed for some RISC-V platforms such as the Allwinner D1. This file is missing from the riscv64 packages, but present on others. This affects (at least) 20.04 and 22.04. itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_arm64.deb | grep _dri.so *snip* hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/sun4i-drm_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so *snip* itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_riscv64.deb | grep _dri.so -rw-r--r-- root/root 16498024 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so -rw-r--r-- root/root 4692400 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r200_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r300_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r600_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeon_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeonsi_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/swrast_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/virtio_gpu_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/zink_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1995137/+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 1995137] Re: "sun4i-drm_dri.so" is missing from libg1-mesa-dri on riscv64
The attached patch disables usage of LLVM JIT on riscv64, which was causing the error I reported in comment #3. I obtained this patch from the following Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004039 This patch, combined with the previous one, seems to work well on the Sipeed Lichee RV board. I have tested this with ubuntu-frame and a custom-built mesa-core20 snap containing the drivers built using these patches. ** Bug watch added: Debian Bug tracker #1004039 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004039 ** Patch added: "mesa-disable-llvm-riscv64.debdiff" https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1995137/+attachment/5630389/+files/mesa-disable-llvm-riscv64.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1995137 Title: "sun4i-drm_dri.so" is missing from libg1-mesa-dri on riscv64 Status in mesa package in Ubuntu: New Bug description: "sun4i-drm_dri.so" is needed for some RISC-V platforms such as the Allwinner D1. This file is missing from the riscv64 packages, but present on others. This affects (at least) 20.04 and 22.04. itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_arm64.deb | grep _dri.so *snip* hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/sun4i-drm_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so *snip* itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_riscv64.deb | grep _dri.so -rw-r--r-- root/root 16498024 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so -rw-r--r-- root/root 4692400 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r200_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r300_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r600_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeon_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeonsi_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/swrast_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/virtio_gpu_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/zink_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1995137/+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 1995137] Re: "sun4i-drm_dri.so" is missing from libg1-mesa-dri on riscv64
Using this library results in the following error: 'generic' is not a recognized processor for this target (ignoring processor) 'generic' is not a recognized processor for this target (ignoring processor) WARNING: This target JIT is not designed for the host you are running. If bad things happen, please choose a different -march switch. 'generic' is not a recognized processor for this target (ignoring processor) 'generic' is not a recognized processor for this target (ignoring processor) 'generic' is not a recognized processor for this target (ignoring processor) 'generic' is not a recognized processor for this target (ignoring processor) 'generic' is not a recognized processor for this target (ignoring processor) 'generic' is not a recognized processor for this target (ignoring processor) 'generic' is not a recognized processor for this target (ignoring processor) 'generic' is not a recognized processor for this target (ignoring processor) LLVM ERROR: Cannot select: 0x3fa81e7fa8: ch = store<(store 4 into %ir.mask_ptr1 + 12, basealign 16), trunc to i32> 0x3fa81eadd0, 0x3fa81eea00, 0x3fa81b3358, undef:i64 0x3fa81eea00: i64 = sub Constant:i64<0>, 0x3fa81e7c68 0x3fa81b59a8: i64 = Constant<0> 0x3fa81e7c68: i64 = and 0x3fa81e7ed8, Constant:i64<1> 0x3fa81e7ed8: i64 = srl 0x3fa81e9430, Constant:i64<7> 0x3fa81e9430: i64,ch = load<(load 2 from %fixed-stack.5, align 8), zext from i16> 0x3fa80c34b8, FrameIndex:i64<-2>, undef:i64 0x3fa81b2e78: i64 = FrameIndex<-2> 0x3fa81b2da8: i64 = undef 0x3fa81e7e70: i64 = Constant<7> 0x3fa81b5a78: i64 = Constant<1> 0x3fa81b3358: i64 = add FrameIndex:i64<6>, Constant:i64<28> 0x3fa81b34f8: i64 = FrameIndex<6> 0x3fa8217440: i64 = Constant<28> 0x3fa81b2da8: i64 = undef In function: fs_variant_partial !!! Fatal signal received. Attempting cleanup, but deadlock may occur pure virtual method called terminate called without an active exception !!! Fatal signal received. Attempting cleanup, but deadlock may occur Mir fatal error: Unsupported attempt to continue after a fatal signal: SIGABRT Seems similar to https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1993800 but probably unrelated -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1995137 Title: "sun4i-drm_dri.so" is missing from libg1-mesa-dri on riscv64 Status in mesa package in Ubuntu: New Bug description: "sun4i-drm_dri.so" is needed for some RISC-V platforms such as the Allwinner D1. This file is missing from the riscv64 packages, but present on others. This affects (at least) 20.04 and 22.04. itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_arm64.deb | grep _dri.so *snip* hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/sun4i-drm_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so *snip* itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_riscv64.deb | grep _dri.so -rw-r--r-- root/root 16498024 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so -rw-r--r-- root/root 4692400 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r200_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r300_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r600_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeon_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeonsi_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/swrast_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/virtio_gpu_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/zink_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1995137/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe :
[Touch-packages] [Bug 1995137] Re: "sun4i-drm_dri.so" is missing from libg1-mesa-dri on riscv64
The attached debdiff enables building the lima driver on riscv64. This drivers provides sun4i-drm_dri.so. I'm currently testing this locally and waiting on riscv64 to be enabled for my PPA to build a package on LP. ** Patch added: "mesa-build-lima-on-riscv64.debdiff" https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1995137/+attachment/5630053/+files/mesa-build-lima-on-riscv64.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1995137 Title: "sun4i-drm_dri.so" is missing from libg1-mesa-dri on riscv64 Status in mesa package in Ubuntu: New Bug description: "sun4i-drm_dri.so" is needed for some RISC-V platforms such as the Allwinner D1. This file is missing from the riscv64 packages, but present on others. This affects (at least) 20.04 and 22.04. itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_arm64.deb | grep _dri.so *snip* hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/sun4i-drm_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so *snip* itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_riscv64.deb | grep _dri.so -rw-r--r-- root/root 16498024 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so -rw-r--r-- root/root 4692400 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r200_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r300_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r600_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeon_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeonsi_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/swrast_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/virtio_gpu_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/zink_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1995137/+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 1995137] [NEW] "sun4i-drm_dri.so" is missing from libg1-mesa-dri on riscv64
Public bug reported: "sun4i-drm_dri.so" is needed for some RISC-V platforms such as the Allwinner D1. This file is missing from the riscv64 packages, but present on others. This affects (at least) 20.04 and 22.04. itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_arm64.deb | grep _dri.so *snip* hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/sun4i-drm_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so *snip* itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_riscv64.deb | grep _dri.so -rw-r--r-- root/root 16498024 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so -rw-r--r-- root/root 4692400 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r200_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r300_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/r600_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeon_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/nouveau_vieux_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/radeonsi_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/swrast_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/virtio_gpu_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/riscv64-linux-gnu/dri/zink_dri.so link to ./usr/lib/riscv64-linux-gnu/dri/kms_swrast_dri.so ** Affects: mesa (Ubuntu) Importance: Undecided Status: New ** Description changed: "sun4i-drm_dri.so" is needed for some RISC-V platforms such as the Allwinner D1. This file is missing from the riscv64 packages, but present on others. This affects (at least) 20.04 and 22.04. itrue@lxc-focal ~/tmp> dpkg -c libgl1-mesa-dri_21.2.6-0ubuntu0.1~20.04.2_arm64.deb | grep _dri.so - -rw-r--r-- root/root 23619952 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/d3d12_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/etnaviv_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/exynos_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/hx8357d_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/ili9225_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/ili9341_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/imx-dcss_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/imx-drm_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/ingenic-drm_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/kgsl_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/kms_swrast_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/lima_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/mali-dp_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/mcde_dri.so link to ./usr/lib/aarch64-linux-gnu/dri/armada-drm_dri.so - hrw-r--r-- root/root 0 2022-03-08 16:37 ./usr/lib/aarch64-linux-gnu/dri/mediatek_dri.so link to
[Touch-packages] [Bug 1964100] Re: Cannot connect to open WLAN with 1.36.0-1ubuntu2 on Jammy
Hi @seb128, Sorry I haven't yet had the chance to test it with GNOME, but I can confirm that it works if I manually add the connection with nmcli, without adding any particular arguments: nmcli c add type wifi ssid "" It does seem to indeed be an issue with plasma-nm. Cheers, Isaac -- 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/1964100 Title: Cannot connect to open WLAN with 1.36.0-1ubuntu2 on Jammy Status in network-manager package in Ubuntu: Incomplete Bug description: I'm trying to connect to an open (i.e. no ecryption) WLAN with network-manager 1.36.0-1ubuntu2 on 22.04 but it's failing with the following error message (after selecting the network from the network- manager applet prompt): Mär 08 10:50:04 Isaac-Laptop NetworkManager[31754]: [1646733004.4425] audit: op="connection-add-activate" pid=12122 uid=1000 result="fail" reason="802-11-wireless-security.key-mgmt: Access point does not support PSK but setting requires it" I haven't changed any of the default settings for network-manager and this network worked on 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1964100/+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 1964100] Re: Cannot connect to open WLAN with 1.36.0-1ubuntu2 on Jammy
This seems to be related to OWE (https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encryption). If I disable this in the router, then I can connect without any issues. -- 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/1964100 Title: Cannot connect to open WLAN with 1.36.0-1ubuntu2 on Jammy Status in network-manager package in Ubuntu: Incomplete Bug description: I'm trying to connect to an open (i.e. no ecryption) WLAN with network-manager 1.36.0-1ubuntu2 on 22.04 but it's failing with the following error message (after selecting the network from the network- manager applet prompt): Mär 08 10:50:04 Isaac-Laptop NetworkManager[31754]: [1646733004.4425] audit: op="connection-add-activate" pid=12122 uid=1000 result="fail" reason="802-11-wireless-security.key-mgmt: Access point does not support PSK but setting requires it" I haven't changed any of the default settings for network-manager and this network worked on 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1964100/+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 1964100] Re: Cannot connect to open WLAN with 1.36.0-1ubuntu2 on Jammy
I've attached the journalctl output. I'm running Kubuntu with plasma-nm 5.24.2-0ubuntu1. I haven't provided a certificate or any authentication details, and the security is set to none in the settings. ** Attachment added: "log" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1964100/+attachment/5567059/+files/log -- 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/1964100 Title: Cannot connect to open WLAN with 1.36.0-1ubuntu2 on Jammy Status in network-manager package in Ubuntu: Incomplete Bug description: I'm trying to connect to an open (i.e. no ecryption) WLAN with network-manager 1.36.0-1ubuntu2 on 22.04 but it's failing with the following error message (after selecting the network from the network- manager applet prompt): Mär 08 10:50:04 Isaac-Laptop NetworkManager[31754]: [1646733004.4425] audit: op="connection-add-activate" pid=12122 uid=1000 result="fail" reason="802-11-wireless-security.key-mgmt: Access point does not support PSK but setting requires it" I haven't changed any of the default settings for network-manager and this network worked on 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1964100/+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 1964100] [NEW] Cannot connect to open WLAN with 1.36.0-1ubuntu2 on Jammy
Public bug reported: I'm trying to connect to an open (i.e. no ecryption) WLAN with network- manager 1.36.0-1ubuntu2 on 22.04 but it's failing with the following error message (after selecting the network from the network-manager applet prompt): Mär 08 10:50:04 Isaac-Laptop NetworkManager[31754]: [1646733004.4425] audit: op="connection-add-activate" pid=12122 uid=1000 result="fail" reason="802-11-wireless-security.key-mgmt: Access point does not support PSK but setting requires it" I haven't changed any of the default settings for network-manager and this network worked on 20.04. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: jammy -- 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/1964100 Title: Cannot connect to open WLAN with 1.36.0-1ubuntu2 on Jammy Status in network-manager package in Ubuntu: New Bug description: I'm trying to connect to an open (i.e. no ecryption) WLAN with network-manager 1.36.0-1ubuntu2 on 22.04 but it's failing with the following error message (after selecting the network from the network- manager applet prompt): Mär 08 10:50:04 Isaac-Laptop NetworkManager[31754]: [1646733004.4425] audit: op="connection-add-activate" pid=12122 uid=1000 result="fail" reason="802-11-wireless-security.key-mgmt: Access point does not support PSK but setting requires it" I haven't changed any of the default settings for network-manager and this network worked on 20.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1964100/+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
