[Touch-packages] [Bug 1452115] Re: Python interpreter binary is not compiled as PIE
Thanks @Giovanni Pellerano for bumping this again. I can confirm that this is an issue in python3.9 (3.9.7, "3.9.7-2build1") and python3.10 (3.10.0, "3.10.0-2") on 21.10 (amd64). I imagine if nothing is done, the upcoming 22.04 LTS will have the issue in its default python(3), which I imagine will be some version of 3.10. # python3 --version Python 3.9.7 # ./checksec --file=/usr/bin/python3 RELRO STACK CANARY NXPIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE Partial RELRO Canary found NX enabledNo PIE No RPATH No RUNPATH No SymbolsYes 14 39 /usr/bin/python3 # python3.10 --version Python 3.10.0 # ./checksec --file=/usr/bin/python3.10 RELRO STACK CANARY NXPIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE Partial RELRO Canary found NX enabledNo PIE No RPATH No RUNPATH No SymbolsYes 14 39 /usr/bin/python3.10 Alternatively, via `hardening-check` from the devscripts package: # hardening-check /usr/bin/python3 /usr/bin/python3: Position Independent Executable: no, normal executable! Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: no, not found! Stack clash protection: unknown, no -fstack-clash-protection instructions found Control flow integrity: yes # hardening-check /usr/bin/python3.10 /usr/bin/python3.10: Position Independent Executable: no, normal executable! Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: no, not found! Stack clash protection: unknown, no -fstack-clash-protection instructions found Control flow integrity: yes ** Also affects: python3.9 (Ubuntu) Importance: Undecided Status: New ** Also affects: python3.10 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1452115 Title: Python interpreter binary is not compiled as PIE Status in Python: New Status in python2.7 package in Ubuntu: Fix Released Status in python3.10 package in Ubuntu: New Status in python3.4 package in Ubuntu: Fix Released Status in python3.6 package in Ubuntu: Confirmed Status in python3.7 package in Ubuntu: Confirmed Status in python3.8 package in Ubuntu: Confirmed Status in python3.9 package in Ubuntu: New Status in python3.7 package in Debian: New Status in python3.8 package in Debian: New Bug description: The python2.7 binary (installed at /usr/bin/python2.7; package version 2.7.6-8) is not compiled as a position independent executable (PIE). It appears that the python compilation process is somewhat arcane and the hardening wrapper probably doesn't do the trick for it. This is incredibly dangerous as it means that any vulnerability within a native module (e.g. ctypes-based), or within python itself will expose an incredibly large amount of known memory contents at known addresses (including a large number of dangerous instruction groupings). This enables ROP-based (https://en.wikipedia.org/wiki/Return-oriented_programming) to abuse the interpreter itself to bypass non-executable page protections. I have put together an example vulnerable C shared object (with a buffer overflow) accessed via python through the ctypes interface as an example. This uses a single ROP "gadget" on top of using the known PLT location for system(3) (https://en.wikipedia.org/wiki/Return-to-libc_attack) to call "id". The example code is accessible at: - https://gist.github.com/ChaosData/ae6076cb1c3cc7b0a367 I'm not exactly familiar enough with the python build process to say where exactly an -fPIE needs to be injected into a script/makefile, but I feel that given the perceived general preference for ctypes- based modules over python written ones, as the native code implementations tend to be more performant, this feels like a large security hole within the system. Given the nature of this "issue," I'm not 100% sure of where it is best reported, but from what I can tell, this conflicts with the Ubuntu hardening features and is definitely exploitable should a native module contain a sufficiently exploitable vulnerability that allows for control of the instruction register. To manage notifications about this bug go to: https://bugs.launchpad.net/python/+bug/1452115/+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 1452115] Re: Python interpreter binary is not compiled as PIE
Hello! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1452115 Title: Python interpreter binary is not compiled as PIE Status in Python: New Status in python2.7 package in Ubuntu: Fix Released Status in python3.4 package in Ubuntu: Fix Released Status in python3.6 package in Ubuntu: Confirmed Status in python3.7 package in Ubuntu: Confirmed Status in python3.8 package in Ubuntu: Confirmed Status in python3.7 package in Debian: New Status in python3.8 package in Debian: New Bug description: The python2.7 binary (installed at /usr/bin/python2.7; package version 2.7.6-8) is not compiled as a position independent executable (PIE). It appears that the python compilation process is somewhat arcane and the hardening wrapper probably doesn't do the trick for it. This is incredibly dangerous as it means that any vulnerability within a native module (e.g. ctypes-based), or within python itself will expose an incredibly large amount of known memory contents at known addresses (including a large number of dangerous instruction groupings). This enables ROP-based (https://en.wikipedia.org/wiki/Return-oriented_programming) to abuse the interpreter itself to bypass non-executable page protections. I have put together an example vulnerable C shared object (with a buffer overflow) accessed via python through the ctypes interface as an example. This uses a single ROP "gadget" on top of using the known PLT location for system(3) (https://en.wikipedia.org/wiki/Return-to-libc_attack) to call "id". The example code is accessible at: - https://gist.github.com/ChaosData/ae6076cb1c3cc7b0a367 I'm not exactly familiar enough with the python build process to say where exactly an -fPIE needs to be injected into a script/makefile, but I feel that given the perceived general preference for ctypes- based modules over python written ones, as the native code implementations tend to be more performant, this feels like a large security hole within the system. Given the nature of this "issue," I'm not 100% sure of where it is best reported, but from what I can tell, this conflicts with the Ubuntu hardening features and is definitely exploitable should a native module contain a sufficiently exploitable vulnerability that allows for control of the instruction register. To manage notifications about this bug go to: https://bugs.launchpad.net/python/+bug/1452115/+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 1962337] Re: Pointer,Prospekt Mail
** Package changed: ubuntu => xorg (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1962337 Title: Pointer,Prospekt Mail Status in xorg package in Ubuntu: New Bug description: My Mouse sometimes jumps from left to right and presses down the right and left buttons. Restarting helps. It opens apps and i am unable to use the computer. Prospekt Mail refuses to open. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-30-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Feb 25 18:05:27 2022 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu ExtraDebuggingInterest: No GraphicsCard: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company HD Graphics 5500 [103c:80dd] InstallationDate: Installed on 2022-01-29 (27 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 04f2:b50c Chicony Electronics Co., Ltd HP Truevision HD Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bus 001 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: HP HP ENVY m6 Notebook ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-30-generic root=UUID=4e8d5df3-3d45-48d0-a629-0d7e3fa05d7e ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/16/2015 dmi.bios.release: 15.34 dmi.bios.vendor: Insyde dmi.bios.version: F.22 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 80DD dmi.board.vendor: HP dmi.board.version: 64.31 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 64.31 dmi.modalias: dmi:bvnInsyde:bvrF.22:bd10/16/2015:br15.34:efr64.31:svnHP:pnHPENVYm6Notebook:pvrType1ProductConfigId:rvnHP:rn80DD:rvr64.31:cvnHP:ct10:cvrChassisVersion:skuT0U83UA#ABA: dmi.product.family: 103C_5335KV G=N L=CON B=HP S=ENV dmi.product.name: HP ENVY m6 Notebook dmi.product.sku: T0U83UA#ABA dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1~20.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1~20.04.2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1962337/+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 1962337] [NEW] Pointer,Prospekt Mail
You have been subscribed to a public bug: My Mouse sometimes jumps from left to right and presses down the right and left buttons. Restarting helps. It opens apps and i am unable to use the computer. Prospekt Mail refuses to open. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-30-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Feb 25 18:05:27 2022 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu ExtraDebuggingInterest: No GraphicsCard: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company HD Graphics 5500 [103c:80dd] InstallationDate: Installed on 2022-01-29 (27 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 04f2:b50c Chicony Electronics Co., Ltd HP Truevision HD Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bus 001 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: HP HP ENVY m6 Notebook ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-30-generic root=UUID=4e8d5df3-3d45-48d0-a629-0d7e3fa05d7e ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/16/2015 dmi.bios.release: 15.34 dmi.bios.vendor: Insyde dmi.bios.version: F.22 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 80DD dmi.board.vendor: HP dmi.board.version: 64.31 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 64.31 dmi.modalias: dmi:bvnInsyde:bvrF.22:bd10/16/2015:br15.34:efr64.31:svnHP:pnHPENVYm6Notebook:pvrType1ProductConfigId:rvnHP:rn80DD:rvr64.31:cvnHP:ct10:cvrChassisVersion:skuT0U83UA#ABA: dmi.product.family: 103C_5335KV G=N L=CON B=HP S=ENV dmi.product.name: HP ENVY m6 Notebook dmi.product.sku: T0U83UA#ABA dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.107-8ubuntu1~20.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.2.6-0ubuntu0.1~20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.13-1ubuntu1~20.04.2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal ubuntu -- Pointer,Prospekt Mail https://bugs.launchpad.net/bugs/1962337 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. -- 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 1870829] Re: AptX and AptX HD unavailable as Bluetooth audio quality options
** Changed in: pulseaudio (Debian) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1870829 Title: AptX and AptX HD unavailable as Bluetooth audio quality options Status in pulseaudio package in Ubuntu: Confirmed Status in pulseaudio package in Debian: Fix Released Bug description: Current situation: When one connects a Bluetooth audio device, at best one can choose between "Headset Head Unit (HSP/HFP)" and "High Fidelity Playback (A2DP Sink)". That is sad when the audio device supports AptX or AptX HD. Expected situation: One can select AptX or AptX HD as the Bluetooth audio output profile. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1870829/+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 1962340] [NEW] Printer rarely actually prints after processing the file.
Public bug reported: My printer is a Brother HL-L2320D laser printer connected via USB with no option for wifi-printing as it's not supported by this printer. It is connected via a USB 3.0 port on my laptop. I'm logged in via regular user, not admin. It is odd that it acts as though it's going to print, then when it's done processing it just disappears from the print que as if the print has been completed. This isn't specific to my Brother printer. I also had this problem with an HP printer prior to replacing the old HP printer. I had this happen in Lubuntu and also in Ubuntu. Description:Ubuntu 20.04.3 LTS Release:20.04 cups: Installed: 2.3.1-9ubuntu1.1 Candidate: 2.3.1-9ubuntu1.1 Version table: *** 2.3.1-9ubuntu1.1 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2.3.1-9ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages I expected my files to print, but they didn't. I did successfully print two of the 6 documents, but what's different about them versus the others, I have no idea. I tried printing via Eye of MATE (which was the default program to open some of the files), and I tried printing them via Firefox, and another file via Libre Office Writer. LO Writer won't print. Eye of Mate won't print. Firefox won't print. I restarted cups via the terminal with "service cups restart" and tried printing via Eye of MATE. It didn't work. I then tried to print via LO Writer. Of the six page document, only the first page printed. What the heck is going on? I then exported that Writer document (which was saved both as .odt and as .docx (neither would print properly or at all) as PDF and opened that with Atril Document Viewer, and it also wouldn't print. It acted like it was processing then disappeared from the Document Printer Status window as if it had completed. Clicking the checkbox it appears as though it was completed. I've never had so many problems trying to print before. I know it's not specific to HP printers, because it's my current printer that's behaving the same way as my old HP and this is Brother. I hoped restarting cups again would fix it, it has not. Switching to a USB 2.0 port didn't resolve the problem. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: cups 2.3.1-9ubuntu1.1 ProcVersionSignature: Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-30-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CupsErrorLog: CurrentDesktop: MATE Date: Fri Feb 25 09:54:20 2022 InstallationDate: Installed on 2022-01-06 (50 days ago) InstallationMedia: Ubuntu-MATE 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819.1) Lpstat: device for HL-L2320D-series: usb://Brother/HL-L2320D%20series?serial=U63877M0N488610 MachineType: Acer Aspire R5-471T Papersize: letter PpdFiles: Error: command ['fgrep', '-H', '*NickName', '/etc/cups/ppd/HL-L2320D-series.ppd'] failed with exit code 2: grep: /etc/cups/ppd/HL-L2320D-series.ppd: Permission denied ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-30-generic root=UUID=f217636e-4924-4eb3-8c0e-bde536732ded ro quiet splash vt.handoff=7 SourcePackage: cups UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/07/2018 dmi.bios.release: 1.13 dmi.bios.vendor: Acer dmi.bios.version: V1.13 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: Luffy dmi.board.vendor: Acer dmi.board.version: V1.13 dmi.chassis.type: 10 dmi.chassis.vendor: Acer dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 1.9 dmi.modalias: dmi:bvnAcer:bvrV1.13:bd03/07/2018:br1.13:efr1.9:svnAcer:pnAspireR5-471T:pvrV1.13:rvnAcer:rnLuffy:rvrV1.13:cvnAcer:ct10:cvrChassisVersion:skuAspireR5-471T_105A_1.13: dmi.product.family: SKL dmi.product.name: Aspire R5-471T dmi.product.sku: Aspire R5-471T_105A_1.13 dmi.product.version: V1.13 dmi.sys.vendor: Acer ** Affects: cups (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1962340 Title: Printer rarely actually prints after processing the file. Status in cups package in Ubuntu: New Bug description: My printer is a Brother HL-L2320D laser printer connected via USB with no option for wifi-printing as it's not supported by this printer. It is connected via a USB 3.0 port on my laptop. I'm logged in via regular user, not admin. It is odd that it acts as though it's going to print, then when it's done processing it just disappears from the print que as if the print has been completed. This isn't specific to my Brother printer. I also had this problem with an HP printer prior to replacing the old HP printer. I had this
[Touch-packages] [Bug 1962332] [NEW] xenial systemd fails to start if cgroup2 is mounted
Public bug reported: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in f and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. ** Affects: systemd (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- 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/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: New Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in f and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1959085] Re: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption
Thank you all for investigating and fixing this. -- 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/1959085 Title: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption Status in Ubuntu CD Images: Fix Released Status in initramfs-tools package in Ubuntu: Invalid Status in zfs-linux package in Ubuntu: Fix Released Bug description: Hi, I just installed the latest Ubuntu desktop from iso file ubuntu-21.10-desktop-amd64.iso inside of VMWare workstation. I chose ZFS and native ZFS encryption of the filesystem. The installation went fine. Everything worked as expected. Then I upgraded the packages to the latest version via the Software updater. After reboot I'm stuck in the initramfs prompt. The following command fails: mount -o zfsutil -t zfs rpool/ROOT/ubuntu_gtw63h /root// Permission denied. And the system never asks me for the password to unlock the root fs. So, I'm guessing that there is something wrong with the new initramfs disk: initrd.img-5.13.0-27-generic When I reboot and select the previous version in grub: initrd.img-5.13.0-27-generic, the system asks for the password and boots without a problem. Thanks. To summarize: 1. Installed new VM using the Ubuntu iso image. Chose ZFS native encryption. Minimal install. 2. As soon as the system came up, I hit the update/upgrade prompt. Rebooted and failed to boot the new version. I didn't customize anything or installed anything extra. root@ubud01:/var# lsb_release -rd Description: Ubuntu 21.10 Release: 21.10 root@ubud01:/var# dpkg -l | grep zfs ii libzfs4linux 2.0.6-1ubuntu2 amd64OpenZFS filesystem library for Linux ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs ii zfs-zed2.0.6-1ubuntu2 amd64OpenZFS Event Daemon ii zfsutils-linux 2.0.6-1ubuntu2 amd64command-line tools to manage OpenZFS filesystems root@ubud01:/var# dpkg -l | grep init ii busybox-initramfs 1:1.30.1-6ubuntu3.1 amd64Standalone shell setup for initramfs ii cryptsetup-initramfs 2:2.3.6-0ubuntu1 all disk encryption support - initramfs integration ii gnome-initial-setup40.4-1ubuntu1 amd64Initial GNOME system setup helper ii init 1.60build1 amd64metapackage ensuring an init system is installed ii init-system-helpers1.60build1 all helper tools for all init systems ii initramfs-tools0.140ubuntu6 all generic modular initramfs generator (automation) ii initramfs-tools-bin0.140ubuntu6 amd64binaries used by initramfs-tools ii initramfs-tools-core 0.140ubuntu6 all generic modular initramfs generator (core tools) ii libatopology2:amd641.2.4-1.1ubuntu3.1 amd64shared library for handling ALSA topology definitions ii libklibc:amd64 2.0.8-6.1ubuntu2 amd64minimal libc subset for use with initramfs ii lsb-base 11.1.0ubuntu3 all Linux Standard Base init script functionality ii ncurses-base 6.2+20201114-2build1 all basic terminal type definitions ii sysvinit-utils 2.96-7ubuntu1 amd64System-V-like utilities ii xinit 1.4.1-0ubuntu3 amd64X server initialisation tool ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs root@ubud01:/var# zfs list NAME USED AVAIL REFER MOUNTPOINT bpool 290M 542M 96K /boot bpool/BOOT 289M 542M 96K none bpool/BOOT/ubuntu_gtw63h 288M 542M 156M /boot rpool
[Touch-packages] [Bug 1959993] Re: SRU of LXC 4.0.12 to focal (upstream bugfix release)
At yesterday's SRU team meeting we concluded that we don't want the archive to end up going down in versions as you upgrade from Focal to Impish. IOW, we aren't granting an exception in this case. Some reasons: The time a security update is needed in the future would not be an appropriate time to be dealing with this complication - for example we wouldn't want to rule out a cherry-pick and a simple ".1" upload to Impish should that be the most appropriate thing at a later time, even if that isn't your normal intention. I trust Stéphane to make sure the right thing happens in the future, but what if he's not around at the time? All general processes we have assume this situation never arises, so fixing it up properly later might get neglected, and it doesn't seem worth ensuring all relevant processes are adjusted to ensure this is done properly if we can just avoid the situation occurring in the first place. Brian noted that the upgrade path from Focal to Impish _is_ supported. It sounded like you can get an update for Impish prepared to match the one you have for Focal, and that wouldn't take you too much effort. Please could you proceed on this basis? -- 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/1959993 Title: SRU of LXC 4.0.12 to focal (upstream bugfix release) Status in lxc package in Ubuntu: In Progress Bug description: LXC released 4.0.12 as a bugfix release and is now in jammy. We'd like to line things up in focal. [Impact] The proposed SRU will bump from 4.0.6 all the way to 4.0.12, lining it up with what's currently in jammy. We've been skipping a few of the bugfix releases in focal so far, mostly catching up when we're starting to see problems with the older version. In this case, we've seen a number of issues when running with the HWE kernels as well as autopkgtest issues on foreign architectures (arm64 and s390x), all those will go away with this bump as we've confirmed everything is clean in jammy. Changelog: * Cherry-pick upstream bugfixes (stable-4.0): - 0002-lxc-checkconfig-Fix-bashism.patch - 0003-doc-Fix-reverse-allowlist-denylist.patch * New upstream bugfix release (4.0.12): (https://discuss.linuxcontainers.org/t/lxc-4-0-12-has-been-released/13288) - Fixed CRIU restoration of containers with pre-created veth interfaces - Fixed issue with kernels lacking SMT support - Extended cgroup2 config options in lxc.mount.auto (cgroup2) - lxc-download now relies on HTTPS for validation (avoids GPG issues) * New upstream bugfix release (4.0.11): (https://discuss.linuxcontainers.org/t/lxc-4-0-11-has-been-released/12427) - Core scheduling support (lxc.sched.core) - riscv64 support in lxc.arch - Significantly improved bash completion profile - Greater use of the new VFS mount API (when supported by the kernel) - Fix containers with empty network namespaces - Handle kernels that lack TIOCGPTPEER - Improve CPU bitmask/id handling (handle skipped CPU numbers) - Reworked the tests to run offline * New upstream bugfix release (4.0.10): (https://discuss.linuxcontainers.org/t/lxc-4-0-10-has-been-released/11618) - Fix issues with less common architectures - Support for additional idmap mounts - nft support in lxc-net - Cleaner mount entries for sys:mixed - Switched GPG server to keyserver.ubuntu.com * New upstream bugfix release (4.0.9): (https://discuss.linuxcontainers.org/t/lxc-4-0-9-has-been-released/10999) - Fix incorrect personality setting when running 32bit containers on 64bit * New upstream bugfix release (4.0.8): - Fix CGroup attach against older running containers * New upstream bugfix release (4.0.7): - Testing improvements including fixes from oss-fuzz - Rework of the attach codepath - Cgroup handling rework * Bump to debhelper 12 (allows focal SRUs) * Bump standards to 4.6.0.1 * Add lintian overrides for incorrect bashism detection * Remove bash completion install logic (now done upstream) Just like Ubuntu itself, upstream releases long term support releases, e.g. 4.0, and then periodic point releases including all the accumulated bugfixes. Only the latest upstream release gets full support from the upstream developers, everyone else is expected to first update to it before receiving any kind of support. This should qualify under the minor/micro upstream bugfix release allowance of the SRU policy, letting us SRU this without paperwork for every single change included in this upstream release. [Test Plan] lxc has autopkgtests which will assert that the binaries built in -proposed are functional. [Where problems could occur] This is catching up a fair bit on recent kernel API changes, including
[Touch-packages] [Bug 1959993] Re: SRU of LXC 4.0.12 to focal (upstream bugfix release)
(note that I haven't actually reviewed the upload yet) -- 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/1959993 Title: SRU of LXC 4.0.12 to focal (upstream bugfix release) Status in lxc package in Ubuntu: In Progress Bug description: LXC released 4.0.12 as a bugfix release and is now in jammy. We'd like to line things up in focal. [Impact] The proposed SRU will bump from 4.0.6 all the way to 4.0.12, lining it up with what's currently in jammy. We've been skipping a few of the bugfix releases in focal so far, mostly catching up when we're starting to see problems with the older version. In this case, we've seen a number of issues when running with the HWE kernels as well as autopkgtest issues on foreign architectures (arm64 and s390x), all those will go away with this bump as we've confirmed everything is clean in jammy. Changelog: * Cherry-pick upstream bugfixes (stable-4.0): - 0002-lxc-checkconfig-Fix-bashism.patch - 0003-doc-Fix-reverse-allowlist-denylist.patch * New upstream bugfix release (4.0.12): (https://discuss.linuxcontainers.org/t/lxc-4-0-12-has-been-released/13288) - Fixed CRIU restoration of containers with pre-created veth interfaces - Fixed issue with kernels lacking SMT support - Extended cgroup2 config options in lxc.mount.auto (cgroup2) - lxc-download now relies on HTTPS for validation (avoids GPG issues) * New upstream bugfix release (4.0.11): (https://discuss.linuxcontainers.org/t/lxc-4-0-11-has-been-released/12427) - Core scheduling support (lxc.sched.core) - riscv64 support in lxc.arch - Significantly improved bash completion profile - Greater use of the new VFS mount API (when supported by the kernel) - Fix containers with empty network namespaces - Handle kernels that lack TIOCGPTPEER - Improve CPU bitmask/id handling (handle skipped CPU numbers) - Reworked the tests to run offline * New upstream bugfix release (4.0.10): (https://discuss.linuxcontainers.org/t/lxc-4-0-10-has-been-released/11618) - Fix issues with less common architectures - Support for additional idmap mounts - nft support in lxc-net - Cleaner mount entries for sys:mixed - Switched GPG server to keyserver.ubuntu.com * New upstream bugfix release (4.0.9): (https://discuss.linuxcontainers.org/t/lxc-4-0-9-has-been-released/10999) - Fix incorrect personality setting when running 32bit containers on 64bit * New upstream bugfix release (4.0.8): - Fix CGroup attach against older running containers * New upstream bugfix release (4.0.7): - Testing improvements including fixes from oss-fuzz - Rework of the attach codepath - Cgroup handling rework * Bump to debhelper 12 (allows focal SRUs) * Bump standards to 4.6.0.1 * Add lintian overrides for incorrect bashism detection * Remove bash completion install logic (now done upstream) Just like Ubuntu itself, upstream releases long term support releases, e.g. 4.0, and then periodic point releases including all the accumulated bugfixes. Only the latest upstream release gets full support from the upstream developers, everyone else is expected to first update to it before receiving any kind of support. This should qualify under the minor/micro upstream bugfix release allowance of the SRU policy, letting us SRU this without paperwork for every single change included in this upstream release. [Test Plan] lxc has autopkgtests which will assert that the binaries built in -proposed are functional. [Where problems could occur] This is catching up a fair bit on recent kernel API changes, including cgroup1/cgroup2 support, handling of nftables, riscv64 and core scheduling which were all needed to properly handle the most recent HWE kernels especially as we're getting ready for Ubuntu 22.04's 5.15 to get pushed to focal. We've had all that code running on well over a million of LXD snap users for a few months now without seeing any issues (or more precisely, those issues we found have been all been resolved as of 4.0.12). However what LXD exercises isn't 100% of LXC and it's certainly possible that we missed a corner case in one of those changes. The good news is that this would most likely be triggered by a HWE kernel, so a viable workaround in many cases would be to temporarily go back to the original kernel (5.4) while the issue is sorted out in a follow up SRU. It's also worth noting that LXD CI runs daily tests against over a dozen different kernels coming from various distros which helps us identify such issues quite early on. [Other Info] Unless absolutely required, we're not intending to push for an SRU to impish as it has a reasonably recent LXC (4.0.10) and
[Touch-packages] [Bug 1959085] Re: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption
On 21.10, zfs-linux packages 2.0.6-1ubuntu2 generate incorrect boot entries for snapshoted systems, please upgrade to 2.0.6-1ubuntu2.1. Snapshots created with the broken old version are not bootable. ** Changed in: zfs-linux (Ubuntu) Status: Incomplete => Fix Released ** Changed in: ubuntu-cdimage Status: Confirmed => Fix Released -- 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/1959085 Title: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption Status in Ubuntu CD Images: Fix Released Status in initramfs-tools package in Ubuntu: Invalid Status in zfs-linux package in Ubuntu: Fix Released Bug description: Hi, I just installed the latest Ubuntu desktop from iso file ubuntu-21.10-desktop-amd64.iso inside of VMWare workstation. I chose ZFS and native ZFS encryption of the filesystem. The installation went fine. Everything worked as expected. Then I upgraded the packages to the latest version via the Software updater. After reboot I'm stuck in the initramfs prompt. The following command fails: mount -o zfsutil -t zfs rpool/ROOT/ubuntu_gtw63h /root// Permission denied. And the system never asks me for the password to unlock the root fs. So, I'm guessing that there is something wrong with the new initramfs disk: initrd.img-5.13.0-27-generic When I reboot and select the previous version in grub: initrd.img-5.13.0-27-generic, the system asks for the password and boots without a problem. Thanks. To summarize: 1. Installed new VM using the Ubuntu iso image. Chose ZFS native encryption. Minimal install. 2. As soon as the system came up, I hit the update/upgrade prompt. Rebooted and failed to boot the new version. I didn't customize anything or installed anything extra. root@ubud01:/var# lsb_release -rd Description: Ubuntu 21.10 Release: 21.10 root@ubud01:/var# dpkg -l | grep zfs ii libzfs4linux 2.0.6-1ubuntu2 amd64OpenZFS filesystem library for Linux ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs ii zfs-zed2.0.6-1ubuntu2 amd64OpenZFS Event Daemon ii zfsutils-linux 2.0.6-1ubuntu2 amd64command-line tools to manage OpenZFS filesystems root@ubud01:/var# dpkg -l | grep init ii busybox-initramfs 1:1.30.1-6ubuntu3.1 amd64Standalone shell setup for initramfs ii cryptsetup-initramfs 2:2.3.6-0ubuntu1 all disk encryption support - initramfs integration ii gnome-initial-setup40.4-1ubuntu1 amd64Initial GNOME system setup helper ii init 1.60build1 amd64metapackage ensuring an init system is installed ii init-system-helpers1.60build1 all helper tools for all init systems ii initramfs-tools0.140ubuntu6 all generic modular initramfs generator (automation) ii initramfs-tools-bin0.140ubuntu6 amd64binaries used by initramfs-tools ii initramfs-tools-core 0.140ubuntu6 all generic modular initramfs generator (core tools) ii libatopology2:amd641.2.4-1.1ubuntu3.1 amd64shared library for handling ALSA topology definitions ii libklibc:amd64 2.0.8-6.1ubuntu2 amd64minimal libc subset for use with initramfs ii lsb-base 11.1.0ubuntu3 all Linux Standard Base init script functionality ii ncurses-base 6.2+20201114-2build1 all basic terminal type definitions ii sysvinit-utils 2.96-7ubuntu1 amd64System-V-like utilities ii xinit 1.4.1-0ubuntu3 amd64X server initialisation tool ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs root@ubud01:/var# zfs list NAME USED AVAIL REFER
[Touch-packages] [Bug 1959085] Re: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption
Ubuntu 22.04 daily images testing issues have been resolved and a new image promoted, jammy installs are now working correctly. -- 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/1959085 Title: Ubuntu 22.04 boot stuck in initramfs, when installed with zfs encryption Status in Ubuntu CD Images: Confirmed Status in initramfs-tools package in Ubuntu: Invalid Status in zfs-linux package in Ubuntu: Incomplete Bug description: Hi, I just installed the latest Ubuntu desktop from iso file ubuntu-21.10-desktop-amd64.iso inside of VMWare workstation. I chose ZFS and native ZFS encryption of the filesystem. The installation went fine. Everything worked as expected. Then I upgraded the packages to the latest version via the Software updater. After reboot I'm stuck in the initramfs prompt. The following command fails: mount -o zfsutil -t zfs rpool/ROOT/ubuntu_gtw63h /root// Permission denied. And the system never asks me for the password to unlock the root fs. So, I'm guessing that there is something wrong with the new initramfs disk: initrd.img-5.13.0-27-generic When I reboot and select the previous version in grub: initrd.img-5.13.0-27-generic, the system asks for the password and boots without a problem. Thanks. To summarize: 1. Installed new VM using the Ubuntu iso image. Chose ZFS native encryption. Minimal install. 2. As soon as the system came up, I hit the update/upgrade prompt. Rebooted and failed to boot the new version. I didn't customize anything or installed anything extra. root@ubud01:/var# lsb_release -rd Description: Ubuntu 21.10 Release: 21.10 root@ubud01:/var# dpkg -l | grep zfs ii libzfs4linux 2.0.6-1ubuntu2 amd64OpenZFS filesystem library for Linux ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs ii zfs-zed2.0.6-1ubuntu2 amd64OpenZFS Event Daemon ii zfsutils-linux 2.0.6-1ubuntu2 amd64command-line tools to manage OpenZFS filesystems root@ubud01:/var# dpkg -l | grep init ii busybox-initramfs 1:1.30.1-6ubuntu3.1 amd64Standalone shell setup for initramfs ii cryptsetup-initramfs 2:2.3.6-0ubuntu1 all disk encryption support - initramfs integration ii gnome-initial-setup40.4-1ubuntu1 amd64Initial GNOME system setup helper ii init 1.60build1 amd64metapackage ensuring an init system is installed ii init-system-helpers1.60build1 all helper tools for all init systems ii initramfs-tools0.140ubuntu6 all generic modular initramfs generator (automation) ii initramfs-tools-bin0.140ubuntu6 amd64binaries used by initramfs-tools ii initramfs-tools-core 0.140ubuntu6 all generic modular initramfs generator (core tools) ii libatopology2:amd641.2.4-1.1ubuntu3.1 amd64shared library for handling ALSA topology definitions ii libklibc:amd64 2.0.8-6.1ubuntu2 amd64minimal libc subset for use with initramfs ii lsb-base 11.1.0ubuntu3 all Linux Standard Base init script functionality ii ncurses-base 6.2+20201114-2build1 all basic terminal type definitions ii sysvinit-utils 2.96-7ubuntu1 amd64System-V-like utilities ii xinit 1.4.1-0ubuntu3 amd64X server initialisation tool ii zfs-initramfs 2.0.6-1ubuntu2 amd64OpenZFS root filesystem capabilities for Linux - initramfs root@ubud01:/var# zfs list NAME USED AVAIL REFER MOUNTPOINT bpool 290M 542M 96K /boot bpool/BOOT 289M 542M 96K none bpool/BOOT/ubuntu_gtw63h
[Touch-packages] [Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm
** Description changed: + [Impact] + + * There's currently a deadlock between PID 1 and dbus-daemon: in some + cases dbus-daemon will do NSS lookups (which are blocking) at the same + time PID 1 synchronously blocks on some call to dbus-daemon (e.g. `GetConnectionUnixUser` DBus call). Let's break + that by setting SYSTEMD_NSS_DYNAMIC_BYPASS=1 env var for dbus-daemon, + which will disable synchronously blocking varlink calls from nss-systemd + to PID 1. + + * This can lead to delayed boot times + + * It can also lead to dbus-daemon being killed/re-started, taking down + other services with it, like GDM, killing user sessions on the way (e.g. + on installing updates) + + [Test Plan] + + * This bug is really hard to reproduce, as can be seen from the multi- + year long discussion at https://github.com/systemd/systemd/issues/15316 + + * Canonical's CPC team has the ability to reproduce this issue (with a + relatively high probability) in their Azure test environment, due to the + specific setup they are using + + * So our test plan is to ask CPC (@gjolly) for confirmation if the + issue is fixed. + + [Where problems could occur] + + * This fix touches the communication between systemd and dbus daemon, + especially the NSS lookup, so if something is broken the (user-)name + resolution could be broken. + + * As a workaround dbus-daemon could be replaced by dbus-broker, which + never showed this issue or the behaviour could be changed back by using + the `SYSTEMD_NSS_DYNAMIC_BYPASS` env variable, like this: + + #/etc/systemd/system/dbus.service.d/override.conf + [Service] + Environment=SYSTEMD_NSS_DYNAMIC_BYPASS=0 + + [Other Info] + + * Fixed upstream (v251) in https://github.com/systemd/systemd/pull/22552 + + + === Original Description === + + + This morning I found my computer on the login screen. But not the one of the screen log, no a new one - so something must have crashed. Logging in again confirmed that all apps were gone and the gnome shell was brought down what seems like triggered by a background update o accountsservice. As always things are not perfectly clear :-/ The following goes *back* in time through my logs one by one. Multiple apps crashed at 06:09, but we will find later that this is a follow on issue of the underlying gnome/X/... recycling. -rw-r- 1 paelzer whoopsie 52962868 Apr 8 06:09 _usr_bin_konversation.1000.crash -rw-r- 1 paelzer whoopsie 986433 Apr 8 06:09 _usr_lib_x86_64-linux-gnu_libexec_drkonqi.1000.crash - rdkit was failing fast and giving up (that will be a different bug, it just seems broken on my system): Apr 08 06:10:13 Keschdeichel systemd[1]: Started RealtimeKit Scheduling Policy Service. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully called chroot. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully dropped privileges. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully limited resources. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: pthread_create failed: Resource temporarily unavailable Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Canary thread running. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Exiting canary thread. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoting known real-time threads. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoted 0 threads. Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Main process exited, code=exited, status=1/FAILURE Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with result 'exit-code'. Apr 08 06:10:13 Keschdeichel dbus-daemon[1208]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' requested by ':1.1176' (uid=121 pid=> Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Start request repeated too quickly. Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with result 'exit-code'. Apr 08 06:10:13 Keschdeichel systemd[1]: Failed to start RealtimeKit Scheduling Policy Service. Apr 08 06:10:13 Keschdeichel bluetoothd[1729331]: Bluetooth daemon 5.53 - - But that already was only triggered by a gnome restart that kicked of earlier: + But that already was only triggered by a gnome restart that kicked of + earlier: Apr 08 06:09:27 Keschdeichel systemd[1726656]: Started GNOME Shell on Wayland. Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Shell on Wayland. Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session is initialized. Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Wayland Session. Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached target GNOME Session (session: gnome-login). - X was recycleing before: Apr 08 06:09:19 Keschdeichel systemd[10683]: Stopping GNOME Shell on X11... ... Apr 08 06:09:22
[Touch-packages] [Bug 1962035] Re: apparmor blocks VM installation when automatic UEFI firmware is set
/etc/apparmor.d/abstractions/libvirt-qemu is shipped by libvirt-daemon-
system, reassigning. I can reproduce this, and I'll attempt to work on a
fix. I'll update the Debian bug as well.
Complete copy reproducer:
virt-install --connect qemu:///system --quiet --os-variant fedora28 --memory
128 --name test --wait -1 --disk size=0.125,format=qcow2 --graphics
vnc,listen=127.0.0.1 --graphics spice,listen=127.0.0.1 --print-xml 1 | sed
"s/ /tmp/test1.xml
virsh define /tmp/test1.xml
touch /var/lib/libvirt/novell.iso
virt-install --connect qemu:///system --reinstall test --wait -1
--noautoconsole --cdrom /var/lib/libvirt/novell.iso --autostart
** Package changed: apparmor (Ubuntu) => libvirt (Ubuntu)
** Changed in: libvirt (Ubuntu)
Status: New => Triaged
** Changed in: libvirt (Ubuntu)
Assignee: (unassigned) => Martin Pitt (pitti)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1962035
Title:
apparmor blocks VM installation when automatic UEFI firmware is set
Status in libvirt package in Ubuntu:
Triaged
Status in apparmor package in Debian:
New
Bug description:
# lsb_release -rd
Description: Ubuntu 21.10
Release: 21.10
Package: apparmor
Version: 3.0.3-0ubuntu1
Package: virtinst
Version: 1:3.2.0-3
When trying to re-install an existing VM with uefi boot set up using the
recently introduced `--reinstall` option apparmor makes the installation
fail with the following error:
Could not open '/var/lib/libvirt/qemu/nvram/test_VARS.fd': Permission
denied
Steps to reproduce:
Create a VM:
root@ubuntu:~# virt-install --connect qemu:///system --quiet --os-variant
fedora28 --memory 1024 --name test --wait -1 --disk size=1,format=qcow2
--print-xml 1 > /tmp/test1.xml
Edit the VM configuration to enable automatic UEFI boot by changing the
like follows:
-
+
Define the VM:
root@ubuntu:~# virsh define /tmp/test1.xml
Start VM installation:
root@ubuntu:~# virt-install --connect qemu:///system --reinstall test --wait
-1 --noautoconsole --cdrom /var/lib/libvirt/novell.iso --autostart
WARNING No operating system detected, VM performance may suffer. Specify an
OS with --os-variant for optimal results.
Starting install...
ERRORinternal error: process exited while connecting to monitor:
2022-02-23T18:56:54.738510Z qemu-system-x86_64: -blockdev
{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/test_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}:
Could not open '/var/lib/libvirt/qemu/nvram/test_VARS.fd': Permission denied
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start test
otherwise, please restart your installation.
Expected behavior:
VM installation will start without apparmor error.
Actual behavior:
The above denial happens:
Feb 23 18:56:54 ubuntu audit[4420]: AVC apparmor="DENIED"
operation="open" profile="libvirt-
bdd92fa6-6030-4980-951c-2a52ec7e406c"
name="/var/lib/libvirt/qemu/nvram/test_VARS.fd" pid=4420 comm="qemu-
system-x86" requested_mask="r" denied_m>
and stop the installation.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1962035/+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 1962310] Re: ubuntu-bug has python errors that show up in the terminal
1) The release of Ubuntu you are using, via 'lsb_release -rd' or System
-> About Ubuntu
$ lsb_release -rd
Description: Ubuntu 20.04.4 LTS
Release: 20.04
2) The version of the package you are using, via 'apt-cache policy
pkgname' or by checking in Software Center
$ apt-cache policy apport
apport:
Installed: 2.20.11-0ubuntu27.21
Candidate: 2.20.11-0ubuntu27.21
Version table:
*** 2.20.11-0ubuntu27.21 500
500 http://gb.archive.ubuntu.com/ubuntu focal-updates/main amd64
Packages
500 http://gb.archive.ubuntu.com/ubuntu focal-updates/main i386 Packages
500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
500 http://security.ubuntu.com/ubuntu focal-security/main i386 Packages
100 /var/lib/dpkg/status
2.20.11-0ubuntu27 500
500 http://gb.archive.ubuntu.com/ubuntu focal/main amd64 Packages
500 http://gb.archive.ubuntu.com/ubuntu focal/main i386 Packages
3) What you expected to happen
No errors when running ubuntu-bug.
4) What happened instead
Errors displayed about ubuntu-bug as above. Application seems to run
fine just enough so that I can send bug reports.
--
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/1962310
Title:
ubuntu-bug has python errors that show up in the terminal
Status in apport package in Ubuntu:
New
Bug description:
Error displayed in the terminal is:
/usr/lib/python3/dist-packages/requests/__init__.py:89:
RequestsDependencyWarning: urllib3 (1.26.8) or chardet (3.0.4) doesn't match a
supported version!
warnings.warn("urllib3 ({}) or chardet ({}) doesn't match a supported "
dpkg-query: no packages found matching ubuntu-bug
The application does run, after a while I also get the following
messages:
/usr/lib/python3/dist-packages/requests/__init__.py:89:
RequestsDependencyWarning: urllib3 (1.26.8) or chardet (3.0.4) doesn't match a
supported version!
warnings.warn("urllib3 ({}) or chardet ({}) doesn't match a supported "
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late
to send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
[Touch-packages] [Bug 1962310] [NEW] ubuntu-bug has python errors that show up in the terminal
Public bug reported:
Error displayed in the terminal is:
/usr/lib/python3/dist-packages/requests/__init__.py:89:
RequestsDependencyWarning: urllib3 (1.26.8) or chardet (3.0.4) doesn't match a
supported version!
warnings.warn("urllib3 ({}) or chardet ({}) doesn't match a supported "
dpkg-query: no packages found matching ubuntu-bug
The application does run, after a while I also get the following
messages:
/usr/lib/python3/dist-packages/requests/__init__.py:89:
RequestsDependencyWarning: urllib3 (1.26.8) or chardet (3.0.4) doesn't match a
supported version!
warnings.warn("urllib3 ({}) or chardet ({}) doesn't match a supported "
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PBackgroundIDBDatabase::Msg_Close) Channel closing: too late
to send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
Send(msgname=PMessagePort::Msg___delete__) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close) Channel closing: too late to
send/recv, messages will be lost
###!!! [Parent][PBackgroundParent] Error:
RunMessage(msgname=PMessagePort::Msg_Close)
[Touch-packages] [Bug 1962038] Re: wrong sysrq value in /usr/lib/sysctl.d/50-default.conf
** Also affects: procps (Ubuntu) Importance: Undecided Status: New ** Changed in: procps (Ubuntu Impish) Status: New => Won't Fix ** Tags added: update-excuse -- 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/1962038 Title: wrong sysrq value in /usr/lib/sysctl.d/50-default.conf Status in procps package in Ubuntu: New Status in systemd package in Ubuntu: Triaged Status in procps source package in Impish: Won't Fix Status in systemd source package in Impish: New Status in procps source package in Jammy: New Status in systemd source package in Jammy: Triaged Bug description: [Impact] I've just learned that systemd is setting kernel.sysrq to 16 in /usr/lib/sysctl.d/50-default.conf. This is inconsistent with /etc/sysctl.d/10-magic-sysrq.conf which intentionally sets it to 176 by default. systemd should drop its setting to defer to the file that we have been carrying in procps for a very long time. Therefore, users can only sync their storage but not do any other actions using the magic sysrq key. [Test Plan] $ sysctl kernel.sysrq => This should show "kernel.sysrq = 176" as set by /etc/sysctl.d/10-magic-sysrq.conf $ sysctl net.ipv4.conf.all.rp_filter => This should show "net.ipv4.conf.all.rp_filter=2" as set by /etc/sysctl.d/10-network-security.conf [Where problems could occur] * This patch changes systemd's sysctl configuration in /lib/sysctl.d/*.conf * If something is broken it could fail to apply any of systemd's sysctl configuration, but Ubuntu's defaults from /etc/sysctl.d/*.conf would still be in place. [Other Info] * None To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1962038/+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 1962038] Re: wrong sysrq value in /usr/lib/sysctl.d/50-default.conf
** Description changed: + [Impact] + I've just learned that systemd is setting kernel.sysrq to 16 in /usr/lib/sysctl.d/50-default.conf. This is inconsistent with /etc/sysctl.d/10-magic-sysrq.conf which intentionally sets it to 176 by default. systemd should drop its setting to defer to the file that we have been carrying in procps for a very long time. + + Therefore, users can only sync their storage but not do any other + actions using the magic sysrq key. + + [Test Plan] + + $ sysctl kernel.sysrq + => This should show "kernel.sysrq = 176" as set by /etc/sysctl.d/10-magic-sysrq.conf + $ sysctl net.ipv4.conf.all.rp_filter + => This should show "net.ipv4.conf.all.rp_filter=2" as set by /etc/sysctl.d/10-network-security.conf + + [Where problems could occur] + + * This patch changes systemd's sysctl configuration in /lib/sysctl.d/*.conf + * If something is broken it could fail to apply any of systemd's sysctl configuration, but Ubuntu's defaults from /etc/sysctl.d/*.conf would still be in place. + + [Other Info] + + * None -- 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/1962038 Title: wrong sysrq value in /usr/lib/sysctl.d/50-default.conf Status in systemd package in Ubuntu: Triaged Status in systemd source package in Impish: New Status in systemd source package in Jammy: Triaged Bug description: [Impact] I've just learned that systemd is setting kernel.sysrq to 16 in /usr/lib/sysctl.d/50-default.conf. This is inconsistent with /etc/sysctl.d/10-magic-sysrq.conf which intentionally sets it to 176 by default. systemd should drop its setting to defer to the file that we have been carrying in procps for a very long time. Therefore, users can only sync their storage but not do any other actions using the magic sysrq key. [Test Plan] $ sysctl kernel.sysrq => This should show "kernel.sysrq = 176" as set by /etc/sysctl.d/10-magic-sysrq.conf $ sysctl net.ipv4.conf.all.rp_filter => This should show "net.ipv4.conf.all.rp_filter=2" as set by /etc/sysctl.d/10-network-security.conf [Where problems could occur] * This patch changes systemd's sysctl configuration in /lib/sysctl.d/*.conf * If something is broken it could fail to apply any of systemd's sysctl configuration, but Ubuntu's defaults from /etc/sysctl.d/*.conf would still be in place. [Other Info] * None To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962038/+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 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm
** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** No longer affects: systemd (Ubuntu Groovy) ** No longer affects: systemd (Ubuntu Hirsute) ** Also affects: dbus (Ubuntu Jammy) Importance: High Status: Incomplete ** Also affects: gnome-shell (Ubuntu Jammy) Importance: Undecided Status: Invalid ** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: accountsservice (Ubuntu Jammy) Importance: Undecided Status: Invalid ** Changed in: dbus (Ubuntu Impish) Status: Incomplete => Invalid ** Changed in: dbus (Ubuntu Jammy) Status: Incomplete => Invalid ** Changed in: dbus (Ubuntu Groovy) Status: Incomplete => Invalid ** Changed in: dbus (Ubuntu Focal) Status: Incomplete => 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/1871538 Title: dbus timeout-ed during an upgrade, taking services down including gdm Status in D-Bus: Unknown Status in systemd: New Status in accountsservice package in Ubuntu: Invalid Status in dbus package in Ubuntu: Invalid Status in gnome-shell package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Status in accountsservice source package in Focal: Invalid Status in dbus source package in Focal: Invalid Status in gnome-shell source package in Focal: Invalid Status in systemd source package in Focal: New Status in accountsservice source package in Groovy: Invalid Status in dbus source package in Groovy: Invalid Status in gnome-shell source package in Groovy: Invalid Status in accountsservice source package in Hirsute: Invalid Status in dbus source package in Hirsute: Won't Fix Status in gnome-shell source package in Hirsute: Invalid Status in accountsservice source package in Impish: Invalid Status in dbus source package in Impish: Invalid Status in gnome-shell source package in Impish: Invalid Status in systemd source package in Impish: New Status in accountsservice source package in Jammy: Invalid Status in dbus source package in Jammy: Invalid Status in gnome-shell source package in Jammy: Invalid Status in systemd source package in Jammy: New Bug description: This morning I found my computer on the login screen. But not the one of the screen log, no a new one - so something must have crashed. Logging in again confirmed that all apps were gone and the gnome shell was brought down what seems like triggered by a background update o accountsservice. As always things are not perfectly clear :-/ The following goes *back* in time through my logs one by one. Multiple apps crashed at 06:09, but we will find later that this is a follow on issue of the underlying gnome/X/... recycling. -rw-r- 1 paelzer whoopsie 52962868 Apr 8 06:09 _usr_bin_konversation.1000.crash -rw-r- 1 paelzer whoopsie 986433 Apr 8 06:09 _usr_lib_x86_64-linux-gnu_libexec_drkonqi.1000.crash rdkit was failing fast and giving up (that will be a different bug, it just seems broken on my system): Apr 08 06:10:13 Keschdeichel systemd[1]: Started RealtimeKit Scheduling Policy Service. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully called chroot. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully dropped privileges. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Successfully limited resources. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: pthread_create failed: Resource temporarily unavailable Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Canary thread running. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Exiting canary thread. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoting known real-time threads. Apr 08 06:10:13 Keschdeichel rtkit-daemon[1729333]: Demoted 0 threads. Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Main process exited, code=exited, status=1/FAILURE Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with result 'exit-code'. Apr 08 06:10:13 Keschdeichel dbus-daemon[1208]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' requested by ':1.1176' (uid=121 pid=> Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Start request repeated too quickly. Apr 08 06:10:13 Keschdeichel systemd[1]: rtkit-daemon.service: Failed with result 'exit-code'. Apr 08 06:10:13 Keschdeichel systemd[1]: Failed to start RealtimeKit Scheduling Policy Service. Apr 08 06:10:13 Keschdeichel bluetoothd[1729331]: Bluetooth daemon 5.53 But that already was only triggered by a gnome restart that kicked of earlier: Apr 08 06:09:27 Keschdeichel systemd[1726656]: Started GNOME Shell on Wayland. Apr 08 06:09:27 Keschdeichel systemd[1726656]: Reached
[Touch-packages] [Bug 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)
To summarize: 1. Removing resolvconf looks like practical solution for people who face the problem 2. I do not know, whether crashes in such a case are natural and expected, or they simply trigger some buggy behaviour unlikely in „normal” situation. Depending on that either there should be some installation-level protection (like Conflict between packages) … or this is the way to reproduce. -- 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/1906331 Title: systemd-resolve crashes fairly often (and reports various assertions) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Incomplete Status in systemd source package in Groovy: Won't Fix Status in systemd source package in Hirsute: Fix Released Bug description: [impact] systemd-resolved crashes [test case] see original description; I can't reproduce so I'm relying on the reporter(s) to test/verify. [regression potential] any regression would likely occur while processing sd_event objects, which are used throughout systemd code; this could result in crashes in almost any part of systemd code. However a more likely regression would be leaks of sd_event objects due to failure to release the final ref for an object. [scope] This is needed for f/g/h This might be fixed by upstream commit f814c871e65df8552a055dd887bc94b074037833; if so, that commit isn't included in any systemd release yet, and so is needed in h and earlier. [other info] I believe this is caused by a freed sd_event object that is then processed and calls the on_query_timeout callback with invalid state, leading to failed assertion, which causes resolved to crash; that's what analysis of the crash dump appears to indicate. This may be fixed by the upstream commit referenced in [scope], which takes additional refs during function calls. However I haven't reproduced this myself, so I'm only guessing as to the cause and solution at this point. I'm unsure why this would not occur in bionic, but per comment 5 it seems it doesn't happen in that release. [original description] (Tested on regularly updated Ubuntu 20.04, currently i use systemd 245.4-4ubuntu3.2) I observe fairly lot of segfaults of systemd-resolve. Frequency vary but … see below. I have no clue what is the reason. Specific feature of my machine is that apart from normal cable connection (to OpenWRT router) I use OpenVPN for business network (and this submits specific nameserver for myorg.local domain). ~ $ LC_ALL=C dmesg -T --level=info | grep systemd-resolve [Sun Nov 29 11:47:37 2020] systemd-resolve[1629307]: segfault at 190eed7bdc6 ip 7fd98f771dc9 sp 7ffc2352a100 error 4 in libsystemd-shared-245.so[7fd98f74c000+16e000] [Sun Nov 29 11:57:27 2020] systemd-resolve[1629787]: segfault at 1f ip 55ab7b0cb686 sp 7fff78ce4bd0 error 4 in systemd-resolved[55ab7b0a4000+3e000] [Sun Nov 29 12:07:37 2020] systemd-resolve[1630481]: segfault at 191 ip 55ca69fed91c sp 7ffc4d757dc0 error 6 in systemd-resolved[55ca69fc2000+3e000] [Sun Nov 29 13:12:26 2020] systemd-resolve[1638829]: segfault at 19224162371 ip 7fc1bc9b9dc9 sp 7ffc21378170 error 4 in libsystemd-shared-245.so[7fc1bc994000+16e000] [Sun Nov 29 13:32:57 2020] systemd-resolve[1639886]: segfault at 1926d8126d3 ip 7f7ed17e9dc9 sp 7ffda2cea0b0 error 4 in libsystemd-shared-245.so[7f7ed17c4000+16e000] [Sun Nov 29 13:42:37 2020] systemd-resolve[1640246]: segfault at 61 ip 558d992e2686 sp 7fff08906af0 error 4 in systemd-resolved[558d992bb000+3e000] [Sun Nov 29 15:42:26 2020] systemd-resolve[1645397]: segfault at 1943c92afc7 ip 7fd4c1721dc9 sp 7fff25259ce0 error 4 in libsystemd-shared-245.so[7fd4c16fc000+16e000] [Sun Nov 29 16:02:36 2020] systemd-resolve[1646052]: segfault at 1947ecb3726 ip 7f1008549dc9 sp 7fff44a6db70 error 4 in libsystemd-shared-245.so[7f1008524000+16e000] [Sun Nov 29 17:42:35 2020] systemd-resolve[1649403]: segfault at 71 ip 55a37fe5a686 sp 7ffd9a160440 error 4 in systemd-resolved[55a37fe33000+3e000] [Sun Nov 29 17:52:35 2020] systemd-resolve[1649759]: segfault at 558d292947d0 ip 558d292947d0 sp 7ffec7ab3bf8 error 15 [Sun Nov 29 19:17:55 2020] systemd-resolve[1652349]: segfault at 558995b77cf0 ip 558995b77cf0 sp 7ffe545ae4a8 error 15 [Sun Nov 29 19:32:35 2020] systemd-resolve[1652640]: segfault at 19773c20194 ip 7f66bb529dc9 sp 7fffd7066fc0 error 4 in libsystemd-shared-245.so[7f66bb504000+16e000] [Sun Nov 29 20:03:54 2020] systemd-resolve[1653715]: segfault at 197e3aee918 ip 7fdc40b51dc9 sp 7ffde484fbf0 error 4 in libsystemd-shared-245.so[7fdc40b2c000+16e000] [Sun Nov 29 20:22:24 2020] systemd-resolve[1654540]: segfault at 19820a05297 ip
[Touch-packages] [Bug 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)
More than 12 hours now (since `apt remove resolvconf`). systemd-resolved still running without crash -- 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/1906331 Title: systemd-resolve crashes fairly often (and reports various assertions) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Incomplete Status in systemd source package in Groovy: Won't Fix Status in systemd source package in Hirsute: Fix Released Bug description: [impact] systemd-resolved crashes [test case] see original description; I can't reproduce so I'm relying on the reporter(s) to test/verify. [regression potential] any regression would likely occur while processing sd_event objects, which are used throughout systemd code; this could result in crashes in almost any part of systemd code. However a more likely regression would be leaks of sd_event objects due to failure to release the final ref for an object. [scope] This is needed for f/g/h This might be fixed by upstream commit f814c871e65df8552a055dd887bc94b074037833; if so, that commit isn't included in any systemd release yet, and so is needed in h and earlier. [other info] I believe this is caused by a freed sd_event object that is then processed and calls the on_query_timeout callback with invalid state, leading to failed assertion, which causes resolved to crash; that's what analysis of the crash dump appears to indicate. This may be fixed by the upstream commit referenced in [scope], which takes additional refs during function calls. However I haven't reproduced this myself, so I'm only guessing as to the cause and solution at this point. I'm unsure why this would not occur in bionic, but per comment 5 it seems it doesn't happen in that release. [original description] (Tested on regularly updated Ubuntu 20.04, currently i use systemd 245.4-4ubuntu3.2) I observe fairly lot of segfaults of systemd-resolve. Frequency vary but … see below. I have no clue what is the reason. Specific feature of my machine is that apart from normal cable connection (to OpenWRT router) I use OpenVPN for business network (and this submits specific nameserver for myorg.local domain). ~ $ LC_ALL=C dmesg -T --level=info | grep systemd-resolve [Sun Nov 29 11:47:37 2020] systemd-resolve[1629307]: segfault at 190eed7bdc6 ip 7fd98f771dc9 sp 7ffc2352a100 error 4 in libsystemd-shared-245.so[7fd98f74c000+16e000] [Sun Nov 29 11:57:27 2020] systemd-resolve[1629787]: segfault at 1f ip 55ab7b0cb686 sp 7fff78ce4bd0 error 4 in systemd-resolved[55ab7b0a4000+3e000] [Sun Nov 29 12:07:37 2020] systemd-resolve[1630481]: segfault at 191 ip 55ca69fed91c sp 7ffc4d757dc0 error 6 in systemd-resolved[55ca69fc2000+3e000] [Sun Nov 29 13:12:26 2020] systemd-resolve[1638829]: segfault at 19224162371 ip 7fc1bc9b9dc9 sp 7ffc21378170 error 4 in libsystemd-shared-245.so[7fc1bc994000+16e000] [Sun Nov 29 13:32:57 2020] systemd-resolve[1639886]: segfault at 1926d8126d3 ip 7f7ed17e9dc9 sp 7ffda2cea0b0 error 4 in libsystemd-shared-245.so[7f7ed17c4000+16e000] [Sun Nov 29 13:42:37 2020] systemd-resolve[1640246]: segfault at 61 ip 558d992e2686 sp 7fff08906af0 error 4 in systemd-resolved[558d992bb000+3e000] [Sun Nov 29 15:42:26 2020] systemd-resolve[1645397]: segfault at 1943c92afc7 ip 7fd4c1721dc9 sp 7fff25259ce0 error 4 in libsystemd-shared-245.so[7fd4c16fc000+16e000] [Sun Nov 29 16:02:36 2020] systemd-resolve[1646052]: segfault at 1947ecb3726 ip 7f1008549dc9 sp 7fff44a6db70 error 4 in libsystemd-shared-245.so[7f1008524000+16e000] [Sun Nov 29 17:42:35 2020] systemd-resolve[1649403]: segfault at 71 ip 55a37fe5a686 sp 7ffd9a160440 error 4 in systemd-resolved[55a37fe33000+3e000] [Sun Nov 29 17:52:35 2020] systemd-resolve[1649759]: segfault at 558d292947d0 ip 558d292947d0 sp 7ffec7ab3bf8 error 15 [Sun Nov 29 19:17:55 2020] systemd-resolve[1652349]: segfault at 558995b77cf0 ip 558995b77cf0 sp 7ffe545ae4a8 error 15 [Sun Nov 29 19:32:35 2020] systemd-resolve[1652640]: segfault at 19773c20194 ip 7f66bb529dc9 sp 7fffd7066fc0 error 4 in libsystemd-shared-245.so[7f66bb504000+16e000] [Sun Nov 29 20:03:54 2020] systemd-resolve[1653715]: segfault at 197e3aee918 ip 7fdc40b51dc9 sp 7ffde484fbf0 error 4 in libsystemd-shared-245.so[7fdc40b2c000+16e000] [Sun Nov 29 20:22:24 2020] systemd-resolve[1654540]: segfault at 19820a05297 ip 7f6a92839dc9 sp 7ffe4ba00440 error 4 in libsystemd-shared-245.so[7f6a92814000+16e000] [Sun Nov 29 21:13:10 2020] systemd-resolve[1660272]: segfault at 555f9a5915e0 ip 555f9a5915e0 sp 7fff053e5e68 error 15 [Sun Nov 29 21:32:34 2020] systemd-resolve[1661026]: segfault at 1991af73f2e ip
[Touch-packages] [Bug 1962038] Re: wrong sysrq value in /usr/lib/sysctl.d/50-default.conf
** Also affects: systemd (Ubuntu Impish) 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/1962038 Title: wrong sysrq value in /usr/lib/sysctl.d/50-default.conf Status in systemd package in Ubuntu: Triaged Status in systemd source package in Impish: New Status in systemd source package in Jammy: Triaged Bug description: I've just learned that systemd is setting kernel.sysrq to 16 in /usr/lib/sysctl.d/50-default.conf. This is inconsistent with /etc/sysctl.d/10-magic-sysrq.conf which intentionally sets it to 176 by default. systemd should drop its setting to defer to the file that we have been carrying in procps for a very long time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962038/+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 1961983] Re: New Debian upstream: netcat-openbsd 1.218-4
** Changed in: netcat-openbsd (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to netcat-openbsd in Ubuntu. https://bugs.launchpad.net/bugs/1961983 Title: New Debian upstream: netcat-openbsd 1.218-4 Status in netcat-openbsd package in Ubuntu: Fix Committed Bug description: Debian has updated the package. We should merge the changes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netcat-openbsd/+bug/1961983/+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
