[Touch-packages] [Bug 2032991] Re: NetworkManager does not complete DHCP negotiation
[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.] ** Changed in: network-manager (Ubuntu) Status: Incomplete => Expired -- 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/2032991 Title: NetworkManager does not complete DHCP negotiation Status in network-manager package in Ubuntu: Expired Bug description: I run into a problem today where NetworkManager suddenly stopped configuring network interfaces - it would ask DHCP server for an IP address, the say negotiation failed and then do this again in a loop. This happened on a built-in wired interface, and also on a USB ethernet dongle that I plugged in. Turns out the cause was that I run "dhclient -v" to try to force DHCP client to renew the lease. Apparently, dhclient creates directory "/run/network" and if this directory is present the NetworkManager refuses to accept DHCP server proposals. This happens even after server restart, and with no dhclient running - just the presence of /run/network is enough to cause the problem. Removing the directory "/run/network" fixes the issue. I imagine quite a few people run into this, because using dhclient to manually bring up an address is fairly common practice. I am using Ubuntu 22.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2032991/+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 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic
OK, thanks all! In that case, Aleksandr (or someone) please could you start by preparing a debdiff for noble to fix the issue there and add an appropriate autopkgtest as Stéphane recommends? While noble isn't open the SRU isn't strictly blocked on this, but we should at least have the upload ready to go. -- 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+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 2039868]
#98
The amdgpu.mcbp=0 will only help GFX9 products. For GFX10 this is a
different problem, please open at AMD Gitlab.
--
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/2039868
Title:
amdgpu reset during usage of firefox
Status in Linux:
Unknown
Status in linux package in Ubuntu:
Confirmed
Status in mesa package in Ubuntu:
New
Bug description:
Running nightly on 23.10 (since monday), I have been experiencing a
few amdgpu resets in the past hours
ProblemType: Bug
DistroRelease: Ubuntu 23.10
Package: linux-image-6.5.0-9-generic 6.5.0-9.9
ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
Uname: Linux 6.5.0-9-generic x86_64
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Thu Oct 19 18:26:43 2023
HibernationDevice: RESUME=/dev/mapper/vg--ubuntu-lv--ubuntu--swap
InstallationDate: Installed on 2022-07-04 (472 days ago)
InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64
(20220419)
MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
ProcEnviron:
LANG=fr_FR.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.5.0-9-generic
root=/dev/mapper/vg--ubuntu-lv--ubuntu--root ro rootflags=subvol=@ quiet splash
resume=/dev/mapper/vg--ubuntu-lv--ubuntu--swap vt.handoff=7
RelatedPackageVersions:
linux-restricted-modules-6.5.0-9-generic N/A
linux-backports-modules-6.5.0-9-generic N/A
linux-firmware 20230919.git3672ccab-0ubuntu2.1
SourcePackage: linux
UpgradeStatus: Upgraded to mantic on 2023-10-16 (3 days ago)
dmi.bios.date: 05/15/2023
dmi.bios.release: 1.24
dmi.bios.vendor: LENOVO
dmi.bios.version: R1MET54W (1.24 )
dmi.board.asset.tag: Not Available
dmi.board.name: 21A0CTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.24
dmi.modalias:
dmi:bvnLENOVO:bvrR1MET54W(1.24):bd05/15/2023:br1.24:efr1.24:svnLENOVO:pn21A0CTO1WW:pvrThinkPadP14sGen2a:rvnLENOVO:rn21A0CTO1WW:rvrNotDefined:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21A0_BU_Think_FM_ThinkPadP14sGen2a:
dmi.product.family: ThinkPad P14s Gen 2a
dmi.product.name: 21A0CTO1WW
dmi.product.sku: LENOVO_MT_21A0_BU_Think_FM_ThinkPad P14s Gen 2a
dmi.product.version: ThinkPad P14s Gen 2a
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/2039868/+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 2018996] Re: whoopsie uses 100% CPU indefinitely on chrome crash file
It is happening to me too. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/2018996 Title: whoopsie uses 100% CPU indefinitely on chrome crash file Status in whoopsie package in Ubuntu: New Bug description: $@ lsb_release -rd No LSB modules are available. Description:Ubuntu 23.04 Release:23.04 $@ apt-cache policy whoopsie whoopsie: Installed: 0.2.77 Candidate: 0.2.77 Version table: *** 0.2.77 500 500 http://jp.archive.ubuntu.com/ubuntu lunar/main amd64 Packages 100 /var/lib/dpkg/status TL;DR whoopsie will happily consume 100% for hours in what seems like a pretty futile attempt to deal with massive crash files. It should be more aware of what is a realistic crash to upload. This has happened a couple of times today, so I searched, found https://askubuntu.com/questions/1245078/woopsie-upload-all-process- consumes-cpu-100/1296481#1296481 which suggested looking in /var/crash/ where I found $@ ls -lh /var/crash/ total 8.3G -rw-r- 1 fergal whoopsie 8.3G May 8 23:03 _opt_google_chrome_chrome.1000.crash I don't know what whoopsie was doing but I doubt that was ever going to be productive and I cannot have a service that is going to occasionally use 100% CPU for hours. Here's what `top` had to say before I killed it 94802 root 20 0 11.7g 11.3g 58624 R 100.0 36.6 108:11.76 whoopsie-upload So it had been trying for 108 minutes and was using 11G of RAM. I would love to enable crash reporting but this is unacceptable. I've deleted the crash file and uninstalled whoopsie. I'll happily reinstall it if it gains some safeguards against this kind of thing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/2018996/+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 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic
> Looking at the changelog, it appears that Serge simply pulled all changes following 5.0.1 from git, which he likely did mistakenly looking at the master branch rather than the stable-5.0 branch which wouldn't have had that particular change. That sounds like exactly what I would do. -- 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+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 2039743] Re: Intermittent DHCP startup failure during boot due to potential race condition in interface renaming
** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2039743 Title: Intermittent DHCP startup failure during boot due to potential race condition in interface renaming Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Bug description: The server fails to start its network with DHCP seemingly randomly. It can take a few reboots to bring up the network. This causes issues where automated updates that trigger a reboot cause the server to go offline. I've attached syslog examples of both success and failure. My assumption is that the cause of this bug is a race condition where systemd is not waiting on the interface renaming. Notably, when it boots properly, it says: "Interface is under renaming, pending initialization." That message is not logged when it fails. The server uses cloud-init, and the cloud image provided by Ubuntu. Another possible explanation is the netplan configuration at /etc/netplan/50-cloud-init.yaml is: network: version: 2 ethernets: eth0: dhcp4: true match: macaddress: 92:00:00:00:43:6a set-name: eth0 Maybe set-name is redundant here, but it's the default configuration generated by cloud-init. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.21 ProcVersionSignature: Ubuntu 5.4.0-164.181-generic 5.4.248 Uname: Linux 5.4.0-164-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.27 Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Oct 18 16:22:57 2023 Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M MachineType: Slicie.com Slicie Cloud Server ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-164-generic root=UUID=f849f569-82f8-4fc0-9ac6-d4f7f7ef9609 ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1ubuntu1.1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-2.1 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1ubuntu1.1:bd04/01/2014:svnSlicie.com:pnSlicieCloudServer:pvr1.0.0:cvnQEMU:ct1:cvrpc-i440fx-2.1: dmi.product.name: Slicie Cloud Server dmi.product.version: 1.0.0 dmi.sys.vendor: Slicie.com To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2039743/+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 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic
This was definitely a mistake made when preparing the original LXC 5.0 snapshot for upload in Ubuntu. LXC_DEVEL=1 should only ever be set when dealing with current snapshots of the upstream codebase. Shipping an older snapshot with LXC_DEVEL=1 set will cause any tool that consumes liblxc and which needs to do feature detection to incorrectly expect that the liblxc version present on the system has that feature supported, at best causing build failures, at worst causing runtime crashes. I can certainly see how this mess was created with 5.0.0 as we had to push a pre-release snapshot to the archive and keep the build on autotools due to issues with meson at the time (resolved in 5.0.1). Using an upstream snapshot rather than a release tarball, caused the inclusion of the problematic LXC_DEVEL=1. What's quite puzzling is how we ended up with the 5.0.1 upload also having that LXC_DEVEL=1 bit be applied as a patch on top of it... Looking at the changelog, it appears that Serge simply pulled all changes following 5.0.1 from git, which he likely did mistakenly looking at the master branch rather than the stable-5.0 branch which wouldn't have had that particular change. My opinion is that we really need to: - Drop the LXC_DEVEL=1 cherry-pick from noble, ideally merge with Debian to pull in the more current 5.0.3 too. - Drop the LXC_DEVEL=1 cherry-pick from both mantic and lunar - Add a batch to drop LXC_DEVEL=1 from the git snapshot of 5.0 that's in jammy Additionally, I'd very strongly recommend that an autopkgtest test is added to validate that no liblxc package ever ship with LXC_DEVEL=1 ever again. -- 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+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 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic
>I meant the *Ubuntu* development release, not an upstream development >release. Ugh. If applied/ubuntu/devel is the right branch to check it then it is not fixed in the Ubuntu development release too. See: https://git.launchpad.net/ubuntu/+source/lxc/tree/meson.build?h=applied/ubuntu/devel#n33 At the same time in Debian: https://git.launchpad.net/ubuntu/+source/lxc/tree/meson.build?h=applied/debian/bookworm#n36 >I understand that, but that's not my question. You explained how it is >intended to be used. But how is it actually used? It is used precisely as it intended to be used (at least in the go-lxc) :) >Sure, but it is insufficient to consider just the reverse dependency >involved in the use case you're trying to fix. We must consider all >other reasonable use cases as well. Ok, let's take https://github.com/search?q=LXC_DEVEL=code As I can see from the search results there is no any other use cases for LXC_DEVEL anywhere except go-lxc. >For SRU purposes, it is not sufficient to rely on your "properly written >software" condition. We must also avoid regressing "improperly written >software" as much as we can in any change we make to a stable release. Sure, I agree. But I'm 99.999% sure that this change is safe :) >But this also suggests that there isn't actually a bug that impacts a >binary that is shipped by Ubuntu in Jammy It does not impacts a *binary*. But it impacts /usr/include/lxc/version.h file contents which is a part of a liblxc-dev package. >1) What use cases might be regressed as a result of this change, even >for software that is not "properly written". This is a hard requirement >for any stable release update in Ubuntu. Have done using https://github.com/search?q=LXC_DEVEL=code >2) In light of the above, what is an appropriate minimal way to fix the >issue. I believe that my fix is the minimal appropriate way to fix the issue. -- 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+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 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic
Sorry, I just hit send on a reply by accident on a reply before I was ready - I intended to postpone it instead. I need to go now but I will get back to this later and fix my reply. -- 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+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 2040051] Re: systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument"
Maybe it is nothing, but please not that the file path has changed with 23.10. It is not `/usr/lib/...` anymore, but only `/lib/...`. The error messages comes from https://github.com/systemd/systemd/blob/2c87b71b00523ef2aecdd2b68e61008b7d2e5ecc/src/network/wait- online/wait-online.c#L217 (and it is similar, though a different executable for bug #2040055). Moreover, `systemctl status` reports ● h2917298.stratoserver.net State: degraded Units: 220 loaded (incl. loaded aliases) Jobs: 0 queued Failed: 3 units Since: Sat 2023-10-21 15:43:27 CEST; 2 days ago systemd: 253.5-1ubuntu6 Tainted: unmerged-usr:cgroupsv1 Note that the line `Tainted: unmerged-usr` is new since 23.10. (The complaint about cgroupsv1 is really old and around since 21.04.) I know from another distro, that systemd has recently moved out everything from `/usr`. So maybe it has something to do with that, but it is really a shot in the dark. -- 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/2040051 Title: systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument" Status in systemd package in Ubuntu: Incomplete Bug description: # lsb_release -rd No LSB modules are available. Description:Ubuntu 23.10 Release:23.10 # aptitude show systemd Package: systemd Version: 253.5-1ubuntu6 State: installed systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument". This lets the corresponding service (systemd-networkd-wait- online.service) fail as well. The error also appears when one directly invokes /lib/systemd/systemd-networkd-wait-online from a shell. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2040051/+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
Re: [Touch-packages] [Bug 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic
On Mon, Oct 23, 2023 at 04:27:16PM -, Aleksandr Mikhalitsyn wrote: > >Has this been fixed in the development release, and if so, how? > > LXC_DEVEL is 1 in the development release: > https://github.com/lxc/lxc/blob/main/meson.build#L36 > > But LXC_DEVEL is 0 in *any* stable tag: > https://github.com/lxc/lxc/blob/lxc-5.0.3/meson.build#L36 I meant the *Ubuntu* development release, not an upstream development release. > >It's not clear to me that making this change is the appropriate thing > to do in an SRU. How is LXC_DEVEL used in practice? > > LXC_DEVEL is used to determine if the liblxc is a cutting-edge development > snapshot of the LXC or not. > So, it should be 1 *only* for the main branch of lxc. But in all stable > version it is 0. I understand that, but that's not my question. You explained how it is intended to be used. But how is it actually used? > > > Have you analysed known reverse dependencies to understand the impact > of making this change? What did you find? > > I have analyzed well-known reverse dependency go-lxc. It's used by LXD > to communicate with liblxc C API. Sure, but it is insufficient to consider just the reverse dependency involved in the use case you're trying to fix. We must consider all other reasonable use cases as well. > Speaking honestly, I have no idea about other good ways to fix this. And > this change seems to be a "minimal" for me because it does not change > LXC code (and should not) it's just a matter of having proper build > configuration. The risk is that some other project is dependent on this variable in some way that has not been considered and will break if the change is made. > I don't think that changing LXC_DEVEL to 0 can break any properly written > code. For example, Debian folks have it disabled: > https://git.launchpad.net/ubuntu/+source/lxc/tree/meson.build?h=applied/debian/bookworm#n36 For SRU purposes, it is not sufficient to rely on your "properly written software" condition. We must also avoid regressing "improperly written software" as much as we can in any change we make to a stable release. In other words, "your software was written improperly and therefore the fact that you, as a user, were regressed by our change to a stable Ubuntu release is your problem and we don't care" would be an unacceptable position to take if a user reported a regression as a result of making this change. > Of course, we can patch go-lxc (go-lxc also part of the LXC project). > But this will be a hacky and incorrect way to fix things. Ah, sorry, I had assumed that VERSION_AT_LEAST was being defined by the lxc source package. Nevertheless, a less-than-clean fix is what we sometimes need to do in stable releases to minimise regression risk to users. It can be gated on a build against a specific version to keep the solution clean for the future, though. For example, in your build system you could check if you're But this also suggests that there isn't actually a bug that impacts a binary that is shipped by Ubuntu in Jammy Please reconsider: 1) What use cases might be regressed as a result of this change, even for software that is not "properly written". This is a hard requirement for any stable release update in Ubuntu. 2) In light of the above, what is an appropriate minimal way to fix the issue. Right now, based on the information you've provided and the criteria you seem to have used for your analysis, it doesn't seem appropriate to make this change in a stable release in Ubuntu, so I'm marking the bug as Won't Fix for Jammy and unsubscribing ~ubuntu-sponsors. -- 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have
[Touch-packages] [Bug 2040055] Re: systemd-resolved fails: Failed to start query: Invalid argument
Unfortunately, increasing the log level to debug doesn't make any difference. I already tried the approach with the drop-in configuration file, but systemd-resolved doesn't log any additional information. It is basically the same "non-reaction" as in https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2040051/comments/3. Sorry, that I didn't mention that I already had tried to turn on debugging in the first place. -- 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/2040055 Title: systemd-resolved fails: Failed to start query: Invalid argument Status in systemd package in Ubuntu: Incomplete Bug description: # lsb_release -rd No LSB modules are available. Description:Ubuntu 23.10 Release:23.10 # aptitude show 'systemd-resolved' Package: systemd-resolved Version: 253.5-1ubuntu6 State: installed The system is unable to resolve any DNS names. Whenever a DNS name shall be resolved the following error appears in the journal Oct 21 15:50:32 my-host.my-domain.tld systemd-resolved[114]: Failed to start query: Invalid argument If one manually tries to resolve a DNS name from the local stub resolver via dig @127.0.0.53 A www.google.com. another error message is added to the journal. However, resolving a DNS name from the configured upstream DNS server works perfectly dig @81.169.163.106 A www.google.com. Returns a proper response. (Note, 81.169.163.106 is the internal DNS server from my hoster.) Some more infos # resolvectl Global Protocols: -LLMNR mDNS=resolve -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Current DNS Server: 81.169.163.106 DNS Servers: 81.169.163.106 85.214.7.22 DNS Domain: my-domain.tld Link 2 (venet0) Current Scopes: none Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported # cat /etc/systemd/resolved.conf [Resolve] DNS=81.169.163.106 85.214.7.22 Domains=my-domain.tld # aptitude search '~i resolv' i libnss-resolve - nss module to resolve names via systemd-resolved i A systemd-resolved- systemd DNS resolver To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2040055/+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 2040051] Re: systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument"
Unfortunately, it doesn't make any difference. There is no additional output root@h2917298:~ # SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd-wait-online Could not create manager: Invalid argument I have already tried that before filing the bug report. Sorry, I didn't mention that in the first place. -- 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/2040051 Title: systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument" Status in systemd package in Ubuntu: Incomplete Bug description: # lsb_release -rd No LSB modules are available. Description:Ubuntu 23.10 Release:23.10 # aptitude show systemd Package: systemd Version: 253.5-1ubuntu6 State: installed systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument". This lets the corresponding service (systemd-networkd-wait- online.service) fail as well. The error also appears when one directly invokes /lib/systemd/systemd-networkd-wait-online from a shell. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2040051/+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 2040153] Re: Network Manager will not remove Netplan YAMLs when connections are deleted
** Merge proposal linked: https://code.launchpad.net/~danilogondolfo/network-manager/+git/network-manager/+merge/454296 -- 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/2040153 Title: Network Manager will not remove Netplan YAMLs when connections are deleted Status in netplan.io package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Triaged Status in netplan.io source package in Mantic: Triaged Status in network-manager source package in Mantic: Triaged Bug description: When a connection is deleted using any NM facility, libnetplan is failing to delete the YAML file. Because of that, the connection will be recreated when "netplan generate" runs again. This is probably being caused by a combination of two things. First, the NM's systemd unit has this setting "ProtectSystem=true", which will mount /usr as read-only for NM. Second, we migrated the default "00-network-manager-all.yaml" file to, /usr/lib/netplan recently [1]. When libnetplan tries to open this file for writing, the open system fails with EROFS: --- 22517 openat(AT_FDCWD, "/lib/netplan/00-network-manager-all.yaml", O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1 EROFS (Read-only file system) 22517 write(2, "netplan_delete_connection: Canno"..., 76) = 76 --- [1] - https://launchpad.net/ubuntu/+source/ubuntu-settings/23.10.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2040153/+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" "fixed" it for me, thanks to those posting the solution. -- 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 package in Lunar: Fix Committed Bug description: [NOTE] If you are running a desktop system and you see this issue, you should run: $ systemctl disable --now systemd-networkd.service This will disable systemd-networkd and associated units, including systemd-networkd-wait-online.service. NetworkManager and systemd- networkd should not be running at the same time. On desktop, NetworkManager is the default network stack. [Impact] When all interfaces are "not required for online", e.g. when they are marked "optional: true" in netplan, systemd-networkd-wait-online will timeout. Or, in other words, systemd-networkd-wait-online will timeout even though all interfaces are ignored, hence none of them will ever be marked as "ready." Depending on what units depend on network- online.target, this can delay boot by 120 seconds (the default timeout for systemd-networkd-wait-online). [Test Plan] 1. Create a new LXD container. These instructions assume jammy is the release, but the same can be done for lunar. $ lxc launch ubuntu-daily:jammy jammy $ lxc exec jammy bash 2. Once in the container, modify the default /etc/netplan/10-lxc.yaml so that eth0 is configured with "optional: true": $ vi /etc/netplan/50-cloud-init.yaml # Use whatever editor you like $ cat /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: eth0: dhcp4: true dhcp-identifier: mac optional: true 3. Re-generate and apply the netplan configuration. $ netplan generate $ netplan apply 4. Manually run systemd-networkd-wait-online, and observe that all links are ignored, and the command times out: $ SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd-wait-online --timeout=10 Found link lo(1) Found link eth0(19) lo: link is ignored eth0: link is ignored Timeout occurred while waiting for network connectivity. [Where problems could occur] This patch partially re-instates a patch remove in bug 1982218. However, instead of exiting if all links are unmanaged, we exit if all links are ignored in manager_configured(). If the patch was wrong, we may re-introduce bug 1982218, so as part of this SRU verification, that bug should be tested too. Any other regressions would also be related to systemd-networkd-wait-online behavior. [Original Description] On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic
Dear Robie, thanks for paying attention to this bug! >Has this been fixed in the development release, and if so, how? LXC_DEVEL is 1 in the development release: https://github.com/lxc/lxc/blob/main/meson.build#L36 But LXC_DEVEL is 0 in *any* stable tag: https://github.com/lxc/lxc/blob/lxc-5.0.3/meson.build#L36 And this is correct. >It's not clear to me that making this change is the appropriate thing to do in an SRU. How is LXC_DEVEL used in practice? LXC_DEVEL is used to determine if the liblxc is a cutting-edge development snapshot of the LXC or not. So, it should be 1 *only* for the main branch of lxc. But in all stable version it is 0. > Have you analysed known reverse dependencies to understand the impact of making this change? What did you find? I have analyzed well-known reverse dependency go-lxc. It's used by LXD to communicate with liblxc C API. >The only impact to users that I can understand from your explanation is that VERSION_AT_LEAST is disabled, causing builds outside the archive that use that macro to fail. Everything else seems to make the assumption that the correct way to fix this is to change LXC_DEVEL from 1 to 0, but without explaining why this is the minimal change possible. Speaking honestly, I have no idea about other good ways to fix this. And this change seems to be a "minimal" for me because it does not change LXC code (and should not) it's just a matter of having proper build configuration. >Is there any other actual real world impact? I don't think that changing LXC_DEVEL to 0 can break any properly written code. For example, Debian folks have it disabled: https://git.launchpad.net/ubuntu/+source/lxc/tree/meson.build?h=applied/debian/bookworm#n36 >Could you just patch to make VERSION_AT_LEAST work instead, for SRU purposes, to minimise regression risk? Of course, we can patch go-lxc (go-lxc also part of the LXC project). But this will be a hacky and incorrect way to fix things. -- 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+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 2029268] Re: Do not consider two versions with differing SHA256 to be the same
** Tags removed: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/2029268 Title: Do not consider two versions with differing SHA256 to be the same Status in apt package in Ubuntu: Fix Released Status in apt source package in Jammy: Fix Released Status in apt source package in Lunar: Fix Released Status in apt source package in Mantic: Fix Released Bug description: [Impact] APT sometimes deduplicates two debs into the same version object even if they have different SHA256 field values, causing download to fail later if one the sources also defines SHA512 (or MD5 or SHA1). This is a problem for example, if you rebuild in a PPA because PPAs do not have SHA512 enabled but the priamary archive does. Repositories are not required to have SHA256, so this does nothing if we do not have SHA256 for both .deb. [Test plan] An automated test is included in apt's extensive autopkgtest regression test suite. Successful pass of autopkgtest is the goal. [Where problems could occur] In terms of regressions it seems unlikely, because we compare the SHA256 only if we previously would have considered them the same version to reject them if they differ. But of course there could be the usual unsafe memory bugs. In a future this will bite us when we migrated to SHA3 and want to drop SHA256, just like we cannot seem to drop MD5 now. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2029268/+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 2037202] Re: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up
** Tags removed: foundations-todo -- 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/2037202 Title: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up Status in initramfs-tools package in Ubuntu: Fix Released Bug description: I'm not sure whether this is the correct package for this bug, please reassign if not. I'm booting the Ubuntu Mantic/23.10 desktop beta image via PXE in order to perform an unattended installation. The kernel command line looks like that: iso/casper/vmlinuz --- ip=dhcp netboot=nfs nfsroot=192.168.1.1:/export/ubuntu autoinstall ds=nocloud\;s= This has worked perfectly before. However, in 23.10, the kernel tries to intialize DHCP before a network link is up. I can see a few instances of messages like the following: dhcpcd-10.0.2 starting dev: loaded udev no interfaces have a carrier exiting due to oneshot dhcpcd exited Then, the kernel tries to mount NFS, even though neither an IP address nor even a link is available: connect: Network is unreachable NFS over TCP not available from 192.168.1.1 This is repeated for a while. In between, a message tells that now the link is up: [10.0002805] e1000e :00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx The NFS messages repeat for a while, until the system gives up and I'm dropped into a busybox prompt. Executing dhcpcd now correctly gets IP addresses, but I don't know how to continue the boot from there. The problem occurs on most physical machines that I tried, but not in VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2037202/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems
** Tags removed: foundations-todo -- 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/2037417 Title: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems Status in cloud-images: Fix Released Status in maas-images: Fix Released Status in The Ubuntu-power-systems project: Invalid Status in Release Notes for Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in util-linux package in Ubuntu: Fix Released Status in linux source package in Mantic: Invalid Status in systemd source package in Mantic: Invalid Status in util-linux source package in Mantic: Fix Released Bug description: Mantic arm64 deploys started failing on Sept 18th with: [ 41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems... Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File Systems... [ 41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug All udev Devices... Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev Devices... [ 41.964758] systemd[1]: Started systemd-journald.service - Journal Service. [[0;32m OK [0m] Started [0;1;39msystemd-journald.service[0m - Journal Service. [[0;32m OK [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages File System. [[0;32m OK [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message Queue File System. [[0;32m OK [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug File System. [[0;32m OK [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace File System. [[0;32m OK [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console keyboard layout. [[0;32m OK [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static Device Nodes. [[0;32m OK [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or progress polling. [[0;32m OK [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel Module configfs. [[0;32m OK [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel Module dm_mod. [[0;32m OK [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel Module drm. [[0;32m OK [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel Module efi_pstore. [[0;32m OK [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel Module fuse. [[0;32m OK [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel Module loop. [[0;32m OK [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load Kernel Modules. [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and Kernel File Systems. See 'systemctl status systemd-remount-fs.service' for details. After this many other services and cloud-init fails. See the full kopter-0918.log. For comparison, a log from the prior day's test is also attached. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/2037417/+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 2018128] Re: Apport does not collect all logs when the package is HWE kernel
Maybe it doesn't matter if the kernel hook is triggered for those since they never get bug reports anyways :-) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2018128 Title: Apport does not collect all logs when the package is HWE kernel Status in apport package in Ubuntu: Triaged Status in linux package in Ubuntu: Invalid Bug description: Ubuntu 22.04 LTS with kernel 5.19.0-41-generic When filing bugs against the package 'linux' apport collects all the logs needed to the kernel But in case the user is not on stock kernel anymore and has the HWE kernel apport only imports 2 logs Dependencies.txt + ProcCpuInfoMinimal.txt and forwards the package 'linux' towards linux-signed-hwe-5.19 (in my case) would it be possible to make apport collect all the logs needed in all kernel cases? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: apport 2.20.11-0ubuntu82.4 ProcVersionSignature: Ubuntu 5.19.0-41.42~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-41-generic x86_64 ApportLog: ApportVersion: 2.20.11-0ubuntu82.4 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sat Apr 29 05:25:30 2023 PackageArchitecture: all SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2018128/+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 2023462] Re: chromeos_pstore.service started on non chrome platform hardware.
** Tags removed: foundations-todo -- 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/2023462 Title: chromeos_pstore.service started on non chrome platform hardware. Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Released Bug description: [Impact] Kernel modules that provide pstore backends are unnecessarily loaded by systemd-pstore.service. While this is pretty benign behavior, it was introduced by an earlier SRU (bug 1978079) and is not consistent with newer releases in which systemd-pstore.service only tries to load efi_pstore. [Test Plan] Check which modules systemd-pstore.service depends on: $ systemctl list-dependencies systemd-pstore.service systemd-pstore.service * |--.mount * |-modprobe@chromeos_pstore.service * |-modprobe@efi_pstore.service * |-modprobe@pstore_blk.service * |-modprobe@pstore_zone.service * |-modprobe@ramoops.service * `-system.slice On an affected machine, we see several pstore providers in addition to efi_pstore. On a patched system, we should only see efi_pstore. [Where problems could occur] If somehow a user was running a configuration where one of the other modules was needed for pstore on their system, and that module was not loaded when systemd-pstore.service ran, they might not get correct output. However, the original bug (bug 1978079) was only about efi_pstore, and that will still be loaded by systemd-pstore.service. On all releases newer than Jammy, only efi_pstore is loaded by systemd-pstore.service, and there have not been bug reports. [Original Description] systemd-analyze blame | grep pstore 110ms modprobe@chromeos_pstore.service 5ms modprobe@efi_pstore.service 5ms modprobe@pstore_blk.service 3ms modprobe@pstore_zone.service /lib/systemd/system/systemd-pstore.service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2023462/+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 2023229] Re: Autopkgtest failure for tests-in-lxd
** Tags removed: foundations-todo -- 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/2023229 Title: Autopkgtest failure for tests-in-lxd Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Released Status in systemd source package in Kinetic: Won't Fix Status in systemd source package in Lunar: Fix Released Status in systemd source package in Mantic: Fix Released Bug description: [Impact] systemd autopkgtests are failing in stable releases due to a change in LXD. We want the tests to be in good shape so that we can properly catch regressions etc. during SRUs. [Test Plan] The tests-in-lxd test should pass. [Where problems could occur] The patch adds a flag to lxc invocation in the debian/tests/tests-in- lxd script, so any problems would be contained to that test. [Original Description] Autopackagetests on multiple Jammy kernels show the same failure on the test-in-lxd test Error: Aliases already exists: autopkgtest/ubuntu/jammy/amd64 autopkgtest [16:33:58]: test tests-in-lxd: ---] autopkgtest [16:33:58]: test tests-in-lxd: - - - - - - - - - - results - - - - - - - - - - tests-in-lxd FAIL non-zero exit status 1 Where the error seems to be triggered by debian/tests/tests-in-lxd lxc publish systemd-lxc --alias $IMAGE To be determined if this a problem in the autopkgtest infrastructure or test bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2023229/+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 2025462] Re: Apt deletes ubuntu-desktop during dist-upgrade
** Tags removed: foundations-todo
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/2025462
Title:
Apt deletes ubuntu-desktop during dist-upgrade
Status in apt package in Ubuntu:
Fix Released
Status in apt source package in Jammy:
Fix Released
Status in apt source package in Kinetic:
Won't Fix
Status in apt source package in Lunar:
Fix Released
Status in apt source package in Mantic:
Fix Released
Bug description:
[Impact]
gnome-shell gets removed on upgrades of gnome-shell and mutter if due to
phasing we can only upgrade src:gnome-shell.
[Test plan]
This adds a minimal test case to the test suite that reproduced the issue and
verifies the fix, test plan consists of the autopkgtests.
[Where problems could occur]
We could see a resurgence of bugs like LP#1990586 where the solver failed to
run at all because things got too complex, however this is a bit more unlikely
as we now use the by-keep resolver to handle rolling back phased updates.
We also saw an issue with a phased update's dependencies being
installed despite the phased update being hold back. We saw that both
before in `apt upgrade` and with the fix for this bug, we also
introduced it to `dist-upgrade`, but this is also fixed and tested in
these uploads, basically we skip marking for install (which in turn
caused me to discover we need to check a different version).
[Other Info]
gnome-shell Depends: gnome-shell-common (= ${binary-Version), mutter (>=
matching)
So when mutter cannot be updated due to phasing, gnome-shell becomes
non-installable, but gnome-shell-common can be updated, so APT decided
to remove gnome-shell and the meta packages in its infinite wisdom.
The fix addresses this by resolving the dist-upgrade as if there were
no phasing, and then retroactively marks phases for keep and then
anything broken by that for keep.
This required some restructuring because normally we'd also keep
broken Recommends back, but here dist-upgrade may have decided that
was ok, so we need to build an allowlist of where Recommends can be
broken to avoid undoing unrelated changes.
[Original bug report]
This morning I got surprised by my laptop booting to a tty instead of
a desktop environment. It turned out that the entire desktop
environment was no longer present on my machine. Doing an apt install
ubuntu-desktop-minimal resolved the issue.
The machine had been running for a while. Looking at the apt logs, it
looks like apt deleted ubuntu-desktop on its own during a dist-upgrade
a couple of weeks back.
Start-Date: 2023-06-08 14:20:46
Commandline: apt dist-upgrade
Requested-By: alex (1000)
Upgrade: gnome-shell-common:amd64 (44.0-2ubuntu3, 44.1-0ubuntu1)
Remove: gnome-shell:amd64 (44.0-2ubuntu3), ubuntu-desktop:amd64 (1.501),
gdm3:amd64 (44.0-1ubuntu1), gnome-shell-extension-desktop-icons-ng:amd64
(46+really47.0.2-3), gnome-shell-extension-appindicator:amd64 (53-1),
ubuntu-session:amd64 (44.0-1ubuntu1), gnome-shell-extension-manager:amd64
(0.4.0-1), gnome-shell-extension-ubuntu-dock:amd64 (79ubuntu2.23.04.1),
ubuntu-desktop-minimal:amd64 (1.501)
End-Date: 2023-06-08 14:20:48
I'm using the following version of Ubuntu:
Distributor ID: Ubuntu
Description: Ubuntu 23.04
Release: 23.04
Codename: lunar
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2025462/+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 2025563] Re: System can not shutdown if system has multiple VROC RAID arrays
** Tags removed: foundations-todo -- 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/2025563 Title: System can not shutdown if system has multiple VROC RAID arrays Status in OEM Priority Project: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Released Status in systemd source package in Kinetic: Fix Released Bug description: [ Impact ] The system can not shutdown if the system has multiple VROC RAID arrays. Intel has fixed it in systemd v251 [1]. Need to cherry-pick the commit to ubuntu-jammy systemd 249.11-0ubuntu3.9. [1] The commit fixes the issue: commit 3a3b022d2cc112803ea7b9beea98bbcad110368a Author: Mariusz Tkaczyk Date: Tue Mar 29 12:49:54 2022 +0200 shutdown: get only active md arrays. Current md_list_get() implementation filters all block devices, started from "md*". This is ambiguous because list could contain: - partitions created upon md device (mdXpY) - external metadata container- specific type of md array. For partitions there is no issue, because they aren't handle STOP_ARRAY ioctl sent later. It generates misleading errors only. Second case is more problematic because containers are not locked in kernel. They are stopped even if container member array is active. For that reason reboot or shutdown flow could be blocked because metadata manager cannot be restarted after switch root on shutdown. Add filters to remove partitions and containers from md_list. Partitions can be excluded by DEVTYPE. Containers are determined by MD_LEVEL property, we are excluding all with "container" value. Signed-off-by: Mariusz Tkaczyk In the journal, we can see systemd-shutdown looping repeatedly as it tries and fails to detach all md devices: ... [ 513.416293] systemd-shutdown[1]: Stopping MD /dev/md124p2 (259:5). [ 513.422953] systemd-shutdown[1]: Could not stop MD /dev/md124p2: Device or resource busy [ 513.431227] systemd-shutdown[1]: Stopping MD /dev/md124p1 (259:4). [ 513.437952] systemd-shutdown[1]: Could not stop MD /dev/md124p1: Device or resource busy [ 513.449298] systemd-shutdown[1]: Stopping MD /dev/md124 (9:124). [ 513.456278] systemd-shutdown[1]: Could not stop MD /dev/md124: Device or resource busy [ 513.465323] systemd-shutdown[1]: Not all MD devices stopped, 4 left. [ 513.472564] systemd-shutdown[1]: Couldn't finalize remaining MD devices, trying again. [ 513.485302] systemd-shutdown[1]: Failed to open watchdog device /dev/watchdog: No such file or directory [ 513.496195] systemd-shutdown[1]: Stopping MD devices. [ 513.502176] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 513.513382] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 513.521436] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 513.534810] systemd-shutdown[1]: Stopping MD /dev/md126 (9:126). [ 513.545384] systemd-shutdown[1]: Failed to sync MD block device /dev/md126, ignoring: Input/output error [ 513.557265] md: md126 stopped. [ 513.561451] systemd-shutdown[1]: Stopping MD /dev/md124p2 (259:5). [ 513.576673] systemd-shutdown[1]: Could not stop MD /dev/md124p2: Device or resource busy [ 513.589274] systemd-shutdown[1]: Stopping MD /dev/md124p1 (259:4). [ 513.597976] systemd-shutdown[1]: Could not stop MD /dev/md124p1: Device or resource busy [ 513.607263] systemd-shutdown[1]: Stopping MD /dev/md124 (9:124). [ 513.615067] systemd-shutdown[1]: Could not stop MD /dev/md124: Device or resource busy [ 513.625157] systemd-shutdown[1]: Not all MD devices stopped, 4 left. [ 513.632209] systemd-shutdown[1]: Couldn't finalize remaining MD devices, trying again. [ 513.641474] systemd-shutdown[1]: Failed to open watchdog device /dev/watchdog: No such file or directory [ 513.653660] systemd-shutdown[1]: Stopping MD devices. [ 513.661257] systemd-shutdown[1]: sd-device-enumerator: Scan all dirs [ 513.668833] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/bus [ 513.677347] systemd-shutdown[1]: sd-device-enumerator: Scanning /sys/class [ 513.687047] systemd-shutdown[1]: Stopping MD /dev/md126 (9:126). [ 513.697206] systemd-shutdown[1]: Failed to sync MD block device /dev/md126, ignoring: Input/output error [ 513.707193] md: md126 stopped. ... [ Test Plan ] 1. Build two VROC RAID. One RAID 0 for System volume, another RAID 10 for Data volume. 2. Install system on System volume. 3. Update systemd. 4. Reboot the system. 5. Verify if the system can reboot. [ Where problems could occur ] The patch confirmed fixed the reboot issue on the system with two VROC RAIDs but more than two VROC RAIDs and the combinations of RAID levels are not all
[Touch-packages] [Bug 1977630] Re: machinectl pull-tar/pull-raw Operation not permitted
** Tags removed: foundations-todo -- 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/1977630 Title: machinectl pull-tar/pull-raw Operation not permitted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Released Bug description: [impact] machinectl pull-tar does not work, ever [test case] see comment 2 [regression potential] problems/failures during pull-tar operation [scope] needed only in j fixed (indirectly) by upstream commit referenced in original description, which is included in v250, so fixed already in k pull-tar does not fail on f; no fix needed there [original description] There is a bug in systemd 249, where one can't pull any images. This was fixed in version 250, and never got backported. (FIX: https://github.com/systemd/systemd/commit/c40d82abf7b23803aa7394a7a7e24c40c32af851) Hopefully this can be addressed. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-container 249.11-0ubuntu3.1 ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35 Uname: Linux 5.15.0-35-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl icp ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Jun 4 04:51:42 2022 InstallationDate: Installed on 2022-06-01 (2 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1977630/+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 1995247] Re: Leftover /tmp/apt-key.* files after updates with embedded gpg keys in deb822 sources
** Tags removed: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1995247 Title: Leftover /tmp/apt-key.* files after updates with embedded gpg keys in deb822 sources Status in apt package in Ubuntu: Fix Released Status in apt source package in Jammy: Fix Released Status in apt source package in Kinetic: Won't Fix Status in apt source package in Lunar: Fix Released Bug description: [Impact] When keys are embedded into deb822 sources files as Signed-By, apt writes them to a temporary file, but the code to delete them accidentally had an if (0) in front of the deletion, so they don't get deleted and accumulate with each `apt update` run. [Test plan] Including a test case for this in our comprehensive integration test suite which runs as autopkgtest, so passing autopkgtest = good. [Where problems could occur] Files could end up being removed too soon if the code is otherwise wrong? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1995247/+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 2012437] Re: Ship a static libsystemd.a
** Tags removed: foundations-todo -- 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/2012437 Title: Ship a static libsystemd.a Status in systemd package in Ubuntu: Fix Released Bug description: More and more things are requiring linking against libsystemd. In particular, because dbus is now linked against libsystemd, anything that wants to make a dbus client call needs it. By not shipping a static libsystemd.a, all such users are prevented from building statically. This includes tools like the lxc-init container init, and stacker container build tool, which both want to be re-execed inside a container which may have completely different - or no - distro. With the attached debdiff, libsystemd-dev ships a libsystem.a so tools can be built statically. The package has been built (for lunar) with this debdiff at ppa:serge- hallyn/systemd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2012437/+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 2015355] Re: Please backport patches for false atari partition detection to Ubuntu 20.04
** Tags removed: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/2015355 Title: Please backport patches for false atari partition detection to Ubuntu 20.04 Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Focal: Fix Released Bug description: [Impact] The partition detection logic in libblkid1 can falsely report the presence of an atari partition. One place where this has a practical impact is in kubernetes where mount-utils will refuse to format the device (https://github.com/kubernetes/mount- utils/blob/732a08ae47571516020ef99c303c70c1fa5b3e6c/mount_linux.go#L437-L441). [Test Plan] * Create a new qcow2 disk image: $ qemu-img create -f qcow2 test.img 20G * Boot a focal ISO with QEMU/KVM as if installing to test.img: $ qemu-system-x86_64 -enable-kvm -m 4096 -name test -drive file=test.img,format=qcow2 -net nic,model=virtio -net user,hostfwd=tcp::1022-:22 -vga virtio -cdrom ubuntu-20.04.6-desktop- amd64.iso * Using the live environment, format the empty disk. These particular commands were given as a reproducer on the upstream bug report (https://github.com/util-linux/util-linux/issues/1116). $ parted -s /dev/sda -- mklabel msdos $ parted -s /dev/sda -- mkpart primary 0% 10% mkpart primary 10% 30% * Run wipefs on /dev/sda to list partitions. On an affected machine, an atari partition will be listed. On a fixed machine, the incorrect atari listing will be gone. $ wipefs /dev/sda DEVICE OFFSET TYPE UUID LABEL sda0x1fe dos sda0x1d2 atari [Where problems could occur] These patches specifically address the atari prober logic in libblkid. Therefore, if we saw regressions it would be related to detecting atari partitions with libblkid. This would potentially impact tools such as wipefs and blkid, or any other tool that uses libblkid1 for this purpose. [Original Description] There are three patches in util-linux upstream that were released in util-linux 2.37 and prevent false detection of the atari partition table with blkid and wipefs. We see this mostly on LUKS devices initialised via luksFormat reporting there is an atari partition table on the device when it is empty. This causes issues in various places, but one key example for us is in kubernetes where mount-utils will refuse to format the device (https://github.com/kubernetes/mount- utils/blob/732a08ae47571516020ef99c303c70c1fa5b3e6c/mount_linux.go#L437-L441) RedHat backported these fixes to RHEL 8 under https://bugzilla.redhat.com/show_bug.cgi?id=2060030 and it would be helpful if Ubuntu also backported them to Ubuntu 20.04 which is still running util-linux 2.34 The request is to backport patches based on the https://github.com/util-linux/util-linux/issues/1159 upstream report. Upstream commits to cherry-pick the changes to libblkid/src/partitions/atari.c from: 2cc76d50d7a14bef8e7b07fab11b26c9e49d36a2 282ceadc3a72fc07dd0388b8880fd751490bb87f c70b4f2a5b99876d230b8f4f413c3bb3ee6647f1 # lsb_release -a Distributor ID: Ubuntu Description:Ubuntu 20.04.6 LTS Release:20.04 Codename: focal # blkid -V blkid from util-linux 2.34 (libblkid 2.34.0, 14-Jun-2019) # blkid -p -s TYPE -s PTTYPE -o export /dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted DEVNAME=dev/mapper/pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted PTTYPE=atari # lsblk ... sdccrypto_LUKS a79d2982-74f2-44c7-bb29-460768ebfe64 `-3600a09803830474a735d4c63744c4a56crypto_LUKS a79d2982-74f2-44c7-bb29-460768ebfe64 `-pvc-7b331195-cd5a-4ab6-8fdc-552af4b9139d_encrypted To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2015355/+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 2008952] Re: DNS failure while trying to fetch user-data
** Tags removed: foundations-todo -- 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/2008952 Title: DNS failure while trying to fetch user-data Status in cloud-init: Fix Released Status in netplan: Invalid Status in subiquity: Invalid Status in livecd-rootfs package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Invalid Bug description: In testing netboot + autoinstall of the new ubuntu desktop subiquity based installer for 23.04 I found cloud-init is failing to retrieve user-data because it can't resolved the hostname in the URL. This same configuration does work for 22.04 based subiquity, so seems a regression. From the ipxe config: imgargs vmlinuz initrd=initrd \ ip=dhcp \ iso-url=http://cdimage.ubuntu.com/daily-live/pending/lunar-desktop-amd64.iso \ fsck.mode=skip \ layerfs-path=minimal.standard.live.squashfs \ autoinstall \ 'ds=nocloud-net;s=http://boot.linuxgroove.com/ubuntu/23.04/' \ That fails, but if we replace boot.linuxgroove.com with the IP it works. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2008952/+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 2038650] Re: crash reports not sent to the Error Tracker
** Tags removed: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2038650 Title: crash reports not sent to the Error Tracker Status in apport package in Ubuntu: Fix Released Status in apport source package in Lunar: Fix Released Status in apport source package in Mantic: Fix Released Bug description: [ Impact ] Crash reports aren't sent in when going through the UI, unless the user looks at the crash details. [ Test Plan ] 0) Make sure that error reporting is set to manual in the system settings (in Privacy screen) 1) Launch xeyes 2) pkill -11 xeyes 3) Click send in the apport dialog. DO NOT look at the details of the report. 4) ls -lh /var/crash/*xeyes* There should be 3 files: -rw-r- 1 bdmurray whoopsie 3370567 Oct 6 11:53 _usr_bin_xeyes.1000.crash -rw-rw-r-- 1 bdmurray bdmurray0 Oct 6 11:53 _usr_bin_xeyes.1000.upload -rw--- 1 whoopsie whoopsie 37 Oct 6 11:53 _usr_bin_xeyes.1000.uploaded [ Where problems could occur ] If the patch is wrong, we actually see similar bugs for other UI paths, e.g. ticking the "Remember this" box, etc. I tried to cover them during manual testing but I might have missed some. [ Other Info ] If possible I'd like for us not to wait too long for this to mature in -proposed, as this would affect crashes during the upgrade. [ Original report ] From what I can tell when I click the send button to send a crash report to the Error Tracker the crash doesn't actually get sent. My testing process follows: 1) Launch xeyes 2) pkill -11 xeyes 3) Click send in the apport dialog 4) ls -lh /var/crash I would expect there to be three files in /var/crash: -rw-r- 1 bdmurray whoopsie 3370567 Oct 6 11:53 _usr_bin_xeyes.1000.crash -rw-rw-r-- 1 bdmurray bdmurray0 Oct 6 11:53 _usr_bin_xeyes.1000.upload -rw--- 1 whoopsie whoopsie 37 Oct 6 11:53 _usr_bin_xeyes.1000.uploaded However, after step #4 I'm only seeing the .crash file and not a .upload or .uploaded. I was able to get the .upload and .uploaded files created if I chose to "View Report" and then click "Send". It's worth noting though that I did notice the size of the .crash file increase after clicking "Send" so some post-processing was done. ProblemType: BugDistroRelease: Ubuntu 23.10 Package: apport 2.27.0-0ubuntu4 ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0 Uname: Linux 6.5.0-5-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.27.0-0ubuntu4 Architecture: amd64 CasperMD5CheckResult: pass CrashReports: 640:1000:123:20944237:2023-10-06 12:10:47.809248208 +0100:2023-10-06 12:11:23.340030509 +0100:/var/crash/_usr_bin_mpv.1000.crash CurrentDesktop: ubuntu:GNOME Date: Fri Oct 6 12:12:46 2023 InstallationDate: Installed on 2022-01-07 (637 days ago) InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012) PackageArchitecture: allSourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2038650/+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 2018128] Re: Apport does not collect all logs when the package is HWE kernel
List of kernel source packages as of 2023/10/23. ** Attachment added: "ubuntu-kernels.list" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2018128/+attachment/5712664/+files/ubuntu-kernels.list -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2018128 Title: Apport does not collect all logs when the package is HWE kernel Status in apport package in Ubuntu: Triaged Status in linux package in Ubuntu: Invalid Bug description: Ubuntu 22.04 LTS with kernel 5.19.0-41-generic When filing bugs against the package 'linux' apport collects all the logs needed to the kernel But in case the user is not on stock kernel anymore and has the HWE kernel apport only imports 2 logs Dependencies.txt + ProcCpuInfoMinimal.txt and forwards the package 'linux' towards linux-signed-hwe-5.19 (in my case) would it be possible to make apport collect all the logs needed in all kernel cases? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: apport 2.20.11-0ubuntu82.4 ProcVersionSignature: Ubuntu 5.19.0-41.42~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-41-generic x86_64 ApportLog: ApportVersion: 2.20.11-0ubuntu82.4 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sat Apr 29 05:25:30 2023 PackageArchitecture: all SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2018128/+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 2018128] Re: Apport does not collect all logs when the package is HWE kernel
I don't think we can do this with a regex. There are linux- package that are not kernels. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2018128 Title: Apport does not collect all logs when the package is HWE kernel Status in apport package in Ubuntu: Triaged Status in linux package in Ubuntu: Invalid Bug description: Ubuntu 22.04 LTS with kernel 5.19.0-41-generic When filing bugs against the package 'linux' apport collects all the logs needed to the kernel But in case the user is not on stock kernel anymore and has the HWE kernel apport only imports 2 logs Dependencies.txt + ProcCpuInfoMinimal.txt and forwards the package 'linux' towards linux-signed-hwe-5.19 (in my case) would it be possible to make apport collect all the logs needed in all kernel cases? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: apport 2.20.11-0ubuntu82.4 ProcVersionSignature: Ubuntu 5.19.0-41.42~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-41-generic x86_64 ApportLog: ApportVersion: 2.20.11-0ubuntu82.4 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sat Apr 29 05:25:30 2023 PackageArchitecture: all SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2018128/+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 2020474] Re: openssh-server-1:9.2p1-2ubuntu1 cannot be installed from active ssh session
** Tags removed: foundations-todo -- 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/2020474 Title: openssh-server-1:9.2p1-2ubuntu1 cannot be installed from active ssh session Status in openssh package in Ubuntu: Fix Released Bug description: Installation seems to fail on restarting ssh.socket via systemctl Setting up openssh-server (1:9.2p1-2ubuntu1) ... rescue-ssh.target is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145. dpkg: error processing package openssh-server (--configure): installed openssh-server package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: openssh-server E: Sub-process /usr/bin/dpkg returned an error code (1) $ systemctl status ssh.socket × ssh.socket - OpenBSD Secure Shell server socket Loaded: loaded (/lib/systemd/system/ssh.socket; enabled; preset: enabled) Active: failed (Result: resources) since Tue 2023-05-23 15:01:41 CEST; 48s ago Duration: 3h 6min 36.071s Triggers: ● ssh.service Listen: [::]:22 (Stream) CPU: 2ms May 23 11:55:05 venus2 systemd[1]: Listening on ssh.socket - OpenBSD Secure Shell server socket. May 23 15:01:41 venus2 systemd[1]: ssh.socket: Deactivated successfully. May 23 15:01:41 venus2 systemd[1]: Closed ssh.socket - OpenBSD Secure Shell server socket. May 23 15:01:41 venus2 systemd[1]: Stopping ssh.socket - OpenBSD Secure Shell server socket... May 23 15:01:41 venus2 systemd[2631]: ssh.socket: Failed to create listening socket ([::]:22): Address already in use May 23 15:01:41 venus2 systemd[1]: ssh.socket: Failed to receive listening socket ([::]:22): Input/output error May 23 15:01:41 venus2 systemd[1]: ssh.socket: Failed to listen on sockets: Input/output error May 23 15:01:41 venus2 systemd[1]: ssh.socket: Failed with result 'resources'. May 23 15:01:41 venus2 systemd[1]: Failed to listen on ssh.socket - OpenBSD Secure Shell server socket. At this point, sshd is no longer listening for new connections. A manual systemctl restart of ssh.socket fails with the same error. I am ssh-ed into this box, so I *think* the failure is because my session is already sitting on port 22, maybe? The only way I can be sure I will be able to ssh to this box again is to reboot it (so that ssh.socket can start cleanly). $ lsb_release -rd No LSB modules are available. Description: Ubuntu Mantic Minotaur (development branch) Release: 23.10 $ apt policy openssh-server openssh-server: Installed: 1:9.2p1-2ubuntu1 Candidate: 1:9.2p1-2ubuntu1 Version table: *** 1:9.2p1-2ubuntu1 500 500 http://ch.ports.ubuntu.com/ubuntu-ports mantic-proposed/main riscv64 Packages 100 /var/lib/dpkg/status 1:9.0p1-1ubuntu8.1 500 500 http://ch.ports.ubuntu.com/ubuntu-ports mantic/main riscv64 Packages ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: openssh-server 1:9.2p1-2ubuntu1 ProcVersionSignature: Ubuntu 6.2.0-19.19.1-generic 6.2.6 Uname: Linux 6.2.0-19-generic riscv64 ApportVersion: 2.26.1-0ubuntu3 Architecture: riscv64 CasperMD5CheckResult: unknown CloudArchitecture: riscv64 CloudBuildName: server CloudID: nocloud CloudName: unknown CloudPlatform: nocloud CloudSerial: 20230413.1 CloudSubPlatform: seed-dir (/var/lib/cloud/seed/nocloud-net) Date: Tue May 23 14:58:35 2023 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 1: /etc/ssh/sshd_config.d/50-cloud-init.conf: Permission denied SourcePackage: openssh UpgradeStatus: Upgraded to mantic on 2023-05-12 (11 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2020474/+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 2040051] Re: systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument"
** Changed in: systemd (Ubuntu) Status: Invalid => Incomplete -- 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/2040051 Title: systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument" Status in systemd package in Ubuntu: Incomplete Bug description: # lsb_release -rd No LSB modules are available. Description:Ubuntu 23.10 Release:23.10 # aptitude show systemd Package: systemd Version: 253.5-1ubuntu6 State: installed systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument". This lets the corresponding service (systemd-networkd-wait- online.service) fail as well. The error also appears when one directly invokes /lib/systemd/systemd-networkd-wait-online from a shell. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2040051/+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 2040055] Re: systemd-resolved fails: Failed to start query: Invalid argument
Please provide debug-level logs from systemd-resolved.service from a time where this issue is observed. You can enable debug-level logging like this: $ mkdir -p /etc/systemd/system/systemd-resolved.service.d/ $ cat > /etc/systemd/system/systemd-resolved.service.d/debug.conf << EOF [Service] Environment=SYSTEMD_LOG_LEVEL=debug EOF $ systemctl daemon-reload $ systemctl restart systemd-resolved.service (or reboot if you prefer). ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- 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/2040055 Title: systemd-resolved fails: Failed to start query: Invalid argument Status in systemd package in Ubuntu: Incomplete Bug description: # lsb_release -rd No LSB modules are available. Description:Ubuntu 23.10 Release:23.10 # aptitude show 'systemd-resolved' Package: systemd-resolved Version: 253.5-1ubuntu6 State: installed The system is unable to resolve any DNS names. Whenever a DNS name shall be resolved the following error appears in the journal Oct 21 15:50:32 my-host.my-domain.tld systemd-resolved[114]: Failed to start query: Invalid argument If one manually tries to resolve a DNS name from the local stub resolver via dig @127.0.0.53 A www.google.com. another error message is added to the journal. However, resolving a DNS name from the configured upstream DNS server works perfectly dig @81.169.163.106 A www.google.com. Returns a proper response. (Note, 81.169.163.106 is the internal DNS server from my hoster.) Some more infos # resolvectl Global Protocols: -LLMNR mDNS=resolve -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Current DNS Server: 81.169.163.106 DNS Servers: 81.169.163.106 85.214.7.22 DNS Domain: my-domain.tld Link 2 (venet0) Current Scopes: none Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported # cat /etc/systemd/resolved.conf [Resolve] DNS=81.169.163.106 85.214.7.22 Domains=my-domain.tld # aptitude search '~i resolv' i libnss-resolve - nss module to resolve names via systemd-resolved i A systemd-resolved- systemd DNS resolver To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2040055/+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 2040051] Re: systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument"
Since you say this happens from a shell too, please provide the output of the following: SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/systemd-networkd-wait-online ** Changed in: systemd (Ubuntu) Status: New => Invalid -- 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/2040051 Title: systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument" Status in systemd package in Ubuntu: Incomplete Bug description: # lsb_release -rd No LSB modules are available. Description:Ubuntu 23.10 Release:23.10 # aptitude show systemd Package: systemd Version: 253.5-1ubuntu6 State: installed systemd-networkd-wait-online terminates with "Could not create manager: Invalid argument". This lets the corresponding service (systemd-networkd-wait- online.service) fail as well. The error also appears when one directly invokes /lib/systemd/systemd-networkd-wait-online from a shell. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2040051/+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 2018128] Re: Apport does not collect all logs when the package is HWE kernel
The source_linux.py package hook could be moved to general-hooks (where it is always run) and do a regular expression check for the source package name. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2018128 Title: Apport does not collect all logs when the package is HWE kernel Status in apport package in Ubuntu: Triaged Status in linux package in Ubuntu: Invalid Bug description: Ubuntu 22.04 LTS with kernel 5.19.0-41-generic When filing bugs against the package 'linux' apport collects all the logs needed to the kernel But in case the user is not on stock kernel anymore and has the HWE kernel apport only imports 2 logs Dependencies.txt + ProcCpuInfoMinimal.txt and forwards the package 'linux' towards linux-signed-hwe-5.19 (in my case) would it be possible to make apport collect all the logs needed in all kernel cases? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: apport 2.20.11-0ubuntu82.4 ProcVersionSignature: Ubuntu 5.19.0-41.42~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-41-generic x86_64 ApportLog: ApportVersion: 2.20.11-0ubuntu82.4 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sat Apr 29 05:25:30 2023 PackageArchitecture: all SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2018128/+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 2018128] Re: Apport does not collect all logs when the package is HWE kernel
Or the kernel package itself needs to provide the symlink. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2018128 Title: Apport does not collect all logs when the package is HWE kernel Status in apport package in Ubuntu: Triaged Status in linux package in Ubuntu: Invalid Bug description: Ubuntu 22.04 LTS with kernel 5.19.0-41-generic When filing bugs against the package 'linux' apport collects all the logs needed to the kernel But in case the user is not on stock kernel anymore and has the HWE kernel apport only imports 2 logs Dependencies.txt + ProcCpuInfoMinimal.txt and forwards the package 'linux' towards linux-signed-hwe-5.19 (in my case) would it be possible to make apport collect all the logs needed in all kernel cases? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: apport 2.20.11-0ubuntu82.4 ProcVersionSignature: Ubuntu 5.19.0-41.42~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-41-generic x86_64 ApportLog: ApportVersion: 2.20.11-0ubuntu82.4 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sat Apr 29 05:25:30 2023 PackageArchitecture: all SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2018128/+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 2018128] Re: Apport does not collect all logs when the package is HWE kernel
This needs some rework. Kernel source package names change a lot and with every release so static symlinks will not work. We might have to query LP to get up-to-date kernel source information. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2018128 Title: Apport does not collect all logs when the package is HWE kernel Status in apport package in Ubuntu: Triaged Status in linux package in Ubuntu: Invalid Bug description: Ubuntu 22.04 LTS with kernel 5.19.0-41-generic When filing bugs against the package 'linux' apport collects all the logs needed to the kernel But in case the user is not on stock kernel anymore and has the HWE kernel apport only imports 2 logs Dependencies.txt + ProcCpuInfoMinimal.txt and forwards the package 'linux' towards linux-signed-hwe-5.19 (in my case) would it be possible to make apport collect all the logs needed in all kernel cases? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: apport 2.20.11-0ubuntu82.4 ProcVersionSignature: Ubuntu 5.19.0-41.42~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-41-generic x86_64 ApportLog: ApportVersion: 2.20.11-0ubuntu82.4 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sat Apr 29 05:25:30 2023 PackageArchitecture: all SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2018128/+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
Chris, Andreas, SRU team - In short, I think this should be released to -updates, yes. From looking through the various comments I have observed the same that either (a) a user is not testing with -proposed, or (b) they are in a slightly different situation (but see the timeout nonetheless, hence find this bug report). -- 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 package in Lunar: Fix Committed Bug description: [NOTE] If you are running a desktop system and you see this issue, you should run: $ systemctl disable --now systemd-networkd.service This will disable systemd-networkd and associated units, including systemd-networkd-wait-online.service. NetworkManager and systemd- networkd should not be running at the same time. On desktop, NetworkManager is the default network stack. [Impact] When all interfaces are "not required for online", e.g. when they are marked "optional: true" in netplan, systemd-networkd-wait-online will timeout. Or, in other words, systemd-networkd-wait-online will timeout even though all interfaces are ignored, hence none of them will ever be marked as "ready." Depending on what units depend on network- online.target, this can delay boot by 120 seconds (the default timeout for systemd-networkd-wait-online). [Test Plan] 1. Create a new LXD container. These instructions assume jammy is the release, but the same can be done for lunar. $ lxc launch ubuntu-daily:jammy jammy $ lxc exec jammy bash 2. Once in the container, modify the default /etc/netplan/10-lxc.yaml so that eth0 is configured with "optional: true": $ vi /etc/netplan/50-cloud-init.yaml # Use whatever editor you like $ cat /etc/netplan/50-cloud-init.yaml network: version: 2 ethernets: eth0: dhcp4: true dhcp-identifier: mac optional: true 3. Re-generate and apply the netplan configuration. $ netplan generate $ netplan apply 4. Manually run systemd-networkd-wait-online, and observe that all links are ignored, and the command times out: $ SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd-wait-online --timeout=10 Found link lo(1) Found link eth0(19) lo: link is ignored eth0: link is ignored Timeout occurred while waiting for network connectivity. [Where problems could occur] This patch partially re-instates a patch remove in bug 1982218. However, instead of exiting if all links are unmanaged, we exit if all links are ignored in manager_configured(). If the patch was wrong, we may re-introduce bug 1982218, so as part of this SRU verification, that bug should be tested too. Any other regressions would also be related to systemd-networkd-wait-online behavior. [Original Description] On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2039815] Re: Update to at least systemd v254 in lunar
We do not do these kinds of updates in stable releases - just bug fixes etc. We will have systemd > v254 in 24.04. ** Changed in: systemd (Ubuntu) Status: New => Invalid -- 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/2039815 Title: Update to at least systemd v254 in lunar Status in systemd package in Ubuntu: Invalid Bug description: There have been many enhancements to systemd in the newer versions, which i would like to use. fe. see this thread: https://github.com/systemd/systemd/issues/28984#issuecomment-1770883963 ``` $ lsb_release -rd: Description: Ubuntu 23.04 Release: 23.04 $ apt-cache policy systemd systemd: Installed: 252.5-2ubuntu3.1 Candidate: 252.5-2ubuntu3.1 Version table: *** 252.5-2ubuntu3.1 500 500 http://archive.ubuntu.com/ubuntu lunar-updates/main amd64 Packages 100 /var/lib/dpkg/status 252.5-2ubuntu3 500 500 http://archive.ubuntu.com/ubuntu lunar/main amd64 Packages ``` ``` Operating System: Kubuntu 23.04 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.0-34-generic (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-5820K CPU @ 3.30GHz Memory: 31,2 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2 Manufacturer: ASUS Product Name: All Series ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2039815/+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 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic
Thank you for working on this. Has this been fixed in the development release, and if so, how? It's not clear to me that making this change is the appropriate thing to do in an SRU. How is LXC_DEVEL used in practice? Have you analysed known reverse dependencies to understand the impact of making this change? What did you find? The only impact to users that I can understand from your explanation is that VERSION_AT_LEAST is disabled, causing builds outside the archive that use that macro to fail. Everything else seems to make the assumption that the correct way to fix this is to change LXC_DEVEL from 1 to 0, but without explaining why this is the minimal change possible. Is there any other actual real world impact? Could you just patch to make VERSION_AT_LEAST work instead, for SRU purposes, to minimise regression risk? Please note the entire paragraph from https://wiki.ubuntu.com/StableReleaseUpdates that includes the following text: "...requirements for stable updates are not necessarily the same as those in the development release..." -- 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+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 2018128] Re: Apport does not collect all logs when the package is HWE kernel
Can you test with including the version number in the link name? /usr/share/apport/package-hooks/source_linux-signed-hwe-5.19.py -> source_linux.py -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2018128 Title: Apport does not collect all logs when the package is HWE kernel Status in apport package in Ubuntu: Triaged Status in linux package in Ubuntu: Invalid Bug description: Ubuntu 22.04 LTS with kernel 5.19.0-41-generic When filing bugs against the package 'linux' apport collects all the logs needed to the kernel But in case the user is not on stock kernel anymore and has the HWE kernel apport only imports 2 logs Dependencies.txt + ProcCpuInfoMinimal.txt and forwards the package 'linux' towards linux-signed-hwe-5.19 (in my case) would it be possible to make apport collect all the logs needed in all kernel cases? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: apport 2.20.11-0ubuntu82.4 ProcVersionSignature: Ubuntu 5.19.0-41.42~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-41-generic x86_64 ApportLog: ApportVersion: 2.20.11-0ubuntu82.4 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sat Apr 29 05:25:30 2023 PackageArchitecture: all SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2018128/+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 2018128] Re: Apport does not collect all logs when the package is HWE kernel
** Changed in: linux (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2018128 Title: Apport does not collect all logs when the package is HWE kernel Status in apport package in Ubuntu: Triaged Status in linux package in Ubuntu: Invalid Bug description: Ubuntu 22.04 LTS with kernel 5.19.0-41-generic When filing bugs against the package 'linux' apport collects all the logs needed to the kernel But in case the user is not on stock kernel anymore and has the HWE kernel apport only imports 2 logs Dependencies.txt + ProcCpuInfoMinimal.txt and forwards the package 'linux' towards linux-signed-hwe-5.19 (in my case) would it be possible to make apport collect all the logs needed in all kernel cases? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: apport 2.20.11-0ubuntu82.4 ProcVersionSignature: Ubuntu 5.19.0-41.42~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-41-generic x86_64 ApportLog: ApportVersion: 2.20.11-0ubuntu82.4 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sat Apr 29 05:25:30 2023 PackageArchitecture: all SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/2018128/+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 2040153] Re: Network Manager will not remove Netplan YAMLs when connections are deleted
** Tags added: foundations-todo ** Changed in: netplan.io (Ubuntu Mantic) Status: New => Triaged ** Changed in: network-manager (Ubuntu Mantic) Status: New => Triaged -- 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/2040153 Title: Network Manager will not remove Netplan YAMLs when connections are deleted Status in netplan.io package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Triaged Status in netplan.io source package in Mantic: Triaged Status in network-manager source package in Mantic: Triaged Bug description: When a connection is deleted using any NM facility, libnetplan is failing to delete the YAML file. Because of that, the connection will be recreated when "netplan generate" runs again. This is probably being caused by a combination of two things. First, the NM's systemd unit has this setting "ProtectSystem=true", which will mount /usr as read-only for NM. Second, we migrated the default "00-network-manager-all.yaml" file to, /usr/lib/netplan recently [1]. When libnetplan tries to open this file for writing, the open system fails with EROFS: --- 22517 openat(AT_FDCWD, "/lib/netplan/00-network-manager-all.yaml", O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1 EROFS (Read-only file system) 22517 write(2, "netplan_delete_connection: Canno"..., 76) = 76 --- [1] - https://launchpad.net/ubuntu/+source/ubuntu-settings/23.10.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2040153/+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 2040153] [NEW] Network Manager will not remove Netplan YAMLs when connections are deleted
Public bug reported: When a connection is deleted using any NM facility, libnetplan is failing to delete the YAML file. Because of that, the connection will be recreated when "netplan generate" runs again. This is probably being caused by a combination of two things. First, the NM's systemd unit has this setting "ProtectSystem=true", which will mount /usr as read-only for NM. Second, we migrated the default "00-network-manager-all.yaml" file to, /usr/lib/netplan recently [1]. When libnetplan tries to open this file for writing, the open system fails with EROFS: --- 22517 openat(AT_FDCWD, "/lib/netplan/00-network-manager-all.yaml", O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1 EROFS (Read-only file system) 22517 write(2, "netplan_delete_connection: Canno"..., 76) = 76 --- [1] - https://launchpad.net/ubuntu/+source/ubuntu-settings/23.10.1 ** Affects: netplan.io (Ubuntu) Importance: Critical Status: Triaged ** Affects: network-manager (Ubuntu) Importance: Critical Status: Triaged ** Affects: netplan.io (Ubuntu Mantic) Importance: Critical Status: Triaged ** Affects: network-manager (Ubuntu Mantic) Importance: Critical Status: Triaged ** Tags: foundations-todo ** Also affects: netplan.io (Ubuntu) Importance: Undecided Status: New ** Also affects: network-manager (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: netplan.io (Ubuntu Mantic) Importance: Undecided Status: New ** Changed in: netplan.io (Ubuntu Mantic) Importance: Undecided => Critical ** Changed in: network-manager (Ubuntu Mantic) Importance: Undecided => Critical -- 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/2040153 Title: Network Manager will not remove Netplan YAMLs when connections are deleted Status in netplan.io package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Triaged Status in netplan.io source package in Mantic: Triaged Status in network-manager source package in Mantic: Triaged Bug description: When a connection is deleted using any NM facility, libnetplan is failing to delete the YAML file. Because of that, the connection will be recreated when "netplan generate" runs again. This is probably being caused by a combination of two things. First, the NM's systemd unit has this setting "ProtectSystem=true", which will mount /usr as read-only for NM. Second, we migrated the default "00-network-manager-all.yaml" file to, /usr/lib/netplan recently [1]. When libnetplan tries to open this file for writing, the open system fails with EROFS: --- 22517 openat(AT_FDCWD, "/lib/netplan/00-network-manager-all.yaml", O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1 EROFS (Read-only file system) 22517 write(2, "netplan_delete_connection: Canno"..., 76) = 76 --- [1] - https://launchpad.net/ubuntu/+source/ubuntu-settings/23.10.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2040153/+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 2038811] Re: NetworkManager crashes when updating wpa-eap connections
I'm working on the SRU of a couple of fixes for Netplan. This ticket is being user for the SRU https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2039825 -- 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/2038811 Title: NetworkManager crashes when updating wpa-eap connections Status in netplan.io package in Ubuntu: Triaged Status in network-manager package in Ubuntu: Triaged Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding network-manager. This problem was most recently seen with package version 1.44.2-1ubuntu1, the problem page at https://errors.ubuntu.com/problem/0185fff02c2976262de9f862e539829420f9c737 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2038811/+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 2034986] Re: some text became unreadable during a distribution upgrade
I see the bug is addressed, but for what it's worth, one more data point. I just run into the issue today when doing apt remove fonts-ubuntu* What I didn't notice was that a replacement instead of a removal was carried out fonts-ubuntu (0.83-6ubuntu1 => 0.869-0ubuntu1) After a while I turned back to Firefox — which I had set up to use Ubuntu font as default — and it had corrupted font. That was not during installation, it was my normal several months old Mantic environment. Restarting Firefox solved the problem. I can reproduce it with apt install fonts-ubuntu fonts-ubuntu-classic- ** Attachment added: "zalgo:firefox-right:chromium-left.png" https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2034986/+attachment/5712410/+files/zalgo%3Afirefox-right%3Achromium-left.png -- 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/2034986 Title: some text became unreadable during a distribution upgrade Status in Cinnamon: New Status in Ubuntu MATE: New Status in ubuntu-meta package in Ubuntu: Fix Released Status in ubuntu-release-upgrader package in Ubuntu: In Progress Status in ubuntu-release-upgrader source package in Jammy: Fix Committed Status in ubuntu-release-upgrader source package in Lunar: Fix Released Status in ubuntu-meta source package in Mantic: Fix Released Status in ubuntu-release-upgrader source package in Mantic: In Progress Bug description: [ Impact ] * On Ubuntu Mate with the Lunar series, when running ubuntu-release-upgrader, the displayed font of running applications (including the upgrader) becomes very corrupted. * This is not just a display problem, it is also a functional one. The release upgrader will have text corrupted to the point where a dialog asks a decision, and displays two buttons, but the text is unreadable and one has to guess which button is the one that carries out their desired action. * In the early parts of the upgrader tool, users are told in bold: "To prevent data loss close all open applications and documents." This is just before the "Start Upgrade" button is available. But they may not do so. Many applications may have a corrupted font. * To address this, an additional environment variable is being passed along to pkexec, XDG_CURRENT_DESKTOP, as this is the critical criteria for making the Mate version of the fix work. * Also in the change are * an update to tests * from pre-build.sh * an update of the mirrors.cfg, adding and removing several mirrors * a refresh of the po files [ Test Plan ] * acquire an Ubuntu Mate environment running Ubuntu Lunar on amd64 * as user, run "update-manager -d" * monitor the "Distribution Upgrade" screen. During the "Installing the upgrades" step (and mind that this step will be long), observe the text of the "Distribution Upgrade" screen and verify that the font does not corrupt. * Repeat the above for Ubuntu Desktop [ Where problems could occur ] * We are changing, at release time, ubuntu-release upgrader. If we are careless, we could regress upgrades for a wider group of users than just Ubuntu Mate. That said, it is believed that passing the additional XDG_CURRENT_DESKTOP variable is relatively low risk. [ Other Info ] * TBD --- Original description: I was upgrading from Lunar to Mantic the other day and left a couple of applications open during the upgrade process. During the upgrade the text in audacious became unreadable (I'll attach a screenshot) and I seem to recall the title bar of Firefox being unreadable but the contents of web pages still being readable. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: ubuntu-release-upgrader-core 1:23.10.5 ProcVersionSignature: Ubuntu 6.5.0-4.4-generic 6.5.0 Uname: Linux 6.5.0-4-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia zfs ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CrashDB: ubuntu CurrentDesktop: ubuntu:GNOME Date: Fri Sep 8 15:39:27 2023 InstallationDate: Installed on 2018-08-10 (1855 days ago) InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) PackageArchitecture: all SourcePackage: ubuntu-release-upgrader Symptom: ubuntu-release-upgrader UpgradeStatus: Upgraded to mantic on 2023-09-06 (2 days ago) VarLogDistupgradeAptclonesystemstate.tar.gz: Error: command ['pkexec', 'cat', '/var/log/dist-upgrade/apt-clone_system_state.tar.gz'] failed with exit code 126: Error executing command as another user: Request dismissed VarLogDistupgradeTermlog: mtime.conffile..etc.update-manager.meta-release: 2021-05-27T16:30:16.970490 To manage notifications about this bug go to:
[Touch-packages] [Bug 2039873] Re: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: lxc (Ubuntu) Status: New => Confirmed -- 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/2039873 Title: liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic Status in lxc package in Ubuntu: Confirmed Bug description: [ Impact ] LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release build we should have LXC_DEVEL=0. LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h and then can be (and actually it is) used by other projects to detect if liblxc-dev is a development build or stable. Having LXC_DEVEL=1 makes problems for the users who want to build projects those are depend on liblxc from source (for example, LXD, go-lxc: https://github.com/canonical/lxd/pull/12420). Q: Why it was not a problem for so long? A: Because LXC API was stable for a long time, but recently we have extended liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc was updated too (https://github.com/lxc/go-lxc/pull/166). This change was developed properly to be backward compatible with the old versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro check VERSION_AT_LEAST (https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7) is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release build of LXC. [ Test Plan ] Install liblxc-dev package and check /usr/include/lxc/version.h file LXC_DEVEL should be 0 [ Where problems could occur ] Theoretically, build of a software which depends on liblxc-dev may start to fail if it assumes that LXC_DEVEL is 1. [ Other Info ] - To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+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 1998111] Re: Quectel EM05-G not being unlocked
Yes, correct, I no longer see the issue in mantic. ** Changed in: modemmanager (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1998111 Title: Quectel EM05-G not being unlocked Status in modemmanager package in Ubuntu: Fix Released Bug description: Despite support being in fcc-unlock.d Bus 001 Device 003: ID 2c7c:030a Quectel Wireless Solutions Co., Ltd. Quectel EM05-G the modem remains locked and enabling it fails: jak@jak-t14-g3:~:master$ mmcli -m any -e error: couldn't enable the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Retry: Invalid transition' Doing something like # modprobe -r cdc_mbim # modprobe cdc_mbim # mbimcli --device-open-proxy --device="/dev/wwan0mbim0" --quectel-set-radio-state=on # systemctl RestartModemManager # mmcli -m any -e makes it work. Peculiar it seems that the mbim-proxy process that ModemManager started is hanging and causing the mbimcli command to time out (if I just run it manually). Further investigation warranted, tips welcome. ProblemType: Bug DistroRelease: Ubuntu 23.04 Package: modemmanager 1.20.0-1ubuntu1 ProcVersionSignature: Ubuntu 5.19.0-23.24-generic 5.19.7 Uname: Linux 5.19.0-23-generic x86_64 ApportVersion: 2.23.1-0ubuntu3 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Mon Nov 28 13:54:07 2022 InstallationDate: Installed on 2022-11-26 (1 days ago) InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Alpha amd64 (20221126) SourcePackage: modemmanager UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1998111/+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 2038901] Re: Ubuntu default/minimal installation is only ~11% smaller than full installation
** Summary changed: - Ubuntu default/minimal installation should be smaller + Ubuntu default/minimal installation is only ~11% smaller than full installation -- 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/2038901 Title: Ubuntu default/minimal installation is only ~11% smaller than full installation Status in ubuntu-meta package in Ubuntu: New Bug description: Ubuntu default/minimal installation should be made smaller in future. It's a little too close to the full install size right now. As of mantic 2023-10-10, the default/minimal install ends up 8.4 GB whereas the full install is 9.4 GB. https://docs.google.com/spreadsheets/d/e/2PACX-1vSmQLXuDO0E-tKnWcgjL3Ua2bWDeUg4ICZIfuMrrZndBrYjbVLKAWlKuiZLZ9EOrj4N1WV37DRg8GyW/pubchart?oid=2040836911=interactive To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2038901/+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
