[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed
I have successfully resolved the problem. I don't know exactly what helped because I did a few things. Namely: I switched all SATA cables from the second controller to the first (my computer motherboard has two SATA controllers) and disabled the Compatibility Support Module. Unfortunately, CSM turned off the BIOS boot options, only UEFI was left. After changing the settings and rebooting, the message "Initramfs unpacking failed: Decoding failed" was still showing on the screen, but the system continued the boot process and finally saw the Ubuntu Server 20.04 installer -- 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/1835660 Title: initramfs unpacking failed Status in OEM Priority Project: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in grub2 source package in Focal: Invalid Status in initramfs-tools source package in Focal: Invalid Status in linux source package in Focal: Fix Committed Status in grub2 source package in Groovy: Invalid Status in initramfs-tools source package in Groovy: Invalid Status in linux source package in Groovy: Fix Committed Status in grub2 source package in Hirsute: Invalid Status in initramfs-tools source package in Hirsute: Invalid Status in linux source package in Hirsute: Confirmed Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. [Impact] * Decoding failure messages in dmsg with a single lz4 initrd * Multiple lz4 compressed initrds cannot be decompressed by kernel, when loaded by grub * Multiple lz4 compressed initrds cannot be decompressed by kernel, when there is padding between them [Test Case] * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4 * Create an lz4 compressed initrd with a single test-file in it with some content. I.e. echo "second-initrd" > test-file, and then pack that with cpio hewc owned by root & lz4 -l. * Create a combined padded initrd of stock initrd, pad4, and the test-marker initrd created above. * Boot above with "break=top" kernel command line. * With broken kernels, there should be dmesg error message that decoding failed, and one will observe that /test-file does not exist in the shell. * With fixed kernel, /test-file in the initrd shell should exist, and should have the expected content "second-initrd". * The alignment and padding in the above test case depends on the size of the first initrd => if a given padded initrd does not reproduce the problem, try varying the size of the first initrd or that of the padding between 0..4. [Where problems could occur] * This changes compatible lz4 decompressor in the kernel, which can also be used by other kernel modules such as cryptography, squashfs, zram, f2fs, comprssed kernel image, pstore. For example, previously rejected files with "bogus" length and extra padding may now be accepted, whereas they were previously getting rejected by the decompressor. * Ideally kernel should switch to the stable lz4 format which has better specification of end of stream. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+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 1798656] Re: gtk3 frontend gives no widget for answering a boolean prompt
The version is: Setting up docker.io (18.09.7-0ubuntu1~16.04.7) ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1798656 Title: gtk3 frontend gives no widget for answering a boolean prompt Status in debconf package in Ubuntu: Invalid Bug description: On upgrade from bionic to cosmic with update-manager, I was shown a debconf prompt about docker.io that asked: Automatically restart Docker daemon? There was no widget in the window that allowed me to select either yes or no. This is a grave deficiency in the default debconf frontend on the Ubuntu desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1798656/+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 1798656] Re: gtk3 frontend gives no widget for answering a boolean prompt
I also experience this problem on Ubuntu Xenial. The prompt is: ┌───┤ Configuring docker.io ├┐ │ │ │ If Docker is upgraded without restarting the Docker daemon, Docker will often have trouble starting new containers, and in some cases even │ │ maintaining the containers it is currently running. See https://launchpad.net/bugs/1658691 for an example of this breakage. │ │ │ │ Normally, upgrading the package would simply restart the associated daemon(s). In the case of the Docker daemon, that would also imply │ │ stopping all running containers (which will only be restarted if they're part of a "service", have an appropriate restart policy configured, │ │ or have some other means of being restarted such as an external systemd unit). │ │ │ │ Automatically restart Docker daemon? │ │ │ │ │ │ │ └┘ It's seems to be not configurable by dpkg --set-selections: root@server# dpkg --get-selections docker.io docker.io install I could upload a vagrant box to demonstrate this issue when running apt- get upgrade -y. I try to automate the upgrade process, but this atm blocks the upgrade and CI pipelines with interactive prompt. I'm also trying to build a workaround wrapper with expect. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1798656 Title: gtk3 frontend gives no widget for answering a boolean prompt Status in debconf package in Ubuntu: Invalid Bug description: On upgrade from bionic to cosmic with update-manager, I was shown a debconf prompt about docker.io that asked: Automatically restart Docker daemon? There was no widget in the window that allowed me to select either yes or no. This is a grave deficiency in the default debconf frontend on the Ubuntu desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1798656/+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 1876495] Re: bash-completion incorrectly shows source package names for APT
** Changed in: apt (Ubuntu Focal) Importance: Undecided => Low ** Changed in: apt (Ubuntu Groovy) Importance: Undecided => Low -- 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/1876495 Title: bash-completion incorrectly shows source package names for APT Status in apt package in Ubuntu: Fix Released Status in apt source package in Focal: Fix Committed Status in apt source package in Groovy: Fix Committed Status in apt source package in Hirsute: Fix Released Bug description: [Impact] Source packages have been included in apt-cache pkgnames, and virtual packages have not been included in apt-cache pkgnames --all-names. The former leads to completions autocompleting to source package names where they only should complete to binaries. [Test case] An automated test case is included in the test suite test-ubuntu-bug-1876495-pkgnames-virtual It verifies that pkgnames does not return source package names, and that pkgnames --all-names does return source package names and virtual package names. [Where problems could occur] In the pkgnames command only. If there's a bug, it could exclude or include packages it should not. [Original bug report] Steps to reproduce: 1. Have Ubuntu 20.04 LTS installed 2. Open terminal, enter one of the commands below 2a. apt install brisk 2b. apt source brisk-menu 2c. apt-get install brisk 2d. apt-get source brisk-menu 2e. apt-cache policy brisk Expected results: * The bash-completion should not lead to package name as there are no binary packages named with starting part "brisk" (see https://packages.ubuntu.com/search?suite=all=names=brisk ) Actual results: * all commands below get completed to the name of source package - in this example named "brisk-menu" (see https://packages.ubuntu.com/search?suite=all=all=any=brisk=sourcenames). This is absolutely unexpected, as user can not really install this package in binary form. ProblemType: Bug DistroRelease: Ubuntu Kylin 20.04 Package: bash-completion 1:2.10-1ubuntu1 [origin: Ubuntu] ProcVersionSignature: Ubuntu 5.4.0-28.32-lowlatency 5.4.30 Uname: Linux 5.4.0-28-lowlatency x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: MATE Date: Sat May 2 20:35:48 2020 Dependencies: InstallationDate: Installed on 2020-04-22 (9 days ago) InstallationMedia: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Release amd64 (20200422) PackageArchitecture: all SourcePackage: bash-completion UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1876495/+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 1886112] Re: Enabling DMESG_RESTRICT in Groovy Onward
** Changed in: util-linux (Ubuntu) Status: In Progress => Won't Fix -- 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/1886112 Title: Enabling DMESG_RESTRICT in Groovy Onward Status in linux package in Ubuntu: Fix Released Status in procps package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: Won't Fix Status in linux source package in Groovy: Fix Released Status in procps source package in Groovy: Fix Released Status in util-linux source package in Groovy: Won't Fix Bug description: [Impact] This bug implements the enablement of CONFIG_SECURITY_DMESG_RESTRICT feature by default for Groovy onward, proposed to ubuntu-devel: https://lists.ubuntu.com/archives/ubuntu-devel/2020-June/041063.html The kernel log buffer contains a wealth of sensitive information, such as detailed call traces and kernel addresses found in register dumps in kernel oops messages. Exploit developers and attackers can leverage these information leaks to get past KASLR, and they can use the kernel log buffer to get instant feedback on their privilege escalation attacks, as failures will be shown as further oops messages, which attackers can use to fix and tune their programs until they work. Currently, if I create a new, unprivileged user on a Focal system, they cannot access /var/log/kern.log, /var/log/syslog or see system events in journalctl. But yet, they are given free reign to the kernel log buffer. $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ journalctl Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal' can see all messages. Pass -q to turn off this notice. Jun 16 23:44:59 ubuntu systemd[2328]: Reached target Main User Target. Jun 16 23:44:59 ubuntu systemd[2328]: Startup finished in 69ms. $ dmesg [0.00] Linux version 5.4.0-34-generic (buildd at lcy01-amd64-014) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #38-Ubuntu SMP Mon May 25 15:46:55 UTC 2020 (Ubuntu 5.4.0-34.38-generic 5.4.41) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-34-generic root=UUID=f9f909c3-782a-43c2-a59d-c789656b4188 ro ... I propose that we restrict access to dmesg to users in group 'adm' like so: 1) Add kernel.dmesg_restrict = 1 to /etc/sysctl.d/10-kernel-hardening.conf 2) Following changes to /bin/dmesg permissions in package 'util-linux' - Ownership changes to root:adm - Permissions changed to 0750 (-rwxr-x---) - Add cap_syslog capability to binary. For most users, they will use the initial admin account, which is in the 'adm' group already, and will see no impact to these changes. If a log scraper type program needs access to dmesg, the user the daemon runs as can simply be added to the 'adm' group. [Testcase] Currently, all users can run /usr/bin/dmesg to view the kernel log buffer: $ dmesg [0.00] Linux version 5.4.0-34-generic (buildd at lcy01-amd64-014) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #38-Ubuntu SMP Mon May 25 15:46:55 UTC 2020 (Ubuntu 5.4.0-34.38-generic 5.4.41) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-34-generic root=UUID=f9f909c3-782a-43c2-a59d-c789656b4188 ro ... When the changes are applied, the default admin user will be able to view dmesg (since they are in group 'adm'), while new unprivileged users will not. Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1886112-test $ whoami ubuntu $ groups ubuntu adm cdrom sudo dip plugdev $ dmesg [0.00] Linux version 5.4.0-34-generic (buildd at lcy01-amd64-014) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #38-Ubuntu SMP Mon May 25 15:46:55 UTC 2020 (Ubuntu 5.4.0-34.38-generic 5.4.41) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-34-generic root=UUID=f9f909c3-782a-43c2-a59d-c789656b4188 ro ... $ sudo adduser dave $ su dave $ groups dave $ dmesg -bash: /usr/bin/dmesg: Permission denied [Regression Potential] Some users or log scraper type programs may need to view the kernel log buffer, or have access to dmesg. In this case, the underlying service user would need to be added to the 'adm' group. Users have the ability to disable DMESG_RESTRICT by changing kernel.dmesg_restrict sysctl in /etc/sysctl.d/10-kernel-hardening.conf from '1' to '0', followed by a reboot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1886112/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe
[Touch-packages] [Bug 1911030] Re: Graphical flashes on a raspi 4
Full KMS hardware support is available in newer kernels (5.10.x I think) so please try installing a newer arm64 kernel like: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10.8/ -- 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/1911030 Title: Graphical flashes on a raspi 4 Status in mesa package in Ubuntu: New Status in xorg-server package in Ubuntu: New Bug description: Using gnome-shell - activities - see attached video Graphics flash - more prominent with more than one app running. If you install ubuntu-budgie-desktop and simply move through the menu categories the flashing is even more prominent. I'm guessing this is xorg related - but I do note the recent mesa uplift has made things worse ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: xorg 1:7.7+19ubuntu15 ProcVersionSignature: Ubuntu 5.8.0-1011.14+21.04.1-raspi 5.8.18 Uname: Linux 5.8.0-1011-raspi aarch64 ApportVersion: 2.20.11-0ubuntu55 Architecture: arm64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Jan 11 16:49:14 2021 DistUpgraded: Fresh install DistroCodename: hirsute DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: ImageMediaBuild: 20201225 Lspci-vt: -[:00]---00.0-[01]00.0 VIA Technologies, Inc. VL805 USB 3.0 Host Controller ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 video=HDMI-A-1:640x480M@60 smsc95xx.macaddr=DC:A6:32:D1:3E:28 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 dwc_otg.lpm_enable=0 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc quiet splash SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) acpidump: version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.103-2 version.libgl1-mesa-dri: libgl1-mesa-dri 20.3.2-1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A 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/mesa/+bug/1911030/+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 1912275] Re: Xorg freeze
Thanks for the bug report. I can't see any crashes or freezes in the attached files. Next time the problem happens, please reboot and then in a Terminal run: journalctl -b-1 > prevboot.txt and attach the resulting text file here. Please also follow these steps to check for past crashes: 1. Look in /var/crash for crash files and if found run: ubuntu-bug YOURFILE.crash Then tell us the ID of the newly-created bug. 2. If step 1 failed then look at https://errors.ubuntu.com/user/ID where ID is the content of file /var/lib/whoopsie/whoopsie-id on the machine. Do you find any links to recent problems on that page? If so then please send the links to us. 3. If step 2 also failed then apply the workaround from bug 994921, reboot, reproduce the crash, and retry step 1. Please take care to avoid attaching .crash files to bugs as we are unable to process them as file attachments. It would also be a security risk for yourself. ** Summary changed: - Xorg freeze + The system crashes/hangs ** Package changed: xorg (Ubuntu) => ubuntu ** Changed in: ubuntu Status: New => Incomplete -- 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/1912275 Title: The system crashes/hangs Status in Ubuntu: Incomplete Bug description: the system crashes/hangs and sound loops when watching videos. please help as this laptop is needed for my child's home schooling ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.8.0-38.43~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-38-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Jan 18 22:46:57 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom: added broadcom-sta, 6.30.223.271, 5.8.0-38-generic, x86_64: installed GpuHangFrequency: Several times a day GpuHangReproducibility: Occurs more often under certain circumstances GpuHangStarted: Immediately after installing this version of Ubuntu GraphicsCard: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Haswell-ULT Integrated Graphics Controller [103c:227e] InstallationDate: Installed on 2021-01-18 (0 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) MachineType: Hewlett-Packard HP Pavilion 15 Notebook PC ProcEnviron: LANGUAGE=en_GB:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-38-generic root=UUID=1abcb365-cc5b-42e1-8f23-09c6b2cfd2b6 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/19/2014 dmi.bios.release: 15.52 dmi.bios.vendor: Insyde dmi.bios.version: F.34 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 227E dmi.board.vendor: Hewlett-Packard dmi.board.version: 77.35 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 77.53 dmi.modalias: dmi:bvnInsyde:bvrF.34:bd12/19/2014:br15.52:efr77.53:svnHewlett-Packard:pnHPPavilion15NotebookPC:pvr097510405F1620180:rvnHewlett-Packard:rn227E:rvr77.35:cvnHewlett-Packard:ct10:cvrChassisVersion: dmi.product.family: 103C_5335KV G=N L=CON B=HP S=PAV X=Null dmi.product.name: HP Pavilion 15 Notebook PC dmi.product.sku: J5B67EA#ABU dmi.product.version: 097510405F1620180 dmi.sys.vendor: Hewlett-Packard version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1 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/+bug/1912275/+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 1911456] Re: Can't receive files over bluetooth unless settings dialog is open
In that case you probably want: bt-obex -s -y But still it's just a workaround for the original problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1911456 Title: Can't receive files over bluetooth unless settings dialog is open Status in bluez package in Ubuntu: New Status in gnome-user-share package in Ubuntu: New Bug description: On 18.04 I could send files from my phone to my laptop at any time. On 20.04 I can't get files to be accepted by the laptop over bluetooth. After much frustration and experimenting, I figured out that it will work, but only if the bluetooth settings dialog is open. If the settings dialog is not open, the incoming file is rejected. If the dialog is closed after the file transfer begins, the transfer continues but the file is discarded when the transfer is complete. This is very frustrating. I need to be able to send files (mostly photos and videos) from my phone to my laptop without having to open the settings dialog on the laptop, just like I could before upgrading. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1911456/+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 1912091] Re: Memory Leak GNU Tar 1.33
Update: CVE-2021-20193 has been assigned to this vulnerability by Red Hat Security team. --- Carlos ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-20193 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/1912091 Title: Memory Leak GNU Tar 1.33 Status in tar package in Ubuntu: New Bug description: An issue was discovered in GNU Tar 1.33 and earlier. There is a memory leak in read_header() in list.c in the tar application. Occastionally, ASAN detects an out of bounds memory read. Valgrind confirms the memory leak in the standard tar tool installed by default. This degrades the availability of the tar tool, and could potentially result in other memory-related issues. Common Weakness Enumeration IDs for reference: CWE-401: Missing Release of Memory after Effective Lifetime CWE-125: Out-of-bounds Read Attached to this report is a PoC malcrafted file "1311745-out- bounds.tar" VALGRIND OUTPUT: valgrind tar -xf 1311745-out-bounds.tar ==3776== Memcheck, a memory error detector ==3776== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3776== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==3776== Command: tar -xf output/1311745-out-bounds.tar ==3776== tar: Unexpected EOF in archive tar: Exiting with failure status due to previous errors ==3776== ==3776== HEAP SUMMARY: ==3776== in use at exit: 1,311,761 bytes in 2 blocks ==3776== total heap usage: 52 allocs, 50 frees, 1,349,212 bytes allocated ==3776== ==3776== LEAK SUMMARY: ==3776==definitely lost: 1,311,745 bytes in 1 blocks ... NOTE: Version 1.30, 1.32, 1.33 were tested and confirmed to be vulnerable. lsb_release -rd Description: Ubuntu 20.04.1 LTS Release: 20.04 apt-cache policy tar tar: Installed: 1.30+dfsg-7ubuntu0.20.04.1 Candidate: 1.30+dfsg-7ubuntu0.20.04.1 --- Carlos To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tar/+bug/1912091/+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 1912122] Re: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions
Attached is a patch which changes /var/log/dmesg to 0640 on groovy. It also contains Steve's recommendation to set the logrotate files to 0640. ** Patch added: "Debdiff for syslog on groovy" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+attachment/5454311/+files/lp1912122_groovy_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1912122 Title: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions Status in rsyslog package in Ubuntu: In Progress Status in rsyslog source package in Groovy: In Progress Status in rsyslog source package in Hirsute: In Progress Bug description: [Impact] In bug 1886112, CONFIG_SECURITY_DMESG_RESTRICT was enabled on the Ubuntu kernel starting with Groovy and onward, in an effort to restrict access to the kernel log buffer from unprivileged users. It seems we have overlooked /var/log/dmesg, as it is still mode 0644, while /var/log/kern.log, /var/log/syslog are all 0640: $ ll /var/log -rw-r--r-- 1 root adm 81768 Jan 18 09:09 dmesg -rw-r- 1 syslogadm 24538 Jan 18 13:05 kern.log -rw-r- 1 syslogadm213911 Jan 18 13:22 syslog Change /var/log/dmesg to 0640 to close the information leak. [Testcase] $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg [0.00] kernel: Linux version 5.8.0-36-generic (buildd@lgw01-amd64-011) (gcc (Ubuntu 10.2.1-2ubuntu3) 10.2.1 20201221, GNU ld (GNU Binutils for Ubuntu) 2.35.50.20210106) #40+21.04.1-Ubuntu SMP Thu Jan 7 11:35:09 UTC 2021 (Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18) [0.00] kernel: Command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- If you install the package in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1912122-test $ sudo systemctl daemon-reload $ sudo systemctl start dmesg.service $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg cat: /var/log/dmesg: Permission denied [Where problems could occur] Some users or log scraper programs might need to view the kernel log buffers, and in this case, their underlying service accounts should be added to the 'adm' group. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+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 1912122] Re: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions
Attached is a patch which changes /var/log/dmesg to 0640 on hirsute. It also contains Steve's recommendation to set the logrotate files to 0640. ** Patch removed: "Debdiff for rsyslog on hirsute" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+attachment/5454004/+files/lp1912122_hirsute.debdiff ** Patch removed: "Debdiff for syslog on groovy" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+attachment/5454005/+files/lp1912122_groovy.debdiff ** Patch added: "Debdiff for rsyslog on hirsute" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+attachment/5454310/+files/lp1912122_hirsute_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1912122 Title: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions Status in rsyslog package in Ubuntu: In Progress Status in rsyslog source package in Groovy: In Progress Status in rsyslog source package in Hirsute: In Progress Bug description: [Impact] In bug 1886112, CONFIG_SECURITY_DMESG_RESTRICT was enabled on the Ubuntu kernel starting with Groovy and onward, in an effort to restrict access to the kernel log buffer from unprivileged users. It seems we have overlooked /var/log/dmesg, as it is still mode 0644, while /var/log/kern.log, /var/log/syslog are all 0640: $ ll /var/log -rw-r--r-- 1 root adm 81768 Jan 18 09:09 dmesg -rw-r- 1 syslogadm 24538 Jan 18 13:05 kern.log -rw-r- 1 syslogadm213911 Jan 18 13:22 syslog Change /var/log/dmesg to 0640 to close the information leak. [Testcase] $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg [0.00] kernel: Linux version 5.8.0-36-generic (buildd@lgw01-amd64-011) (gcc (Ubuntu 10.2.1-2ubuntu3) 10.2.1 20201221, GNU ld (GNU Binutils for Ubuntu) 2.35.50.20210106) #40+21.04.1-Ubuntu SMP Thu Jan 7 11:35:09 UTC 2021 (Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18) [0.00] kernel: Command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- If you install the package in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1912122-test $ sudo systemctl daemon-reload $ sudo systemctl start dmesg.service $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg cat: /var/log/dmesg: Permission denied [Where problems could occur] Some users or log scraper programs might need to view the kernel log buffers, and in this case, their underlying service accounts should be added to the 'adm' group. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+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 1912122] Re: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions
Oh, I was expecting that it would also be desirable to SRU this back to focal, as I expected CONFIG_SECURITY_DMESG_RESTRICT to come back with the HWE kernels, but looking at the config for linux-hwe-5.8, it appears that the old behavior was kept. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1912122 Title: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions Status in rsyslog package in Ubuntu: In Progress Status in rsyslog source package in Groovy: In Progress Status in rsyslog source package in Hirsute: In Progress Bug description: [Impact] In bug 1886112, CONFIG_SECURITY_DMESG_RESTRICT was enabled on the Ubuntu kernel starting with Groovy and onward, in an effort to restrict access to the kernel log buffer from unprivileged users. It seems we have overlooked /var/log/dmesg, as it is still mode 0644, while /var/log/kern.log, /var/log/syslog are all 0640: $ ll /var/log -rw-r--r-- 1 root adm 81768 Jan 18 09:09 dmesg -rw-r- 1 syslogadm 24538 Jan 18 13:05 kern.log -rw-r- 1 syslogadm213911 Jan 18 13:22 syslog Change /var/log/dmesg to 0640 to close the information leak. [Testcase] $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg [0.00] kernel: Linux version 5.8.0-36-generic (buildd@lgw01-amd64-011) (gcc (Ubuntu 10.2.1-2ubuntu3) 10.2.1 20201221, GNU ld (GNU Binutils for Ubuntu) 2.35.50.20210106) #40+21.04.1-Ubuntu SMP Thu Jan 7 11:35:09 UTC 2021 (Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18) [0.00] kernel: Command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- If you install the package in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1912122-test $ sudo systemctl daemon-reload $ sudo systemctl start dmesg.service $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg cat: /var/log/dmesg: Permission denied [Where problems could occur] Some users or log scraper programs might need to view the kernel log buffers, and in this case, their underlying service accounts should be added to the 'adm' group. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+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 1912275] Re: Xorg freeze
** 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/1912275 Title: Xorg freeze Status in xorg package in Ubuntu: New Bug description: the system crashes/hangs and sound loops when watching videos. please help as this laptop is needed for my child's home schooling ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.8.0-38.43~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-38-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Jan 18 22:46:57 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom: added broadcom-sta, 6.30.223.271, 5.8.0-38-generic, x86_64: installed GpuHangFrequency: Several times a day GpuHangReproducibility: Occurs more often under certain circumstances GpuHangStarted: Immediately after installing this version of Ubuntu GraphicsCard: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Haswell-ULT Integrated Graphics Controller [103c:227e] InstallationDate: Installed on 2021-01-18 (0 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) MachineType: Hewlett-Packard HP Pavilion 15 Notebook PC ProcEnviron: LANGUAGE=en_GB:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-38-generic root=UUID=1abcb365-cc5b-42e1-8f23-09c6b2cfd2b6 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/19/2014 dmi.bios.release: 15.52 dmi.bios.vendor: Insyde dmi.bios.version: F.34 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 227E dmi.board.vendor: Hewlett-Packard dmi.board.version: 77.35 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 77.53 dmi.modalias: dmi:bvnInsyde:bvrF.34:bd12/19/2014:br15.52:efr77.53:svnHewlett-Packard:pnHPPavilion15NotebookPC:pvr097510405F1620180:rvnHewlett-Packard:rn227E:rvr77.35:cvnHewlett-Packard:ct10:cvrChassisVersion: dmi.product.family: 103C_5335KV G=N L=CON B=HP S=PAV X=Null dmi.product.name: HP Pavilion 15 Notebook PC dmi.product.sku: J5B67EA#ABU dmi.product.version: 097510405F1620180 dmi.sys.vendor: Hewlett-Packard version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1 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/1912275/+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 1884887] Re: rsyslogd dmesg unit leaves /var/log/dmesg* world readable
*** This bug is a duplicate of bug 1912122 *** https://bugs.launchpad.net/bugs/1912122 ** This bug has been marked a duplicate of bug 1912122 /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1884887 Title: rsyslogd dmesg unit leaves /var/log/dmesg* world readable Status in rsyslog package in Ubuntu: Confirmed Bug description: [Impact] The rsyslog dmesg systemd unit /lib/systemd/system/dmesg.service in eoan, focal, and groovy create /var/log/dmesg* with the following permissions: -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg Most other system logs in /var/log/ are only readable by root and group adm. While it's true that the kernel dmesg buffer by default can be read by anyone using the dmesg(1) command, this can be disabled by setting the sysctl kernel.dmesg_restrict to 1, but doing so as a hardening measure is thwarted by the world readable nature of /var/log/dmesg. The reason dmesg output is sensitive is that it sometimes contains kernel addresses for diagnosing kernel problems, but attackers looking to attack a kernel are also interested in kernel addresses and other information that shows up there. [Test Case] To reproduce: $ ls -l /var/log/dmesg* should show only root and group adm access like so: -rw-r- 1 root adm 50178 Jun 23 12:55 /var/log/dmesg -rw-r- 1 root adm 50217 Jun 23 12:55 /var/log/dmesg.0 -rw-r- 1 root adm 13941 Jun 23 12:47 /var/log/dmesg.1.gz and not world readable: -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg [Regression Potential] It's possible tools like apport and others might expect /var/log/dmesg to be world-readable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1884887/+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 1912122] Re: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions
The Ubuntu Security team would like to see this fixed, though it probably would be worth adding the following change to the service file so that on log rotation the permissions are corrected as well: -ExecStartPre=-/usr/bin/savelog -q -p -n -c 5 /var/log/dmesg +ExecStartPre=-/usr/bin/savelog -m640 -q -p -n -c 5 /var/log/dmesg Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1912122 Title: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions Status in rsyslog package in Ubuntu: In Progress Status in rsyslog source package in Groovy: In Progress Status in rsyslog source package in Hirsute: In Progress Bug description: [Impact] In bug 1886112, CONFIG_SECURITY_DMESG_RESTRICT was enabled on the Ubuntu kernel starting with Groovy and onward, in an effort to restrict access to the kernel log buffer from unprivileged users. It seems we have overlooked /var/log/dmesg, as it is still mode 0644, while /var/log/kern.log, /var/log/syslog are all 0640: $ ll /var/log -rw-r--r-- 1 root adm 81768 Jan 18 09:09 dmesg -rw-r- 1 syslogadm 24538 Jan 18 13:05 kern.log -rw-r- 1 syslogadm213911 Jan 18 13:22 syslog Change /var/log/dmesg to 0640 to close the information leak. [Testcase] $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg [0.00] kernel: Linux version 5.8.0-36-generic (buildd@lgw01-amd64-011) (gcc (Ubuntu 10.2.1-2ubuntu3) 10.2.1 20201221, GNU ld (GNU Binutils for Ubuntu) 2.35.50.20210106) #40+21.04.1-Ubuntu SMP Thu Jan 7 11:35:09 UTC 2021 (Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18) [0.00] kernel: Command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- If you install the package in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1912122-test $ sudo systemctl daemon-reload $ sudo systemctl start dmesg.service $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg cat: /var/log/dmesg: Permission denied [Where problems could occur] Some users or log scraper programs might need to view the kernel log buffers, and in this case, their underlying service accounts should be added to the 'adm' group. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+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 1912275] [NEW] Xorg freeze
You have been subscribed to a public bug: the system crashes/hangs and sound loops when watching videos. please help as this laptop is needed for my child's home schooling ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.8.0-38.43~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-38-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Jan 18 22:46:57 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom: added broadcom-sta, 6.30.223.271, 5.8.0-38-generic, x86_64: installed GpuHangFrequency: Several times a day GpuHangReproducibility: Occurs more often under certain circumstances GpuHangStarted: Immediately after installing this version of Ubuntu GraphicsCard: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Haswell-ULT Integrated Graphics Controller [103c:227e] InstallationDate: Installed on 2021-01-18 (0 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) MachineType: Hewlett-Packard HP Pavilion 15 Notebook PC ProcEnviron: LANGUAGE=en_GB:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-38-generic root=UUID=1abcb365-cc5b-42e1-8f23-09c6b2cfd2b6 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/19/2014 dmi.bios.release: 15.52 dmi.bios.vendor: Insyde dmi.bios.version: F.34 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 227E dmi.board.vendor: Hewlett-Packard dmi.board.version: 77.35 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 77.53 dmi.modalias: dmi:bvnInsyde:bvrF.34:bd12/19/2014:br15.52:efr77.53:svnHewlett-Packard:pnHPPavilion15NotebookPC:pvr097510405F1620180:rvnHewlett-Packard:rn227E:rvr77.35:cvnHewlett-Packard:ct10:cvrChassisVersion: dmi.product.family: 103C_5335KV G=N L=CON B=HP S=PAV X=Null dmi.product.name: HP Pavilion 15 Notebook PC dmi.product.sku: J5B67EA#ABU dmi.product.version: 097510405F1620180 dmi.sys.vendor: Hewlett-Packard version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.2~20.04.1 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 freeze ubuntu -- Xorg freeze https://bugs.launchpad.net/bugs/1912275 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 1901528] Re: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip)
This bug was fixed in the package gzip - 1.10-2ubuntu2 --- gzip (1.10-2ubuntu2) hirsute; urgency=medium [ William 'jawn-smith' Wilson ] * Applying patch from upstream to fix a segfault caused by passing multiple files larger than 5kb to a gzip command while zlib acceleration is enabled (LP: #1901528) -- Brian Murray Mon, 18 Jan 2021 10:35:03 -0800 ** Changed in: gzip (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: New Status in gzip package in Ubuntu: Fix Released Status in zlib package in Ubuntu: Invalid Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+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 1912277] [NEW] After Closing and Re-Opening the lid, a painful Static sound can be heard, this static cannot be turned down or off, even when changing the system volume, and can
Public bug reported: Every time that i close the laptop lid and then re-open and log in, the speakers emit a static sound that cannot be muted, nor can it be turned off, even when disabling all audio in system settings. This is a large inconvenience as it drowns out all other audio of videos, music etc. The only way that it can be stopped is by doing a system restart. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.8.0-38.43~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-38-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: zekiah 983 F pulseaudio /dev/snd/pcmC0D0c: zekiah 983 F...m pulseaudio /dev/snd/pcmC0D0p: zekiah 983 F...m pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Mon Jan 18 23:13:14 2021 InstallationDate: Installed on 2021-01-10 (8 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) PackageArchitecture: all ProcEnviron: LANGUAGE=en_GB:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Speaker, Internal Symptom_PulsePlaybackTest: PulseAudio playback test successful Symptom_Type: None of the above Title: [Inspiron 5577, Realtek ALC3246, Speaker, Internal] Playback problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/02/2018 dmi.bios.release: 1.1 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.1.3 dmi.board.name: 090HMC dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: Not Specified dmi.modalias: dmi:bvnDellInc.:bvr1.1.3:bd12/02/2018:br1.1:svnDellInc.:pnInspiron5577:pvr1.1.3:rvnDellInc.:rn090HMC:rvrA00:cvnDellInc.:ct10:cvrNotSpecified: dmi.product.family: Inspiron dmi.product.name: Inspiron 5577 dmi.product.sku: 07E1 dmi.product.version: 1.1.3 dmi.sys.vendor: Dell Inc. ** Affects: alsa-driver (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 alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1912277 Title: After Closing and Re-Opening the lid, a painful Static sound can be heard, this static cannot be turned down or off, even when changing the system volume, and can only be stopped by a full system restart. Status in alsa-driver package in Ubuntu: New Bug description: Every time that i close the laptop lid and then re-open and log in, the speakers emit a static sound that cannot be muted, nor can it be turned off, even when disabling all audio in system settings. This is a large inconvenience as it drowns out all other audio of videos, music etc. The only way that it can be stopped is by doing a system restart. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.8.0-38.43~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-38-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: zekiah 983 F pulseaudio /dev/snd/pcmC0D0c: zekiah 983 F...m pulseaudio /dev/snd/pcmC0D0p: zekiah 983 F...m pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Mon Jan 18 23:13:14 2021 InstallationDate: Installed on 2021-01-10 (8 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) PackageArchitecture: all ProcEnviron: LANGUAGE=en_GB:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH successful Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Speaker, Internal Symptom_PulsePlaybackTest: PulseAudio playback test successful Symptom_Type: None of the above Title: [Inspiron 5577, Realtek ALC3246, Speaker, Internal] Playback problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/02/2018 dmi.bios.release: 1.1 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.1.3 dmi.board.name: 090HMC dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: Not Specified dmi.modalias: dmi:bvnDellInc.:bvr1.1.3:bd12/02/2018:br1.1:svnDellInc.:pnInspiron5577:pvr1.1.3:rvnDellInc.:rn090HMC:rvrA00:cvnDellInc.:ct10:cvrNotSpecified: dmi.product.family: Inspiron
[Touch-packages] [Bug 48734] Re: Home permissions too open
Just two things that are broken with DIR_MODE=0750
(Which are still perfectly supported with the proof-of-concept
lock-down plus improved-usability script from last the post.
Independently from the additional group directories that it
introduces.)
* samba usershares
* ~/public_html
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/48734
Title:
Home permissions too open
Status in adduser package in Ubuntu:
Fix Released
Status in shadow package in Ubuntu:
Fix Released
Status in adduser source package in Hirsute:
Fix Released
Status in shadow source package in Hirsute:
Fix Released
Status in Ubuntu RTM:
Opinion
Bug description:
Binary package hint: debian-installer
On a fresh dapper install i noticed that the file permissons for the
home directory for the user created by the installer is set to 755,
giving read access to everyone on the system.
Surely this is a bad idea? If your set on the idea can we atleast have
a option during the boot proccess?
Also new files that are created via the console ('touch' etc.) are
done so with '644' permissons, is there anything that can be done
here? nautlius seems to create files at '600', which is a better
setting.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+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 1911614] Re: Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic
Documentation is horribly insufficient in this regard. To quote the link given, "Ubuntu Desktop flavour now always tracks HWE kernel (hardware enablement). It means that from 20.04.2 release Ubuntu Desktop will gain new major kernel versions every 6 months through to summer of 2022". The words "from 20.04.2 release Ubuntu Desktop will gain new major kernel versions every 6 months" speak volumes, sadly incorrect volumes. 20.04.2 is not even due for release until next month but we've been getting HWE kernel updates for a couple of weeks already! All of the following documentation needs serious updating and must include methods to remain on the GA kernel if one wishes: The first, also from the release notes, states clearly "Ubuntu 20.04 LTS is based on the long-term supported Linux release series 5.4": https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Updated_Packages None of these have been updated to adequately reflect the change to opt- out of HWE rather than opt-in if using original (20.04) or first point release (20.04.1) installation media as had always been the case previously. https://wiki.ubuntu.com/Kernel/LTSEnablementStack https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack https://ubuntu.com/kernel/lifecycle -- 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/1911614 Title: Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: Beginning about January 8th Focal users that installed Focal using either the Ubuntu 20.04 or 20.04.1 installation media began getting updated to the 5.8 series linux kernel. Those who had installed using the Ubuntu Focal Beta were not effected. This is because Focal Beta was properly built with ‘linux-generic’ but the 20.04 and 20.04.1 images were built with ‘linux-generic-hwe-20.04‘. This can be easily verified by looking at the iso manifest: https://releases.ubuntu.com/20.04.1/ubuntu-20.04.1-desktop- amd64.manifest Note: old-release manifests (where 20.04 Beta and 20.04 reside) must be downloaded here: https://old-releases.ubuntu.com/releases/20.04/ The expected behavior is for Ubuntu Focal users to remain on the 5.4 series kernel unless they install with 20.04.2 or later images as indicated here: https://wiki.ubuntu.com/Kernel/LTSEnablementStack While not entirely updated it says “if one wants to remain on the original GA (General Availability) stacks, the options [include]; Install from a previous 12.04.0/12.04.1/14.04.0/14.04.1/16.04.0/16.04.1/18.04.0/18.04.1 point release and update”. Jump just below that to the Focal specific notes and it says “The 20.04.2 and newer point releases will ship with an updated kernel and X stack by default for the desktop”. Since 20.04.2 is not even due for release until next month it makes no sense for updates to the 5.8 series kernel to be occurring unless the focal-proposed repos are enabled even if HWE protocols had been changed. It’s also worth noting that thankfully no accompanying HWE X stack is yet available in the repos. I say thankfully because my efforts at downgrading the X stack in 16.04 and 18.04 were never successful! But the lack of a matching X stack may explain the many complaints on the forums about broken graphics??? It’s also worth noting that even the release notes say that “Ubuntu 20.04 LTS is based on the long-term supported Linux release series 5.4“. https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Linux_Kernel Scroll to the bottom here and you’ll also see that 20.04 and 20.04.1 are supposed to be supported with the 5.4 series kernel for the entire 5 year life span: https://ubuntu.com/kernel/lifecycle The other flavors’ 20.04 and 20.04.1 images were all built correctly with ‘linux-generic’ with the possible exception of Ubuntu Studio which uses a kernel stack I’m not familiar with. I’m also uncertain about Ubuntu server because I’m simply not familiar with it. Original bug description below: ## Just as the title says, the 20.04 and 20.04.1 images use the HWE version of linux-generic resulting in upgrades to the 5.8 series kernel. This seems to effect Ubuntu only, or I should say I checked the Kubuntu, Ubuntu Mate, Xubuntu, and Lubuntu iso manifests which all correctly list linux-generic. Also HWE is not truly complete without the accompanying HWE Xstack. I checked all the documentation I could find and this was clearly not intentional. In fact the manifest for Ubuntu Focal Beta still used linux-generic, so this got messed up some time between April 3, 2020 and April 23, 2020. Here's just one example of the documentation for kernel support in Focal LTS:
[Touch-packages] [Bug 1911614] Re: Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic
It seems this behavior is expected, although probably insufficiently documented. We will make sure to clear things out in various documentation bits, but with 20.04 it has been decided that the Ubuntu Desktop flavor will be shipping a HWE kernel by default from the start. Apologies for this unclear situation, I have no idea how this got missed in the announcements. Per: https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Ubuntu_Desktop -- 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/1911614 Title: Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: Beginning about January 8th Focal users that installed Focal using either the Ubuntu 20.04 or 20.04.1 installation media began getting updated to the 5.8 series linux kernel. Those who had installed using the Ubuntu Focal Beta were not effected. This is because Focal Beta was properly built with ‘linux-generic’ but the 20.04 and 20.04.1 images were built with ‘linux-generic-hwe-20.04‘. This can be easily verified by looking at the iso manifest: https://releases.ubuntu.com/20.04.1/ubuntu-20.04.1-desktop- amd64.manifest Note: old-release manifests (where 20.04 Beta and 20.04 reside) must be downloaded here: https://old-releases.ubuntu.com/releases/20.04/ The expected behavior is for Ubuntu Focal users to remain on the 5.4 series kernel unless they install with 20.04.2 or later images as indicated here: https://wiki.ubuntu.com/Kernel/LTSEnablementStack While not entirely updated it says “if one wants to remain on the original GA (General Availability) stacks, the options [include]; Install from a previous 12.04.0/12.04.1/14.04.0/14.04.1/16.04.0/16.04.1/18.04.0/18.04.1 point release and update”. Jump just below that to the Focal specific notes and it says “The 20.04.2 and newer point releases will ship with an updated kernel and X stack by default for the desktop”. Since 20.04.2 is not even due for release until next month it makes no sense for updates to the 5.8 series kernel to be occurring unless the focal-proposed repos are enabled even if HWE protocols had been changed. It’s also worth noting that thankfully no accompanying HWE X stack is yet available in the repos. I say thankfully because my efforts at downgrading the X stack in 16.04 and 18.04 were never successful! But the lack of a matching X stack may explain the many complaints on the forums about broken graphics??? It’s also worth noting that even the release notes say that “Ubuntu 20.04 LTS is based on the long-term supported Linux release series 5.4“. https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Linux_Kernel Scroll to the bottom here and you’ll also see that 20.04 and 20.04.1 are supposed to be supported with the 5.4 series kernel for the entire 5 year life span: https://ubuntu.com/kernel/lifecycle The other flavors’ 20.04 and 20.04.1 images were all built correctly with ‘linux-generic’ with the possible exception of Ubuntu Studio which uses a kernel stack I’m not familiar with. I’m also uncertain about Ubuntu server because I’m simply not familiar with it. Original bug description below: ## Just as the title says, the 20.04 and 20.04.1 images use the HWE version of linux-generic resulting in upgrades to the 5.8 series kernel. This seems to effect Ubuntu only, or I should say I checked the Kubuntu, Ubuntu Mate, Xubuntu, and Lubuntu iso manifests which all correctly list linux-generic. Also HWE is not truly complete without the accompanying HWE Xstack. I checked all the documentation I could find and this was clearly not intentional. In fact the manifest for Ubuntu Focal Beta still used linux-generic, so this got messed up some time between April 3, 2020 and April 23, 2020. Here's just one example of the documentation for kernel support in Focal LTS: https://ubuntu.com/about/release-cycle#ubuntu-kernel-release-cycle Installations performed with 20.04 and 20.04.1 media were supposed to remain on the 5.4 series kernel throughout Focal's 5 year lifespan as had been the case since HWE was introduced. The first step in fixing this needs to be stopping fresh installs of Focal using the 20.04 and 20.04.1 media from immediately upgrading to the 5.8 series kernel. It might be a little tricky to revert users from 5.8 to 5.4, but there have been reports of breakage, particularly concerning Broadcom wifi drivers and some graphics problems. But the graphics problems could also be exacerbated by the lack of the matching HWE Xstack? At any rate it's a bug. To manage notifications about this bug go to:
[Touch-packages] [Bug 1901528] Re: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip)
** Changed in: gzip (Ubuntu) Status: New => In Progress ** Changed in: zlib (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: New Status in gzip package in Ubuntu: In Progress Status in zlib package in Ubuntu: Invalid Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+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 1848330] Re: Installing auditd sometimes fails in post-inst
Since it's difficult to reproduce the bug, what I'm going to do is setup a system with the previous auditd, setup some rules, confirm they are working, then upgrade, and confirm it keeps working, also after a reboot. # Bionic verification auditd from bionic: auditd: Installed: 1:2.8.2-1ubuntu1 Candidate: 1:2.8.2-1ubuntu1 Version table: *** 1:2.8.2-1ubuntu1 500 500 http://br.archive.ubuntu.com/ubuntu bionic/main amd64 Packages Created a simple rule: # cat /etc/audit/rules.d/30-shadow.rules -w /etc/shadow -p wa -k shadow-changed Loaded after restart: # auditctl -l -w /etc/shadow -p wa -k shadow-changed Confirmed a change to the file gets logged: # chmod 0400 /etc/shadow # /var/log/audit/auditd.log (parsed with ausearch -i): type=PROCTITLE msg=audit(01/18/21 17:49:31.077:32) : proctitle=chmod 0400 /etc/shadow type=PATH msg=audit(01/18/21 17:49:31.077:32) : item=0 name=/etc/shadow inode=64070 dev=fc:01 mode=file,640 ouid=root ogid=shadow rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=CWD msg=audit(01/18/21 17:49:31.077:32) : cwd=/root type=SYSCALL msg=audit(01/18/21 17:49:31.077:32) : arch=x86_64 syscall=fchmodat success=yes exit=0 a0=0xff9c a1=0x5577580dc1c0 a2=0400 a3=0x0 items=1 ppid=1499 pid=1992 auid=ubuntu uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=chmod exe=/bin/chmod key=shadow-changed Now updating the package: # apt-cache policy auditd auditd: Installed: 1:2.8.2-1ubuntu1.1 Candidate: 1:2.8.2-1ubuntu1.1 Version table: *** 1:2.8.2-1ubuntu1.1 500 500 http://br.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages 100 /var/lib/dpkg/status 1:2.8.2-1ubuntu1 500 500 http://br.archive.ubuntu.com/ubuntu bionic/main amd64 Packages (and its deps, like libaudit1, etc). The same rule continues loaded: # auditctl -l -w /etc/shadow -p wa -k shadow-changed Also after a manual restart: # systemctl restart auditd # auditctl -l -w /etc/shadow -p wa -k shadow-changed And changing /etc/shadow is logged (let's use 0640 this time): # chmod 0640 /etc/shadow # log: type=PROCTITLE msg=audit(01/18/21 17:54:51.942:56) : proctitle=chmod 0640 /etc/shadow type=PATH msg=audit(01/18/21 17:54:51.942:56) : item=0 name=/etc/shadow inode=64070 dev=fc:01 mode=file,400 ouid=root ogid=shadow rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=CWD msg=audit(01/18/21 17:54:51.942:56) : cwd=/root type=SYSCALL msg=audit(01/18/21 17:54:51.942:56) : arch=x86_64 syscall=fchmodat success=yes exit=0 a0=0xff9c a1=0x563ae04471c0 a2=0640 a3=0x0 items=1 ppid=1499 pid=2845 auid=ubuntu uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=chmod exe=/bin/chmod key=shadow-changed I then rebooted the system, performed the same tests, and got the same results with the updated package. It would be great if people who were affected by this bug, and can reasonably reproduce it, could test the packages from proposed. In the meantime, I'll mark this as verification succeeded. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to audit in Ubuntu. https://bugs.launchpad.net/bugs/1848330 Title: Installing auditd sometimes fails in post-inst Status in audit package in Ubuntu: Fix Released Status in audit source package in Bionic: Fix Committed Status in audit package in Debian: New Bug description: [Impact] Sometimes, auditd will get stuck when starting up, causing systemd to kill it after a while since it (systemd) never got the start notification. Upstream troubleshooted this to be caused by calling a syslog() function inside a signal handler. [Test Case] There is no reliable test case to reproduce the bug, other than trying the fixed packages on an affected system where the hang occurs more frequently. Basically: sudo systemctl stop auditd sudo systemctl start auditd should work reliably. Do not run that in a tight loop, however, as that will trigger a it's-restarting-too-frequently failure. [Where problems could occur] - if auditd fails to start, then the first fallback is syslog, and if that is not picking up the audit messages, the last resort is the kernel buffer, which can fill up. In the case it fills up, audit logs will be lost. - it's possible to configure the audit system to panic() the machine if audit messages are lost or otherwise not able to be recorded (auditctl -f 2; default is 1 which is printk()) - the update restarts auditd as expected. Misconfiguration on very very busy systems could mean that audit logs would be lost during the brief moment the service is restarted. If that's the case, this update would just be one more way to trigger it, but not be the root cause of
[Touch-packages] [Bug 1911456] Re: Can't receive files over bluetooth unless settings dialog is open
I tried "bluetoothctl". That's a neat tool that I didn't know about, but I couldn't find a command that would let me send stuff from my phone without interaction. I installed bt-obex and tried "bt-obex -s", which allowed file transfer but I still had to acknowledge each one. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1911456 Title: Can't receive files over bluetooth unless settings dialog is open Status in bluez package in Ubuntu: New Status in gnome-user-share package in Ubuntu: New Bug description: On 18.04 I could send files from my phone to my laptop at any time. On 20.04 I can't get files to be accepted by the laptop over bluetooth. After much frustration and experimenting, I figured out that it will work, but only if the bluetooth settings dialog is open. If the settings dialog is not open, the incoming file is rejected. If the dialog is closed after the file transfer begins, the transfer continues but the file is discarded when the transfer is complete. This is very frustrating. I need to be able to send files (mostly photos and videos) from my phone to my laptop without having to open the settings dialog on the laptop, just like I could before upgrading. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1911456/+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 1911614] Re: Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic
I did a fresh installation of the 20.04 LTS media from 20200423 and can confirm this. See the attached screenshot. ** Attachment added: "Screenshot from 2021-01-18 09-46-39.png" https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1911614/+attachment/5454217/+files/Screenshot%20from%202021-01-18%2009-46-39.png ** Tags added: rls-ff-incoming -- 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/1911614 Title: Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: Beginning about January 8th Focal users that installed Focal using either the Ubuntu 20.04 or 20.04.1 installation media began getting updated to the 5.8 series linux kernel. Those who had installed using the Ubuntu Focal Beta were not effected. This is because Focal Beta was properly built with ‘linux-generic’ but the 20.04 and 20.04.1 images were built with ‘linux-generic-hwe-20.04‘. This can be easily verified by looking at the iso manifest: https://releases.ubuntu.com/20.04.1/ubuntu-20.04.1-desktop- amd64.manifest Note: old-release manifests (where 20.04 Beta and 20.04 reside) must be downloaded here: https://old-releases.ubuntu.com/releases/20.04/ The expected behavior is for Ubuntu Focal users to remain on the 5.4 series kernel unless they install with 20.04.2 or later images as indicated here: https://wiki.ubuntu.com/Kernel/LTSEnablementStack While not entirely updated it says “if one wants to remain on the original GA (General Availability) stacks, the options [include]; Install from a previous 12.04.0/12.04.1/14.04.0/14.04.1/16.04.0/16.04.1/18.04.0/18.04.1 point release and update”. Jump just below that to the Focal specific notes and it says “The 20.04.2 and newer point releases will ship with an updated kernel and X stack by default for the desktop”. Since 20.04.2 is not even due for release until next month it makes no sense for updates to the 5.8 series kernel to be occurring unless the focal-proposed repos are enabled even if HWE protocols had been changed. It’s also worth noting that thankfully no accompanying HWE X stack is yet available in the repos. I say thankfully because my efforts at downgrading the X stack in 16.04 and 18.04 were never successful! But the lack of a matching X stack may explain the many complaints on the forums about broken graphics??? It’s also worth noting that even the release notes say that “Ubuntu 20.04 LTS is based on the long-term supported Linux release series 5.4“. https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Linux_Kernel Scroll to the bottom here and you’ll also see that 20.04 and 20.04.1 are supposed to be supported with the 5.4 series kernel for the entire 5 year life span: https://ubuntu.com/kernel/lifecycle The other flavors’ 20.04 and 20.04.1 images were all built correctly with ‘linux-generic’ with the possible exception of Ubuntu Studio which uses a kernel stack I’m not familiar with. I’m also uncertain about Ubuntu server because I’m simply not familiar with it. Original bug description below: ## Just as the title says, the 20.04 and 20.04.1 images use the HWE version of linux-generic resulting in upgrades to the 5.8 series kernel. This seems to effect Ubuntu only, or I should say I checked the Kubuntu, Ubuntu Mate, Xubuntu, and Lubuntu iso manifests which all correctly list linux-generic. Also HWE is not truly complete without the accompanying HWE Xstack. I checked all the documentation I could find and this was clearly not intentional. In fact the manifest for Ubuntu Focal Beta still used linux-generic, so this got messed up some time between April 3, 2020 and April 23, 2020. Here's just one example of the documentation for kernel support in Focal LTS: https://ubuntu.com/about/release-cycle#ubuntu-kernel-release-cycle Installations performed with 20.04 and 20.04.1 media were supposed to remain on the 5.4 series kernel throughout Focal's 5 year lifespan as had been the case since HWE was introduced. The first step in fixing this needs to be stopping fresh installs of Focal using the 20.04 and 20.04.1 media from immediately upgrading to the 5.8 series kernel. It might be a little tricky to revert users from 5.8 to 5.4, but there have been reports of breakage, particularly concerning Broadcom wifi drivers and some graphics problems. But the graphics problems could also be exacerbated by the lack of the matching HWE Xstack? At any rate it's a bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1911614/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to
[Touch-packages] [Bug 1912256] Re: Missing channel binding prevents authentication to ActiveDirectory
Might have been confusing to write # kinit $ export LDAPSASL_CBINDING=tls-endpoint Both are supposed to be called from the same user. I meant to imply that an existing, valid ticket in the current user's credential cache is required for krb5 authentication via SASL in the ldapwhoami step. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1912256 Title: Missing channel binding prevents authentication to ActiveDirectory Status in openldap package in Ubuntu: New Bug description: > Are you uncertain if your issue is really a bug? Effect is an authentication error. Root case is a "missing feature" (see below) and requires updating dependencies, downporting. > If you are certain this is a bug please include the source package the bug is in. It's in the interaction between three libraries: openldap, cyrus-sasl, krb5 > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu Broken in 18.04 and also in 20.10 (I guess it's also broken in anything inbetween) > 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1 ldap-utils: 2.4.53+dfsg-1ubuntu1.2 libgssapi-krb5-2: 1.17-10ubuntu0.1 > 3) What you expected to happen # kinit $ export LDAPSASL_CBINDING=tls-endpoint $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps:// SASL/GSSAPI authentication started SASL username: SASL SSF: 0 u: > 4) What happened instead SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C090597, comment: AcceptSecurityContext error, data 80090346, v4563 --- Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends activating this as a required feature. See https://access.redhat.com/articles/4661861 Authentication to any AD DC which has mandatory channel binding fails. Channel binding requires at least an update to cyrus-sasl, which is not in any release as far as I can see: https://github.com/cyrusimap/cyrus- sasl/commit/975edbb69070eba6b035f08776de771a129cfb57 It also needs this commit in openldap: https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6 Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5). RH also mentions it needs up-to-date krb5 libraries, but I can't tell what minimum version this needs. I can build all libraries from source, current master (except for krb5 where I've used 1.18.3) and can confirm that channel binding works when using those libraries. I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I would guess by extension also SSSD and realmd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1912256/+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 1912256] [NEW] Missing channel binding prevents authentication to ActiveDirectory
Public bug reported: > Are you uncertain if your issue is really a bug? Effect is an authentication error. Root case is a "missing feature" (see below) and requires updating dependencies, downporting. > If you are certain this is a bug please include the source package the bug is > in. It's in the interaction between three libraries: openldap, cyrus-sasl, krb5 > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> > About Ubuntu Broken in 18.04 and also in 20.10 (I guess it's also broken in anything inbetween) > 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1 ldap-utils: 2.4.53+dfsg-1ubuntu1.2 libgssapi-krb5-2: 1.17-10ubuntu0.1 > 3) What you expected to happen # kinit $ export LDAPSASL_CBINDING=tls-endpoint $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps:// SASL/GSSAPI authentication started SASL username: SASL SSF: 0 u: > 4) What happened instead SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C090597, comment: AcceptSecurityContext error, data 80090346, v4563 --- Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends activating this as a required feature. See https://access.redhat.com/articles/4661861 Authentication to any AD DC which has mandatory channel binding fails. Channel binding requires at least an update to cyrus-sasl, which is not in any release as far as I can see: https://github.com/cyrusimap/cyrus- sasl/commit/975edbb69070eba6b035f08776de771a129cfb57 It also needs this commit in openldap: https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6 Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5). RH also mentions it needs up-to-date krb5 libraries, but I can't tell what minimum version this needs. I can build all libraries from source, current master (except for krb5 where I've used 1.18.3) and can confirm that channel binding works when using those libraries. I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I would guess by extension also SSSD and realmd. ** Affects: openldap (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1912256 Title: Missing channel binding prevents authentication to ActiveDirectory Status in openldap package in Ubuntu: New Bug description: > Are you uncertain if your issue is really a bug? Effect is an authentication error. Root case is a "missing feature" (see below) and requires updating dependencies, downporting. > If you are certain this is a bug please include the source package the bug is in. It's in the interaction between three libraries: openldap, cyrus-sasl, krb5 > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu Broken in 18.04 and also in 20.10 (I guess it's also broken in anything inbetween) > 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1 ldap-utils: 2.4.53+dfsg-1ubuntu1.2 libgssapi-krb5-2: 1.17-10ubuntu0.1 > 3) What you expected to happen # kinit $ export LDAPSASL_CBINDING=tls-endpoint $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps:// SASL/GSSAPI authentication started SASL username: SASL SSF: 0 u: > 4) What happened instead SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C090597, comment: AcceptSecurityContext error, data 80090346, v4563 --- Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends activating this as a required feature. See https://access.redhat.com/articles/4661861 Authentication to any AD DC which has mandatory channel binding fails. Channel binding requires at least an update to cyrus-sasl, which is not in any release as far as I can see: https://github.com/cyrusimap/cyrus- sasl/commit/975edbb69070eba6b035f08776de771a129cfb57 It also needs this commit in openldap: https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6 Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5). RH also mentions it needs up-to-date krb5 libraries, but I can't tell what minimum version this needs. I can build all libraries from source, current master (except for krb5 where I've used 1.18.3) and can confirm that channel binding works when using those libraries. I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I would guess by extension also SSSD and realmd.
[Touch-packages] [Bug 48734] Re: Home permissions too open
--- Avoiding the caveat of "this does not work"? ---
You may just not have thought yet of this solution that can be
implemented with little adjustment:
( Privacy by default? YES, even with improved usability! )
Here is a trial script:
https://salsa.debian.org/freedombox-team/freedombox/-/snippets/518
The privacy by default solution goes along these lines:
* Simply let $HOME point to /home//public_html
* /home//incoming
* /home/group/users/
* /home/group/admin/private
* /home/group/admin/incoming
These kind of different problems just need to be seen and solved together.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/48734
Title:
Home permissions too open
Status in adduser package in Ubuntu:
Fix Released
Status in shadow package in Ubuntu:
Fix Released
Status in adduser source package in Hirsute:
Fix Released
Status in shadow source package in Hirsute:
Fix Released
Status in Ubuntu RTM:
Opinion
Bug description:
Binary package hint: debian-installer
On a fresh dapper install i noticed that the file permissons for the
home directory for the user created by the installer is set to 755,
giving read access to everyone on the system.
Surely this is a bad idea? If your set on the idea can we atleast have
a option during the boot proccess?
Also new files that are created via the console ('touch' etc.) are
done so with '644' permissons, is there anything that can be done
here? nautlius seems to create files at '600', which is a better
setting.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+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 48734] Re: Home permissions too open
Hello, I’m original bug reporter back from 2006 and I’ve been watching
the development of this bug over the years and I just wanted to say a
big thank everyone for getting this sorted!
- Dan
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/48734
Title:
Home permissions too open
Status in adduser package in Ubuntu:
Fix Released
Status in shadow package in Ubuntu:
Fix Released
Status in adduser source package in Hirsute:
Fix Released
Status in shadow source package in Hirsute:
Fix Released
Status in Ubuntu RTM:
Opinion
Bug description:
Binary package hint: debian-installer
On a fresh dapper install i noticed that the file permissons for the
home directory for the user created by the installer is set to 755,
giving read access to everyone on the system.
Surely this is a bad idea? If your set on the idea can we atleast have
a option during the boot proccess?
Also new files that are created via the console ('touch' etc.) are
done so with '644' permissons, is there anything that can be done
here? nautlius seems to create files at '600', which is a better
setting.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+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 1835660] Re: initramfs unpacking failed
The same thing happened when I try Ubuntu 20.10 live server... Let me check the 18.04 server. I currently use Ubuntu Desktop 18.04 on my laptop, maybe the server edition will work. -- 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/1835660 Title: initramfs unpacking failed Status in OEM Priority Project: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in grub2 source package in Focal: Invalid Status in initramfs-tools source package in Focal: Invalid Status in linux source package in Focal: Fix Committed Status in grub2 source package in Groovy: Invalid Status in initramfs-tools source package in Groovy: Invalid Status in linux source package in Groovy: Fix Committed Status in grub2 source package in Hirsute: Invalid Status in initramfs-tools source package in Hirsute: Invalid Status in linux source package in Hirsute: Confirmed Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. [Impact] * Decoding failure messages in dmsg with a single lz4 initrd * Multiple lz4 compressed initrds cannot be decompressed by kernel, when loaded by grub * Multiple lz4 compressed initrds cannot be decompressed by kernel, when there is padding between them [Test Case] * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4 * Create an lz4 compressed initrd with a single test-file in it with some content. I.e. echo "second-initrd" > test-file, and then pack that with cpio hewc owned by root & lz4 -l. * Create a combined padded initrd of stock initrd, pad4, and the test-marker initrd created above. * Boot above with "break=top" kernel command line. * With broken kernels, there should be dmesg error message that decoding failed, and one will observe that /test-file does not exist in the shell. * With fixed kernel, /test-file in the initrd shell should exist, and should have the expected content "second-initrd". * The alignment and padding in the above test case depends on the size of the first initrd => if a given padded initrd does not reproduce the problem, try varying the size of the first initrd or that of the padding between 0..4. [Where problems could occur] * This changes compatible lz4 decompressor in the kernel, which can also be used by other kernel modules such as cryptography, squashfs, zram, f2fs, comprssed kernel image, pstore. For example, previously rejected files with "bogus" length and extra padding may now be accepted, whereas they were previously getting rejected by the decompressor. * Ideally kernel should switch to the stable lz4 format which has better specification of end of stream. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+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 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
After discussing this we decided that we will leave cgroups v1 support for 21.04 because the snapd team will not be able to port all features to v2 in time. But early in the 21.10 cycle v1 is turned off and snapd needs to be ported to full v2 support. -- 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/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in snapd: Confirmed Status in docker.io package in Ubuntu: Confirmed Status in lxc package in Ubuntu: Fix Released Status in lxcfs package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Fix Released Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1850667/+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 48734] Re: Home permissions too open
On 18/01/2021 12:46, Launchpad Bug Tracker wrote:
> This bug was fixed in the package adduser - 3.118ubuntu5
>
> ** Changed in: adduser (Ubuntu Hirsute)
>Status: Fix Committed => Fix Released
\o/
Well done and thank you to everyone who worked to make this happen.
I wonder if there will ever be another LP bug <50k that gets fix-
released?
Mark
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/48734
Title:
Home permissions too open
Status in adduser package in Ubuntu:
Fix Released
Status in shadow package in Ubuntu:
Fix Released
Status in adduser source package in Hirsute:
Fix Released
Status in shadow source package in Hirsute:
Fix Released
Status in Ubuntu RTM:
Opinion
Bug description:
Binary package hint: debian-installer
On a fresh dapper install i noticed that the file permissons for the
home directory for the user created by the installer is set to 755,
giving read access to everyone on the system.
Surely this is a bad idea? If your set on the idea can we atleast have
a option during the boot proccess?
Also new files that are created via the console ('touch' etc.) are
done so with '644' permissons, is there anything that can be done
here? nautlius seems to create files at '600', which is a better
setting.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+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 1911802] Re: Video glitches playing hardware accelerated video through VAAPI
** Tags added: rls-ff-incoming -- 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/1911802 Title: Video glitches playing hardware accelerated video through VAAPI Status in mesa package in Ubuntu: New Bug description: Same issue as the post here describes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3681 The video is scaled unevenly in the vertical axis, with a black bar appearing in the bottom of the video window for a few frames. It happens seemingly on all videos able to be hardware decoded, upon starting the video and upon seeking. The regression happened somewhere between 20.0.8-0ubuntu1~20.04.1 and 20.2.6-0ubuntu0.20.04.1 but apparently has been fixed in mesa 20.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1911802/+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 1912214] Re: qemu can't access files that are added as rules on hot-add
Also my new code that I was trying to finish for submission works on
bare metal ... ? /me is puzzled
--
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/1912214
Title:
qemu can't access files that are added as rules on hot-add
Status in apparmor package in Ubuntu:
New
Bug description:
Hi,
to be clear I consider it quite likely that the error is on my side, but I'd
appreciate guidance how to continue resolve. I have rubber ducked my setup with
a coworker and talked to jjohansen if the profile would contain an obvious
fault (it did not).
So hereby I'm filing a bug hoping to get some help on this case.
## 1. What happened
I was trying to add a feature to libvirt to support chained qcow files.
That means instead of adding just one path libvirt has to process the chain
of backing files and add all of those. That works already on guest start, but
not on hot-add of devices.
But while I see my code appending the rules I'd expect and issuing the
apparmor_parser calls I'd expect it still fails.
I'd love to get the profile at runtime to ensure things really are loaded as
expected.
But as discussed on IRC that won't work. So I tested and simplified and
wonder for the test below why things fail.
## 2. how to reproduce
I was taking my new code out of the equation - and to do so I was
adding the path that is needed to the local overrides. But it still is
blocked. So - right now - I'm assuming that my code worked in adding
the lines, but the access is still blocked. Therefore let us try to
fix this one first and only then I can debug into what might be
failing on the new code.
# Allow the access that libvirt does not yet allow
$ echo '"/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2" rwk,' >
/etc/apparmor.d/local/abstractions/libvirt-qemu
# prep the disk chain to be hot-added
qemu-img create -f qcow2 /var/lib/libvirt/images/testdisk-snap-base.qcow2 100M
qemu-img create -f qcow2 -b /var/lib/libvirt/images/testdisk-snap-base.qcow2
/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
cat > hot-add-test.xml << EOF
EOF
# prep a guest to attach to
uvt-simplestreams-libvirt --verbose sync --source
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=focal
uvt-kvm create --host-passthrough --password=ubuntu f-test2 release=focal
arch=amd64 label=daily
We have checked the "effective" profile that is loaded. JJohanssen didn't see
an obvious flaw in it. But for reference here:
root@h-libvirt-orig:~# apparmor_parser -p
/etc/apparmor.d/libvirt/libvirt-e033b910-be06-4975-826f-b6fba368d928 |
pastebinit
https://paste.ubuntu.com/p/yxdmMT6638/
# attach the disk
virsh attach-device f-test2 hot-add-test.xml
Libvirt/Qemu works as usual - except (known and expected) does not add a rule
for "/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2". But for that we
have added out local override.
Yet it is denied access.
apparmor="DENIED" operation="open" namespace="root//lxd-h-libvirt-new_
" profile="libvirt-a2caaf89-0682-464d-92ba-
5295cb5f5128" name="/var/lib/libvirt/images/testdisk-snap-
snapshot.qcow2" pid=2889044 comm="qemu-system-x86" requested_mask="r"
denied_mask="r" fsuid=64055 ouid=64055
## 3. The rule is generally working
To be clear, on the same system if I just open up a new profile and allow
this path to be accessed it works fine. See the working example below.
It must be somewhat that is tied to the way KVM guests get their profile
updates/assigned.
root@h-libvirt-orig:~# cat /etc/apparmor.d/test
#include
profile test flags=(attach_disconnected) {
#include
"/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2" rwk,
"/usr/bin/md5sum" rmix,
}
root@h-libvirt-orig:~# apparmor_parser -r /etc/apparmor.d/test; aa-exec -v -p
test -- md5sum /var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
[6939] aa_change_onexec("test")
[6939] exec md5sum /var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
0f7fc62d270b69ee1b51453fa614d3e4
/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
root@h-libvirt-orig:~# apparmor_parser -r /etc/apparmor.d/test; aa-exec -v -p
test -- md5sum /var/lib/libvirt/images/testdisk-snap-base.qcow2
[6944] aa_change_onexec("test")
[6944] exec md5sum /var/lib/libvirt/images/testdisk-snap-base.qcow2
md5sum: /var/lib/libvirt/images/testdisk-snap-base.qcow2: Permission denied
## 4. tracking apparmor_parser
I was using (for debug) a wrapper for apparmro_parser but all really
looks as expected
$ cat /usr/sbin/apparmor_parser.wrap
#!/bin/bash
echo "ARGS $@" | /usr/bin/systemd-cat
echo "Content of ${2}:" | /usr/bin/systemd-cat
/usr/bin/ls -laF "${2}" | /usr/bin/systemd-cat
/usr/bin/cat "${2}" | /usr/bin/systemd-cat
[Touch-packages] [Bug 1870260] Re: initramfs unpacking failed: Decoding failed", message appears on boot up.
*** This bug is a duplicate of bug 1835660 *** https://bugs.launchpad.net/bugs/1835660 How to fix this bug? Anyone? I would like to use Ubuntu Server on my PC, but I even can't install it. -- 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/1870260 Title: initramfs unpacking failed: Decoding failed", message appears on boot up. Status in linux package in Ubuntu: Confirmed Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: OS : Ubuntu 20.04(20200401) Problem: "initramfs unpacking failed: Decoding failed", message appears on boot up solution: If we edit /etc/initramfs-tools/initramfs.conf and COMPRESS=lz4, to COMPRESS=gzip then the error is fixing . Expected solution: This but in there from a long time I have seen this from Ubuntu 18.04,19.04,19.10 now in 20.04 So please fix it or change it from lz4 to gzip. an early reply is highly appreciated Thank you . --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu21 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: tamal 1451 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-04-02 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200331) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 0bda:b009 Realtek Semiconductor Corp. 802.11n WLAN Adapter Bus 001 Device 003: ID 0408:5365 Quanta Computer, Inc. HP TrueVision HD Camera Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: HP HP Laptop 15-da0xxx Package: ubuntu-meta ProcEnviron: LANGUAGE=en_IN:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_IN SHELL=/bin/bash ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-21-generic root=UUID=29f895bf-ab7b-4df8-8e9a-c277376a2685 ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 RelatedPackageVersions: linux-restricted-modules-5.4.0-21-generic N/A linux-backports-modules-5.4.0-21-generic N/A linux-firmware1.187 Tags: focal Uname: Linux 5.4.0-21-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 11/29/2019 dmi.bios.vendor: Insyde dmi.bios.version: F.23 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 84A6 dmi.board.vendor: HP dmi.board.version: 80.43 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnInsyde:bvrF.23:bd11/29/2019:svnHP:pnHPLaptop15-da0xxx:pvrType1ProductConfigId:rvnHP:rn84A6:rvr80.43:cvnHP:ct10:cvrChassisVersion: dmi.product.family: 103C_5335KV HP Notebook dmi.product.name: HP Laptop 15-da0xxx dmi.product.sku: 5AY34PA#ACJ dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1870260/+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 1912214] Re: qemu can't access files that are added as rules on hot-add
On bare metal this (the simplified case that I described above with the rule in
the local include file) seems to work just fine.
I'll later (sorry sprint week) or tomorrow - re-setup the very same on a
container again.
** Description changed:
Hi,
to be clear I consider it quite likely that the error is on my side, but I'd
appreciate guidance how to continue resolve. I have rubber ducked my setup with
a coworker and talked to jjohansen if the profile would contain an obvious
fault (it did not).
So hereby I'm filing a bug hoping to get some help on this case.
## 1. What happened
I was trying to add a feature to libvirt to support chained qcow files.
That means instead of adding just one path libvirt has to process the chain
of backing files and add all of those. That works already on guest start, but
not on hot-add of devices.
But while I see my code appending the rules I'd expect and issuing the
apparmor_parser calls I'd expect it still fails.
I'd love to get the profile at runtime to ensure things really are loaded as
expected.
But as discussed on IRC that won't work. So I tested and simplified and
wonder for the test below why things fail.
-
## 2. how to reproduce
I was taking my new code out of the equation - and to do so I was adding
the path that is needed to the local overrides. But it still is blocked.
So - right now - I'm assuming that my code worked in adding the lines,
but the access is still blocked. Therefore let us try to fix this one
first and only then I can debug into what might be failing on the new
code.
-
# Allow the access that libvirt does not yet allow
$ echo '"/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2" rwk,' >
/etc/apparmor.d/local/abstractions/libvirt-qemu
# prep the disk chain to be hot-added
qemu-img create -f qcow2 /var/lib/libvirt/images/testdisk-snap-base.qcow2 100M
qemu-img create -f qcow2 -b /var/lib/libvirt/images/testdisk-snap-base.qcow2
/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
cat > hot-add-test.xml << EOF
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
EOF
# prep a guest to attach to
uvt-simplestreams-libvirt --verbose sync --source
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=focal
uvt-kvm create --host-passthrough --password=ubuntu f-test2 release=focal
arch=amd64 label=daily
We have checked the "effective" profile that is loaded. JJohanssen didn't see
an obvious flaw in it. But for reference here:
- root@h-libvirt-orig:~# apparmor_parser -p
/etc/apparmor.d/libvirt/libvirt-e033b910-be06-4975-826f-b6fba368d928 |
pastebinit
+ root@h-libvirt-orig:~# apparmor_parser -p
/etc/apparmor.d/libvirt/libvirt-e033b910-be06-4975-826f-b6fba368d928 |
pastebinit
https://paste.ubuntu.com/p/yxdmMT6638/
# attach the disk
- virsh attach-device f-test2 hot-add-test.xm
-
+ virsh attach-device f-test2 hot-add-test.xml
Libvirt/Qemu works as usual - except (known and expected) does not add a rule
for "/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2". But for that we
have added out local override.
Yet it is denied access.
apparmor="DENIED" operation="open" namespace="root//lxd-h-libvirt-new_
" profile="libvirt-a2caaf89-0682-464d-92ba-
5295cb5f5128" name="/var/lib/libvirt/images/testdisk-snap-
snapshot.qcow2" pid=2889044 comm="qemu-system-x86" requested_mask="r"
denied_mask="r" fsuid=64055 ouid=64055
-
## 3. The rule is generally working
To be clear, on the same system if I just open up a new profile and allow
this path to be accessed it works fine. See the working example below.
It must be somewhat that is tied to the way KVM guests get their profile
updates/assigned.
-
root@h-libvirt-orig:~# cat /etc/apparmor.d/test
#include
profile test flags=(attach_disconnected) {
- #include
+ #include
- "/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2" rwk,
- "/usr/bin/md5sum" rmix,
+ "/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2" rwk,
+ "/usr/bin/md5sum" rmix,
}
root@h-libvirt-orig:~# apparmor_parser -r /etc/apparmor.d/test; aa-exec -v -p
test -- md5sum /var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
[6939] aa_change_onexec("test")
[6939] exec md5sum /var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
0f7fc62d270b69ee1b51453fa614d3e4
/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
- root@h-libvirt-orig:~# apparmor_parser -r /etc/apparmor.d/test; aa-exec -v -p
test -- md5sum /var/lib/libvirt/images/testdisk-snap-base.qcow2
+ root@h-libvirt-orig:~# apparmor_parser -r /etc/apparmor.d/test; aa-exec -v -p
test -- md5sum /var/lib/libvirt/images/testdisk-snap-base.qcow2
[6944] aa_change_onexec("test")
[6944] exec md5sum /var/lib/libvirt/images/testdisk-snap-base.qcow2
md5sum:
[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed
Hi I have this issue when I try to boot USB installation pendrive with Ubuntu 20.04.1 live server made from ISO available from the official webpage. I downloaded ISO two times, I sha256 its content and compared to value stored in the SHA256SUMS file. I want to install Ubuntu on my PC next to Windows 10 (dual-boot). My PC is 4790k, 16GB RAM, GTX1080, multiple hard drives, system disk is SSD. How can I cope with this issue? What can I do to omit it or to resolve it? The "Initramfs unpacking failed: Decoding failed" message pops up just after the GRUB menu disappears. Please help, I would really like to run the Ubuntu server on my computer. Best regards -- 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/1835660 Title: initramfs unpacking failed Status in OEM Priority Project: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in grub2 source package in Focal: Invalid Status in initramfs-tools source package in Focal: Invalid Status in linux source package in Focal: Fix Committed Status in grub2 source package in Groovy: Invalid Status in initramfs-tools source package in Groovy: Invalid Status in linux source package in Groovy: Fix Committed Status in grub2 source package in Hirsute: Invalid Status in initramfs-tools source package in Hirsute: Invalid Status in linux source package in Hirsute: Confirmed Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. [Impact] * Decoding failure messages in dmsg with a single lz4 initrd * Multiple lz4 compressed initrds cannot be decompressed by kernel, when loaded by grub * Multiple lz4 compressed initrds cannot be decompressed by kernel, when there is padding between them [Test Case] * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4 * Create an lz4 compressed initrd with a single test-file in it with some content. I.e. echo "second-initrd" > test-file, and then pack that with cpio hewc owned by root & lz4 -l. * Create a combined padded initrd of stock initrd, pad4, and the test-marker initrd created above. * Boot above with "break=top" kernel command line. * With broken kernels, there should be dmesg error message that decoding failed, and one will observe that /test-file does not exist in the shell. * With fixed kernel, /test-file in the initrd shell should exist, and should have the expected content "second-initrd". * The alignment and padding in the above test case depends on the size of the first initrd => if a given padded initrd does not reproduce the problem, try varying the size of the first initrd or that of the padding between 0..4. [Where problems could occur] * This changes compatible lz4 decompressor in the kernel, which can also be used by other kernel modules such as cryptography, squashfs, zram, f2fs, comprssed kernel image, pstore. For example, previously rejected files with "bogus" length and extra padding may now be accepted, whereas they were previously getting rejected by the decompressor. * Ideally kernel should switch to the stable lz4 format which has better specification of end of stream. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+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 1873895] Re: Regression: block staircase display with side-by-side monitors of different pixel widths
It happened to me as well on my lenovo ideapad laptop when I upgraded from Xubuntu 19.10 to 20.04, and my 1366x768 resolution ended all garbled. Then, after a while googling for solutions (which there wew so few!), I came up with a weird but functional workaround: I opened the display window, selected the 1366x768 resolution, rotation: inverted and reflection: horizontal and vertical, then applied. Worked! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libxcb in Ubuntu. https://bugs.launchpad.net/bugs/1873895 Title: Regression: block staircase display with side-by-side monitors of different pixel widths Status in Linux: Unknown Status in libxcb package in Ubuntu: Confirmed Status in xfwm4 package in Ubuntu: Confirmed Status in xserver-xorg-video-amdgpu package in Ubuntu: Confirmed Bug description: Update based on further research. This only happens when the secondary external display is operating at a different pixel width to the internal. In this case eDP is 1920x1080 whereas the external HDMI-A-0 is natively 1680x1050. It is caused by xfwm4's recent switch from using glx to xpresent for AMD GPUs. The underlying bug is in the AMD driver. I was able to reproduce on an external 1920x1200 display only when it was set to a non-native 1680x1050 resolution. --- Two identical Lenovo E495 laptops with 20.04 installed. The problem occurred initially on the laptop that is having package upgrades applied regularly. With dual monitors and the external monitor placed left or right the display has a blocked staircase effect shown in the attached photograph, and seems related to https://gitlab.freedesktop.org/xorg/driver/xf86-video- amdgpu/-/issues/10 More detailed investigation suggests it only happens when the X coordinate of the two monitors is different. The symptom looks like an off-by-one error because it appears as if the display is divided into, say, 10 rows and 15 columns but the first row has 16 'columns' worth of blocks on it and so wraps to the beginning of the 2nd row, and so on. On the laptop without package upgrades being applied this didn't happen. So I upgraded it (314 packages) and restarted and it too sees the same problem. I suspected libxcomposite1 and downgraded it to 1:0.4.5-0ubuntu1 but that didn't solve it. I now suspect libxcb but so far haven't been able to prove it. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: XFCE DistUpgraded: Fresh install DistroCodename: focal DistroRelease: Ubuntu 20.04 DistroVariant: ubuntu GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Picasso [1002:15d8] (rev c1) (prog-if 00 [VGA controller]) Subsystem: Lenovo ThinkPad E595 [17aa:5124] InstallationDate: Installed on 2020-04-08 (11 days ago) InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200408) MachineType: LENOVO 20NECTO1WW Package: xserver-xorg-video-amdgpu 19.1.0-1 PackageArchitecture: amd64 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-21-generic root=/dev/mapper/ELLOE000-rootfs ro acpi_osi=! "acpi_osi=Windows 2016" quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Tags: focal ubuntu ubuntu Uname: Linux 5.4.0-21-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip libvirt lp lpadmin lxd plugdev sambashare sudo users _MarkForUpload: True dmi.bios.date: 12/23/2019 dmi.bios.vendor: LENOVO dmi.bios.version: R11ET32W (1.12 ) dmi.board.asset.tag: Not Available dmi.board.name: 20NECTO1WW 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.modalias: dmi:bvnLENOVO:bvrR11ET32W(1.12):bd12/23/2019:svnLENOVO:pn20NECTO1WW:pvrThinkPadE495:rvnLENOVO:rn20NECTO1WW:rvrNotDefined:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad E495 dmi.product.name: 20NECTO1WW dmi.product.sku: LENOVO_MT_20NE_BU_Think_FM_ThinkPad E495 dmi.product.version: ThinkPad E495 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.4-2ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2 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:
[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed
** Changed in: linux (Ubuntu Groovy) Status: Confirmed => Fix Committed ** Changed in: linux (Ubuntu Focal) Status: Confirmed => Fix Committed -- 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/1835660 Title: initramfs unpacking failed Status in OEM Priority Project: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in grub2 source package in Focal: Invalid Status in initramfs-tools source package in Focal: Invalid Status in linux source package in Focal: Fix Committed Status in grub2 source package in Groovy: Invalid Status in initramfs-tools source package in Groovy: Invalid Status in linux source package in Groovy: Fix Committed Status in grub2 source package in Hirsute: Invalid Status in initramfs-tools source package in Hirsute: Invalid Status in linux source package in Hirsute: Confirmed Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. [Impact] * Decoding failure messages in dmsg with a single lz4 initrd * Multiple lz4 compressed initrds cannot be decompressed by kernel, when loaded by grub * Multiple lz4 compressed initrds cannot be decompressed by kernel, when there is padding between them [Test Case] * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4 * Create an lz4 compressed initrd with a single test-file in it with some content. I.e. echo "second-initrd" > test-file, and then pack that with cpio hewc owned by root & lz4 -l. * Create a combined padded initrd of stock initrd, pad4, and the test-marker initrd created above. * Boot above with "break=top" kernel command line. * With broken kernels, there should be dmesg error message that decoding failed, and one will observe that /test-file does not exist in the shell. * With fixed kernel, /test-file in the initrd shell should exist, and should have the expected content "second-initrd". * The alignment and padding in the above test case depends on the size of the first initrd => if a given padded initrd does not reproduce the problem, try varying the size of the first initrd or that of the padding between 0..4. [Where problems could occur] * This changes compatible lz4 decompressor in the kernel, which can also be used by other kernel modules such as cryptography, squashfs, zram, f2fs, comprssed kernel image, pstore. For example, previously rejected files with "bogus" length and extra padding may now be accepted, whereas they were previously getting rejected by the decompressor. * Ideally kernel should switch to the stable lz4 format which has better specification of end of stream. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+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 1885474] Re: 1366x768 screen resolution broken, all other resolutions OK
It happened to me as well on my lenovo ideapad laptop with Xubuntu 20.04, and I came with a weird but functional workaround: I opened the display window, selected the 1366x768 resolution, rotation: inverted and reflection: horizontal and vertical, then applied. Worked! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libdrm in Ubuntu. https://bugs.launchpad.net/bugs/1885474 Title: 1366x768 screen resolution broken, all other resolutions OK Status in Ubuntu MATE: New Status in libdrm package in Ubuntu: New Status in mate-control-center package in Ubuntu: New Status in xserver-xorg-video-amdgpu package in Ubuntu: New Bug description: Hi, After upgrade from Ubuntu Mate 19.10 to Ubuntu Mate 20.04 i cannot use a resolution of 1366x768. Screenshot attached. I am using an Asus vivoBook laptop with Amd Ryzen 3 and a Radeon Vega Graphics AMD. I found someone in reddit reporting the same problem: https://www.reddit.com/r/UbuntuMATE/comments/ggq8g5/problem_with_resolution_1366x768_with_ubuntu_mate/ All other screen resolutions OK. Many thanks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1885474/+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 1912214] Re: qemu can't access files that are added as rules on hot-add
Note/TODO (to myself): I have run and failed with that in containers,
try it on bare metal if it is any different.
--
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/1912214
Title:
qemu can't access files that are added as rules on hot-add
Status in apparmor package in Ubuntu:
New
Bug description:
Hi,
to be clear I consider it quite likely that the error is on my side, but I'd
appreciate guidance how to continue resolve. I have rubber ducked my setup with
a coworker and talked to jjohansen if the profile would contain an obvious
fault (it did not).
So hereby I'm filing a bug hoping to get some help on this case.
## 1. What happened
I was trying to add a feature to libvirt to support chained qcow files.
That means instead of adding just one path libvirt has to process the chain
of backing files and add all of those. That works already on guest start, but
not on hot-add of devices.
But while I see my code appending the rules I'd expect and issuing the
apparmor_parser calls I'd expect it still fails.
I'd love to get the profile at runtime to ensure things really are loaded as
expected.
But as discussed on IRC that won't work. So I tested and simplified and
wonder for the test below why things fail.
## 2. how to reproduce
I was taking my new code out of the equation - and to do so I was
adding the path that is needed to the local overrides. But it still is
blocked. So - right now - I'm assuming that my code worked in adding
the lines, but the access is still blocked. Therefore let us try to
fix this one first and only then I can debug into what might be
failing on the new code.
# Allow the access that libvirt does not yet allow
$ echo '"/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2" rwk,' >
/etc/apparmor.d/local/abstractions/libvirt-qemu
# prep the disk chain to be hot-added
qemu-img create -f qcow2 /var/lib/libvirt/images/testdisk-snap-base.qcow2 100M
qemu-img create -f qcow2 -b /var/lib/libvirt/images/testdisk-snap-base.qcow2
/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
cat > hot-add-test.xml << EOF
EOF
# prep a guest to attach to
uvt-simplestreams-libvirt --verbose sync --source
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=focal
uvt-kvm create --host-passthrough --password=ubuntu f-test2 release=focal
arch=amd64 label=daily
We have checked the "effective" profile that is loaded. JJohanssen didn't see
an obvious flaw in it. But for reference here:
root@h-libvirt-orig:~# apparmor_parser -p
/etc/apparmor.d/libvirt/libvirt-e033b910-be06-4975-826f-b6fba368d928 |
pastebinit
https://paste.ubuntu.com/p/yxdmMT6638/
# attach the disk
virsh attach-device f-test2 hot-add-test.xm
Libvirt/Qemu works as usual - except (known and expected) does not add a rule
for "/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2". But for that we
have added out local override.
Yet it is denied access.
apparmor="DENIED" operation="open" namespace="root//lxd-h-libvirt-new_
" profile="libvirt-a2caaf89-0682-464d-92ba-
5295cb5f5128" name="/var/lib/libvirt/images/testdisk-snap-
snapshot.qcow2" pid=2889044 comm="qemu-system-x86" requested_mask="r"
denied_mask="r" fsuid=64055 ouid=64055
## 3. The rule is generally working
To be clear, on the same system if I just open up a new profile and allow
this path to be accessed it works fine. See the working example below.
It must be somewhat that is tied to the way KVM guests get their profile
updates/assigned.
root@h-libvirt-orig:~# cat /etc/apparmor.d/test
#include
profile test flags=(attach_disconnected) {
#include
"/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2" rwk,
"/usr/bin/md5sum" rmix,
}
root@h-libvirt-orig:~# apparmor_parser -r /etc/apparmor.d/test; aa-exec -v -p
test -- md5sum /var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
[6939] aa_change_onexec("test")
[6939] exec md5sum /var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
0f7fc62d270b69ee1b51453fa614d3e4
/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
root@h-libvirt-orig:~# apparmor_parser -r /etc/apparmor.d/test; aa-exec -v -p
test -- md5sum /var/lib/libvirt/images/testdisk-snap-base.qcow2
[6944] aa_change_onexec("test")
[6944] exec md5sum /var/lib/libvirt/images/testdisk-snap-base.qcow2
md5sum: /var/lib/libvirt/images/testdisk-snap-base.qcow2: Permission denied
## 4. tracking apparmor_parser
I was using (for debug) a wrapper for apparmro_parser but all really
looks as expected
$ cat /usr/sbin/apparmor_parser.wrap
#!/bin/bash
echo "ARGS $@" | /usr/bin/systemd-cat
echo "Content of ${2}:" | /usr/bin/systemd-cat
/usr/bin/ls -laF "${2}" | /usr/bin/systemd-cat
/usr/bin/cat
[Touch-packages] [Bug 1912214] [NEW] qemu can't access files that are added as rules on hot-add
Public bug reported:
Hi,
to be clear I consider it quite likely that the error is on my side, but I'd
appreciate guidance how to continue resolve. I have rubber ducked my setup with
a coworker and talked to jjohansen if the profile would contain an obvious
fault (it did not).
So hereby I'm filing a bug hoping to get some help on this case.
## 1. What happened
I was trying to add a feature to libvirt to support chained qcow files.
That means instead of adding just one path libvirt has to process the chain of
backing files and add all of those. That works already on guest start, but not
on hot-add of devices.
But while I see my code appending the rules I'd expect and issuing the
apparmor_parser calls I'd expect it still fails.
I'd love to get the profile at runtime to ensure things really are loaded as
expected.
But as discussed on IRC that won't work. So I tested and simplified and wonder
for the test below why things fail.
## 2. how to reproduce
I was taking my new code out of the equation - and to do so I was adding
the path that is needed to the local overrides. But it still is blocked.
So - right now - I'm assuming that my code worked in adding the lines,
but the access is still blocked. Therefore let us try to fix this one
first and only then I can debug into what might be failing on the new
code.
# Allow the access that libvirt does not yet allow
$ echo '"/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2" rwk,' >
/etc/apparmor.d/local/abstractions/libvirt-qemu
# prep the disk chain to be hot-added
qemu-img create -f qcow2 /var/lib/libvirt/images/testdisk-snap-base.qcow2 100M
qemu-img create -f qcow2 -b /var/lib/libvirt/images/testdisk-snap-base.qcow2
/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
cat > hot-add-test.xml << EOF
EOF
# prep a guest to attach to
uvt-simplestreams-libvirt --verbose sync --source
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=focal
uvt-kvm create --host-passthrough --password=ubuntu f-test2 release=focal
arch=amd64 label=daily
We have checked the "effective" profile that is loaded. JJohanssen didn't see
an obvious flaw in it. But for reference here:
root@h-libvirt-orig:~# apparmor_parser -p
/etc/apparmor.d/libvirt/libvirt-e033b910-be06-4975-826f-b6fba368d928 |
pastebinit
https://paste.ubuntu.com/p/yxdmMT6638/
# attach the disk
virsh attach-device f-test2 hot-add-test.xm
Libvirt/Qemu works as usual - except (known and expected) does not add a rule
for "/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2". But for that we
have added out local override.
Yet it is denied access.
apparmor="DENIED" operation="open" namespace="root//lxd-h-libvirt-new_
" profile="libvirt-a2caaf89-0682-464d-92ba-
5295cb5f5128" name="/var/lib/libvirt/images/testdisk-snap-
snapshot.qcow2" pid=2889044 comm="qemu-system-x86" requested_mask="r"
denied_mask="r" fsuid=64055 ouid=64055
## 3. The rule is generally working
To be clear, on the same system if I just open up a new profile and allow this
path to be accessed it works fine. See the working example below.
It must be somewhat that is tied to the way KVM guests get their profile
updates/assigned.
root@h-libvirt-orig:~# cat /etc/apparmor.d/test
#include
profile test flags=(attach_disconnected) {
#include
"/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2" rwk,
"/usr/bin/md5sum" rmix,
}
root@h-libvirt-orig:~# apparmor_parser -r /etc/apparmor.d/test; aa-exec -v -p
test -- md5sum /var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
[6939] aa_change_onexec("test")
[6939] exec md5sum /var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
0f7fc62d270b69ee1b51453fa614d3e4
/var/lib/libvirt/images/testdisk-snap-snapshot.qcow2
root@h-libvirt-orig:~# apparmor_parser -r /etc/apparmor.d/test; aa-exec -v -p
test -- md5sum /var/lib/libvirt/images/testdisk-snap-base.qcow2
[6944] aa_change_onexec("test")
[6944] exec md5sum /var/lib/libvirt/images/testdisk-snap-base.qcow2
md5sum: /var/lib/libvirt/images/testdisk-snap-base.qcow2: Permission denied
## 4. tracking apparmor_parser
I was using (for debug) a wrapper for apparmro_parser but all really
looks as expected
$ cat /usr/sbin/apparmor_parser.wrap
#!/bin/bash
echo "ARGS $@" | /usr/bin/systemd-cat
echo "Content of ${2}:" | /usr/bin/systemd-cat
/usr/bin/ls -laF "${2}" | /usr/bin/systemd-cat
/usr/bin/cat "${2}" | /usr/bin/systemd-cat
echo "Content of ${2}.files:" | /usr/bin/systemd-cat
/usr/bin/ls -laF "${2}.files" | /usr/bin/systemd-cat
/usr/bin/cat "${2}.files" | /usr/bin/systemd-cat
/usr/sbin/apparmor_parser.orig "$@" | /usr/bin/systemd-cat
It is called with "-r filepath" and the content of that filepath contain
the aforementioned rules. So what else might be wrong - why else could
the access be denied despite the rule that should allow it.
** Affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
** Summary changed:
- qemu can't
[Touch-packages] [Bug 1911903] Re: Auto-reconnection of wifi doesn't work
and again :( gen 18 14:18:36 R2D2 rtkit-daemon[1724]: Successfully made thread 185495 of process 185283 owned by '1000' RT at priority 10. gen 18 14:18:36 R2D2 rtkit-daemon[1724]: Supervising 10 threads of 6 processes of 1 users. gen 18 14:20:13 R2D2 wpa_supplicant[1529]: wlp2s0b1: WPA: Group rekeying completed with e0:28:6d:89:10:fa [GTK=CCMP] gen 18 14:23:22 R2D2 gnome-shell[2651]: ../clutter/clutter/clutter-actor.c:10558: The clutter_actor_set_allocation() function can only be called from within the implementation of the ClutterActor::allocate() virtual function. gen 18 14:23:31 R2D2 systemd[2368]: gnome-launched-heroic.desktop-122485.scope: Succeeded. gen 18 14:25:01 R2D2 CRON[186659]: pam_unix(cron:session): session opened for user root by (uid=0) gen 18 14:25:01 R2D2 CRON[186660]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) gen 18 14:25:01 R2D2 CRON[186659]: pam_unix(cron:session): session closed for user root gen 18 14:29:30 R2D2 audit[1489]: USER_AVC pid=1489 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/UPower" interface="org.freedesktop.UPower" member="EnumerateDevices" mask="send" name="org.freedesktop.UPow> exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?' gen 18 14:29:30 R2D2 kernel: kauditd_printk_skb: 14 callbacks suppressed gen 18 14:29:30 R2D2 kernel: audit: type=1107 audit(1610976570.847:631): pid=1489 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/UPower" interface="org.freedesktop.UPower" member="EnumerateDevices" mask="se> exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?' gen 18 14:30:01 R2D2 CRON[187349]: pam_unix(cron:session): session opened for user root by (uid=0) gen 18 14:30:01 R2D2 CRON[187350]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi) gen 18 14:30:01 R2D2 CRON[187349]: pam_unix(cron:session): session closed for user root gen 18 14:30:13 R2D2 wpa_supplicant[1529]: wlp2s0b1: WPA: Group rekeying completed with e0:28:6d:89:10:fa [GTK=CCMP] gen 18 14:31:18 R2D2 systemd[1]: Started Run anacron jobs. gen 18 14:31:18 R2D2 anacron[187616]: Anacron 2.3 started on 2021-01-18 gen 18 14:31:18 R2D2 anacron[187616]: Normal exit (0 jobs run) gen 18 14:31:18 R2D2 systemd[1]: anacron.service: Succeeded. gen 18 14:33:27 R2D2 NetworkManager[1490]: [1610976807.8819] manager: NetworkManager state is now CONNECTED_SITE gen 18 14:33:27 R2D2 whoopsie[2206]: [14:33:27] offline gen 18 14:33:27 R2D2 dbus-daemon[1489]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.13' (uid=0 pid=1490 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined") gen 18 14:33:27 R2D2 systemd[1]: Starting Network Manager Script Dispatcher Service... gen 18 14:33:27 R2D2 dbus-daemon[1489]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' gen 18 14:33:27 R2D2 systemd[1]: Started Network Manager Script Dispatcher Service. gen 18 14:33:37 R2D2 systemd[1]: NetworkManager-dispatcher.service: Succeeded. gen 18 14:33:48 R2D2 whoopsie[2206]: [14:33:48] Cannot reach: https://daisy.ubuntu.com gen 18 14:34:00 R2D2 systemd[2368]: Started Application launched by gsd-media-keys. gen 18 14:34:00 R2D2 dbus-daemon[2383]: [session uid=1000 pid=2383] Activating via systemd: service name='org.gnome.Terminal' unit='gnome-terminal-server.service' requested by ':1.391' (uid=1000 pid=188724 comm="/usr/bin/gnome-terminal.real " label="unconfined") gen 18 14:34:00 R2D2 systemd[2368]: Starting GNOME Terminal Server... gen 18 14:34:00 R2D2 dbus-daemon[2383]: [session uid=1000 pid=2383] Successfully activated service 'org.gnome.Terminal' gen 18 14:34:00 R2D2 systemd[2368]: Started GNOME Terminal Server. gen 18 14:34:00 R2D2 systemd[2368]: Started VTE child process 188744 launched by gnome-terminal-server process 188730. gen 18 14:34:00 R2D2 systemd[2368]: gnome-launched-x-terminal-emulator-188721.scope: Succeeded. -- 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/1911903 Title: Auto-reconnection of wifi doesn't work Status in network-manager package in Ubuntu: Incomplete Bug description: Hi everyone :) It's a problem that occurs without any possible correlation with other event (wake up, sleep etc). In the middle of a session the Wi-Fi simply stop working and not only the system doesn't reconnect automatically, but you need to turn off and back on the Wi-Fi to be able to continue your activities. IDK if it's related, but sometimes also
[Touch-packages] [Bug 508522] Re: Add automatic switching to HSP/HFP from A2DP when a mic is needed
Ever since I switched to linux I have been encountering various issues with my Bose QC35 II headset. I used it extensively on my mac book pro before, here is the behaviour I was used to: - upon connecting the headset the sound streams where automatically redirected to it - upon starting a visio conference call (meet.google.com on chrome and firefox, skype, jitsi, slack) the built-in microphone would activate automatically and I don't remember lowered sound quality (as in noone ever told me I sounded like a robot even after switching from builtin mike to headset mike). - upon disconnecting, spotify would pause automatically (which avoids the sudden "music blasting off the laptop speaker" when the headset runs out of battery :) On ubuntu 20.04, after encountering various issues, I am in a state where it's **almost** working: - for playback on connecting it works just fine - for visio conferencing, without custom configuration pulseaudio systematically prefers the laptop microphone over the BT microphone, I can enable it but I have to manually select it in gnome settings, sometimes within the app itself. When switching from built-in laptop microphone to headset microphone, multiple interlocutors reported I suddenly sounded like a robot. - upon disconnecting, spotify does not pause automatically, I have learned to make sure the laptop speakers are muted before disconnecting or on low battery warnings from the headset. I read through a lot of material on pulseaudio lately and I think this could be configured though a policy (either by loading one that exists or by creating an additional one) According to https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/508522/comments/39, with the default configuration, autoswitch shoudl trigger when the calling app attempts to record with media.role=phone. I haven't been able to make this work on ubuntu 20.04, with - snap slack - firefox (jitsi or google meet) - chrome (jitsi or google meet), - a dockerized zoom (https://github.com/mdouchement/docker-zoom-us/blob/master/scripts/zoom-us-wrapper) now there is the "more aggressive switching behaviour" : when specifying load-module module-bluetooth-policy auto_switch=2 Using auto_switch=2, almost works \o/ Using chrome : - Google meet session: autoswitch does lots of back and forth making my headset beep dozens of time (which is quite annoying). Sometimes ends up working sometimes not and I get loads of bluetooth/sound related errors in journald janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 janv. 18 11:48:16 x1byjean rtkit-daemon[1817]: Supervising 7 threads of 1 processes of 1 users. janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 294 janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 294 janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 294 janv. 18 11:48:16 x1byjean rtkit-daemon[1817]: Successfully made thread 773344 of process 770761 owned by '1000' RT at priority 5. janv. 18 11:48:16 x1byjean rtkit-daemon[1817]: Supervising 8 threads of 1 processes of 1 users. janv. 18 11:48:16 x1byjean gsd-media-keys[6497]: Unable to get default sink janv. 18 11:48:16 x1byjean gsd-media-keys[6497]: Unable to get default source janv. 18 11:48:16 x1byjean rtkit-daemon[1817]: Supervising 7 threads of 1 processes of 1 users. janv. 18 11:48:16 x1byjean rtkit-daemon[1817]: Successfully made thread 773349 of process 770761 owned by '1000' RT at priority 5. janv. 18 11:48:16 x1byjean rtkit-daemon[1817]: Supervising 8 threads of 1 processes of 1 users. janv. 18 11:48:16 x1byjean gsd-media-keys[6497]: Unable to get default sink janv. 18 11:48:16 x1byjean gsd-media-keys[6497]: Unable to get default source janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 janv. 18 11:48:16 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 0 janv. 18 11:48:17 x1byjean rtkit-daemon[1817]: Supervising 7 threads of 1 processes of 1 users. janv. 18 11:48:17 x1byjean kernel: Bluetooth: hci0: SCO packet for unknown connection handle 295 janv. 18 11:48:17 x1byjean kernel: Bluetooth: hci0: SCO packet for
[Touch-packages] [Bug 1911903] Re: Auto-reconnection of wifi doesn't work
Hi Sebastien thanks for your support, the problem occured at 13:57. Here part of the loh. Hope this might help gen 18 13:51:38 R2D2 kernel: intel_powerclamp: Start idle injection to reduce power gen 18 13:53:16 R2D2 rtkit-daemon[1724]: Supervising 9 threads of 5 processes of 1 users. gen 18 13:53:16 R2D2 rtkit-daemon[1724]: Supervising 9 threads of 5 processes of 1 users. gen 18 13:53:26 R2D2 kernel: intel_powerclamp: Stop forced idle injection gen 18 13:55:01 R2D2 CRON[179442]: pam_unix(cron:session): session opened for user root by (uid=0) gen 18 13:55:01 R2D2 CRON[179443]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) gen 18 13:55:01 R2D2 CRON[179442]: pam_unix(cron:session): session closed for user root gen 18 13:55:25 R2D2 systemd[2368]: Started Application launched by gsd-media-keys. gen 18 13:55:25 R2D2 systemd[2368]: Started VTE child process 179579 launched by gnome-terminal-server process 167917. gen 18 13:55:25 R2D2 systemd[2368]: gnome-launched-x-terminal-emulator-179567.scope: Succeeded. gen 18 13:55:50 R2D2 systemd-resolved[1049]: Failed to send hostname reply: Invalid argument gen 18 13:55:52 R2D2 rtkit-daemon[1724]: Supervising 9 threads of 5 processes of 1 users. gen 18 13:55:52 R2D2 rtkit-daemon[1724]: Supervising 9 threads of 5 processes of 1 users. gen 18 13:55:54 R2D2 rtkit-daemon[1724]: Supervising 9 threads of 5 processes of 1 users. gen 18 13:55:54 R2D2 rtkit-daemon[1724]: Supervising 9 threads of 5 processes of 1 users. gen 18 13:55:56 R2D2 NetworkManager[1490]: [1610974556.9734] manager: NetworkManager state is now CONNECTED_SITE gen 18 13:55:56 R2D2 whoopsie[2206]: [13:55:56] offline gen 18 13:55:56 R2D2 dbus-daemon[1489]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.13' (uid=0 pid=1490 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined") gen 18 13:55:56 R2D2 systemd[1]: Starting Network Manager Script Dispatcher Service... gen 18 13:55:56 R2D2 dbus-daemon[1489]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' gen 18 13:55:56 R2D2 systemd[1]: Started Network Manager Script Dispatcher Service. gen 18 13:56:03 R2D2 systemd-resolved[1049]: Failed to send hostname reply: Invalid argument gen 18 13:56:03 R2D2 systemd-resolved[1049]: Failed to send hostname reply: Invalid argument gen 18 13:56:03 R2D2 systemd-resolved[1049]: Failed to send hostname reply: Invalid argument gen 18 13:56:06 R2D2 systemd[1]: NetworkManager-dispatcher.service: Succeeded. gen 18 13:56:09 R2D2 systemd-resolved[1049]: Failed to send hostname reply: Invalid argument gen 18 13:56:15 R2D2 systemd-resolved[1049]: Failed to send hostname reply: Invalid argument gen 18 13:56:23 R2D2 syncthing.desktop[2866]: [2Z4JW] 13:56:23 INFO: Disconnected from relay relay://176.9.147.217:22067 gen 18 13:56:27 R2D2 syncthing.desktop[2866]: [2Z4JW] 13:56:27 INFO: Could not connect to relay relay://51.255.75.9:22067/?id=4Y2VEN4-7NRYXYG-64X6KIU-B26R7LT-QPERGZI-4ZZ3MBR-DFKKAOE-EFT24Q6=1m0s=2m0s=0=0=:22070=www.agdi.info AGDI Data Recovery Services: dial tcp 51.255.75.9:22067: connect: no route to host gen 18 13:56:33 R2D2 systemd-resolved[1049]: Failed to send hostname reply: Invalid argument gen 18 13:56:37 R2D2 syncthing.desktop[2866]: [2Z4JW] 13:56:37 INFO: Could not connect to relay relay://5.9.154.53:22067/?id=4QJTDBX-5V56432-ZZZ5UXG-Z7PMWP7-ZFKB5OJ-PSKVII6-SROJDM5-SIZVCQK=1m0s=2m0s=0=0=:22070=: dial tcp 5.9.154.53:22067: i/o timeout gen 18 13:56:47 R2D2 syncthing.desktop[2866]: [2Z4JW] 13:56:47 INFO: Could not connect to relay relay://178.63.79.89:22067/?id=ANQMPFG-MGRLECJ-GJDGIK3-GYKXD5Q-GY6MIO6-OFEIXGL-POB4FI7-G7VTYAN=1m0s=2m0s=0=0=:22070=freifunk-3laendereck.net: dial tcp 178.63.79.89:22067: i/o timeout gen 18 13:56:48 R2D2 syncthing.desktop[2866]: [2Z4JW] 13:56:48 INFO: Could not connect to relay relay://89.42.31.58:22067/?id=A62AIM2-X6THY3I-EPB5AAA-P6N3K2D-TVKBKEE-6LJQGHD-3JMRZOB-YWYG3QJ=1m0s=2m0s=0=0=:22070=TUSIEK-UK: dial tcp 89.42.31.58:22067: connect: no route to host gen 18 13:56:48 R2D2 systemd-resolved[1049]: Failed to send hostname reply: Invalid argument gen 18 13:56:51 R2D2 syncthing.desktop[2866]: [2Z4JW] 13:56:51 INFO: Could not connect to relay relay://85.143.216.244:22067/?id=ZZH75EM-CQTOHQW-ZNYHBFF-VDNIX62-WCOSHLF-RDWCR36-HZD5OZK-GZ4TUAD=1m0s=2m0s=0=150=:22070=667BDRM-Delfin: dial tcp 85.143.216.244:22067: connect: no route to host gen 18 13:56:54 R2D2 syncthing.desktop[2866]: [2Z4JW] 13:56:54 INFO: Could not connect to relay relay://89.14.194.61:22067/?id=DNNRZEH-YJMQ62S-LZ4ATBN-TYIOESN-24DXP6K-IBWXR5Q-XNG6UNS-VLOVAAF=1m0s=2m0s=0=0=:22070=: dial tcp 89.14.194.61:22067: connect: no route to host gen 18 13:56:58 R2D2 syncthing.desktop[2866]: [2Z4JW] 13:56:58 INFO: Could not connect to relay
[Touch-packages] [Bug 48734] Re: Home permissions too open
This bug was fixed in the package adduser - 3.118ubuntu5
---
adduser (3.118ubuntu5) hirsute; urgency=medium
* Enable private home directories by default (LP: #48734)
- Set DIR_MODE=0750 in the default adduser.conf
- Change the description and default value to select private home
directories by default in debconf template
- Change the DIR_MODE when private home directories is configured via
debconf from 0751 to 0750 to ensure files are truly private
-- Alex Murray Wed, 06 Jan 2021 16:46:50
+1030
** Changed in: adduser (Ubuntu Hirsute)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/48734
Title:
Home permissions too open
Status in adduser package in Ubuntu:
Fix Released
Status in shadow package in Ubuntu:
Fix Released
Status in adduser source package in Hirsute:
Fix Released
Status in shadow source package in Hirsute:
Fix Released
Status in Ubuntu RTM:
Opinion
Bug description:
Binary package hint: debian-installer
On a fresh dapper install i noticed that the file permissons for the
home directory for the user created by the installer is set to 755,
giving read access to everyone on the system.
Surely this is a bad idea? If your set on the idea can we atleast have
a option during the boot proccess?
Also new files that are created via the console ('touch' etc.) are
done so with '644' permissons, is there anything that can be done
here? nautlius seems to create files at '600', which is a better
setting.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+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 1912162] Re: NetworkManager managed wifi can't connect
Thanks for the reply, I opened the following upstream issue: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/635 Though I'm not sure how effective that is going to be as ubuntu is not using the latest upstream NM so they just tell me "please update to latest version and report back"... ** Bug watch added: gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues #635 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/635 -- 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/1912162 Title: NetworkManager managed wifi can't connect Status in network-manager package in Ubuntu: New Bug description: My computer has an built-in intel ax200 adapter (the motherboard is asock taichi x570). With the latest stable 5.4 kernel on Ubuntu Focal 20.04 I cannot get the card to connect to my home wifi (2.4ghz). The errors I get are : iwlwifi :05:00.0: No beacon heard and the time event is over already... wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) Initially I thought this could be due to a problem with the iwlwifi driver and the firmware used. I upgraded to a custom-build (using ubuntu's configuration) 5.10 kernel And now the errors I was getting were: [нд яну 17 22:01:33 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:33 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:33 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) [нд яну 17 22:01:34 2021] wlp5s0: authentication with 30:b5:c2:75:a4:ce timed out [нд яну 17 22:01:35 2021] wlp5s0: authenticate with 30:b5:c2:75:a4:ce [нд яну 17 22:01:35 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 1/3) [нд яну 17 22:01:36 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:36 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:36 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) [нд яну 17 22:01:37 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:37 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:37 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) The change of message is because newer versions of the driver/firmware have moved part of the processing in firmware. At this point I was willing to accept this is an issue with the kernel. However, I added the following configuration to /etc/network/interfaces: allow-hotplug wlp5s0 iface wlp5s0 inet dhcp wpa-ssid HOME wpa-psk wpa-debug-level 2 And what do you know - I was able to connect to my home wifi with no problems. I'm attaching the output of wpa_supplicant run with -dd from both the /etc/network/interfaces-based configuration (wpa_supplicant_working) and from the NetworkManager managed one ( I have edited /lib/systemd/system/wpa_supplicant.service to include -f /var/log/wpa_supplicant -dd) options. I wasn't able to figure any glaring differences between the flows of the two. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1912162/+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 1907878] Re: wrong var declaration in if-up.d/resolved (nm-dispatcher[54417]: /etc/network/if-up.d/resolved: 12: mystatedir: not found)
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: ifupdown (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1907878 Title: wrong var declaration in if-up.d/resolved (nm-dispatcher[54417]: /etc/network/if-up.d/resolved: 12: mystatedir: not found) Status in ifupdown package in Ubuntu: Confirmed Bug description: Syslog error: nm-dispatcher[...]: /etc/network/if-up.d/resolved: 12: mystatedir: not found I think it's because of this line: if systemctl is-enabled systemd-resolved > /dev/null 2>&1; then mystatedir statedir ifindex interface <- this is interpreted as a 'mystatedir' command and fails interface=$IFACE if [ ! "$interface" ]; then Perhaps the intention was to 'export mystatedir statedir ...' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1907878/+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 1779657] Re: apt autoremove not removing old kernels
I was looking into the same thing
It seems like this is intentional
I'm on this version
lsb_release -a
LSB Version:
core-11.1.0ubuntu2-noarch:printing-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description:Ubuntu 20.04.1 LTS
Release:20.04
Codename: focal
It appears apt is configured to never autoremove kernels
/etc/apt/apt.conf.d/01autoremove
NeverAutoRemove
{
"^firmware-linux.*";
"^linux-firmware$";
"^linux-image-[a-z0-9]*$";
"^linux-image-[a-z0-9]*-[a-z0-9]*$";
};
--
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/1779657
Title:
apt autoremove not removing old kernels
Status in apt package in Ubuntu:
New
Bug description:
I noticed that apt autoremove stopped removing old kernels recently.
Currently I have 6 installed and apt autoremove does not try to remove
old ones:
$ sudo apt autoremove --purge
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
In /etc/apt/apt.conf.d/01autoremove-kernels it is said to only keep
last three versions:
# list of different kernel versions:
4.15.0-24.26~16.04.1
4.15.0-23.25~16.04.1
4.15.0-22.24~16.04.1
4.15.0-15.16~16.04.1
4.13.0-45.50~16.04.1
4.13.0-43.48~16.04.1
# Installing kernel: 4.13.0-45.50~16.04.1 (4.13.0-45-generic)
# Running kernel: 4.15.0-23.25~16.04.1 (4.15.0-23-generic)
# Last kernel: 4.15.0-24.26~16.04.1
# Previous kernel: 4.15.0-23.25~16.04.1
# Kernel versions list to keep:
4.13.0-45.50~16.04.1
4.15.0-23.25~16.04.1
4.15.0-24.26~16.04.1
# Kernel packages (version part) to protect:
4\.13\.0-45-generic
4\.15\.0-23-generic
4\.15\.0-24-generic
It was working fine previously and I didn't change anything that could
break this functionality.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: apt 1.2.26
ProcVersionSignature: Ubuntu 4.15.0-24.26~16.04.1-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Jul 2 14:12:03 2018
InstallationDate: Installed on 2018-01-19 (164 days ago)
InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64
(20170801)
SourcePackage: apt
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1779657/+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 1911903] Re: Auto-reconnection of wifi doesn't work
Thank you for the bug report. Could you add the 'journalctl -b 0' log after seeing the issue and indicate the time where the problem happened to be able to better match a potential corresponding error? ** Changed in: network-manager (Ubuntu) Importance: Undecided => Low ** Changed in: network-manager (Ubuntu) Status: New => Incomplete -- 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/1911903 Title: Auto-reconnection of wifi doesn't work Status in network-manager package in Ubuntu: Incomplete Bug description: Hi everyone :) It's a problem that occurs without any possible correlation with other event (wake up, sleep etc). In the middle of a session the Wi-Fi simply stop working and not only the system doesn't reconnect automatically, but you need to turn off and back on the Wi-Fi to be able to continue your activities. IDK if it's related, but sometimes also happens that the other Wi-Fi networks around me are not visible in the setting. If I can help in any way with logs of any other information please contact me Antonio ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: network-manager 1.22.10-1ubuntu2.2 ProcVersionSignature: Ubuntu 5.8.0-36.40~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-36-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Jan 15 12:56:08 2021 InstallationDate: Installed on 2020-11-03 (73 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) IpRoute: default via 192.168.178.1 dev wlp2s0b1 proto dhcp metric 20600 169.254.0.0/16 dev br-90c79c39374f scope link metric 1000 linkdown 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 172.18.0.0/16 dev br-90c79c39374f proto kernel scope link src 172.18.0.1 linkdown 192.168.178.0/24 dev wlp2s0b1 proto kernel scope link src 192.168.178.52 metric 600 SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.22.10 connected (site only) started limited enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1911903/+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 1912162] Re: NetworkManager managed wifi can't connect
Thank you for the bug report and the details, you would probably have a better chance to get a reply reporting directly upstream for network manager since that component currently doesn't have a dedicated maintainer in Ubuntu and is dealt with on best effort basis https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1912162 Title: NetworkManager managed wifi can't connect Status in network-manager package in Ubuntu: New Bug description: My computer has an built-in intel ax200 adapter (the motherboard is asock taichi x570). With the latest stable 5.4 kernel on Ubuntu Focal 20.04 I cannot get the card to connect to my home wifi (2.4ghz). The errors I get are : iwlwifi :05:00.0: No beacon heard and the time event is over already... wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) Initially I thought this could be due to a problem with the iwlwifi driver and the firmware used. I upgraded to a custom-build (using ubuntu's configuration) 5.10 kernel And now the errors I was getting were: [нд яну 17 22:01:33 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:33 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:33 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) [нд яну 17 22:01:34 2021] wlp5s0: authentication with 30:b5:c2:75:a4:ce timed out [нд яну 17 22:01:35 2021] wlp5s0: authenticate with 30:b5:c2:75:a4:ce [нд яну 17 22:01:35 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 1/3) [нд яну 17 22:01:36 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:36 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:36 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) [нд яну 17 22:01:37 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:37 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:37 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) The change of message is because newer versions of the driver/firmware have moved part of the processing in firmware. At this point I was willing to accept this is an issue with the kernel. However, I added the following configuration to /etc/network/interfaces: allow-hotplug wlp5s0 iface wlp5s0 inet dhcp wpa-ssid HOME wpa-psk wpa-debug-level 2 And what do you know - I was able to connect to my home wifi with no problems. I'm attaching the output of wpa_supplicant run with -dd from both the /etc/network/interfaces-based configuration (wpa_supplicant_working) and from the NetworkManager managed one ( I have edited /lib/systemd/system/wpa_supplicant.service to include -f /var/log/wpa_supplicant -dd) options. I wasn't able to figure any glaring differences between the flows of the two. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1912162/+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 1911059] Re: gce: 247.1-4ubuntu1 causes loss of networking
** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Balint Reczey (rbalint) -- 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/1911059 Title: gce: 247.1-4ubuntu1 causes loss of networking Status in systemd package in Ubuntu: New Bug description: Summary === On Hirsute, upgrading or using to systemd 247.1-4ubuntu1 causes Google Cloud instance to loose network access. Expected Result === Working network access Actual Result === After upgrade, network access is lost and serial console is filled with messages about IPv4 martian source and ll header, see below. Steps to Reproduce === 1. Launch `daily-ubuntu-2104-hirsute-v20210107` the last known good image 2. sudo apt update 3. sudo apt install systemd 4. ssh is lost The images, built with this version do not appear to be able to start networking. Logs === Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915720] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915724] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978762] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978803] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042242] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042302] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105412] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105448] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168141] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168178] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 $ journalctl --no-pager -u systemd-net -- Journal begins at Mon 2021-01-11 21:30:31 UTC, ends at Mon 2021-01-11 21:52:03 UTC. -- Jan 11 21:30:35 ubuntu systemd[1]: Starting Network Service... Jan 11 21:30:35 ubuntu systemd-networkd[413]: Enumeration completed Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Interface name change detected, ens4 has been renamed to eth0. Jan 11 21:30:35 ubuntu systemd[1]: Started Network Service. Jan 11 21:30:35 ubuntu systemd-networkd[413]: eth0: Interface name change detected, eth0 has been renamed to ens4. Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: IPv6 successfully enabled Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Link UP Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Gained carrier Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Classless static routes received from DHCP server: ignoring router option Jan 11 21:30:37 ubuntu systemd-networkd[413]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[413]: ens4: DHCPv6 lease lost Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopping Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: systemd-networkd.service: Succeeded. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopped Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Starting Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: Enumeration completed Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Started Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911059/+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 1905044] Re: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8
This bug was fixed in the package systemd - 237-3ubuntu10.44 --- systemd (237-3ubuntu10.44) bionic; urgency=medium * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c5a2db69aafc7a3ab4e71bae44fd7ad9dd955c97 * d/p/lp1905044/0001-capability-add-a-way-to-get-a-uint64_t-with-all-caps.patch, d/p/lp1905044/0002-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=34ebc6e28e63881d40c91c5839597acc2fdab546 * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch: print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5ab225b7f731c6cf6b4655cb27c3a842150c4c1a * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=036230cac8232bf4f970e565c355ee1a82fc2ee6 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b284b93e40b6cb834bb40dd3db94850853ab5bb8 -- Dan Streetman Wed, 06 Jan 2021 16:04:25 -0500 ** Changed in: systemd (Ubuntu Bionic) Status: Fix Committed => 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/1905044 Title: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: Fix Released Bug description: [impact] autopkgtest failure when running with 5.8 kernel, if systemd is built with earlier kernel (e.g. 5.4) [test case] see autopkgtest results, e.g. links in original description below [regression potential] as this only fixes a test case, any regression would likely result in an incorrectly passing, or incorrectly failing, test. [scope] this is needed for b/f/g/h. this bug was introduced by upstream commit 23cc81e7c22 which first added testing for 'invalid' cap numbers, but incorrectly using capability_list_length() instead of cap_last_cap(). That commit was first included in v236, so this bug does not exist before Bionic. this is fixed upstream by commit ebc815cd1c647faa934a446ceea91ff4bc9dffa4, which was first included in v247, so this is needed for h and earlier. Also note that even though the 5.8 kernel is not planned to be released for Bionic, this test also runs at build time, and since the LP build farm builds inside chroots, if the build farm ever moved up to Focal with a 5.8 kernel, the build of systemd for Bionic would start failing (since it would still be building using the older kernel headers, inside the chroot), so this does need to be fixed in Bionic systemd as well. [other info] there is a non-test bug related to this in bug 1905245 [original description] Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20201117_174614_4ece6@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20201117_221555_48b91@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/ppc64el/s/systemd/20201117_175806_e779f@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20201117_153051_90e7e@/log.gz The failing testcases are: - root-unittests Assertion 'capability_set_to_string_alloc(c, ) == 0' failed at src/test/test-cap-list.c:60, funct ion test_capability_set_one(). Aborting. FAIL: test-cap-list (code: 134) - upstream TEST-24-UNIT-TESTS: --- test-cap-list begin --- Assertion
[Touch-packages] [Bug 1907306] Re: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind
Released it as I saw it was merged for hirsute - please make sure that all the approved changes are also released into hirsute whenever possible. -- 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/1907306 Title: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind Status in systemd: Fix Released Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: In Progress Bug description: [impact] networkd dhcpv4 client never attempts more than 2 renew and 2 rebind [test case] configure an interface to use dhcpv4; acquire a dhcpv4 address, then stop the dhcpv4 server, and wait for the networkd client to perform its renewals and rebinds before expiring the lease using a 20 minute lease time as an example (all times are approximate due to RFC-mandated random 'fuzz' time of -1 to +1 sec): the current behavior would be to sent renew requests at: 10:00 13:45 and then rebind requests at: 17:30 18:45 then the lease would expire at 20:00 the correct/new behavior should be renew requests at: 10:00 13:45 15:37 16:37 and then rebind requests at: 17:30 18:45 19:45 and then lease expiration at 20:00. longer lease times would increase the number of retransmissions. [regression potential] any regression would likely result in problems receiving and/or maintaining a dhcpv4 address [scope] this is needed in b/f/g/h. this was fixed upstream in: https://github.com/systemd/systemd/pull/17908 that was just added, so this is not fixed in any ubuntu release yet. technically, this is needed in x as well, however I don't plan to backport to x since 1) it reaches ESM soon and 2) the default network management tool in x is ifupdown, not systemd-networkd. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1907306/+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 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.
This bug was fixed in the package systemd - 237-3ubuntu10.44 --- systemd (237-3ubuntu10.44) bionic; urgency=medium * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c5a2db69aafc7a3ab4e71bae44fd7ad9dd955c97 * d/p/lp1905044/0001-capability-add-a-way-to-get-a-uint64_t-with-all-caps.patch, d/p/lp1905044/0002-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=34ebc6e28e63881d40c91c5839597acc2fdab546 * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch: print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5ab225b7f731c6cf6b4655cb27c3a842150c4c1a * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=036230cac8232bf4f970e565c355ee1a82fc2ee6 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b284b93e40b6cb834bb40dd3db94850853ab5bb8 -- Dan Streetman Wed, 06 Jan 2021 16:04:25 -0500 ** Changed in: systemd (Ubuntu Bionic) Status: Fix Committed => 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/1881947 Title: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. Status in systemd: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: In Progress Bug description: [Impact] * Autopkgtest fails due to corrupted journal file [Test Case] * Observe autopkgtest root-unittests not failing with: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. [Where problems could occur] * The change has no impact on the systemd binary packages. The relaxed test could hide a journal corruption problem, but it seems the corrupted journal files occur only on arm64 probably due to arm64 reboots being resets: LP: #1748280. [Original Bug Text] Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz [...] PASS: test-journal-enum == test-journal-flush === Root directory /var/log/journal removed. Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed. mmap cache statistics: 739 hit, 5 miss journal_file_copy_entry failed: Bad message Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. FAIL: test-journal-flush (code: 134) Aborted (core dumped) == test-journal-importer === [...] autopkgtest [07:17:29]: summary timedatedPASS hostnamedPASS localed-locale PASS localed-x11-keymap PASS logind PASS unit-config PASS storage PASS networkd-test.py PASS build-login PASS boot-and-servicesPASS udev PASS root-unittests FAIL non-zero exit status 134 upstream PASS boot-smoke PASS systemd-fsckdPASS Exit request sent. [...] To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1881947/+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 1878955] Re: resolved dhclient-enter-hook complains about an empty file
This bug was fixed in the package systemd - 237-3ubuntu10.44 --- systemd (237-3ubuntu10.44) bionic; urgency=medium * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c5a2db69aafc7a3ab4e71bae44fd7ad9dd955c97 * d/p/lp1905044/0001-capability-add-a-way-to-get-a-uint64_t-with-all-caps.patch, d/p/lp1905044/0002-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=34ebc6e28e63881d40c91c5839597acc2fdab546 * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch: print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5ab225b7f731c6cf6b4655cb27c3a842150c4c1a * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=036230cac8232bf4f970e565c355ee1a82fc2ee6 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b284b93e40b6cb834bb40dd3db94850853ab5bb8 -- Dan Streetman Wed, 06 Jan 2021 16:04:25 -0500 ** Changed in: systemd (Ubuntu Bionic) Status: Fix Committed => 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/1878955 Title: resolved dhclient-enter-hook complains about an empty file Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Bug description: [impact] When starting/using `dhclient`, it will often return an error such as: cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty [test case] run dhclient for the first time (for the current boot) on a bionic/focal system, or remove the file(s) in /run/systemd/resolved.conf.d/ starting with 'isc-dhcp-*', and then run dhclient. [regression potential] any regression would likely cause the DNS configuration that dhclient gets to not be properly reported to systemd-resolved, resulting in problematic/broken systemd DNS resolution. [scope] this is needed in b/f this hook was removed from systemd starting in g, and the hook was not yet added in x, so this change is needed only in b and f. [original description] When starting/using `dhclient`, it will often return an error such as: cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty This is due to the use of `cmp` in "/etc/dhcp/dhclient-enter- hooks.d/resolved" Because the $oldstate file can be empty, or different, it should use `cmp --quiet` This happens when "/run/systemd/resolved.conf.d/isc- dhcp-v*-$interface.conf" files do not exist, or when the content changes. This is very loosely related to https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1878955/+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 1905245] Re: "Failed to parse bus message: Invalid argument" with Linux 5.8
This bug was fixed in the package systemd - 237-3ubuntu10.44 --- systemd (237-3ubuntu10.44) bionic; urgency=medium * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c5a2db69aafc7a3ab4e71bae44fd7ad9dd955c97 * d/p/lp1905044/0001-capability-add-a-way-to-get-a-uint64_t-with-all-caps.patch, d/p/lp1905044/0002-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=34ebc6e28e63881d40c91c5839597acc2fdab546 * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch: print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5ab225b7f731c6cf6b4655cb27c3a842150c4c1a * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=036230cac8232bf4f970e565c355ee1a82fc2ee6 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b284b93e40b6cb834bb40dd3db94850853ab5bb8 -- Dan Streetman Wed, 06 Jan 2021 16:04:25 -0500 ** Changed in: systemd (Ubuntu Bionic) Status: Fix Committed => 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/1905245 Title: "Failed to parse bus message: Invalid argument" with Linux 5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Bug description: [impact] newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show' [test case] install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel. Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it: ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor Failed to parse bus message: Invalid argument the command should correctly show the value, e.g.: $ systemctl show -p CapabilityBoundingSet apparmor CapabilityBoundingSet=cap_chown cap_dac_override ...etc... [regression potential] a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services. [scope] this is needed only in focal and bionic. This is fixed upstream by PR 16424: https://github.com/systemd/systemd/pull/16424 which was first included in v246, so this is already fixed in groovy and later. This was introduced upstream in systemd by commit 52610b020c077ee769c6923249f7e6c4e99d2980 which was first included in v235, so this bug does not exist in Xenial. This bug will reproduce on any system running under the 5.8 kernel, with the new capability, if the systemd binary was compiled with kernel headers that do not include the new capability. This means this is reproducable on bare-metal/vm instances running 5.8, as well as containers on hosts running 5.8. Therefore, while bionic may not ever receive a new kernel with added capability, it still needs to be patched to avoid the bug on a bionic container running on a host with the 5.8 kernel. [other info] there is a testcase-only related bug 1905044 [original description] When I run `systemctl show myservice.service`, I get the following error message: Failed to parse bus message: Invalid argument systemd version: 245.4-4ubuntu3.3 linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge) This is a bug that has been fixed in Debian. See
[Touch-packages] [Bug 1907306] Re: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind
This bug was fixed in the package systemd - 237-3ubuntu10.44 --- systemd (237-3ubuntu10.44) bionic; urgency=medium * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c5a2db69aafc7a3ab4e71bae44fd7ad9dd955c97 * d/p/lp1905044/0001-capability-add-a-way-to-get-a-uint64_t-with-all-caps.patch, d/p/lp1905044/0002-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=34ebc6e28e63881d40c91c5839597acc2fdab546 * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch: print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5ab225b7f731c6cf6b4655cb27c3a842150c4c1a * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=036230cac8232bf4f970e565c355ee1a82fc2ee6 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b284b93e40b6cb834bb40dd3db94850853ab5bb8 -- Dan Streetman Wed, 06 Jan 2021 16:04:25 -0500 ** Changed in: systemd (Ubuntu Bionic) Status: Fix Committed => 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/1907306 Title: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind Status in systemd: Fix Released Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: In Progress Bug description: [impact] networkd dhcpv4 client never attempts more than 2 renew and 2 rebind [test case] configure an interface to use dhcpv4; acquire a dhcpv4 address, then stop the dhcpv4 server, and wait for the networkd client to perform its renewals and rebinds before expiring the lease using a 20 minute lease time as an example (all times are approximate due to RFC-mandated random 'fuzz' time of -1 to +1 sec): the current behavior would be to sent renew requests at: 10:00 13:45 and then rebind requests at: 17:30 18:45 then the lease would expire at 20:00 the correct/new behavior should be renew requests at: 10:00 13:45 15:37 16:37 and then rebind requests at: 17:30 18:45 19:45 and then lease expiration at 20:00. longer lease times would increase the number of retransmissions. [regression potential] any regression would likely result in problems receiving and/or maintaining a dhcpv4 address [scope] this is needed in b/f/g/h. this was fixed upstream in: https://github.com/systemd/systemd/pull/17908 that was just added, so this is not fixed in any ubuntu release yet. technically, this is needed in x as well, however I don't plan to backport to x since 1) it reaches ESM soon and 2) the default network management tool in x is ifupdown, not systemd-networkd. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1907306/+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 1894329] Re: ZFS revert from grub menu not working.
This bug was fixed in the package zfs-linux - 0.8.4-1ubuntu11.1
---
zfs-linux (0.8.4-1ubuntu11.1) groovy; urgency=medium
[ Didier Roche ]
[ Jean-Baptiste Lallement ]
* Generate clone uuid without dd which is flagged as having an executable
stack. Thanks Usarin Heininga for the patch (LP: #1894329)
[ Andrea Righi ]
* fix potential user-space double free when running "zfs mount -a"
(LP: #1902588)
- 4702-Revert-Let-zfs-mount-all-tolerate-in-progress-mounts.patch
-- Colin Ian King Mon, 30 Nov 2020 19:00:00
+
** Changed in: zfs-linux (Ubuntu Groovy)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1894329
Title:
ZFS revert from grub menu not working.
Status in coreutils package in Ubuntu:
Incomplete
Status in zfs-linux package in Ubuntu:
Fix Released
Status in coreutils source package in Focal:
Incomplete
Status in zfs-linux source package in Focal:
Fix Committed
Status in coreutils source package in Groovy:
Incomplete
Status in zfs-linux source package in Groovy:
Fix Released
Bug description:
[Impact]
* Users can’t revert to previous snapshots when enabling the hw enablement
stack kernel on focal or using any more recent version.
* The option is available on grub and will let you with a broken system,
partially cloned.
[Test Case]
* Boot on a system, using ZFS and ZSys.
* In grub, select "History" entry
* Select one of the "Revert" option: the system should boot after being
reverted with an older version.
[Where problems could occur]
* The code is in the initramfs, where the generated id suffix for all our
ZFS datasets was empty due to new coreutils/kernels.
* We replace dd with another way (more robust and simple) for generating
this ID.
-
@coreutils maintainers, any idea why dd is being flagged as having an
executable stack?
When I try to revert to a previous state from the grub menu, the boot
fails. The system drops me to a repair modus.
zfs-mount-generator fails with the message:
couldn't ensure boot: Mounted clone bootFS dataset created by initramfs
doesn't have a valid _suffix (at least .*_): \"rpool/ROOT/ubuntu_\"".
After a reboot I have an extra clone called "rpool/ROOT/ubuntu_", indeed
without a suffix.
After a little investigation I found the problem in
/usr/share/initramfs-tools/scripts/zfs at the end in function
uid()
{
dd if=/dev/urandom of=/dev/stdout bs=1 count=100 2>/dev/null | tr -dc
'a-z0-9' | cut -c-6
}, the dd command fails during boot with the message "process 'dd' started
with executable stack.
After this an empty uid is returned which explains the dataset without a
proper suffix.
Replacing the function with:
uid()
{
grep -a -m10 -E "\*" /dev/urandom 2>/dev/null | tr -dc 'a-z0-9' | cut -c-6
}
fixes the problem.
Ubuntu version is:
Description:Ubuntu Groovy Gorilla (development branch)
Release:20.10
zfs-initramfs version is:
0.8.4-1ubuntu11
With regards,
Usarin Heininga
ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: zfs-initramfs 0.8.4-1ubuntu11
ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
Uname: Linux 5.8.0-18-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu45
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Fri Sep 4 20:23:44 2020
InstallationDate: Installed on 2020-09-02 (2 days ago)
InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200831)
ProcEnviron:
LANGUAGE=
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=nl_NL.UTF-8
SHELL=/bin/bash
SourcePackage: zfs-linux
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1894329/+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 1878955] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- 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/1878955 Title: resolved dhclient-enter-hook complains about an empty file Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] When starting/using `dhclient`, it will often return an error such as: cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty [test case] run dhclient for the first time (for the current boot) on a bionic/focal system, or remove the file(s) in /run/systemd/resolved.conf.d/ starting with 'isc-dhcp-*', and then run dhclient. [regression potential] any regression would likely cause the DNS configuration that dhclient gets to not be properly reported to systemd-resolved, resulting in problematic/broken systemd DNS resolution. [scope] this is needed in b/f this hook was removed from systemd starting in g, and the hook was not yet added in x, so this change is needed only in b and f. [original description] When starting/using `dhclient`, it will often return an error such as: cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty This is due to the use of `cmp` in "/etc/dhcp/dhclient-enter- hooks.d/resolved" Because the $oldstate file can be empty, or different, it should use `cmp --quiet` This happens when "/run/systemd/resolved.conf.d/isc- dhcp-v*-$interface.conf" files do not exist, or when the content changes. This is very loosely related to https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1878955/+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 1878955] Re: resolved dhclient-enter-hook complains about an empty file
This bug was fixed in the package systemd - 245.4-4ubuntu3.4 --- systemd (245.4-4ubuntu3.4) focal; urgency=medium * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch, d/p/lp1905245/0002-basic-capability-util-let-cap_last_cap-return-unsign.patch, d/p/lp1905245/0003-basic-cap-list-reduce-scope-of-variables.patch: - print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5cd98102e16a6e4acc1444b10db3308d87930933 * d/p/lp1890448-hwdb-Add-EliteBook-to-use-micmute-hotkey.patch: Add EliteBook to use micmute hotkey (LP: #1890448) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=238c8c1a7b9d75f69bdeafb1d55f1faf00acb063 * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=83df4fc182f8ffe87256f5d7c4b49cee5192529a * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff21f41e624d9e603f3be463846ce981a433842a * d/p/lp1903300/0001-network-VXLan-fix-adding-Group-address.patch, d/p/lp1903300/0002-network-VXLan-Add-support-for-remote-address.patch, d/p/lp1903300/0003-networkctl-Add-support-to-display-VXLan-remote-addre.patch: set vxlan multicast group when specified (LP: #1903300) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9deff4b7c5495dbe738561ca47daf3756df9fcde * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a73c51d0df284dcc38e6924d40eed810554bab2e * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ec7ba2358aa68d8d6276ed56ef91caafc287cecf * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5481fececdb3cb35ca7118598cad537681b5ff14 -- Dan Streetman Wed, 06 Jan 2021 15:47:39 -0500 ** Changed in: systemd (Ubuntu Focal) Status: Fix Committed => 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/1878955 Title: resolved dhclient-enter-hook complains about an empty file Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] When starting/using `dhclient`, it will often return an error such as: cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty [test case] run dhclient for the first time (for the current boot) on a bionic/focal system, or remove the file(s) in /run/systemd/resolved.conf.d/ starting with 'isc-dhcp-*', and then run dhclient. [regression potential] any regression would likely cause the DNS configuration that dhclient gets to not be properly reported to systemd-resolved, resulting in problematic/broken systemd DNS resolution. [scope] this is needed in b/f this hook was removed from systemd starting in g, and the hook was not yet added in x, so this change is needed only in b and f. [original description] When starting/using `dhclient`, it will often return an error such as: cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty This is due to the use of `cmp` in "/etc/dhcp/dhclient-enter- hooks.d/resolved" Because the $oldstate file can be empty, or different, it should use `cmp --quiet` This happens when "/run/systemd/resolved.conf.d/isc- dhcp-v*-$interface.conf" files do not exist, or when the content changes. This is very loosely related to https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183 To manage notifications about this bug go to:
[Touch-packages] [Bug 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.
This bug was fixed in the package systemd - 245.4-4ubuntu3.4 --- systemd (245.4-4ubuntu3.4) focal; urgency=medium * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch, d/p/lp1905245/0002-basic-capability-util-let-cap_last_cap-return-unsign.patch, d/p/lp1905245/0003-basic-cap-list-reduce-scope-of-variables.patch: - print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5cd98102e16a6e4acc1444b10db3308d87930933 * d/p/lp1890448-hwdb-Add-EliteBook-to-use-micmute-hotkey.patch: Add EliteBook to use micmute hotkey (LP: #1890448) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=238c8c1a7b9d75f69bdeafb1d55f1faf00acb063 * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=83df4fc182f8ffe87256f5d7c4b49cee5192529a * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff21f41e624d9e603f3be463846ce981a433842a * d/p/lp1903300/0001-network-VXLan-fix-adding-Group-address.patch, d/p/lp1903300/0002-network-VXLan-Add-support-for-remote-address.patch, d/p/lp1903300/0003-networkctl-Add-support-to-display-VXLan-remote-addre.patch: set vxlan multicast group when specified (LP: #1903300) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9deff4b7c5495dbe738561ca47daf3756df9fcde * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a73c51d0df284dcc38e6924d40eed810554bab2e * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ec7ba2358aa68d8d6276ed56ef91caafc287cecf * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5481fececdb3cb35ca7118598cad537681b5ff14 -- Dan Streetman Wed, 06 Jan 2021 15:47:39 -0500 ** Changed in: systemd (Ubuntu Focal) Status: Fix Committed => 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/1881947 Title: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. Status in systemd: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: In Progress Bug description: [Impact] * Autopkgtest fails due to corrupted journal file [Test Case] * Observe autopkgtest root-unittests not failing with: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. [Where problems could occur] * The change has no impact on the systemd binary packages. The relaxed test could hide a journal corruption problem, but it seems the corrupted journal files occur only on arm64 probably due to arm64 reboots being resets: LP: #1748280. [Original Bug Text] Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz [...] PASS: test-journal-enum == test-journal-flush === Root directory /var/log/journal removed. Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed. mmap cache statistics: 739 hit, 5 miss journal_file_copy_entry failed: Bad message Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. FAIL: test-journal-flush (code: 134)
[Touch-packages] [Bug 1888726] Re: systemd-udevd regression: some renamed network interfaces stuck in "pending" state
This bug was fixed in the package netplan.io - 0.101-0ubuntu3~20.04.2 --- netplan.io (0.101-0ubuntu3~20.04.2) focal; urgency=medium * Backport netplan.io 0.101-0ubuntu3 to 20.04 (LP: #1908509) - Includes DBus Config/Get/Set/Try API - Includes fixes for NetworkManager integration - Includes Documentation improvements - Compatibility with systemd v247 * Improve test stability, by adding two patches from upstream: - debian/patches/0004-tests-tunnels-improve-test-reliability.patch - debian/patches/0005-tests-dbus-improve-test-stability-of-timeouts.patch -- Lukas Märdian Fri, 08 Jan 2021 15:17:07 +0100 ** Changed in: netplan.io (Ubuntu Focal) 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/1888726 Title: systemd-udevd regression: some renamed network interfaces stuck in "pending" state Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Invalid Status in netplan.io source package in Focal: Fix Released Status in systemd source package in Focal: Invalid Bug description: Summary: In Ubuntu Server 20.04 LTS and newer, using netplan.io and systemd- networkd, in certain network configurations, renamed network interfaces get stuck in "pending" state and are not configured properly. On boot, system is stuck on "Wait for Network to be Configured" for 2 minutes. How to reproduce: 1. Configure a machine (for example, a virtual machine) with two Ethernet network cards. Make note of MAC addresses of these network cards. 2. Set up netplan with a single configuration file, contents are in the attached "00-static.yaml" file. Replace the MAC addresses to match your setup. IP address configuration is omitted and is not necessary to reproduce the bug. 3. Reboot the system. Expected outcome: 1. System boots in a reasonable time 2. First network interface (wan) is brought up, is not renamed, and is marked as configured by networkd 3. Second network interface (lan) is brought up, renamed, configured for MTU=9000, and is marked as configured by networkd 4. VLAN interface (vlan20) is brought up, renamed, configured for MTU=9000, and is marked as configured by networkd Actual outcome: 1. System boot is delayed by 2 minutes 2. First network interface (wan) is configured as expected 3. Second network interface (lan) is configured as expected 4. VLAN interface (vlan20) seems to be configured as expected, but is stuck in "pending" state according to networkctl list Test environment: Hardware: Virtual machine with the following configuration * 4 amd64 CPU cores (also tested with a single core) * 1 GB RAM * 8 GB disk * 2 network cards (vmxnet3 in VMware, virtio in Parallels) Working as expected: * [1] Ubuntu Server 19.10, kernel 5.3.0-62, netplan.io 0.99-0ubuntu3~19.10.2, systemd+udev 242-7ubuntu3.11 Broken: * [2] Ubuntu Server 19.10, kernel 5.3.0-62, netplan.io 0.99-0ubuntu3~19.10.2, systemd 242-7ubuntu3.11, udev 245.4-4ubuntu3.1 * [3] Ubuntu Server 20.04 LTS, kernel 5.4.0-42, netplan.io 0.99-0ubuntu3~20.04.2, systemd+udev 245.4-4ubuntu3.1 * [4] Ubuntu Server 20.04 LTS, kernel 5.4.0-42, netplan.io 0.99-0ubuntu3~20.04.2, systemd+udev vanilla upstream git e9769453 * [5] Ubuntu Server 20.04 LTS, kernel 5.4.0-42, netplan.io 0.99-0ubuntu3~20.04.2, systemd+udev vanilla upstream git v242 * [6] Ubuntu Server 20.10 daily-live, kernel 5.4.0-26, netplan.io 0.99-0ubuntu5, systemd+udev 245.6-3ubuntu3 [2] As noted above, issue was reproduced in 19.10 by upgrading ONLY udev and libudev1 to ones shipped in focal-updates. [4] It was also reproduced in vanilla upstream systemd, git master commit e9769453. Just installed on top of existing systemd using "sudo ninja -C build install". [5] Interestingly enough, issue also seems to exist in vanilla v242. Either that, or the installation didn't replace the packaged systemd properly. This may hint at some distribution-specific patch that got removed before 20.04. This issue was reproduced in VMware ESXi 6.7U3, VMware Fusion 11.5.5 and Parallels Desktop 15.1.4. This leads me to believe that network card drivers or virtualisation engines do not play part in the issue. Extra observations: To make the example configuration (00-static.yaml) not get stuck in "pending" state, any one of the following options helps: * Remove "set-name" parameter for "lan" interface * Remove "mtu" parameter for "lan" interface * Remove "wan" interface entirely I got some data/logs for each of these scenarios for eoan [1] and focal [3], as well as the original broken config, and put them together in the attached "parallels.tar.gz". Note about Apport: Attached apport report was generated
[Touch-packages] [Bug 1890448] Update Released
The verification of the Stable Release Update for systemd has completed
successfully and the package is now being released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report. In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.
--
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/1890448
Title:
hwdb: Add EliteBook to use micmute hotkey
Status in HWE Next:
New
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Focal:
Fix Released
Bug description:
[Impact]
Micmute hotkey on many HP EliteBooks don't work.
[Fix]
Commit b6eb208b29ae ("hwdb: Add EliteBook to use micmute hotkey"), to map AT
keyboard's scancode to micmute hotkey.
[Test]
With the one-liner fix, micmute hotkey works on all the EliteBooks I tested.
[Regression Potential]
The hwdb originally only matches a few EliteBook, and fix changes that to
match all EliteBook models. So if there's an EliteBook that uses the scancode
for other purpose, there will be a regression.
However, the risk is rather slim because HP is confident that all EliteBooks
use the same scancode for mic mute hotkey.
[scope]
this is needed for f and earlier.
this is fixed upstream by commit b6eb208b29ae which is included
starting in v246, so g and later are already fixed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1890448/+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 1890448] Re: hwdb: Add EliteBook to use micmute hotkey
This bug was fixed in the package systemd - 245.4-4ubuntu3.4
---
systemd (245.4-4ubuntu3.4) focal; urgency=medium
* d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch,
d/p/lp1905245/0002-basic-capability-util-let-cap_last_cap-return-unsign.patch,
d/p/lp1905245/0003-basic-cap-list-reduce-scope-of-variables.patch:
- print number of unknown capabilities instead of failing
(LP: #1905245)
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5cd98102e16a6e4acc1444b10db3308d87930933
* d/p/lp1890448-hwdb-Add-EliteBook-to-use-micmute-hotkey.patch:
Add EliteBook to use micmute hotkey (LP: #1890448)
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=238c8c1a7b9d75f69bdeafb1d55f1faf00acb063
* d/extra/dhclient-enter-resolved-hook:
suppress output of cmp command in dhclient hook (LP: #1878955)
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=83df4fc182f8ffe87256f5d7c4b49cee5192529a
* d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch:
test: use cap_last_cap() instead of capability_list_length()
(LP: #1905044)
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff21f41e624d9e603f3be463846ce981a433842a
* d/p/lp1903300/0001-network-VXLan-fix-adding-Group-address.patch,
d/p/lp1903300/0002-network-VXLan-Add-support-for-remote-address.patch,
d/p/lp1903300/0003-networkctl-Add-support-to-display-VXLan-remote-addre.patch:
set vxlan multicast group when specified (LP: #1903300)
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9deff4b7c5495dbe738561ca47daf3756df9fcde
*
d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch,
d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch,
d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch,
d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch,
d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch,
d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch,
d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch,
d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch:
Send correct number of dhcpv4 renew and rebind requests
(LP: #1907306)
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a73c51d0df284dcc38e6924d40eed810554bab2e
* d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch:
Run net_setup_link on 'change' uevents (LP: #1902960)
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ec7ba2358aa68d8d6276ed56ef91caafc287cecf
* d/t/root-unittests:
Remove any corrupt journal files (LP: #1881947)
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5481fececdb3cb35ca7118598cad537681b5ff14
-- Dan Streetman Wed, 06 Jan 2021 15:47:39
-0500
** Changed in: systemd (Ubuntu Focal)
Status: Fix Committed => 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/1890448
Title:
hwdb: Add EliteBook to use micmute hotkey
Status in HWE Next:
New
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Focal:
Fix Released
Bug description:
[Impact]
Micmute hotkey on many HP EliteBooks don't work.
[Fix]
Commit b6eb208b29ae ("hwdb: Add EliteBook to use micmute hotkey"), to map AT
keyboard's scancode to micmute hotkey.
[Test]
With the one-liner fix, micmute hotkey works on all the EliteBooks I tested.
[Regression Potential]
The hwdb originally only matches a few EliteBook, and fix changes that to
match all EliteBook models. So if there's an EliteBook that uses the scancode
for other purpose, there will be a regression.
However, the risk is rather slim because HP is confident that all EliteBooks
use the same scancode for mic mute hotkey.
[scope]
this is needed for f and earlier.
this is fixed upstream by commit b6eb208b29ae which is included
starting in v246, so g and later are already fixed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1890448/+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 1894329] Update Released
The verification of the Stable Release Update for zfs-linux has
completed successfully and the package is now being released to
-updates. Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report. In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1894329
Title:
ZFS revert from grub menu not working.
Status in coreutils package in Ubuntu:
Incomplete
Status in zfs-linux package in Ubuntu:
Fix Released
Status in coreutils source package in Focal:
Incomplete
Status in zfs-linux source package in Focal:
Fix Committed
Status in coreutils source package in Groovy:
Incomplete
Status in zfs-linux source package in Groovy:
Fix Released
Bug description:
[Impact]
* Users can’t revert to previous snapshots when enabling the hw enablement
stack kernel on focal or using any more recent version.
* The option is available on grub and will let you with a broken system,
partially cloned.
[Test Case]
* Boot on a system, using ZFS and ZSys.
* In grub, select "History" entry
* Select one of the "Revert" option: the system should boot after being
reverted with an older version.
[Where problems could occur]
* The code is in the initramfs, where the generated id suffix for all our
ZFS datasets was empty due to new coreutils/kernels.
* We replace dd with another way (more robust and simple) for generating
this ID.
-
@coreutils maintainers, any idea why dd is being flagged as having an
executable stack?
When I try to revert to a previous state from the grub menu, the boot
fails. The system drops me to a repair modus.
zfs-mount-generator fails with the message:
couldn't ensure boot: Mounted clone bootFS dataset created by initramfs
doesn't have a valid _suffix (at least .*_): \"rpool/ROOT/ubuntu_\"".
After a reboot I have an extra clone called "rpool/ROOT/ubuntu_", indeed
without a suffix.
After a little investigation I found the problem in
/usr/share/initramfs-tools/scripts/zfs at the end in function
uid()
{
dd if=/dev/urandom of=/dev/stdout bs=1 count=100 2>/dev/null | tr -dc
'a-z0-9' | cut -c-6
}, the dd command fails during boot with the message "process 'dd' started
with executable stack.
After this an empty uid is returned which explains the dataset without a
proper suffix.
Replacing the function with:
uid()
{
grep -a -m10 -E "\*" /dev/urandom 2>/dev/null | tr -dc 'a-z0-9' | cut -c-6
}
fixes the problem.
Ubuntu version is:
Description:Ubuntu Groovy Gorilla (development branch)
Release:20.10
zfs-initramfs version is:
0.8.4-1ubuntu11
With regards,
Usarin Heininga
ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: zfs-initramfs 0.8.4-1ubuntu11
ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4
Uname: Linux 5.8.0-18-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu45
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Fri Sep 4 20:23:44 2020
InstallationDate: Installed on 2020-09-02 (2 days ago)
InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200831)
ProcEnviron:
LANGUAGE=
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=nl_NL.UTF-8
SHELL=/bin/bash
SourcePackage: zfs-linux
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1894329/+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 1903300] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- 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/1903300 Title: systemd-networkd silently fails to set vxlan multicast group Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Released Bug description: [impact] setting VXLAN.Group does not correctly configure multicast group [test case] taken from upstream bug, example networkd config: [NetDev] Kind=vxlan Name=myvx [VXLAN] VNI=1 Group=ff02::42:1 DestinationPort=8472 After restarting systemd-networkd the VXLAN device is created, but the group address is not assigned. Use ip -d link show myvx and networkctl show myvx to verify. [regression potential] any regression would likely cause problems only with VXLAN netdevs created by networkd. [scope] this is needed only for f. this was introduced by upstream commit 83cb24ac20b which was first in v243, so this bug does not exist in b and earlier. this was fixed by upstream commit 7c9b26900cc33daf080627daf5904de74c1ef267 (and two following commits) which were first included in v246, so this is already fixed in g and later. [original description] Fixed upstream, please include [1]. Thank you. [1] https://github.com/systemd/systemd/pull/15397 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.3 ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65 Uname: Linux 5.4.0-52-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.11 Architecture: amd64 CasperMD5CheckResult: skip Date: Fri Nov 6 14:16:19 2020 MachineType: QEMU Standard PC (Q35 + ICH9, 2009) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-52-generic root=UUID=97786d27-c04a-4592-a087-f19a689468a9 ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: Upgraded to focal on 2020-08-27 (70 days ago) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-5.1 dmi.modalias: dmi:bvnSeaBIOS:bvrrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-5.1:cvnQEMU:ct1:cvrpc-q35-5.1: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-5.1 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1903300/+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 1903300] Re: systemd-networkd silently fails to set vxlan multicast group
This bug was fixed in the package systemd - 245.4-4ubuntu3.4 --- systemd (245.4-4ubuntu3.4) focal; urgency=medium * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch, d/p/lp1905245/0002-basic-capability-util-let-cap_last_cap-return-unsign.patch, d/p/lp1905245/0003-basic-cap-list-reduce-scope-of-variables.patch: - print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5cd98102e16a6e4acc1444b10db3308d87930933 * d/p/lp1890448-hwdb-Add-EliteBook-to-use-micmute-hotkey.patch: Add EliteBook to use micmute hotkey (LP: #1890448) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=238c8c1a7b9d75f69bdeafb1d55f1faf00acb063 * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=83df4fc182f8ffe87256f5d7c4b49cee5192529a * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff21f41e624d9e603f3be463846ce981a433842a * d/p/lp1903300/0001-network-VXLan-fix-adding-Group-address.patch, d/p/lp1903300/0002-network-VXLan-Add-support-for-remote-address.patch, d/p/lp1903300/0003-networkctl-Add-support-to-display-VXLan-remote-addre.patch: set vxlan multicast group when specified (LP: #1903300) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9deff4b7c5495dbe738561ca47daf3756df9fcde * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a73c51d0df284dcc38e6924d40eed810554bab2e * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ec7ba2358aa68d8d6276ed56ef91caafc287cecf * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5481fececdb3cb35ca7118598cad537681b5ff14 -- Dan Streetman Wed, 06 Jan 2021 15:47:39 -0500 ** Changed in: systemd (Ubuntu Focal) Status: Fix Committed => 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/1903300 Title: systemd-networkd silently fails to set vxlan multicast group Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Released Bug description: [impact] setting VXLAN.Group does not correctly configure multicast group [test case] taken from upstream bug, example networkd config: [NetDev] Kind=vxlan Name=myvx [VXLAN] VNI=1 Group=ff02::42:1 DestinationPort=8472 After restarting systemd-networkd the VXLAN device is created, but the group address is not assigned. Use ip -d link show myvx and networkctl show myvx to verify. [regression potential] any regression would likely cause problems only with VXLAN netdevs created by networkd. [scope] this is needed only for f. this was introduced by upstream commit 83cb24ac20b which was first in v243, so this bug does not exist in b and earlier. this was fixed by upstream commit 7c9b26900cc33daf080627daf5904de74c1ef267 (and two following commits) which were first included in v246, so this is already fixed in g and later. [original description] Fixed upstream, please include [1]. Thank you. [1] https://github.com/systemd/systemd/pull/15397 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.3 ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65 Uname: Linux 5.4.0-52-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.11 Architecture: amd64 CasperMD5CheckResult: skip Date: Fri Nov 6 14:16:19 2020 MachineType: QEMU Standard PC (Q35 + ICH9, 2009) ProcEnviron:
[Touch-packages] [Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
This bug was fixed in the package systemd - 245.4-4ubuntu3.4 --- systemd (245.4-4ubuntu3.4) focal; urgency=medium * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch, d/p/lp1905245/0002-basic-capability-util-let-cap_last_cap-return-unsign.patch, d/p/lp1905245/0003-basic-cap-list-reduce-scope-of-variables.patch: - print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5cd98102e16a6e4acc1444b10db3308d87930933 * d/p/lp1890448-hwdb-Add-EliteBook-to-use-micmute-hotkey.patch: Add EliteBook to use micmute hotkey (LP: #1890448) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=238c8c1a7b9d75f69bdeafb1d55f1faf00acb063 * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=83df4fc182f8ffe87256f5d7c4b49cee5192529a * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff21f41e624d9e603f3be463846ce981a433842a * d/p/lp1903300/0001-network-VXLan-fix-adding-Group-address.patch, d/p/lp1903300/0002-network-VXLan-Add-support-for-remote-address.patch, d/p/lp1903300/0003-networkctl-Add-support-to-display-VXLan-remote-addre.patch: set vxlan multicast group when specified (LP: #1903300) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9deff4b7c5495dbe738561ca47daf3756df9fcde * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a73c51d0df284dcc38e6924d40eed810554bab2e * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ec7ba2358aa68d8d6276ed56ef91caafc287cecf * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5481fececdb3cb35ca7118598cad537681b5ff14 -- Dan Streetman Wed, 06 Jan 2021 15:47:39 -0500 ** Changed in: systemd (Ubuntu Focal) Status: Fix Committed => 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/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases Status in cloud-images: New Status in systemd: New Status in cloud-init package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Focal: Incomplete Status in systemd source package in Focal: Fix Released Status in cloud-init source package in Groovy: Incomplete Status in systemd source package in Groovy: Fix Released Bug description: [impact] on boot of a specific azure instance, the ID_NET_DRIVER parameter of the instance's eth0 interface is not set. That leads to a failure of systemd-networkd to take control of the interface after a restart of systemd-networkd, which results in DNS failures (at first) and eventually complete loss of networking (once the DHCP lease expires). [test case] this occurs on first boot of an instance using the specific image; it is not reproducable using the latest ubuntu image nor any reboot of the affected image, and it has not been reproducable (for me) when using debug-enabled images based on the affected image. So, while the problem is reproducable using the specific image in question, it's not possible to verify the fix since any change to the image removes reproducability. however, while the problem itself can't be reproduced and then verified, if the assumption is correct (that the 'add' uevent is being missed on boot), that is possible to test and verify: $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc $
[Touch-packages] [Bug 1905044] Re: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8
This bug was fixed in the package systemd - 245.4-4ubuntu3.4 --- systemd (245.4-4ubuntu3.4) focal; urgency=medium * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch, d/p/lp1905245/0002-basic-capability-util-let-cap_last_cap-return-unsign.patch, d/p/lp1905245/0003-basic-cap-list-reduce-scope-of-variables.patch: - print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5cd98102e16a6e4acc1444b10db3308d87930933 * d/p/lp1890448-hwdb-Add-EliteBook-to-use-micmute-hotkey.patch: Add EliteBook to use micmute hotkey (LP: #1890448) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=238c8c1a7b9d75f69bdeafb1d55f1faf00acb063 * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=83df4fc182f8ffe87256f5d7c4b49cee5192529a * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff21f41e624d9e603f3be463846ce981a433842a * d/p/lp1903300/0001-network-VXLan-fix-adding-Group-address.patch, d/p/lp1903300/0002-network-VXLan-Add-support-for-remote-address.patch, d/p/lp1903300/0003-networkctl-Add-support-to-display-VXLan-remote-addre.patch: set vxlan multicast group when specified (LP: #1903300) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9deff4b7c5495dbe738561ca47daf3756df9fcde * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a73c51d0df284dcc38e6924d40eed810554bab2e * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ec7ba2358aa68d8d6276ed56ef91caafc287cecf * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5481fececdb3cb35ca7118598cad537681b5ff14 -- Dan Streetman Wed, 06 Jan 2021 15:47:39 -0500 ** Changed in: systemd (Ubuntu Focal) Status: Fix Committed => 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/1905044 Title: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: Fix Released Bug description: [impact] autopkgtest failure when running with 5.8 kernel, if systemd is built with earlier kernel (e.g. 5.4) [test case] see autopkgtest results, e.g. links in original description below [regression potential] as this only fixes a test case, any regression would likely result in an incorrectly passing, or incorrectly failing, test. [scope] this is needed for b/f/g/h. this bug was introduced by upstream commit 23cc81e7c22 which first added testing for 'invalid' cap numbers, but incorrectly using capability_list_length() instead of cap_last_cap(). That commit was first included in v236, so this bug does not exist before Bionic. this is fixed upstream by commit ebc815cd1c647faa934a446ceea91ff4bc9dffa4, which was first included in v247, so this is needed for h and earlier. Also note that even though the 5.8 kernel is not planned to be released for Bionic, this test also runs at build time, and since the LP build farm builds inside chroots, if the build farm ever moved up to Focal with a 5.8 kernel, the build of systemd for Bionic would start failing (since it would still be building using the older kernel headers, inside the chroot), so this does need to be fixed in Bionic
[Touch-packages] [Bug 1905245] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- 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/1905245 Title: "Failed to parse bus message: Invalid argument" with Linux 5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show' [test case] install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel. Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it: ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor Failed to parse bus message: Invalid argument the command should correctly show the value, e.g.: $ systemctl show -p CapabilityBoundingSet apparmor CapabilityBoundingSet=cap_chown cap_dac_override ...etc... [regression potential] a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services. [scope] this is needed only in focal and bionic. This is fixed upstream by PR 16424: https://github.com/systemd/systemd/pull/16424 which was first included in v246, so this is already fixed in groovy and later. This was introduced upstream in systemd by commit 52610b020c077ee769c6923249f7e6c4e99d2980 which was first included in v235, so this bug does not exist in Xenial. This bug will reproduce on any system running under the 5.8 kernel, with the new capability, if the systemd binary was compiled with kernel headers that do not include the new capability. This means this is reproducable on bare-metal/vm instances running 5.8, as well as containers on hosts running 5.8. Therefore, while bionic may not ever receive a new kernel with added capability, it still needs to be patched to avoid the bug on a bionic container running on a host with the 5.8 kernel. [other info] there is a testcase-only related bug 1905044 [original description] When I run `systemctl show myservice.service`, I get the following error message: Failed to parse bus message: Invalid argument systemd version: 245.4-4ubuntu3.3 linux version: 5.8.0-29-generic #31~20.04.1-Ubuntu (From linux-generic-hwe-20.04-edge) This is a bug that has been fixed in Debian. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926 Please can we port the fix to the ubuntu 20.04 version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905245/+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 1905245] Re: "Failed to parse bus message: Invalid argument" with Linux 5.8
This bug was fixed in the package systemd - 245.4-4ubuntu3.4 --- systemd (245.4-4ubuntu3.4) focal; urgency=medium * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch, d/p/lp1905245/0002-basic-capability-util-let-cap_last_cap-return-unsign.patch, d/p/lp1905245/0003-basic-cap-list-reduce-scope-of-variables.patch: - print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5cd98102e16a6e4acc1444b10db3308d87930933 * d/p/lp1890448-hwdb-Add-EliteBook-to-use-micmute-hotkey.patch: Add EliteBook to use micmute hotkey (LP: #1890448) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=238c8c1a7b9d75f69bdeafb1d55f1faf00acb063 * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=83df4fc182f8ffe87256f5d7c4b49cee5192529a * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff21f41e624d9e603f3be463846ce981a433842a * d/p/lp1903300/0001-network-VXLan-fix-adding-Group-address.patch, d/p/lp1903300/0002-network-VXLan-Add-support-for-remote-address.patch, d/p/lp1903300/0003-networkctl-Add-support-to-display-VXLan-remote-addre.patch: set vxlan multicast group when specified (LP: #1903300) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9deff4b7c5495dbe738561ca47daf3756df9fcde * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a73c51d0df284dcc38e6924d40eed810554bab2e * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ec7ba2358aa68d8d6276ed56ef91caafc287cecf * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5481fececdb3cb35ca7118598cad537681b5ff14 -- Dan Streetman Wed, 06 Jan 2021 15:47:39 -0500 ** Changed in: systemd (Ubuntu Focal) Status: Fix Committed => 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/1905245 Title: "Failed to parse bus message: Invalid argument" with Linux 5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Released Bug description: [impact] newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show' [test case] install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel. Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it: ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor Failed to parse bus message: Invalid argument the command should correctly show the value, e.g.: $ systemctl show -p CapabilityBoundingSet apparmor CapabilityBoundingSet=cap_chown cap_dac_override ...etc... [regression potential] a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services. [scope] this is needed only in focal and bionic. This is fixed upstream by PR 16424: https://github.com/systemd/systemd/pull/16424 which was first included in v246, so this is already fixed in groovy and
[Touch-packages] [Bug 1907306] Re: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind
This bug was fixed in the package systemd - 245.4-4ubuntu3.4 --- systemd (245.4-4ubuntu3.4) focal; urgency=medium * d/p/lp1905245/0001-basic-cap-list-parse-print-numerical-capabilities.patch, d/p/lp1905245/0002-basic-capability-util-let-cap_last_cap-return-unsign.patch, d/p/lp1905245/0003-basic-cap-list-reduce-scope-of-variables.patch: - print number of unknown capabilities instead of failing (LP: #1905245) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5cd98102e16a6e4acc1444b10db3308d87930933 * d/p/lp1890448-hwdb-Add-EliteBook-to-use-micmute-hotkey.patch: Add EliteBook to use micmute hotkey (LP: #1890448) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=238c8c1a7b9d75f69bdeafb1d55f1faf00acb063 * d/extra/dhclient-enter-resolved-hook: suppress output of cmp command in dhclient hook (LP: #1878955) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=83df4fc182f8ffe87256f5d7c4b49cee5192529a * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff21f41e624d9e603f3be463846ce981a433842a * d/p/lp1903300/0001-network-VXLan-fix-adding-Group-address.patch, d/p/lp1903300/0002-network-VXLan-Add-support-for-remote-address.patch, d/p/lp1903300/0003-networkctl-Add-support-to-display-VXLan-remote-addre.patch: set vxlan multicast group when specified (LP: #1903300) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9deff4b7c5495dbe738561ca47daf3756df9fcde * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a73c51d0df284dcc38e6924d40eed810554bab2e * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ec7ba2358aa68d8d6276ed56ef91caafc287cecf * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5481fececdb3cb35ca7118598cad537681b5ff14 -- Dan Streetman Wed, 06 Jan 2021 15:47:39 -0500 ** Changed in: systemd (Ubuntu Focal) Status: Fix Committed => 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/1907306 Title: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind Status in systemd: Fix Released Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: In Progress Bug description: [impact] networkd dhcpv4 client never attempts more than 2 renew and 2 rebind [test case] configure an interface to use dhcpv4; acquire a dhcpv4 address, then stop the dhcpv4 server, and wait for the networkd client to perform its renewals and rebinds before expiring the lease using a 20 minute lease time as an example (all times are approximate due to RFC-mandated random 'fuzz' time of -1 to +1 sec): the current behavior would be to sent renew requests at: 10:00 13:45 and then rebind requests at: 17:30 18:45 then the lease would expire at 20:00 the correct/new behavior should be renew requests at: 10:00 13:45 15:37 16:37 and then rebind requests at: 17:30 18:45 19:45 and then lease expiration at 20:00. longer lease times would increase the number of retransmissions. [regression potential] any regression would likely result in problems receiving and/or maintaining a dhcpv4 address [scope] this is needed in b/f/g/h. this was fixed upstream in: https://github.com/systemd/systemd/pull/17908 that was just added, so this is not fixed in any ubuntu release yet. technically, this is needed in x as well,
[Touch-packages] [Bug 1892358] Re: autopkgtest success rate dropped inhibiting proposed migration
This bug was fixed in the package systemd - 246.6-1ubuntu1.1 --- systemd (246.6-1ubuntu1.1) groovy; urgency=medium [ Dan Streetman ] * d/t/boot-smoke: update test to avoid false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=205c30ca53b0e421db28bb56afaf5f88650ce592 * d/t/boot-and-services: remove unneeded test lines (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=71853082af4e668996db574915c5a156f9897fd3 * d/t/systemd-fsckd: rewrite test to try to fix false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6ae6be039ec582410769d2d6d131e12bdcd19a68 * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=84a4832f5f7d4f939c1c78c6be4c3f9e05cd7f59 * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=0a96dc16ac00e90cd3904e6d490d676b9bb98f1f * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=7183e2ef4758ce47b152dec735e7d213d6003e37 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=3d0ea66f0db4a204759fa0005f6f27579ee4195a [ Balint Reczey ] * d/t/systemd-fsckd: Plymouth-start stays active in 20.10 and later (LP: #1908067) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=e3ddd09301c8bdaa59b4fe54d7906f609552370d -- Dan Streetman Wed, 06 Jan 2021 15:40:39 -0500 ** Changed in: systemd (Ubuntu Groovy) Status: Fix Committed => 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/1892358 Title: autopkgtest success rate dropped inhibiting proposed migration Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Released Bug description: [impact] autopkgtests are failing/flaky and prevent other packages from migrating to -updates [test case] check autopkgtest history [regression potential] in regard to the changed test cases, any regression would likely result in either an incorrectly passed test, or an incorrectly failed test. [scope] for systemd, this is needed for x, b, and f. tests in g appear to be mostly stable, but I've opened MR (linked from this bug) to update the tests there as well. i don't plan to update x, as it's reaching ESM in ~6 months, and backporting the test fixes is more work than just a simple code copy, since there are additional differences/changes needed in the older version of systemd (and python3). the failing/flaky tests in x have been like that forever, and people have just retried them; we can keep retrying them until x moves into ESM next year. [original description] Hi, we had such cases in the past like bug 1817721 for bionic and maybe bug 1892130 is about the same as well. There were more but I didn't want to search for all of them - what I checked is that there are no open ones clearly pointing out the recent further drop in already flaky subtests. In particular the tests "tests-in-lxd" and "systemd-fsckd" were known to be flaky before, but got even worse. Here stats of the last 40 runs, it might be a coincidences that this is after 246-2ubuntu1 landed. Could as well be any other change groovy amd64 tests-in-lxd (F 42% S 0% B 10% => P 45%/) BFFFBFF.B.F.F...FBF build-login(F 0% S 0% B 10% => P 87%/) B...B...BB. unit-config(F 0% S 0% B 10% => P 87%/)
[Touch-packages] [Bug 1902960] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- 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/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases Status in cloud-images: New Status in systemd: New Status in cloud-init package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Focal: Incomplete Status in systemd source package in Focal: Fix Committed Status in cloud-init source package in Groovy: Incomplete Status in systemd source package in Groovy: Fix Released Bug description: [impact] on boot of a specific azure instance, the ID_NET_DRIVER parameter of the instance's eth0 interface is not set. That leads to a failure of systemd-networkd to take control of the interface after a restart of systemd-networkd, which results in DNS failures (at first) and eventually complete loss of networking (once the DHCP lease expires). [test case] this occurs on first boot of an instance using the specific image; it is not reproducable using the latest ubuntu image nor any reboot of the affected image, and it has not been reproducable (for me) when using debug-enabled images based on the affected image. So, while the problem is reproducable using the specific image in question, it's not possible to verify the fix since any change to the image removes reproducability. however, while the problem itself can't be reproduced and then verified, if the assumption is correct (that the 'add' uevent is being missed on boot), that is possible to test and verify: $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc $ sudo rm /run/udev/data/n2 (note, change 'n2' to whichever network interface index is correct) $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER $ sudo udevadm trigger -c change /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER (note the 'change' uevent did not populate ID_NET_DRIVER property) $ sudo udevadm trigger -c add /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc (note the 'add' uevent did populate ID_NET_DRIVER) the test verification should result in ID_NET_DRIVER being populated for a 'change' uevent. [regression potential] any regression would likely involve problems with systemd-udevd processing 'change' events from network devices, and/or incorrect udevd device properties. [scope] this is needed only for focal and groovy. this is fixed by upstream commit e0e789c1e97 which is first included in v247, so this is fixed already in hirsute. while this commit is not included in bionic, due to the difficult nature of reproducing (and verifying) this, and the fact it has only been seen once on a focal image, I don't think it's appropriate to SRU to bionic at this point; possibly it may be appropriate if this is ever reproduced with a bionic image. [other info] note that this bug's subject and description, as well as the upstream systemd bug subject and description, talk about the problem being DNS resolution. However that is strictly a side-effect of the real problem and is not the actual issue. [original description] The systemd upgrade 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to have broken DNS resolution across much of our Azure fleet earlier today. We ended up mitigating this by forcing reboots on the associated instances, no combination of networkctl reload, reconfigure, systemctl daemon-reexec, systemctl daemon-reload, netplan generate, netplan apply would get resolvectl to have a DNS server again. The main symptom appears to have been systemd-networkd believing it wasn't managing the eth0 interfaces: ubuntu@machine-1:~$ sudo networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 etherroutableunmanaged 2 links listed. Which eventually made them lose their DNS resolvers: ubuntu@machine-1:~$ sudo resolvectl dns Global: Link 2 (eth0): After rebooting, we see this behaving properly: ubuntu@machine-1:~$ sudo networkctl list IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 etherroutable
[Touch-packages] [Bug 1881947] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- 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/1881947 Title: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. Status in systemd: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: In Progress Bug description: [Impact] * Autopkgtest fails due to corrupted journal file [Test Case] * Observe autopkgtest root-unittests not failing with: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. [Where problems could occur] * The change has no impact on the systemd binary packages. The relaxed test could hide a journal corruption problem, but it seems the corrupted journal files occur only on arm64 probably due to arm64 reboots being resets: LP: #1748280. [Original Bug Text] Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz [...] PASS: test-journal-enum == test-journal-flush === Root directory /var/log/journal removed. Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed. mmap cache statistics: 739 hit, 5 miss journal_file_copy_entry failed: Bad message Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. FAIL: test-journal-flush (code: 134) Aborted (core dumped) == test-journal-importer === [...] autopkgtest [07:17:29]: summary timedatedPASS hostnamedPASS localed-locale PASS localed-x11-keymap PASS logind PASS unit-config PASS storage PASS networkd-test.py PASS build-login PASS boot-and-servicesPASS udev PASS root-unittests FAIL non-zero exit status 134 upstream PASS boot-smoke PASS systemd-fsckdPASS Exit request sent. [...] To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1881947/+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 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
This bug was fixed in the package systemd - 246.6-1ubuntu1.1 --- systemd (246.6-1ubuntu1.1) groovy; urgency=medium [ Dan Streetman ] * d/t/boot-smoke: update test to avoid false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=205c30ca53b0e421db28bb56afaf5f88650ce592 * d/t/boot-and-services: remove unneeded test lines (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=71853082af4e668996db574915c5a156f9897fd3 * d/t/systemd-fsckd: rewrite test to try to fix false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6ae6be039ec582410769d2d6d131e12bdcd19a68 * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=84a4832f5f7d4f939c1c78c6be4c3f9e05cd7f59 * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=0a96dc16ac00e90cd3904e6d490d676b9bb98f1f * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=7183e2ef4758ce47b152dec735e7d213d6003e37 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=3d0ea66f0db4a204759fa0005f6f27579ee4195a [ Balint Reczey ] * d/t/systemd-fsckd: Plymouth-start stays active in 20.10 and later (LP: #1908067) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=e3ddd09301c8bdaa59b4fe54d7906f609552370d -- Dan Streetman Wed, 06 Jan 2021 15:40:39 -0500 ** Changed in: systemd (Ubuntu Groovy) Status: Fix Committed => 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/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases Status in cloud-images: New Status in systemd: New Status in cloud-init package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Focal: Incomplete Status in systemd source package in Focal: Fix Committed Status in cloud-init source package in Groovy: Incomplete Status in systemd source package in Groovy: Fix Released Bug description: [impact] on boot of a specific azure instance, the ID_NET_DRIVER parameter of the instance's eth0 interface is not set. That leads to a failure of systemd-networkd to take control of the interface after a restart of systemd-networkd, which results in DNS failures (at first) and eventually complete loss of networking (once the DHCP lease expires). [test case] this occurs on first boot of an instance using the specific image; it is not reproducable using the latest ubuntu image nor any reboot of the affected image, and it has not been reproducable (for me) when using debug-enabled images based on the affected image. So, while the problem is reproducable using the specific image in question, it's not possible to verify the fix since any change to the image removes reproducability. however, while the problem itself can't be reproduced and then verified, if the assumption is correct (that the 'add' uevent is being missed on boot), that is possible to test and verify: $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc $ sudo rm /run/udev/data/n2 (note, change 'n2' to whichever network interface index is correct) $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER $ sudo udevadm trigger -c change /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER (note the 'change' uevent did not populate ID_NET_DRIVER property) $ sudo udevadm trigger -c add /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E:
[Touch-packages] [Bug 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.
This bug was fixed in the package systemd - 246.6-1ubuntu1.1 --- systemd (246.6-1ubuntu1.1) groovy; urgency=medium [ Dan Streetman ] * d/t/boot-smoke: update test to avoid false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=205c30ca53b0e421db28bb56afaf5f88650ce592 * d/t/boot-and-services: remove unneeded test lines (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=71853082af4e668996db574915c5a156f9897fd3 * d/t/systemd-fsckd: rewrite test to try to fix false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6ae6be039ec582410769d2d6d131e12bdcd19a68 * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=84a4832f5f7d4f939c1c78c6be4c3f9e05cd7f59 * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=0a96dc16ac00e90cd3904e6d490d676b9bb98f1f * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=7183e2ef4758ce47b152dec735e7d213d6003e37 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=3d0ea66f0db4a204759fa0005f6f27579ee4195a [ Balint Reczey ] * d/t/systemd-fsckd: Plymouth-start stays active in 20.10 and later (LP: #1908067) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=e3ddd09301c8bdaa59b4fe54d7906f609552370d -- Dan Streetman Wed, 06 Jan 2021 15:40:39 -0500 ** Changed in: systemd (Ubuntu Groovy) Status: Fix Committed => 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/1881947 Title: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. Status in systemd: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: In Progress Bug description: [Impact] * Autopkgtest fails due to corrupted journal file [Test Case] * Observe autopkgtest root-unittests not failing with: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. [Where problems could occur] * The change has no impact on the systemd binary packages. The relaxed test could hide a journal corruption problem, but it seems the corrupted journal files occur only on arm64 probably due to arm64 reboots being resets: LP: #1748280. [Original Bug Text] Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz [...] PASS: test-journal-enum == test-journal-flush === Root directory /var/log/journal removed. Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed. mmap cache statistics: 739 hit, 5 miss journal_file_copy_entry failed: Bad message Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. FAIL: test-journal-flush (code: 134) Aborted (core dumped) == test-journal-importer === [...] autopkgtest [07:17:29]: summary timedatedPASS hostnamedPASS localed-locale PASS localed-x11-keymap PASS logind PASS unit-config PASS storage PASS networkd-test.py PASS build-login PASS boot-and-servicesPASS udev PASS root-unittests FAIL non-zero exit
[Touch-packages] [Bug 1905044] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- 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/1905044 Title: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: Fix Released Bug description: [impact] autopkgtest failure when running with 5.8 kernel, if systemd is built with earlier kernel (e.g. 5.4) [test case] see autopkgtest results, e.g. links in original description below [regression potential] as this only fixes a test case, any regression would likely result in an incorrectly passing, or incorrectly failing, test. [scope] this is needed for b/f/g/h. this bug was introduced by upstream commit 23cc81e7c22 which first added testing for 'invalid' cap numbers, but incorrectly using capability_list_length() instead of cap_last_cap(). That commit was first included in v236, so this bug does not exist before Bionic. this is fixed upstream by commit ebc815cd1c647faa934a446ceea91ff4bc9dffa4, which was first included in v247, so this is needed for h and earlier. Also note that even though the 5.8 kernel is not planned to be released for Bionic, this test also runs at build time, and since the LP build farm builds inside chroots, if the build farm ever moved up to Focal with a 5.8 kernel, the build of systemd for Bionic would start failing (since it would still be building using the older kernel headers, inside the chroot), so this does need to be fixed in Bionic systemd as well. [other info] there is a non-test bug related to this in bug 1905245 [original description] Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20201117_174614_4ece6@/log.gz arm64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20201117_221555_48b91@/log.gz ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/ppc64el/s/systemd/20201117_175806_e779f@/log.gz s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/s/systemd/20201117_153051_90e7e@/log.gz The failing testcases are: - root-unittests Assertion 'capability_set_to_string_alloc(c, ) == 0' failed at src/test/test-cap-list.c:60, funct ion test_capability_set_one(). Aborting. FAIL: test-cap-list (code: 134) - upstream TEST-24-UNIT-TESTS: --- test-cap-list begin --- Assertion 'capability_set_to_string_alloc(c, ) == 0' failed at src/test/test-cap-list.c:60, funct ion test_capability_set_one(). Aborting. --- test-cap-list end --- Both seem to be failing with the same assertion. These tests are successful on Focal with linux 5.4, therefore they would regress when upgrading the kernel from 5.4 to 5.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905044/+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 1905044] Re: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8
This bug was fixed in the package systemd - 246.6-1ubuntu1.1 --- systemd (246.6-1ubuntu1.1) groovy; urgency=medium [ Dan Streetman ] * d/t/boot-smoke: update test to avoid false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=205c30ca53b0e421db28bb56afaf5f88650ce592 * d/t/boot-and-services: remove unneeded test lines (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=71853082af4e668996db574915c5a156f9897fd3 * d/t/systemd-fsckd: rewrite test to try to fix false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6ae6be039ec582410769d2d6d131e12bdcd19a68 * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=84a4832f5f7d4f939c1c78c6be4c3f9e05cd7f59 * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=0a96dc16ac00e90cd3904e6d490d676b9bb98f1f * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=7183e2ef4758ce47b152dec735e7d213d6003e37 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=3d0ea66f0db4a204759fa0005f6f27579ee4195a [ Balint Reczey ] * d/t/systemd-fsckd: Plymouth-start stays active in 20.10 and later (LP: #1908067) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=e3ddd09301c8bdaa59b4fe54d7906f609552370d -- Dan Streetman Wed, 06 Jan 2021 15:40:39 -0500 ** Changed in: systemd (Ubuntu Groovy) Status: Fix Committed => 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/1905044 Title: systemd 245.4-4ubuntu3.3 ADT test failure with linux-hwe-5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: Fix Released Bug description: [impact] autopkgtest failure when running with 5.8 kernel, if systemd is built with earlier kernel (e.g. 5.4) [test case] see autopkgtest results, e.g. links in original description below [regression potential] as this only fixes a test case, any regression would likely result in an incorrectly passing, or incorrectly failing, test. [scope] this is needed for b/f/g/h. this bug was introduced by upstream commit 23cc81e7c22 which first added testing for 'invalid' cap numbers, but incorrectly using capability_list_length() instead of cap_last_cap(). That commit was first included in v236, so this bug does not exist before Bionic. this is fixed upstream by commit ebc815cd1c647faa934a446ceea91ff4bc9dffa4, which was first included in v247, so this is needed for h and earlier. Also note that even though the 5.8 kernel is not planned to be released for Bionic, this test also runs at build time, and since the LP build farm builds inside chroots, if the build farm ever moved up to Focal with a 5.8 kernel, the build of systemd for Bionic would start failing (since it would still be building using the older kernel headers, inside the chroot), so this does need to be fixed in Bionic systemd as well. [other info] there is a non-test bug related to this in bug 1905245 [original description] Testing failed on: amd64: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20201117_174614_4ece6@/log.gz arm64:
[Touch-packages] [Bug 1907306] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- 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/1907306 Title: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind Status in systemd: Fix Released Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: In Progress Bug description: [impact] networkd dhcpv4 client never attempts more than 2 renew and 2 rebind [test case] configure an interface to use dhcpv4; acquire a dhcpv4 address, then stop the dhcpv4 server, and wait for the networkd client to perform its renewals and rebinds before expiring the lease using a 20 minute lease time as an example (all times are approximate due to RFC-mandated random 'fuzz' time of -1 to +1 sec): the current behavior would be to sent renew requests at: 10:00 13:45 and then rebind requests at: 17:30 18:45 then the lease would expire at 20:00 the correct/new behavior should be renew requests at: 10:00 13:45 15:37 16:37 and then rebind requests at: 17:30 18:45 19:45 and then lease expiration at 20:00. longer lease times would increase the number of retransmissions. [regression potential] any regression would likely result in problems receiving and/or maintaining a dhcpv4 address [scope] this is needed in b/f/g/h. this was fixed upstream in: https://github.com/systemd/systemd/pull/17908 that was just added, so this is not fixed in any ubuntu release yet. technically, this is needed in x as well, however I don't plan to backport to x since 1) it reaches ESM soon and 2) the default network management tool in x is ifupdown, not systemd-networkd. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1907306/+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 1907306] Re: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind
This bug was fixed in the package systemd - 246.6-1ubuntu1.1 --- systemd (246.6-1ubuntu1.1) groovy; urgency=medium [ Dan Streetman ] * d/t/boot-smoke: update test to avoid false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=205c30ca53b0e421db28bb56afaf5f88650ce592 * d/t/boot-and-services: remove unneeded test lines (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=71853082af4e668996db574915c5a156f9897fd3 * d/t/systemd-fsckd: rewrite test to try to fix false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6ae6be039ec582410769d2d6d131e12bdcd19a68 * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=84a4832f5f7d4f939c1c78c6be4c3f9e05cd7f59 * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=0a96dc16ac00e90cd3904e6d490d676b9bb98f1f * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=7183e2ef4758ce47b152dec735e7d213d6003e37 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=3d0ea66f0db4a204759fa0005f6f27579ee4195a [ Balint Reczey ] * d/t/systemd-fsckd: Plymouth-start stays active in 20.10 and later (LP: #1908067) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=e3ddd09301c8bdaa59b4fe54d7906f609552370d -- Dan Streetman Wed, 06 Jan 2021 15:40:39 -0500 ** Changed in: systemd (Ubuntu Groovy) Status: Fix Committed => 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/1907306 Title: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind Status in systemd: Fix Released Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Released Status in systemd source package in Hirsute: In Progress Bug description: [impact] networkd dhcpv4 client never attempts more than 2 renew and 2 rebind [test case] configure an interface to use dhcpv4; acquire a dhcpv4 address, then stop the dhcpv4 server, and wait for the networkd client to perform its renewals and rebinds before expiring the lease using a 20 minute lease time as an example (all times are approximate due to RFC-mandated random 'fuzz' time of -1 to +1 sec): the current behavior would be to sent renew requests at: 10:00 13:45 and then rebind requests at: 17:30 18:45 then the lease would expire at 20:00 the correct/new behavior should be renew requests at: 10:00 13:45 15:37 16:37 and then rebind requests at: 17:30 18:45 19:45 and then lease expiration at 20:00. longer lease times would increase the number of retransmissions. [regression potential] any regression would likely result in problems receiving and/or maintaining a dhcpv4 address [scope] this is needed in b/f/g/h. this was fixed upstream in: https://github.com/systemd/systemd/pull/17908 that was just added, so this is not fixed in any ubuntu release yet. technically, this is needed in x as well, however I don't plan to backport to x since 1) it reaches ESM soon and 2) the default network management tool in x is ifupdown, not systemd-networkd. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1907306/+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 1908067] Update Released
The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- 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/1908067 Title: systemd-fsckd test fails on groovy checking plymouth-start isactive Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Groovy: Fix Released Bug description: [impact] systemd-fsckd test fails on groovy because plymouth-start service is active [test case] check autopkgtest logs of systemd-fsckd test case on groovy [regression potential] incorrectly passed, or failed, systemd-fsckd test [scope] this is needed only for groovy. the plymouth-start.service did not include RemainAfterExit=true before groovy, so the service is expected to be inactive when checked by the test before groovy. this is already fixed in hirsute: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c46eda821e97df5595a4cdc5f5c41a9b49a51745 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1908067/+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 1908067] Re: systemd-fsckd test fails on groovy checking plymouth-start isactive
This bug was fixed in the package systemd - 246.6-1ubuntu1.1 --- systemd (246.6-1ubuntu1.1) groovy; urgency=medium [ Dan Streetman ] * d/t/boot-smoke: update test to avoid false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=205c30ca53b0e421db28bb56afaf5f88650ce592 * d/t/boot-and-services: remove unneeded test lines (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=71853082af4e668996db574915c5a156f9897fd3 * d/t/systemd-fsckd: rewrite test to try to fix false negatives (LP: #1892358) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6ae6be039ec582410769d2d6d131e12bdcd19a68 * d/p/lp1905044-test-use-cap_last_cap-for-max-supported-cap-number-n.patch: test: use cap_last_cap() instead of capability_list_length() (LP: #1905044) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=84a4832f5f7d4f939c1c78c6be4c3f9e05cd7f59 * d/p/lp1907306/0001-sd-dhcp-client-don-t-log-timeouts-if-already-expired.patch, d/p/lp1907306/0002-sd-dhcp-client-track-dhcp4-t1-t2-expire-times.patch, d/p/lp1907306/0003-sd-dhcp-client-add-RFC2131-retransmission-details.patch, d/p/lp1907306/0004-sd-dhcp-client-simplify-dhcp4-t1-t2-parsing.patch, d/p/lp1907306/0005-sd-dhcp-client-correct-dhcpv4-renew-rebind-retransmi.patch, d/p/lp1907306/0006-sd-dhcp-client-correct-retransmission-timeout-to-mat.patch, d/p/lp1907306/0007-test-network-increase-wait_online-timeout-to-handle-.patch, d/p/lp1907306/0008-sd-dhcp-client-fix-renew-rebind-timeout-calculation-.patch: Send correct number of dhcpv4 renew and rebind requests (LP: #1907306) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=0a96dc16ac00e90cd3904e6d490d676b9bb98f1f * d/p/lp1902960-udev-re-assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch: Run net_setup_link on 'change' uevents (LP: #1902960) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=7183e2ef4758ce47b152dec735e7d213d6003e37 * d/t/root-unittests: Remove any corrupt journal files (LP: #1881947) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=3d0ea66f0db4a204759fa0005f6f27579ee4195a [ Balint Reczey ] * d/t/systemd-fsckd: Plymouth-start stays active in 20.10 and later (LP: #1908067) https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=e3ddd09301c8bdaa59b4fe54d7906f609552370d -- Dan Streetman Wed, 06 Jan 2021 15:40:39 -0500 ** Changed in: systemd (Ubuntu Groovy) Status: Fix Committed => 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/1908067 Title: systemd-fsckd test fails on groovy checking plymouth-start isactive Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Groovy: Fix Released Bug description: [impact] systemd-fsckd test fails on groovy because plymouth-start service is active [test case] check autopkgtest logs of systemd-fsckd test case on groovy [regression potential] incorrectly passed, or failed, systemd-fsckd test [scope] this is needed only for groovy. the plymouth-start.service did not include RemainAfterExit=true before groovy, so the service is expected to be inactive when checked by the test before groovy. this is already fixed in hirsute: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c46eda821e97df5595a4cdc5f5c41a9b49a51745 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1908067/+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 1911456] Re: Can't receive files over bluetooth unless settings dialog is open
** Package changed: gnome-control-center (Ubuntu) => gnome-user-share (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1911456 Title: Can't receive files over bluetooth unless settings dialog is open Status in bluez package in Ubuntu: New Status in gnome-user-share package in Ubuntu: New Bug description: On 18.04 I could send files from my phone to my laptop at any time. On 20.04 I can't get files to be accepted by the laptop over bluetooth. After much frustration and experimenting, I figured out that it will work, but only if the bluetooth settings dialog is open. If the settings dialog is not open, the incoming file is rejected. If the dialog is closed after the file transfer begins, the transfer continues but the file is discarded when the transfer is complete. This is very frustrating. I need to be able to send files (mostly photos and videos) from my phone to my laptop without having to open the settings dialog on the laptop, just like I could before upgrading. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1911456/+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 1896098] Re: Lenovo P1G3 - unable to select system speakers when headset plugged into audio jack
** Tags added: oem-priority originate-from-1912136 sutton -- 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/1896098 Title: Lenovo P1G3 - unable to select system speakers when headset plugged into audio jack Status in OEM Priority Project: New Status in pulseaudio package in Ubuntu: Invalid Bug description: I suspect this is a pulseaudio or alsa bug. Our test team reported this: 1. Prepare Padme-3 machine and Install Ubuntu_20.04 OS . 2. Boot system. 3. Play audio or video file. 4. Open Settings > Sound. 5. Hot attach headset. 6. Notice that headset is selected as output device in sound settings and sound can be heard from headset => EXPECTED 7. While playback, select Internal Speaker as output device => KEYPOINT 9. Notice:SUT havo no sound from Internal Speakers => PROBLEM I was able to confirm this - it seems with the headphones connected that I can't select the system speakers. If I don't have headphones connected I can switch between dock audio and system speakers correctly - so it's just related to the audio jack Thanks Mark To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1896098/+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 1912162] Re: NetworkManager managed wifi can't connect
Just to make it explicitly clear - I think there are 2 bugs involved - 1 is related to driver/firmware on older 5.4 kernel since on that version I couldn't get the adapter to connect even with the /etc/network/interfaces based configuration, but on kernel 5.10 it works. This bug deals only with not being able to connect via NetworkManager to my wifi even on 5.10. Once this is resolved I can go back and try to do bisection of the kernel which patch enables the /etc/networking/interfaces configuration to work. -- 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/1912162 Title: NetworkManager managed wifi can't connect Status in network-manager package in Ubuntu: New Bug description: My computer has an built-in intel ax200 adapter (the motherboard is asock taichi x570). With the latest stable 5.4 kernel on Ubuntu Focal 20.04 I cannot get the card to connect to my home wifi (2.4ghz). The errors I get are : iwlwifi :05:00.0: No beacon heard and the time event is over already... wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) Initially I thought this could be due to a problem with the iwlwifi driver and the firmware used. I upgraded to a custom-build (using ubuntu's configuration) 5.10 kernel And now the errors I was getting were: [нд яну 17 22:01:33 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:33 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:33 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) [нд яну 17 22:01:34 2021] wlp5s0: authentication with 30:b5:c2:75:a4:ce timed out [нд яну 17 22:01:35 2021] wlp5s0: authenticate with 30:b5:c2:75:a4:ce [нд яну 17 22:01:35 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 1/3) [нд яну 17 22:01:36 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:36 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:36 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) [нд яну 17 22:01:37 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:37 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:37 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) The change of message is because newer versions of the driver/firmware have moved part of the processing in firmware. At this point I was willing to accept this is an issue with the kernel. However, I added the following configuration to /etc/network/interfaces: allow-hotplug wlp5s0 iface wlp5s0 inet dhcp wpa-ssid HOME wpa-psk wpa-debug-level 2 And what do you know - I was able to connect to my home wifi with no problems. I'm attaching the output of wpa_supplicant run with -dd from both the /etc/network/interfaces-based configuration (wpa_supplicant_working) and from the NetworkManager managed one ( I have edited /lib/systemd/system/wpa_supplicant.service to include -f /var/log/wpa_supplicant -dd) options. I wasn't able to figure any glaring differences between the flows of the two. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1912162/+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 1912162] Re: NetworkManager managed wifi can't connect
Here's the output wpa_supplicant as used from NetworkManager and under which my intel ax200 based interface cannot connect. ** Attachment added: "wpa-supllicant-broken" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1912162/+attachment/5454051/+files/wpa-supllicant-broken -- 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/1912162 Title: NetworkManager managed wifi can't connect Status in network-manager package in Ubuntu: New Bug description: My computer has an built-in intel ax200 adapter (the motherboard is asock taichi x570). With the latest stable 5.4 kernel on Ubuntu Focal 20.04 I cannot get the card to connect to my home wifi (2.4ghz). The errors I get are : iwlwifi :05:00.0: No beacon heard and the time event is over already... wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) Initially I thought this could be due to a problem with the iwlwifi driver and the firmware used. I upgraded to a custom-build (using ubuntu's configuration) 5.10 kernel And now the errors I was getting were: [нд яну 17 22:01:33 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:33 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:33 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) [нд яну 17 22:01:34 2021] wlp5s0: authentication with 30:b5:c2:75:a4:ce timed out [нд яну 17 22:01:35 2021] wlp5s0: authenticate with 30:b5:c2:75:a4:ce [нд яну 17 22:01:35 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 1/3) [нд яну 17 22:01:36 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:36 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:36 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) [нд яну 17 22:01:37 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:37 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:37 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) The change of message is because newer versions of the driver/firmware have moved part of the processing in firmware. At this point I was willing to accept this is an issue with the kernel. However, I added the following configuration to /etc/network/interfaces: allow-hotplug wlp5s0 iface wlp5s0 inet dhcp wpa-ssid HOME wpa-psk wpa-debug-level 2 And what do you know - I was able to connect to my home wifi with no problems. I'm attaching the output of wpa_supplicant run with -dd from both the /etc/network/interfaces-based configuration (wpa_supplicant_working) and from the NetworkManager managed one ( I have edited /lib/systemd/system/wpa_supplicant.service to include -f /var/log/wpa_supplicant -dd) options. I wasn't able to figure any glaring differences between the flows of the two. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1912162/+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 1912162] [NEW] NetworkManager managed wifi can't connect
Public bug reported: My computer has an built-in intel ax200 adapter (the motherboard is asock taichi x570). With the latest stable 5.4 kernel on Ubuntu Focal 20.04 I cannot get the card to connect to my home wifi (2.4ghz). The errors I get are : iwlwifi :05:00.0: No beacon heard and the time event is over already... wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) Initially I thought this could be due to a problem with the iwlwifi driver and the firmware used. I upgraded to a custom-build (using ubuntu's configuration) 5.10 kernel And now the errors I was getting were: [нд яну 17 22:01:33 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:33 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:33 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) [нд яну 17 22:01:34 2021] wlp5s0: authentication with 30:b5:c2:75:a4:ce timed out [нд яну 17 22:01:35 2021] wlp5s0: authenticate with 30:b5:c2:75:a4:ce [нд яну 17 22:01:35 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 1/3) [нд яну 17 22:01:36 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:36 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:36 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) [нд яну 17 22:01:37 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:37 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:37 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) The change of message is because newer versions of the driver/firmware have moved part of the processing in firmware. At this point I was willing to accept this is an issue with the kernel. However, I added the following configuration to /etc/network/interfaces: allow-hotplug wlp5s0 iface wlp5s0 inet dhcp wpa-ssid HOME wpa-psk wpa-debug-level 2 And what do you know - I was able to connect to my home wifi with no problems. I'm attaching the output of wpa_supplicant run with -dd from both the /etc/network/interfaces-based configuration (wpa_supplicant_working) and from the NetworkManager managed one ( I have edited /lib/systemd/system/wpa_supplicant.service to include -f /var/log/wpa_supplicant -dd) options. I wasn't able to figure any glaring differences between the flows of the two. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Attachment added: "output of working wpa supplicant from ifupdown scripts" https://bugs.launchpad.net/bugs/1912162/+attachment/5454050/+files/wpa-supllicant-working -- 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/1912162 Title: NetworkManager managed wifi can't connect Status in network-manager package in Ubuntu: New Bug description: My computer has an built-in intel ax200 adapter (the motherboard is asock taichi x570). With the latest stable 5.4 kernel on Ubuntu Focal 20.04 I cannot get the card to connect to my home wifi (2.4ghz). The errors I get are : iwlwifi :05:00.0: No beacon heard and the time event is over already... wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) Initially I thought this could be due to a problem with the iwlwifi driver and the firmware used. I upgraded to a custom-build (using ubuntu's configuration) 5.10 kernel And now the errors I was getting were: [нд яну 17 22:01:33 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:33 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:33 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) [нд яну 17 22:01:34 2021] wlp5s0: authentication with 30:b5:c2:75:a4:ce timed out [нд яну 17 22:01:35 2021] wlp5s0: authenticate with 30:b5:c2:75:a4:ce [нд яну 17 22:01:35 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 1/3) [нд яну 17 22:01:36 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:36 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:36 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 2/3) [нд яну 17 22:01:37 2021] iwlwifi :05:00.0: No beacon heard and the session protection is over already... [нд яну 17 22:01:37 2021] wlp5s0: Connection to AP 30:b5:c2:75:a4:ce lost [нд яну 17 22:01:37 2021] wlp5s0: send auth to 30:b5:c2:75:a4:ce (try 3/3) The change of message is because newer
[Touch-packages] [Bug 1908167] Re: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic
tested the focal -proposed package on a lenovo machine (internal mic + internal spk) and a dell machine (only internal spk): Installed 20.04 on the machine, enable the -proposed ppa, run 'sudo apt dist-upgrade', check the pulseaudio version is 1:13.99.1-1ubuntu3.10: On the lenovo machine, plug a headset, the output changes to headphone and input changes to headset-microphone, output and input all works well, unplug the headset, the output changes back to spk and input changes back to internal mic. This fixed the regression of 1:13.99.1-1ubuntu3.9 On the Dell machine, plug a headset, the output changes to headphone and input changes to headset-microphone, output and input all works well, unplug the headset, the output changes back to spk and input changes back to blank. This fixed the regression of 1:13.99.1-1ubuntu3.9 and fixed the issue of "the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic" in the 1:13.99.1-1ubuntu3.8 verified done on focal. ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- 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/1908167 Title: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic Status in HWE Next: New Status in OEM Priority Project: New Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Focal: Fix Committed Status in pulseaudio source package in Groovy: Fix Committed Status in pulseaudio source package in Hirsute: Fix Released Bug description: [Impact] On the Dell AIO machines, there is no internal mic, after plugging a headset, users expect the headset-mic or headphone-mic could be selected automatically. But with the current rule, the headset-mic/headphone-mic will not be selected automatically and even users manually select them, they will not show up in the gnome sound setting, and users could not record sound by headset-mic/headphone-mic. [Fix] backport a patch from pulseaudio mergerequest, the patch is going to be merged to pulseaudio 14.1. This patch could be backported to hirsute without any change, but need to be changed if backport it to groovy and focal. [Test] With the old pulseaudio (prior to 1:13.99.1-1ubuntu3.10), plugging in a headset to the problematic Dell AIO machine will not automatically select headset-mic/headphone-mic, and they also do not show up in Gnome sound settings, leading to failure to record any sound. With the new proposed package, on those Dell AIO, plug a headset, open the gnome sound setting, the headset-mic is selected automatically, use the headset-mic to record the sound, the sound could be recorded and the sound quality is good. [Where problems could occur] This patch could change the policy of audio device switching, it will not affect all audio devices, but only the devices which has AVAIL_UNKNOWN available status, that means it has possibility to introduce the regression on headphone-mic ,headset-mic, internal mic and internal speaker's switching since they all has AVAIL_UNKNOWN status. For example, after unpluging the headset, the input device will not switch to internal mic automatically or after unplug the headphone, the output device will not switch to internal speaker automatically. But this possibility is very low, we have tested the patch on many Dell and Lenovo machines, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1908167/+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 1908167] Re: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic
tested the groovy -proposed package on a lenovo machine (internal mic + internal spk) and a dell machine (only internal spk): Installed groovy on the machine, enable the -proposed ppa, run 'sudo apt dist-upgrade', check the pulseaudio version is 1:13.99.2-1ubuntu2.3: On the lenovo machine, plug a headset, the output changes to headphone and input changes to headset-microphone, output and input all works well, unplug the headset, the output changes back to spk and input changes back to internal mic. This fixed the regression of 1:13.99.2-1ubuntu2.2 On the Dell machine, plug a headset, the output changes to headphone and input changes to headset-microphone, output and input all works well, unplug the headset, the output changes back to spk and input changes back to blank. This fixed the regression of 1:13.99.2-1ubuntu2.2 and fixed the issue of "the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic" in the 1:13.99.2-1ubuntu2.1 verified done on groovy. ** Tags removed: verification-needed-groovy ** Tags added: verification-done-groovy -- 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/1908167 Title: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic Status in HWE Next: New Status in OEM Priority Project: New Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Focal: Fix Committed Status in pulseaudio source package in Groovy: Fix Committed Status in pulseaudio source package in Hirsute: Fix Released Bug description: [Impact] On the Dell AIO machines, there is no internal mic, after plugging a headset, users expect the headset-mic or headphone-mic could be selected automatically. But with the current rule, the headset-mic/headphone-mic will not be selected automatically and even users manually select them, they will not show up in the gnome sound setting, and users could not record sound by headset-mic/headphone-mic. [Fix] backport a patch from pulseaudio mergerequest, the patch is going to be merged to pulseaudio 14.1. This patch could be backported to hirsute without any change, but need to be changed if backport it to groovy and focal. [Test] With the old pulseaudio (prior to 1:13.99.1-1ubuntu3.10), plugging in a headset to the problematic Dell AIO machine will not automatically select headset-mic/headphone-mic, and they also do not show up in Gnome sound settings, leading to failure to record any sound. With the new proposed package, on those Dell AIO, plug a headset, open the gnome sound setting, the headset-mic is selected automatically, use the headset-mic to record the sound, the sound could be recorded and the sound quality is good. [Where problems could occur] This patch could change the policy of audio device switching, it will not affect all audio devices, but only the devices which has AVAIL_UNKNOWN available status, that means it has possibility to introduce the regression on headphone-mic ,headset-mic, internal mic and internal speaker's switching since they all has AVAIL_UNKNOWN status. For example, after unpluging the headset, the input device will not switch to internal mic automatically or after unplug the headphone, the output device will not switch to internal speaker automatically. But this possibility is very low, we have tested the patch on many Dell and Lenovo machines, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1908167/+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
