[Touch-packages] [Bug 1916462] Re: dnsmasq failed to send packet: Network is unreachable
I've yesterday pinged the security Team as FYI on this. In the meanwhile by tracking the upstream list this seems to be the follow up fix: https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=141a26f979b4bc959d8e866a295e24f8cf456920 With the following being related https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=305cb79c5754d5554729b18a2c06fe7ce699687a It will fix the immediate issue, but compared to the past the SP will stay the same now, see this discussion. https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014735.html @Marc/Security - are you going to follow on on those CVE pushes with that fix or do we need a different plan of action? ** Changed in: dnsmasq (Ubuntu) Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1916462 Title: dnsmasq failed to send packet: Network is unreachable Status in dnsmasq package in Ubuntu: New Bug description: the log shows this: Feb 22 09:37:53 myserver dnsmasq[2259]: failed to send packet: Network is unreachable repeatedly and frequently. This is a known bug in dnsmasq and has been fixed upstream (according to the thread quoted below). Apparently it is IPv6 related and triggered by Windows and Mac clients. An extensive thread on the subject is here on the OpenWRT forum: https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq- multiple-vulnerabilities/85903/123 I think this has been reported in the fallout of the quoted security vulnerabilities. I don't think it is a security vulnerability in itself. dnsmasq version: 2.80-1.1ubuntu1.2 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: dnsmasq 2.80-1.1ubuntu1.2 Uname: Linux 5.4.98-219 armv7l ApportVersion: 2.20.11-0ubuntu27.16 Architecture: armhf CasperMD5CheckResult: skip Date: Mon Feb 22 09:34:12 2021 PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: dnsmasq UpgradeStatus: Upgraded to focal on 2020-11-15 (98 days ago) modified.conffile..etc.default.dnsmasq: [modified] mtime.conffile..etc.default.dnsmasq: 2018-06-27T16:10:40.086905 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1916462/+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 1916469] Re: Ubuntu universe Wayland problem
** No longer affects: ubuntu ** Summary changed: - Ubuntu universe Wayland problem + Apps don't use Wayland by default ** No longer affects: wayland (Ubuntu) ** Tags added: wayland-session ** Changed in: firefox (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1916469 Title: Apps don't use Wayland by default Status in firefox package in Ubuntu: Confirmed Status in qdirstat package in Ubuntu: New Status in telegram-desktop package in Ubuntu: New Status in vlc package in Ubuntu: New Bug description: The Ubuntu universe has a big Wayland problem! What does that mean? So a lot of packages in the Universe repository are not compiled with Wayland support which is really bad and would lead to bad performance after 21.04 comes out. Here are the following packages that I detected with wrong compilation: telegram-desktop (Wayland support work with snap version) qdirstat vlc kiwix firefox (everything works fine with this env variable set:"MOZ_ENABLE_WAYLAND=1") To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1916469/+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 1915870] Re: gnome session not starting (segfault with r300_dri.so)
Actually it looks likely to be https://gitlab.freedesktop.org/mesa/mesa/-/issues/3990 so let's track that for now. ** Also affects: mesa via https://gitlab.freedesktop.org/mesa/mesa/-/issues/3990 Importance: Unknown Status: Unknown ** Bug watch added: Red Hat Bugzilla #1908448 https://bugzilla.redhat.com/show_bug.cgi?id=1908448 ** Also affects: mesa (Fedora) via https://bugzilla.redhat.com/show_bug.cgi?id=1908448 Importance: Unknown Status: Unknown ** No longer affects: gnome-shell (Ubuntu) ** Changed in: mesa (Ubuntu) Status: Incomplete => Confirmed -- 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/1915870 Title: gnome session not starting (segfault with r300_dri.so) Status in Mesa: Unknown Status in mesa package in Ubuntu: Confirmed Status in mesa package in Fedora: Unknown Bug description: Graphical user interface is not coming up upon start. Only SSH is possible. lsb_release -rd: Description: Ubuntu 20.10 Release: 20.10 dmesg: [ 11.985343] gnome-session-c[1013]: segfault at 0 ip sp 7fff7679ca48 error 14 in gnome-session-check-accelerated-gl-helper[56020e238000+2000] [ 11.985352] Code: Unable to access opcode bytes at RIP 0xffd6. [ 14.216117] gnome-shell[1094]: segfault at 0 ip sp 7ffeddff9f88 error 14 [ 14.216122] Code: Unable to access opcode bytes at RIP 0xffd6. [ 15.316292] gnome-shell[1109]: segfault at 0 ip sp 7ffc70716198 error 14 [ 15.316297] Code: Unable to access opcode bytes at RIP 0xffd6. apt-cache policy: gnome-session: Installed: (none) Candidate: 3.38.0-1ubuntu1 Version table: 3.38.0-1ubuntu1 500 500 http://de.archive.ubuntu.com/ubuntu groovy/main amd64 Packages 500 http://de.archive.ubuntu.com/ubuntu groovy/main i386 Packages gnome-session-bin: Installed: 3.38.0-1ubuntu1 Candidate: 3.38.0-1ubuntu1 Version table: *** 3.38.0-1ubuntu1 500 500 http://de.archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status gnome-session-common: Installed: 3.38.0-1ubuntu1 Candidate: 3.38.0-1ubuntu1 Version table: *** 3.38.0-1ubuntu1 500 500 http://de.archive.ubuntu.com/ubuntu groovy/main amd64 Packages 500 http://de.archive.ubuntu.com/ubuntu groovy/main i386 Packages 100 /var/lib/dpkg/status /var/crash: see attachment To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1915870/+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 1915870] Re: gnome session not starting
I should also note that we cannot read the crash file in comment #1. To have that analysed you should run: ubuntu-bug _usr_libexec_gnome-session-check-accelerated-gl- helper.126.crash It looks like it might be one of these crashes in the Mesa r300_dri.so driver: https://errors.ubuntu.com/problem/35e91e8a26a38f12a90e6fdca6b964b9a91889bf https://errors.ubuntu.com/problem/c7097de400ef4606fa71cc05b607d4f8d126838d https://errors.ubuntu.com/problem/d92b45e827f9a2ef27ecbd3039ee0d71134404df ** Also affects: mesa (Ubuntu) Importance: Undecided Status: New ** Changed in: mesa (Ubuntu) Status: New => Incomplete ** Summary changed: - gnome session not starting + gnome session not starting (segfault with r300_dri.so) ** Bug watch added: gitlab.freedesktop.org/mesa/mesa/-/issues #3990 https://gitlab.freedesktop.org/mesa/mesa/-/issues/3990 -- 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/1915870 Title: gnome session not starting (segfault with r300_dri.so) Status in Mesa: Unknown Status in mesa package in Ubuntu: Confirmed Status in mesa package in Fedora: Unknown Bug description: Graphical user interface is not coming up upon start. Only SSH is possible. lsb_release -rd: Description: Ubuntu 20.10 Release: 20.10 dmesg: [ 11.985343] gnome-session-c[1013]: segfault at 0 ip sp 7fff7679ca48 error 14 in gnome-session-check-accelerated-gl-helper[56020e238000+2000] [ 11.985352] Code: Unable to access opcode bytes at RIP 0xffd6. [ 14.216117] gnome-shell[1094]: segfault at 0 ip sp 7ffeddff9f88 error 14 [ 14.216122] Code: Unable to access opcode bytes at RIP 0xffd6. [ 15.316292] gnome-shell[1109]: segfault at 0 ip sp 7ffc70716198 error 14 [ 15.316297] Code: Unable to access opcode bytes at RIP 0xffd6. apt-cache policy: gnome-session: Installed: (none) Candidate: 3.38.0-1ubuntu1 Version table: 3.38.0-1ubuntu1 500 500 http://de.archive.ubuntu.com/ubuntu groovy/main amd64 Packages 500 http://de.archive.ubuntu.com/ubuntu groovy/main i386 Packages gnome-session-bin: Installed: 3.38.0-1ubuntu1 Candidate: 3.38.0-1ubuntu1 Version table: *** 3.38.0-1ubuntu1 500 500 http://de.archive.ubuntu.com/ubuntu groovy/main amd64 Packages 100 /var/lib/dpkg/status gnome-session-common: Installed: 3.38.0-1ubuntu1 Candidate: 3.38.0-1ubuntu1 Version table: *** 3.38.0-1ubuntu1 500 500 http://de.archive.ubuntu.com/ubuntu groovy/main amd64 Packages 500 http://de.archive.ubuntu.com/ubuntu groovy/main i386 Packages 100 /var/lib/dpkg/status /var/crash: see attachment To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1915870/+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 1648183] Re: Crackling and popping sound when using headphones
I tried to run this script (https://wiki.archlinux.org/index.php/ASUS_Zenbook_UX430/UX530#Headphones_audio_is_too_low) and it did nothing. I'm experiencing the same issue with quality headphones but it's on both channels. I created a detailed bug report here before I found this thread https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1908634 . Any advice? -- 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/1648183 Title: Crackling and popping sound when using headphones Status in alsa-driver package in Ubuntu: Confirmed Status in alsa-driver package in Arch Linux: New Status in Fedora: New Bug description: Laptop is HP Pavilion - 15-au118tx. The laptop has B and O play and the output from speakers are just fine, when using headphones there is some kind of crackling and popping sound in both ears but prominently in the left ear. The issue happens only when the sound is played, if i reduce the PCM way low using alsamixer, the effect is minimized but the volume is also reduced. Increasing the volume in the panel increases the PCM as well. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 4.8.0-30.32-generic 4.8.6 Uname: Linux 4.8.0-30-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: antony 1719 F pulseaudio CurrentDesktop: Unity Date: Wed Dec 7 23:30:05 2016 InstallationDate: Installed on 2016-11-20 (17 days ago) InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Black Headphone Out, Left Symptom_Type: Digital clip or distortion, or "overdriven" sound Title: [HP Pavilion Notebook, Realtek ALC295, Black Headphone Out, Left] Sound is distorted UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/19/2016 dmi.bios.vendor: Insyde dmi.bios.version: F.14 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 8216 dmi.board.vendor: HP dmi.board.version: 83.13 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnInsyde:bvrF.14:bd07/19/2016:svnHP:pnHPPavilionNotebook:pvrType1ProductConfigId:rvnHP:rn8216:rvr83.13:cvnHP:ct10:cvrChassisVersion: dmi.product.name: HP Pavilion Notebook dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP mtime.conffile..etc.modprobe.d.alsa-base.conf: 2016-12-07T23:12:52.939689 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1648183/+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 1869368] Re: ubuntu_qrt_apparmor fails on ADT bionic/linux i386
found to be failing on Bionic/fips 4.15.0-1053.61 through regression testing ** Tags added: fips sru-20210125 -- 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/1869368 Title: ubuntu_qrt_apparmor fails on ADT bionic/linux i386 Status in QA Regression Testing: New Status in ubuntu-kernel-tests: New Status in apparmor package in Ubuntu: New Status in linux package in Ubuntu: Invalid Status in apparmor source package in Bionic: New Status in linux source package in Bionic: Confirmed Bug description: Testing failed on: i386: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/i386/l/linux/20200326_224620_0dd01@/log.gz Kernel version: bionic/linux 4.15.0-94.95 The ubuntu_qrt_apparmor.test-apparmor.py fails intermittently on bionic/linux i386 ADT tests. It has failed some releases in the past and I'm seeing the failure in the current release as well. I have not seen this failure on other architectures. These are the last messages on the test log: 20:12:39 ERROR| [stderr] Test mediation of file based SOCK_STREAM connect ... ok 20:12:39 ERROR| [stderr] test_libapparmor_testsuite (__main__.ApparmorTestsuites) 20:14:18 DEBUG| [stdout] unconfined_user can access confined_user's file 20:14:18 DEBUG| [stdout] unconfined_user can access default_user's file 20:14:18 DEBUG| [stdout] unconfined_user can access unconfined_group's file 20:14:18 DEBUG| [stdout] 20:15:42 ERROR| [stderr] Run libapparmor testsuite ... (Applying patch 0001-mount-regression-test-convert-mount-test-to-use-MS_N.patch) (Applying patch 0001-usr-merge-fixups.patch) ok 20:15:42 ERROR| [stderr] test_libapparmor_testsuite3 (__main__.ApparmorTestsuites) 20:15:52 DEBUG| [stdout] preparing apparmor_2.12-4ubuntu5.1.dsc... done 20:15:52 DEBUG| [stdout] 20:17:10 ERROR| [stderr] Run libapparmor testsuite (with python3) ... (Applying patch 0001-mount-regression-test-convert-mount-test-to-use-MS_N.patch) (Applying patch 0001-usr-merge-fixups.patch) ok 20:17:10 ERROR| [stderr] test_old_trusty_parser_testsuite (__main__.ApparmorTestsuites) 20:17:10 DEBUG| [stdout] preparing apparmor_2.12-4ubuntu5.1.dsc... done 20:17:10 ERROR| [stderr] Run parser regression tests from 14.04's apparmor_2.8.95~2430-0ubuntu5.3 ... (skipped: This test is only for 14.04 systems with the apparmor 2.10.95 SRU or newer installed) ok 20:17:10 ERROR| [stderr] test_old_trusty_regression_testsuite (__main__.ApparmorTestsuites) 20:17:10 ERROR| [stderr] Run kernel regression tests from 14.04's apparmor_2.8.95~2430-0ubuntu5.3 ... (skipped: This test is only for 14.04 systems with the apparmor 2.10.95 SRU or newer installed) ok 20:17:10 ERROR| [stderr] test_parser_testsuite (__main__.ApparmorTestsuites) 20:17:19 DEBUG| [stdout] 20:52:35 ERROR| [stderr] Run parser regression tests ... (Applying patch 0001-mount-regression-test-convert-mount-test-to-use-MS_N.patch) (Applying patch 0001-usr-merge-fixups.patch) ok 20:52:35 ERROR| [stderr] test_regression_testsuite (__main__.ApparmorTestsuites) 20:52:42 DEBUG| [stdout] preparing apparmor_2.12-4ubuntu5.1.dsc... done 20:52:42 DEBUG| [stdout] 21:01:56 INFO | ERROR ubuntu_qrt_apparmor.test-apparmor.py ubuntu_qrt_apparmor.test-apparmor.pytimestamp=1585256516localtime=Mar 26 21:01:56 Test subprocess failed rc=9 To manage notifications about this bug go to: https://bugs.launchpad.net/qa-regression-testing/+bug/1869368/+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 1915874] Re: autopkgtest fails in hirsute on armhf with glibc 2.33
** Changed in: libseccomp (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1915874 Title: autopkgtest fails in hirsute on armhf with glibc 2.33 Status in libseccomp package in Ubuntu: Fix Committed Bug description: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/armhf/libs/libseccomp/20210214_103448_4822f@/log.gz ... autopkgtest [10:33:19]: test test-filter: [--- = ./debian/tests/data/all-3.19.filter = DEBUG: seccomp_load_filters ./debian/tests/data/all-3.19.filter Bad system call (core dumped) FAIL: expected to pass ... The problem seems to be that with the new glibc upstream version the test binaries started using statx which is not listed in the .filter files. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1915874/+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 1881207] Re: systemd-networkd brings eno1 up and down repeatedly
** Changed in: systemd Status: Unknown => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1881207 Title: systemd-networkd brings eno1 up and down repeatedly Status in systemd: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Eoan: Won't Fix Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Status in systemd source package in Hirsute: In Progress Bug description: [impact] a system using dhcp for an interface where (1) the interface 'resets' itself during mtu setting (meaning it briefly drops carrier during mtu change), and (2) the dhcp server provides a non-standard (i.e. other than 1500) mtu, will continually loop changing mtu between 1500 and the dhcp-privded mtu. [test case] The e1000e nic is one such nic where the driver briefly drops carrier when changing the mtu, so this can be reproduced by creating a VM and setting the interface to the 'e1000e' emulated hardware. Then configure a dhcp server to provide dhcp service to the VM, and set the mtu to e.g. 9000 (anything other than the default 1500). When the VM runs dhcp, it will loop with: Feb 22 15:18:58 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier Feb 22 15:18:58 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 address 1.2.3.133/24 via 1.2.3.1 Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease lost Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease lost Feb 22 15:19:01 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier Feb 22 15:19:01 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 address 1.2.3.133/24 via 1.2.3.1 Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease lost Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease lost Feb 22 15:19:04 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier Feb 22 15:19:04 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 address 1.2.3.133/24 via 1.2.3.1 Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease lost Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease lost [regression potential] any regression would likely involve an issue with dhcpv4 service; possibly not setting the mtu correctly, or possibly not completing dhcpv4 at all. [scope] this is not fixed upstream yet, so (once fixed upstream) it will be needed for b/f/g/h [original description] Running on a NUC (BOXNUC8i7BEH3). After updating the `systemd` package past `237-3ubuntu10.32`, I see the onboard NIC link being taken down / up repeatedly, as shown below (dates are from my original notes, but the issue remains the same today). The NIC fails to remain up, and all networking is out of action. Running `systemctl stop systemd-netword` stops this and leaves the NIC in an unknown state. Subsequently running `ifconfig eno1 up && dhclient eno1` allows networking to continue basic operation, albeit without systemd's oversight. My original solution was to downgrade both the `libsystemd0` and `systemd` packages to `237-3ubuntu10.28`. After attempting an `apt update && apt upgrade` again today, exactly the same thing is happening with `237-3ubuntu10.41`. Good versions: - 237-3ubuntu10.28 - 237-3ubuntu10.32 (currently in use, and held) Bad versions: - 237-3ubuntu10.33 - 237-3ubuntu10.38 - 237-3ubuntu10.41 dmesg: [ 360.711367] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 360.714370] e1000e :00:1f.6 eno1: changing MTU from 1500 to 9000 [ 360.726189] e1000e :00:1f.6: Interrupt Throttle Rate off [ 361.733073] e1000e :00:1f.6 eno1: changing MTU from 9000 to 1500 [ 361.744146] e1000e :00:1f.6: Interrupt Throttle Rate on [ 366.760198] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 366.763375] e1000e :00:1f.6 eno1: changing MTU from 1500 to 9000 [ 366.776060] e1000e :00:1f.6: Interrupt Throttle Rate off [ 367.781718] e1000e :00:1f.6 eno1: changing MTU from 9000 to 1500 [ 367.792796] e1000e :00:1f.6: Interrupt Throttle Rate on [ 372.808660] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 372.811537] e1000e :00:1f.6 eno1: changing MTU from 1500 to 9000 [ 372.823648] e1000e :00:1f.6: Interrupt Throttle Rate off [ 373.830436] e1000e :00:1f.
[Touch-packages] [Bug 1883447] Re: nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to focal in containers
** Description changed: + [impact] - Recent Linux kernels introduced a number of new syscalls ending in _time64 to fix Y2038 problem; it appears recent glibc, including the version in focal, test for the existence of these. systemd-nspawn in bionic (237-3ubuntu10.38) doesn't know about these so blocks them by default. It seems however glibc isn't expecting an EPERM, causing numerous programs to fail. + nspawn fails on armhf + + [test case] + + TBD + + [regression potential] + + any regression would likely break nspawn creation of containers, + particularly on armhf, but possibly on other archs + + [scope] + + this is needed only in bionic. + + this is fixed upstream by commit + 6ca677106992321326427c89a40e1c9673a499b2 which was included first in + v244, so this is fixed already in focal and later. + + [original description] + + Recent Linux kernels introduced a number of new syscalls ending in + _time64 to fix Y2038 problem; it appears recent glibc, including the + version in focal, test for the existence of these. systemd-nspawn in + bionic (237-3ubuntu10.38) doesn't know about these so blocks them by + default. It seems however glibc isn't expecting an EPERM, causing + numerous programs to fail. In particular, running do-release-upgrade to focal in an nspawn container hosted on bionic will break as soon as the new libc has been unpacked. Solution (tested here) is to cherrypick upstream commit https://github.com/systemd/systemd/commit/6ca677106992321326427c89a40e1c9673a499b2 A newer libseccomp is also needed but this is already being worked on, see bug #1876055. It's a pretty trivial fix one the new libseccomp lands, and there is precedent for SRU-ing for a similar issue in bug #1840640. https://patchwork.kernel.org/patch/10756415/ is apparently the upstream kernel patch, which should give a clearer idea of which architectures are likely to be affected - I noticed it on armhf. ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Low ** Changed in: systemd (Ubuntu Bionic) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1883447 Title: nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to focal in containers 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] nspawn fails on armhf [test case] TBD [regression potential] any regression would likely break nspawn creation of containers, particularly on armhf, but possibly on other archs [scope] this is needed only in bionic. this is fixed upstream by commit 6ca677106992321326427c89a40e1c9673a499b2 which was included first in v244, so this is fixed already in focal and later. [original description] Recent Linux kernels introduced a number of new syscalls ending in _time64 to fix Y2038 problem; it appears recent glibc, including the version in focal, test for the existence of these. systemd-nspawn in bionic (237-3ubuntu10.38) doesn't know about these so blocks them by default. It seems however glibc isn't expecting an EPERM, causing numerous programs to fail. In particular, running do-release-upgrade to focal in an nspawn container hosted on bionic will break as soon as the new libc has been unpacked. Solution (tested here) is to cherrypick upstream commit https://github.com/systemd/systemd/commit/6ca677106992321326427c89a40e1c9673a499b2 A newer libseccomp is also needed but this is already being worked on, see bug #1876055. It's a pretty trivial fix one the new libseccomp lands, and there is precedent for SRU-ing for a similar issue in bug #1840640. https://patchwork.kernel.org/patch/10756415/ is apparently the upstream kernel patch, which should give a clearer idea of which architectures are likely to be affected - I noticed it on armhf. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1883447/+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 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
** No longer affects: pam (Ubuntu) ** No longer affects: pam (Ubuntu Bionic) ** No longer affects: pam (Ubuntu Focal) ** No longer affects: pam (Ubuntu Groovy) ** Also affects: gdm3 (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953557 Importance: Unknown Status: Unknown ** Project changed: gdm => ubuntu-translations ** Changed in: ubuntu-translations Importance: Unknown => Undecided ** Changed in: ubuntu-translations Remote watch: Debian Bug tracker #953557 => None ** No longer affects: ubuntu-translations -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in GNOME Settings Daemon: Unknown Status in gdm3 package in Ubuntu: Confirmed Status in gnome-settings-daemon package in Ubuntu: In Progress Status in gdm3 source package in Bionic: Won't Fix Status in gdm3 source package in Focal: Confirmed Status in gnome-settings-daemon source package in Focal: New Status in gdm3 source package in Groovy: Confirmed Status in gnome-settings-daemon source package in Groovy: New Status in gdm3 package in Debian: Unknown Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-settings-daemon/+bug/1865226/+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 1916250] Re: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute)
** Changed in: libsignon-glib (Ubuntu) Importance: Undecided => Low ** Tags added: package-conflict -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libsignon-glib in Ubuntu. https://bugs.launchpad.net/bugs/1916250 Title: gir1.2-signon-2.0 needs to declare replace on older releases (Groovy2Hirsute) Status in libsignon-glib package in Ubuntu: New Bug description: gir1.2-signon-1.0 from groovy gir1.2-signon-2.0 from hirsute above two packages ship the same file /usr/lib/python3/dist- packages/gi/overrides/Signon.py without specifying how to resolve the conflict. Unpacking gir1.2-signon-2.0:amd64 (2.1-3) ... dpkg: error processing archive /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/gi/overrides/Signon.py', which is also in package gir1.2-signon-1.0 1.14+17.04.20161117-0ubuntu5 Errors were encountered while processing: /var/cache/apt/archives/gir1.2-signon-2.0_2.1-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Probably needs a conflicts/replaces dependency added to the newer hirsute package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libsignon-glib/+bug/1916250/+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 1881207] Re: systemd-networkd brings eno1 up and down repeatedly
** Bug watch added: github.com/systemd/systemd/issues #18738 https://github.com/systemd/systemd/issues/18738 ** Also affects: systemd via https://github.com/systemd/systemd/issues/18738 Importance: Unknown Status: Unknown -- 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/1881207 Title: systemd-networkd brings eno1 up and down repeatedly Status in systemd: Unknown Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Eoan: Won't Fix Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Status in systemd source package in Hirsute: In Progress Bug description: [impact] a system using dhcp for an interface where (1) the interface 'resets' itself during mtu setting (meaning it briefly drops carrier during mtu change), and (2) the dhcp server provides a non-standard (i.e. other than 1500) mtu, will continually loop changing mtu between 1500 and the dhcp-privded mtu. [test case] The e1000e nic is one such nic where the driver briefly drops carrier when changing the mtu, so this can be reproduced by creating a VM and setting the interface to the 'e1000e' emulated hardware. Then configure a dhcp server to provide dhcp service to the VM, and set the mtu to e.g. 9000 (anything other than the default 1500). When the VM runs dhcp, it will loop with: Feb 22 15:18:58 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier Feb 22 15:18:58 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 address 1.2.3.133/24 via 1.2.3.1 Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease lost Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease lost Feb 22 15:19:01 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier Feb 22 15:19:01 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 address 1.2.3.133/24 via 1.2.3.1 Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease lost Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease lost Feb 22 15:19:04 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier Feb 22 15:19:04 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 address 1.2.3.133/24 via 1.2.3.1 Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease lost Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease lost [regression potential] any regression would likely involve an issue with dhcpv4 service; possibly not setting the mtu correctly, or possibly not completing dhcpv4 at all. [scope] this is not fixed upstream yet, so (once fixed upstream) it will be needed for b/f/g/h [original description] Running on a NUC (BOXNUC8i7BEH3). After updating the `systemd` package past `237-3ubuntu10.32`, I see the onboard NIC link being taken down / up repeatedly, as shown below (dates are from my original notes, but the issue remains the same today). The NIC fails to remain up, and all networking is out of action. Running `systemctl stop systemd-netword` stops this and leaves the NIC in an unknown state. Subsequently running `ifconfig eno1 up && dhclient eno1` allows networking to continue basic operation, albeit without systemd's oversight. My original solution was to downgrade both the `libsystemd0` and `systemd` packages to `237-3ubuntu10.28`. After attempting an `apt update && apt upgrade` again today, exactly the same thing is happening with `237-3ubuntu10.41`. Good versions: - 237-3ubuntu10.28 - 237-3ubuntu10.32 (currently in use, and held) Bad versions: - 237-3ubuntu10.33 - 237-3ubuntu10.38 - 237-3ubuntu10.41 dmesg: [ 360.711367] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 360.714370] e1000e :00:1f.6 eno1: changing MTU from 1500 to 9000 [ 360.726189] e1000e :00:1f.6: Interrupt Throttle Rate off [ 361.733073] e1000e :00:1f.6 eno1: changing MTU from 9000 to 1500 [ 361.744146] e1000e :00:1f.6: Interrupt Throttle Rate on [ 366.760198] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 366.763375] e1000e :00:1f.6 eno1: changing MTU from 1500 to 9000 [ 366.776060] e1000e :00:1f.6: Interrupt Throttle Rate off [ 367.781718] e1000e :00:1f.6 eno1: changing MTU from 9000 to 1500 [ 367.792796] e1000e :00:1f.6: Interrupt Throttle Rate on [ 372.808660] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow
[Touch-packages] [Bug 1825186] Re: gpgv-win32 autopkgtest always fails
This bug was fixed in the package gnupg2 - 2.2.4-1ubuntu1.4 --- gnupg2 (2.2.4-1ubuntu1.4) bionic; urgency=medium * d/p/dirmngr-handle-EAFNOSUPPORT-at-connect_server.patch: - Fix IPv6 connectivity for dirmngr (LP: #1910432) * Fix autopkgtests (LP: #1825186) - add d/t/simple-tests from devel branch - remove broken gpgv-win32 test from d/t/control -- Heitor Alves de Siqueira Sat, 16 Jan 2021 14:47:37 + ** Changed in: gnupg2 (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 gnupg in Ubuntu. https://bugs.launchpad.net/bugs/1825186 Title: gpgv-win32 autopkgtest always fails Status in gnupg package in Ubuntu: Invalid Status in gnupg2 package in Ubuntu: Fix Released Status in gnupg source package in Xenial: Won't Fix Status in gnupg2 source package in Bionic: Fix Released Status in gnupg2 source package in Cosmic: Won't Fix Status in gnupg2 source package in Disco: Fix Released Bug description: [impact] gpgv-win32 autopkgtest always fails [test case] check http://autopkgtest.ubuntu.com/packages/g/gnupg2 or run autopkgtest manually note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and has been removed from d/t/control entirely in d [regression potential] little to none; this affects the test case only [other info] as mentioned, in disco, the gpgv-win32 test has been removed from the tests/control completely. not sure if that is a better approach than fixing the test case. For now, I marked this Fix Released for disco since it doesn't fail there (since the testcase was removed). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+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 1856871] Re: i/o error if next unused loop device is queried
** Changed in: linux (Ubuntu) Status: Incomplete => In Progress ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Changed in: parted (Ubuntu) Status: New => Invalid ** Changed in: linux (Ubuntu) Assignee: Mauricio Faria de Oliveira (mfo) => Eric Desrochers (slashd) -- 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/1856871 Title: i/o error if next unused loop device is queried Status in linux package in Ubuntu: In Progress Status in parted package in Ubuntu: Invalid Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Bug description: This is reproducible in Bionic and late. Here's an example running 'focal': $ lsb_release -cs focal $ uname -r 5.3.0-24-generic The error is: blk_update_request: I/O error, dev loop2, sector 0 and on more recent kernel: kernel: [18135.185709] blk_update_request: I/O error, dev loop18, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 How to trigger it: $ sosreport -o block or more precisely the cmd causing the situation inside the block plugin: $ parted -s $(losetup -f) unit s print https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52 but if I run it on the next next unused loop device, in this case /dev/loop3 (which is also unused), no errors. While I agree that sosreport shouldn't query unused loop devices, there is definitely something going on with the next unused loop device. What is differentiate loop2 and loop3 and any other unused ones ? 3 things so far I have noticed: * loop2 is the next unused loop device (losetup -f) * A reboot is needed (if some loop modification (snap install, mount loop, ...) has been made at runtime * I have also noticed that loop2 (or whatever the next unused one is) have some stat as oppose to other unused loop devices. The stat exist already right after the system boot for the next unused loop device. /sys/block/loop2/stat :: 2 0 10 0 1 0 0 0 0 0 0 2 = number of read I/Os processed 10 = number of sectors read 1 = number of write I/Os processed Explanation of each column: https://www.kernel.org/doc/html/latest/block/stat.html while /dev/loop3 doesn't /sys/block/loop3/stat :: 0 0 0 0 0 0 0 0 0 0 0 Which tells me that something during the boot process most likely acquired (on purpose or not) the next unused loop and possibly didn't released it well enough. If loop2 is generating errors, and I install a snap, the snap squashfs will take loop2, making loop3 the next unused loop device. If I query loop3 with 'parted' right after, no errors. If I reboot, and query loop3 again, then no I'll have an error. To triggers the errors it need to be after a reboot and it only impact the first unused loop device available (losetup -f). This was tested with focal/systemd whic his very close to latest upstream code. This has been test with latest v5.5 mainline kernel as well. For now, I don't think it's a kernel problem, I'm more thinking of a userspace misbehaviour dealing with loop device (or block device) at boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856871/+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
Fixed in 20210222 daily images. Marking fix released. ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1911059 Title: gce: 247.1-4ubuntu1 causes loss of networking Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released 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/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 1825186] Update Released
The verification of the Stable Release Update for gnupg2 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 gnupg in Ubuntu. https://bugs.launchpad.net/bugs/1825186 Title: gpgv-win32 autopkgtest always fails Status in gnupg package in Ubuntu: Invalid Status in gnupg2 package in Ubuntu: Fix Released Status in gnupg source package in Xenial: Won't Fix Status in gnupg2 source package in Bionic: Fix Committed Status in gnupg2 source package in Cosmic: Won't Fix Status in gnupg2 source package in Disco: Fix Released Bug description: [impact] gpgv-win32 autopkgtest always fails [test case] check http://autopkgtest.ubuntu.com/packages/g/gnupg2 or run autopkgtest manually note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and has been removed from d/t/control entirely in d [regression potential] little to none; this affects the test case only [other info] as mentioned, in disco, the gpgv-win32 test has been removed from the tests/control completely. not sure if that is a better approach than fixing the test case. For now, I marked this Fix Released for disco since it doesn't fail there (since the testcase was removed). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+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 1916485] Re: test -x fails inside shell scripts in containers
Patches have been proposed for that, but were rejected: [PATCH] syscalls: Document OCI seccomp filter interactions & workaround https://lore.kernel.org/linux-api/87lfer2c0b@oldenburg2.str.redhat.com/ [RFC PATCH] Linux: Add seccomp probing to faccessat2 https://sourceware.org/pipermail/libc-alpha/2020-November/119955.html We *really* need to clean this up properly, so that we are prepared if we need to add a new system call as part of a security fix. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1916485 Title: test -x fails inside shell scripts in containers Status in glibc package in Ubuntu: Triaged Status in libseccomp package in Ubuntu: Fix Committed Bug description: glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1916485/+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 1856871] Re: i/o error if next unused loop device is queried
The upstream proposal fix that mfo and I worked on has been applied: https://patchwork.kernel.org/project/linux- block/patch/20210222154123.61797-1-...@canonical.com/ - Eric -- 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/1856871 Title: i/o error if next unused loop device is queried Status in linux package in Ubuntu: Incomplete Status in parted package in Ubuntu: New Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Bug description: This is reproducible in Bionic and late. Here's an example running 'focal': $ lsb_release -cs focal $ uname -r 5.3.0-24-generic The error is: blk_update_request: I/O error, dev loop2, sector 0 and on more recent kernel: kernel: [18135.185709] blk_update_request: I/O error, dev loop18, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 How to trigger it: $ sosreport -o block or more precisely the cmd causing the situation inside the block plugin: $ parted -s $(losetup -f) unit s print https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52 but if I run it on the next next unused loop device, in this case /dev/loop3 (which is also unused), no errors. While I agree that sosreport shouldn't query unused loop devices, there is definitely something going on with the next unused loop device. What is differentiate loop2 and loop3 and any other unused ones ? 3 things so far I have noticed: * loop2 is the next unused loop device (losetup -f) * A reboot is needed (if some loop modification (snap install, mount loop, ...) has been made at runtime * I have also noticed that loop2 (or whatever the next unused one is) have some stat as oppose to other unused loop devices. The stat exist already right after the system boot for the next unused loop device. /sys/block/loop2/stat :: 2 0 10 0 1 0 0 0 0 0 0 2 = number of read I/Os processed 10 = number of sectors read 1 = number of write I/Os processed Explanation of each column: https://www.kernel.org/doc/html/latest/block/stat.html while /dev/loop3 doesn't /sys/block/loop3/stat :: 0 0 0 0 0 0 0 0 0 0 0 Which tells me that something during the boot process most likely acquired (on purpose or not) the next unused loop and possibly didn't released it well enough. If loop2 is generating errors, and I install a snap, the snap squashfs will take loop2, making loop3 the next unused loop device. If I query loop3 with 'parted' right after, no errors. If I reboot, and query loop3 again, then no I'll have an error. To triggers the errors it need to be after a reboot and it only impact the first unused loop device available (losetup -f). This was tested with focal/systemd whic his very close to latest upstream code. This has been test with latest v5.5 mainline kernel as well. For now, I don't think it's a kernel problem, I'm more thinking of a userspace misbehaviour dealing with loop device (or block device) at boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856871/+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 1916509] [NEW] Update PAM and PAM modules
Public bug reported: I want to implement pam_faillock which replaces pam_tally2 but requires pam version >= 1.4.0 The ability to 'reliably' lock accounts after a certain number of failed attempts is a requirement of the NIST 800-171 controls implemented by many U.S. government agencies and contractors. ** Affects: pam (Ubuntu) Importance: Undecided Status: New ** Tags: libpam pam pam-modules -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1916509 Title: Update PAM and PAM modules Status in pam package in Ubuntu: New Bug description: I want to implement pam_faillock which replaces pam_tally2 but requires pam version >= 1.4.0 The ability to 'reliably' lock accounts after a certain number of failed attempts is a requirement of the NIST 800-171 controls implemented by many U.S. government agencies and contractors. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1916509/+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 1916485] Re: test -x fails inside shell scripts in containers
The other question is whether the change in glibc should be rolled back such that it works when invoked in older container hosts. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1916485 Title: test -x fails inside shell scripts in containers Status in glibc package in Ubuntu: Triaged Status in libseccomp package in Ubuntu: Fix Committed Bug description: glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1916485/+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 1916485] Re: test -x fails inside shell scripts in containers
Fixed in libseccomp2 2.5.1 ** Also affects: libseccomp (Ubuntu) Importance: Undecided Status: New ** Changed in: libseccomp (Ubuntu) Status: New => Fix Committed ** Changed in: libseccomp (Ubuntu) Importance: Undecided => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1916485 Title: test -x fails inside shell scripts in containers Status in glibc package in Ubuntu: Triaged Status in libseccomp package in Ubuntu: Fix Committed Bug description: glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1916485/+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 1881207] Re: systemd-networkd brings eno1 up and down repeatedly
** Description changed: + [impact] + + a system using dhcp for an interface where (1) the interface 'resets' + itself during mtu setting (meaning it briefly drops carrier during mtu + change), and (2) the dhcp server provides a non-standard (i.e. other + than 1500) mtu, will continually loop changing mtu between 1500 and the + dhcp-privded mtu. + + [test case] + + The e1000e nic is one such nic where the driver briefly drops carrier + when changing the mtu, so this can be reproduced by creating a VM and + setting the interface to the 'e1000e' emulated hardware. Then configure + a dhcp server to provide dhcp service to the VM, and set the mtu to e.g. + 9000 (anything other than the default 1500). + + When the VM runs dhcp, it will loop with: + + Feb 22 15:18:58 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier + Feb 22 15:18:58 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 address 1.2.3.133/24 via 1.2.3.1 + Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier + Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease lost + Feb 22 15:18:59 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease lost + Feb 22 15:19:01 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier + Feb 22 15:19:01 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 address 1.2.3.133/24 via 1.2.3.1 + Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier + Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease lost + Feb 22 15:19:02 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease lost + Feb 22 15:19:04 lp1881207-upstream systemd-networkd[992]: ens8: Gained carrier + Feb 22 15:19:04 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv4 address 1.2.3.133/24 via 1.2.3.1 + Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: Lost carrier + Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: DHCP lease lost + Feb 22 15:19:05 lp1881207-upstream systemd-networkd[992]: ens8: DHCPv6 lease lost + + [regression potential] + + any regression would likely involve an issue with dhcpv4 service; + possibly not setting the mtu correctly, or possibly not completing + dhcpv4 at all. + + [scope] + + this is not fixed upstream yet, so (once fixed upstream) it will be + needed for b/f/g/h + + [original description] + Running on a NUC (BOXNUC8i7BEH3). After updating the `systemd` package past `237-3ubuntu10.32`, I see the onboard NIC link being taken down / up repeatedly, as shown below (dates are from my original notes, but the issue remains the same today). The NIC fails to remain up, and all networking is out of action. Running `systemctl stop systemd-netword` stops this and leaves the NIC in an unknown state. Subsequently running `ifconfig eno1 up && dhclient eno1` allows networking to continue basic operation, albeit without systemd's oversight. My original solution was to downgrade both the `libsystemd0` and `systemd` packages to `237-3ubuntu10.28`. After attempting an `apt update && apt upgrade` again today, exactly the same thing is happening with `237-3ubuntu10.41`. Good versions: - 237-3ubuntu10.28 - 237-3ubuntu10.32 (currently in use, and held) Bad versions: - 237-3ubuntu10.33 - 237-3ubuntu10.38 - 237-3ubuntu10.41 dmesg: [ 360.711367] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 360.714370] e1000e :00:1f.6 eno1: changing MTU from 1500 to 9000 [ 360.726189] e1000e :00:1f.6: Interrupt Throttle Rate off [ 361.733073] e1000e :00:1f.6 eno1: changing MTU from 9000 to 1500 [ 361.744146] e1000e :00:1f.6: Interrupt Throttle Rate on [ 366.760198] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 366.763375] e1000e :00:1f.6 eno1: changing MTU from 1500 to 9000 [ 366.776060] e1000e :00:1f.6: Interrupt Throttle Rate off [ 367.781718] e1000e :00:1f.6 eno1: changing MTU from 9000 to 1500 [ 367.792796] e1000e :00:1f.6: Interrupt Throttle Rate on [ 372.808660] e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 372.811537] e1000e :00:1f.6 eno1: changing MTU from 1500 to 9000 [ 372.823648] e1000e :00:1f.6: Interrupt Throttle Rate off [ 373.830436] e1000e :00:1f.6 eno1: changing MTU from 9000 to 1500 [ 373.841512] e1000e :00:1f.6: Interrupt Throttle Rate on journalctl -u systemd-networkd: Jan 06 18:04:05 patch systemd-networkd[755]: eno1: Gained carrier Jan 06 18:04:05 patch systemd-networkd[755]: eno1: DHCPv4 address 10.42.0.5/24 via 10.42.0.3 Jan 06 18:04:05 patch systemd-networkd[755]: eno1: IPv6 successfully enabled Jan 06 18:04:05 patch systemd-networkd[755]: eno1: Configured Jan 06 18:04:06 patch systemd-networkd[755]: eno1: Lost carrier Jan 06 18:04:06 patch systemd-networkd[755]: eno1: DHCP lease lost Jan 06 18:04:06 patch sys
[Touch-packages] [Bug 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
Christian submitted https://github.com/systemd/systemd/pull/18559 which got turned into https://github.com/systemd/systemd/pull/18684 and has now been merged in upstream systemd. We've both tested the resulting systemd and can confirm that /run/udev is now properly populated. Please cherry-pick those udevd fixes into Ubuntu's systemd. ** Changed in: systemd (Ubuntu) Assignee: Christian Brauner (cbrauner) => (unassigned) ** Changed in: systemd (Ubuntu) Status: Fix Released => Triaged ** Changed in: systemd (Ubuntu) Importance: Wishlist => High -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1825186] Re: gpgv-win32 autopkgtest always fails
Autopkgtest failures for gnupg2 on armhf have been fixed with a re-run, so it was likely due to a flaky testbed setup. Failures for libgnupg-interface-perl are the result of the upstream test suite and very unlikely to be related to this SRU. I've opened bug 1916499 to investigate those separately. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnupg in Ubuntu. https://bugs.launchpad.net/bugs/1825186 Title: gpgv-win32 autopkgtest always fails Status in gnupg package in Ubuntu: Invalid Status in gnupg2 package in Ubuntu: Fix Released Status in gnupg source package in Xenial: Won't Fix Status in gnupg2 source package in Bionic: Fix Committed Status in gnupg2 source package in Cosmic: Won't Fix Status in gnupg2 source package in Disco: Fix Released Bug description: [impact] gpgv-win32 autopkgtest always fails [test case] check http://autopkgtest.ubuntu.com/packages/g/gnupg2 or run autopkgtest manually note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and has been removed from d/t/control entirely in d [regression potential] little to none; this affects the test case only [other info] as mentioned, in disco, the gpgv-win32 test has been removed from the tests/control completely. not sure if that is a better approach than fixing the test case. For now, I marked this Fix Released for disco since it doesn't fail there (since the testcase was removed). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+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 1916462] Re: dnsmasq failed to send packet: Network is unreachable
** Tags added: regression-update -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1916462 Title: dnsmasq failed to send packet: Network is unreachable Status in dnsmasq package in Ubuntu: New Bug description: the log shows this: Feb 22 09:37:53 myserver dnsmasq[2259]: failed to send packet: Network is unreachable repeatedly and frequently. This is a known bug in dnsmasq and has been fixed upstream (according to the thread quoted below). Apparently it is IPv6 related and triggered by Windows and Mac clients. An extensive thread on the subject is here on the OpenWRT forum: https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq- multiple-vulnerabilities/85903/123 I think this has been reported in the fallout of the quoted security vulnerabilities. I don't think it is a security vulnerability in itself. dnsmasq version: 2.80-1.1ubuntu1.2 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: dnsmasq 2.80-1.1ubuntu1.2 Uname: Linux 5.4.98-219 armv7l ApportVersion: 2.20.11-0ubuntu27.16 Architecture: armhf CasperMD5CheckResult: skip Date: Mon Feb 22 09:34:12 2021 PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: dnsmasq UpgradeStatus: Upgraded to focal on 2020-11-15 (98 days ago) modified.conffile..etc.default.dnsmasq: [modified] mtime.conffile..etc.default.dnsmasq: 2018-06-27T16:10:40.086905 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1916462/+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 1916485] Re: apt-key add fails in docker - Fails to run gnupg
This is a regression in glibc: [ -x /usr/bin/gpg] fails inside the script. Downgrading libc6 (and rdeps) to 2.32-0ubuntu6 makes it work again. Upgrading libc6 to 2.33-0ubuntu2 breaks it. ** Package changed: apt (Ubuntu) => glibc (Ubuntu) ** Changed in: glibc (Ubuntu) Importance: Undecided => Critical ** Changed in: glibc (Ubuntu) Status: New => Triaged ** Tags added: rls-hh-incoming ** Summary changed: - apt-key add fails in docker - Fails to run gnupg + test -x fails inside shell scripts ** Description changed: + glibc regression causes test -x to fail inside scripts inside + docker/podman: + root@0df2ce5d7a46:/# echo 'test -x /usr/bin/gpg || echo Fail' > a + root@0df2ce5d7a46:/# sh a + Fail + root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail + root@0df2ce5d7a46:/# + + + [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 - root@84b750e443f8:/# dpkg -l gnupg apt + root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement - - Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." - FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ - && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ - && curl https://syncthing.net/release-key.txt | apt-key add - - + && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ + && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo ** Summary changed: - test -x fails inside shell scripts + test -x fails inside shell scripts in containers -- 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/1916485 Title: test -x fails inside shell scripts in containers Status in glibc package in Ubuntu: Triaged Bug description: glibc regression causes test -x to fail inside scripts inside docker/podman: root@0df2ce5d7a46:/# echo 'test -x /usr/bin/gpg || echo Fail' > a root@0df2ce5d7a46:/# sh a Fail root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-=
[Touch-packages] [Bug 1916485] Re: apt-key add fails in docker - Fails to run gnupg
OK; I did not see that gpg was actually installed. Please report bugs properly with ubuntu-bug/apport next time instead of dumping data in the text report. ** Changed in: apt (Ubuntu) Status: Invalid => New -- 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/1916485 Title: apt-key add fails in docker - Fails to run gnupg Status in apt package in Ubuntu: New Bug description: root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1916485/+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 1916485] Re: apt-key add fails in docker - Fails to run gnupg
And no, this is not new in 2.1.20. The gnupg dependency was demoted to Suggests in 1.5~alpha1 (Jun 2017), so it's been this way since 17.10. -- 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/1916485 Title: apt-key add fails in docker - Fails to run gnupg Status in apt package in Ubuntu: New Bug description: root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1916485/+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 1916485] Re: apt-key add fails in docker - Fails to run gnupg
This is a feature, not a bug. We worked hard to not require gnupg anymore. apt-key does not work without gnupg (or gpg). It's also deprecated and has been obsoleted over 10 years ago with the introduction of trusted.gpg.d. The correct thing to do here is to wget -O /etc/apt/trusted.gpg.d/syncthing.asc https://syncthing.net /release-key.txt or wget -O /syncthing.asc https://syncthing.net/release-key.txt and add signed-by=/syncthing.asc to your sources.list entry. ** Changed in: apt (Ubuntu) Status: New => Invalid -- 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/1916485 Title: apt-key add fails in docker - Fails to run gnupg Status in apt package in Ubuntu: New Bug description: root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1916485/+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 1916485] Re: apt-key add fails in docker - Fails to run gnupg
Bug also applies to apt 2.2.0 root@72aa01291622:/# dpkg -l apt gnupg Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.2.0 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement root@72aa01291622:/# curl https://syncthing.net/release-key.txt | apt-key add - % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 2462 100 24620 0 1969 0 0:00:01 0:00:01 --:--:-- 1969 -- 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/1916485 Title: apt-key add fails in docker - Fails to run gnupg Status in apt package in Ubuntu: New Bug description: root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1916485/+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 1916485] [NEW] apt-key add fails in docker - Fails to run gnupg
Public bug reported: root@84b750e443f8:/# lsb_release -rd Description:Ubuntu Hirsute Hippo (development branch) Release:21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo ** Affects: apt (Ubuntu) Importance: Undecided Status: New -- 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/1916485 Title: apt-key add fails in docker - Fails to run gnupg Status in apt package in Ubuntu: New Bug description: root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1916485/+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 1916469] Re: Ubuntu universe Wayland problem
https://answers.launchpad.net/ubuntu/+question/695689 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1916469 Title: Ubuntu universe Wayland problem Status in Ubuntu: New Status in firefox package in Ubuntu: New Status in qdirstat package in Ubuntu: New Status in telegram-desktop package in Ubuntu: New Status in vlc package in Ubuntu: New Status in wayland package in Ubuntu: New Bug description: The Ubuntu universe has a big Wayland problem! What does that mean? So a lot of packages in the Universe repository are not compiled with Wayland support which is really bad and would lead to bad performance after 21.04 comes out. Here are the following packages that I detected with wrong compilation: telegram-desktop (Wayland support work with snap version) qdirstat vlc kiwix firefox (everything works fine with this env variable set:"MOZ_ENABLE_WAYLAND=1") To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1916469/+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 1834250] Re: update-grub complains about non-existent drives (due to cardreader)
This comes from lvs in lvm2 ** Package changed: grub2 (Ubuntu) => lvm2 (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1834250 Title: update-grub complains about non-existent drives (due to cardreader) Status in lvm2 package in Ubuntu: Confirmed Bug description: sudo update-grub Sourcing file `/etc/default/grub' Sourcing file `/etc/default/grub.d/init-select.cfg' Generating grub configuration file ... /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found Found linux image: /boot/vmlinuz-5.0.0-17-generic Found initrd image: /boot/initrd.img-5.0.0-17-generic Found linux image: /boot/vmlinuz-5.0.0-16-generic Found initrd image: /boot/initrd.img-5.0.0-16-generic /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found Adding boot menu entry for EFI firmware configuration done -- lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda8:00 3.7T 0 disk ├─sda1 8:10 512M 0 part /boot/efi ├─sda2 8:20 732M 0 part /boot └─sda3 8:30 3.7T 0 part └─sda3_crypt 253:00 3.7T 0 crypt ├─kubuntu--vg-swap_1 253:10 976M 0 lvm [SWAP] └─kubuntu--vg-root 253:20 3.7T 0 lvm / sdb8:16 0 3.7T 0 disk └─sdb1 8:17 0 3.7T 0 part sdg8:96 0 7.3T 0 disk └─sdg1 8:97 0 7.3T 0 part /media/scott/8TB Ext Drive sr0 11:01 15.7G 0 rom -- cat /etc/default/grub GRUB_DEFAULT=0 GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on" GRUB_CMDLINE_LINUX="" ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: grub2-common 2.02+dfsg1-12ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-17.18-generic 5.0.8 Uname: Linux 5.0.0-17-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu3 Architecture: amd64 CurrentDesktop: KDE Date: Tue Jun 25 15:05:29 2019 InstallationDate: Installed on 2019-06-14 (10 days ago) InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190614) SourcePackage: grub2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1834250/+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 1834250] [NEW] update-grub complains about non-existent drives (due to cardreader)
You have been subscribed to a public bug: sudo update-grub Sourcing file `/etc/default/grub' Sourcing file `/etc/default/grub.d/init-select.cfg' Generating grub configuration file ... /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found Found linux image: /boot/vmlinuz-5.0.0-17-generic Found initrd image: /boot/initrd.img-5.0.0-17-generic Found linux image: /boot/vmlinuz-5.0.0-16-generic Found initrd image: /boot/initrd.img-5.0.0-16-generic /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found /dev/sdc: open failed: No medium found /dev/sdd: open failed: No medium found /dev/sde: open failed: No medium found /dev/sdf: open failed: No medium found Adding boot menu entry for EFI firmware configuration done -- lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda8:00 3.7T 0 disk ├─sda1 8:10 512M 0 part /boot/efi ├─sda2 8:20 732M 0 part /boot └─sda3 8:30 3.7T 0 part └─sda3_crypt 253:00 3.7T 0 crypt ├─kubuntu--vg-swap_1 253:10 976M 0 lvm [SWAP] └─kubuntu--vg-root 253:20 3.7T 0 lvm / sdb8:16 0 3.7T 0 disk └─sdb1 8:17 0 3.7T 0 part sdg8:96 0 7.3T 0 disk └─sdg1 8:97 0 7.3T 0 part /media/scott/8TB Ext Drive sr0 11:01 15.7G 0 rom -- cat /etc/default/grub GRUB_DEFAULT=0 GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on" GRUB_CMDLINE_LINUX="" ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: grub2-common 2.02+dfsg1-12ubuntu3 ProcVersionSignature: Ubuntu 5.0.0-17.18-generic 5.0.8 Uname: Linux 5.0.0-17-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu3 Architecture: amd64 CurrentDesktop: KDE Date: Tue Jun 25 15:05:29 2019 InstallationDate: Installed on 2019-06-14 (10 days ago) InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190614) SourcePackage: grub2 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: lvm2 (Ubuntu) Importance: Low Status: Confirmed ** Tags: amd64 apport-bug eoan -- update-grub complains about non-existent drives (due to cardreader) https://bugs.launchpad.net/bugs/1834250 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 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 1916469] [NEW] Ubuntu universe Wayland problem
Public bug reported: The Ubuntu universe has a big Wayland problem! What does that mean? So a lot of packages in the Universe repository are not compiled with Wayland support which is really bad and would lead to bad performance after 21.04 comes out. Here are the following packages that I detected with wrong compilation: telegram-desktop (Wayland support work with snap version) qdirstat vlc kiwix firefox (everything works fine with this env variable set:"MOZ_ENABLE_WAYLAND=1") ** Affects: ubuntu Importance: Undecided Status: New ** Affects: firefox (Ubuntu) Importance: Undecided Status: New ** Affects: qdirstat (Ubuntu) Importance: Undecided Status: New ** Affects: telegram-desktop (Ubuntu) Importance: Undecided Status: New ** Affects: vlc (Ubuntu) Importance: Undecided Status: New ** Affects: wayland (Ubuntu) Importance: Undecided Status: New ** Tags: hirsute wayland ** Tags added: wayland ** Tags added: hirsute ** Also affects: wayland (Ubuntu) Importance: Undecided Status: New ** Also affects: telegram-desktop (Ubuntu) Importance: Undecided Status: New ** Also affects: qdirstat (Ubuntu) Importance: Undecided Status: New ** Also affects: firefox (Ubuntu) Importance: Undecided Status: New ** Also affects: vlc (Ubuntu) Importance: Undecided Status: New ** Description changed: The Ubuntu universe has a big Wayland problem! What does that mean? So a lot of packages in the Universe repository are not compiled with Wayland support which is really bad and would lead to bad performance after 21.04 comes out. Here are the following packages that I detected with wrong compilation: - telegram (Wayland support work with snap version) + telegram-desktop (Wayland support work with snap version) qdirstat vlc kiwix firefox (everything works fine with this env variable set:"MOZ_ENABLE_WAYLAND=1") -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1916469 Title: Ubuntu universe Wayland problem Status in Ubuntu: New Status in firefox package in Ubuntu: New Status in qdirstat package in Ubuntu: New Status in telegram-desktop package in Ubuntu: New Status in vlc package in Ubuntu: New Status in wayland package in Ubuntu: New Bug description: The Ubuntu universe has a big Wayland problem! What does that mean? So a lot of packages in the Universe repository are not compiled with Wayland support which is really bad and would lead to bad performance after 21.04 comes out. Here are the following packages that I detected with wrong compilation: telegram-desktop (Wayland support work with snap version) qdirstat vlc kiwix firefox (everything works fine with this env variable set:"MOZ_ENABLE_WAYLAND=1") To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1916469/+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 1916462] Re: dnsmasq failed to send packet: Network is unreachable
(redacted) dnsmasq conf fields are: bind-dynamic domain=my.domain.co.uk dhcp-authoritative domain-needed stop-dns-rebind rebind-localhost-ok no-hosts dhcp-broadcast=tag:needs-broadcast no-poll enable-ra bogus-priv bogus-nxdomain=...ipv4 addr... dhcp-boot=grubnetx64.efi.signed dhcp-boot=net:abcde,my.img enable-tftp tftp-root=/srv/tftp/ dhcp-option=42,0.0.0.0 dhcp-option=19,0 dhcp-option=44,0.0.0.0 dhcp-option=45,0.0.0.0 dhcp-option=46,8 dhcp-option=vendor:MSFT,2,1i dhcp-option=option6:dns-server,[::] dhcp-option=option6:domain-search,my.domain.co.uk dhcp-option=option6:ntp-server,[::] dhcp-range=eth0,192.168.1.10,192.168.1.200,255.255.255.0,12h dhcp-range=eth0,...ipv6 suffix...::100,...ipv6 suffix...::::0,slaac,ra-names,64,12h dhcp-range=vlan5,192.168.2.10,192.168.2.200,255.255.255.0,12h dhcp-range=vlan5,fd17:6e78:d6ba:c144::2,fd17:6e78:d6ba:c144::::,slaac,ra-names,64,12h dhcp-range=vlan6,192.168.3.10,192.168.3.200,255.255.255.0,12h dhcp-range=vlan6,fd17:6e78:d6ba:c145::2,fd17:6e78:d6ba:c145::::,slaac,ra-names,64,12h ...plus several dhcp-host and address fields -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1916462 Title: dnsmasq failed to send packet: Network is unreachable Status in dnsmasq package in Ubuntu: New Bug description: the log shows this: Feb 22 09:37:53 myserver dnsmasq[2259]: failed to send packet: Network is unreachable repeatedly and frequently. This is a known bug in dnsmasq and has been fixed upstream (according to the thread quoted below). Apparently it is IPv6 related and triggered by Windows and Mac clients. An extensive thread on the subject is here on the OpenWRT forum: https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq- multiple-vulnerabilities/85903/123 I think this has been reported in the fallout of the quoted security vulnerabilities. I don't think it is a security vulnerability in itself. dnsmasq version: 2.80-1.1ubuntu1.2 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: dnsmasq 2.80-1.1ubuntu1.2 Uname: Linux 5.4.98-219 armv7l ApportVersion: 2.20.11-0ubuntu27.16 Architecture: armhf CasperMD5CheckResult: skip Date: Mon Feb 22 09:34:12 2021 PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: dnsmasq UpgradeStatus: Upgraded to focal on 2020-11-15 (98 days ago) modified.conffile..etc.default.dnsmasq: [modified] mtime.conffile..etc.default.dnsmasq: 2018-06-27T16:10:40.086905 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1916462/+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 1916462] Re: dnsmasq failed to send packet: Network is unreachable
The (redacted) output of ip addr show is: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether ...my mac... brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 ...internet ipv6 addr.../64 scope global valid_lft forever preferred_lft forever inet6 ...internet ipv6 addr.../64 scope global valid_lft forever preferred_lft forever inet6 ...internet ipv6 addr.../64 scope global valid_lft forever preferred_lft forever inet6 fe80::21e:6ff:fe32:613b/64 scope link valid_lft forever preferred_lft forever 3: vlan4@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ...my mac... brd ff:ff:ff:ff:ff:ff inet ...internet ipv4.../24 brd ...internet ipv4255 scope global dynamic vlan4 valid_lft 351763sec preferred_lft 351763sec inet6 fe80::21e:6ff:fe32:613b/64 scope link valid_lft forever preferred_lft forever 4: vlan5@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ...my mac... brd ff:ff:ff:ff:ff:ff inet 192.168.2.1/24 brd 192.168.2.255 scope global vlan5 valid_lft forever preferred_lft forever inet6 fd17:6e78:d6ba:c144::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::21e:6ff:fe32:613b/64 scope link valid_lft forever preferred_lft forever 5: vlan6@eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ...my mac... brd ff:ff:ff:ff:ff:ff inet 192.168.3.1/24 brd 192.168.3.255 scope global vlan6 valid_lft forever preferred_lft forever inet6 fd17:6e78:d6ba:c145::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::21e:6ff:fe32:613b/64 scope link valid_lft forever preferred_lft forever 6: sit0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 7: he-ipv6@NONE: mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000 link/sit ...internet ipv4... peer ...internet ipv4... inet6 ...internet ipv6 addr.../64 scope global valid_lft forever preferred_lft forever inet6 fe80::5ce9:ca14/64 scope link valid_lft forever preferred_lft forever 8: tunl0@NONE: mtu 1480 qdisc noop state DOWN group default qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 9: ipv4-tunnel@NONE: mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000 link/ipip ...internet ipv4... peer ...internet ipv4... inet ...internet ipv4.../32 scope global ipv4-tunnel valid_lft forever preferred_lft forever inet6 fe80::200:5efe:5ce9:ca14/64 scope link valid_lft forever preferred_lft forever 10: wg0: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 192.168.10.1/24 scope global wg0 valid_lft forever preferred_lft forever inet6 fd18:6de:3816:db02::1/64 scope global valid_lft forever preferred_lft forever -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1916462 Title: dnsmasq failed to send packet: Network is unreachable Status in dnsmasq package in Ubuntu: New Bug description: the log shows this: Feb 22 09:37:53 myserver dnsmasq[2259]: failed to send packet: Network is unreachable repeatedly and frequently. This is a known bug in dnsmasq and has been fixed upstream (according to the thread quoted below). Apparently it is IPv6 related and triggered by Windows and Mac clients. An extensive thread on the subject is here on the OpenWRT forum: https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq- multiple-vulnerabilities/85903/123 I think this has been reported in the fallout of the quoted security vulnerabilities. I don't think it is a security vulnerability in itself. dnsmasq version: 2.80-1.1ubuntu1.2 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: dnsmasq 2.80-1.1ubuntu1.2 Uname: Linux 5.4.98-219 armv7l ApportVersion: 2.20.11-0ubuntu27.16 Architecture: armhf CasperMD5CheckResult: skip Date: Mon Feb 22 09:34:12 2021 PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: dnsmasq UpgradeStatus: Upgraded to focal on 2020-11-15 (98 days ago) modified.conffile..etc.default.dnsmasq: [modified] mtime.conffile..etc.default.dnsmasq: 2018-06-27T16:10:40.086905 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1916462/+subscriptions -- M
[Touch-packages] [Bug 1916462] [NEW] dnsmasq failed to send packet: Network is unreachable
Public bug reported: the log shows this: Feb 22 09:37:53 myserver dnsmasq[2259]: failed to send packet: Network is unreachable repeatedly and frequently. This is a known bug in dnsmasq and has been fixed upstream (according to the thread quoted below). Apparently it is IPv6 related and triggered by Windows and Mac clients. An extensive thread on the subject is here on the OpenWRT forum: https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq- multiple-vulnerabilities/85903/123 I think this has been reported in the fallout of the quoted security vulnerabilities. I don't think it is a security vulnerability in itself. dnsmasq version: 2.80-1.1ubuntu1.2 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: dnsmasq 2.80-1.1ubuntu1.2 Uname: Linux 5.4.98-219 armv7l ApportVersion: 2.20.11-0ubuntu27.16 Architecture: armhf CasperMD5CheckResult: skip Date: Mon Feb 22 09:34:12 2021 PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: dnsmasq UpgradeStatus: Upgraded to focal on 2020-11-15 (98 days ago) modified.conffile..etc.default.dnsmasq: [modified] mtime.conffile..etc.default.dnsmasq: 2018-06-27T16:10:40.086905 ** Affects: dnsmasq (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug armhf focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1916462 Title: dnsmasq failed to send packet: Network is unreachable Status in dnsmasq package in Ubuntu: New Bug description: the log shows this: Feb 22 09:37:53 myserver dnsmasq[2259]: failed to send packet: Network is unreachable repeatedly and frequently. This is a known bug in dnsmasq and has been fixed upstream (according to the thread quoted below). Apparently it is IPv6 related and triggered by Windows and Mac clients. An extensive thread on the subject is here on the OpenWRT forum: https://forum.openwrt.org/t/security-advisory-2021-01-19-1-dnsmasq- multiple-vulnerabilities/85903/123 I think this has been reported in the fallout of the quoted security vulnerabilities. I don't think it is a security vulnerability in itself. dnsmasq version: 2.80-1.1ubuntu1.2 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: dnsmasq 2.80-1.1ubuntu1.2 Uname: Linux 5.4.98-219 armv7l ApportVersion: 2.20.11-0ubuntu27.16 Architecture: armhf CasperMD5CheckResult: skip Date: Mon Feb 22 09:34:12 2021 PackageArchitecture: all ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: dnsmasq UpgradeStatus: Upgraded to focal on 2020-11-15 (98 days ago) modified.conffile..etc.default.dnsmasq: [modified] mtime.conffile..etc.default.dnsmasq: 2018-06-27T16:10:40.086905 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1916462/+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 1576844] Re: Touchpad/Trackpad freezes then eventually unfreezes (repeatedly)
Was getting the same problem on Ubuntu 20.04 on Dell Vostro 5401 (and on other distributions such as fedora on the same laptop). Have tried upgrading to Ubuntu 20.10 now. -- 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/1576844 Title: Touchpad/Trackpad freezes then eventually unfreezes (repeatedly) Status in xorg package in Ubuntu: Confirmed Bug description: $ lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 Several times yesterday and today (April 28-29, 2016) the touchpad (trackpad) on the Dell XPS 13 9343 has frozen. Other functions (keyboard, screen, etc.) have been fine but the pointer has been frozen in place. Then after 1-3 minutes functionality returns. Thank you very much for your assistance and I'd be happy to provide more information. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xorg 1:7.7+13ubuntu3 ProcVersionSignature: Ubuntu 4.4.0-22.38-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 NonfreeKernelModules: wl .tmp.unity_support_test.0: ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 BootLog: CompizPlugins: [core,composite,opengl,cube,rotate] CompositorRunning: None CurrentDesktop: GNOME-Flashback:Unity Date: Fri Apr 29 16:09:32 2016 DistUpgraded: 2016-04-27 15:53:13,798 DEBUG icon theme changed, re-reading DistroCodename: xenial DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.248+bdcom, 4.2.0-36-generic, x86_64: installed bcmwl, 6.30.223.248+bdcom, 4.4.0-22-generic, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation Broadwell-U Integrated Graphics [8086:1616] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Broadwell-U Integrated Graphics [1028:0665] InstallationDate: Installed on 2015-08-06 (267 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) MachineType: Dell Inc. XPS 13 9343 ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-22-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: Upgraded to xenial on 2016-04-27 (2 days ago) dmi.bios.date: 07/14/2015 dmi.bios.vendor: Dell Inc. dmi.bios.version: A05 dmi.board.name: 0TM99H dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA05:bd07/14/2015:svnDellInc.:pnXPS139343:pvr:rvnDellInc.:rn0TM99H:rvrA00:cvnDellInc.:ct9:cvr: dmi.product.name: XPS 13 9343 dmi.sys.vendor: Dell Inc. version.compiz: compiz 1:0.9.12.2+16.04.20160415-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.67-1 version.libgl1-mesa-dri: libgl1-mesa-dri 11.2.0-1ubuntu2 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 11.2.0-1ubuntu2 version.xserver-xorg-core: xserver-xorg-core 2:1.18.3-1ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20160325-1ubuntu1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2 xserver.bootTime: Wed Apr 27 15:54:22 2016 xserver.configfile: default xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id5152 vendor SHP xserver.version: 2:1.18.3-1ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1576844/+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 1916256] Re: NVIDIA Driver not working
** Package changed: xorg (Ubuntu) => nvidia-graphics-drivers-460 (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/1916256 Title: NVIDIA Driver not working Status in nvidia-graphics-drivers-460 package in Ubuntu: New Bug description: hello so i have a issue with NVIDIA driver on a 4k res the system is laggy 1 frame per sec and it shows me a glitch when i move the taps like : https://imgur.com/3LWJbbC thanks in advance ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.8.0-43.49~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-43-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.capabilities.gpu0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/capabilities/gpu0' .proc.driver.nvidia.capabilities.mig: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/capabilities/mig' .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 460.32.03 Sun Dec 27 19:00:34 UTC 2020 GCC version: ApportVersion: 2.20.11-0ubuntu27.16 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Feb 19 09:30:48 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation Skylake GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Skylake GT2 [HD Graphics 520] [103c:80e5] Subsystem: Hewlett-Packard Company GM107M [GeForce GTX 950M] [103c:80e5] InstallationDate: Installed on 2021-02-19 (0 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) MachineType: HP HP ENVY Notebook ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-43-generic root=UUID=d6d44f80-a9fe-4951-b886-8035f1017eff ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) acpidump: Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 126: Error executing command as another user: Request dismissed dmi.bios.date: 03/04/2016 dmi.bios.release: 15.53 dmi.bios.vendor: Insyde dmi.bios.version: F.35 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 80E5 dmi.board.vendor: HP dmi.board.version: 87.60 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 87.60 dmi.modalias: dmi:bvnInsyde:bvrF.35:bd03/04/2016:br15.53:efr87.60:svnHP:pnHPENVYNotebook:pvrType1ProductConfigId:rvnHP:rn80E5:rvr87.60:cvnHP:ct10:cvrChassisVersion: dmi.product.family: 103C_5335KV G=N L=CON B=HP S=ENV dmi.product.name: HP ENVY Notebook dmi.product.sku: V8S44EA#A2N dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP 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.nvidia-graphics-drivers: nvidia-graphics-drivers-* 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/nvidia-graphics-drivers-460/+bug/1916256/+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 1916359] Re: Logitech M510 right mouse click does not work anymore in 20.04 (but did in 18.04)
Thanks for the bug report, and thanks for testing 'xev'. The next step after that is to: sudo apt install evtest sudo evtest to see if the kernel is emitting any right click events for the mouse. Please also try some different (slightly older/newer) kernel versions to see if any others do work: https://kernel.ubuntu.com/~kernel- ppa/mainline/?C=M;O=D ** Summary changed: - Logitech M510 worked fine until upgrade to 20.04 + Logitech M510 right mouse click does not work anymore in 20.04 (but did in 18.04) ** Package changed: xorg (Ubuntu) => linux (Ubuntu) ** Changed in: linux (Ubuntu) Status: New => Incomplete ** Tags added: regression-release -- 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/1916359 Title: Logitech M510 right mouse click does not work anymore in 20.04 (but did in 18.04) Status in linux package in Ubuntu: Incomplete Bug description: I was forced to upgrade to 20.04 (not my doing) and my Logitech M510 right mouse click does not work anymore. It was working perfectly fine with 18.04. I tried a wired mouse and the right click works. I have a laptop Dell Inspiron 15 5000 series. The touchpad right click stopped working but got around it by installing gnome-tweaks. When I did the xev - grep -i button the right click does not show anything, the other buttons display action. Information Mouse Logitech M510 USB wireless Optical I am attaching the Xorg.0.log could not figure out how to attach more than one file. See lines 382 to 405 for the mouse info. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-65.73-generic 5.4.78 Uname: Linux 5.4.0-65-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.16 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Sat Feb 20 16:19:06 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Dell UHD Graphics 620 [1028:0810] InstallationDate: Installed on 2019-08-30 (540 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: Dell Inc. Inspiron 5570 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-65-generic root=UUID=b73b1f09-202a-4a95-a225-210c1953e209 ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/02/2018 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.1.3 dmi.board.name: 09YTN7 dmi.board.vendor: Dell Inc. dmi.board.version: X07 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.1.3:bd02/02/2018:svnDellInc.:pnInspiron5570:pvr:rvnDellInc.:rn09YTN7:rvrX07:cvnDellInc.:ct10:cvr: dmi.product.family: Inspiron dmi.product.name: Inspiron 5570 dmi.product.sku: 0810 dmi.sys.vendor: Dell Inc. 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 20.2.6-0ubuntu0.20.04.1 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/linux/+bug/1916359/+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 1916406] Re: Message from Xdiagnostics
Please tell us what kind of problem you are experiencing. ** 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/1916406 Title: Message from Xdiagnostics Status in Ubuntu: Incomplete Bug description: Hi, Here I report to you a bug from my ubuntu, hopefully you find the best solution in order to repair my device. Thank you, Best regards, Mohamad EL AHMAD ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.8.0-43.49~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-43-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.16 Architecture: amd64 CasperMD5CheckResult: skip CompositorRunning: None Date: Sun Feb 21 21:46:35 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DkmsStatus: nvidia, 460.32.03, 5.8.0-43-generic, x86_64: installed rtl8821ce, 5.5.2.1, 5.8.0-41-generic, x86_64: installed rtl8821ce, 5.5.2.1, 5.8.0-43-generic, x86_64: installed rtlwifi-new, 0.6: added GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd] (rev c4) (prog-if 00 [VGA controller]) Subsystem: Lenovo Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [17aa:39ff] InstallationDate: Installed on 2020-04-28 (298 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) MachineType: LENOVO 81H9 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-43-generic root=UUID=6908351f-1483-4983-b686-d19c135f31af ro quiet splash nvme_core.default_ps_max_latency_us=5500 vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/26/2020 dmi.bios.release: 1.58 dmi.bios.vendor: LENOVO dmi.ec.firmware.release: 1.58 dmi.modalias: dmi.product.family: YOGA 530-14ARR dmi.product.name: 81H9 dmi.product.sku: LENOVO_MT_81H9_BU_idea_FM_YOGA 530-14ARR dmi.product.version: Lenovo YOGA 530-14ARR dmi.sys.vendor: LENOVO 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 xserver.bootTime: Sun Feb 21 21:15:18 2021 xserver.configfile: default xserver.logfile: /var/log/Xorg.0.log xserver.version: 2:1.20.9-2ubuntu1.2~20.04.1 xserver.video_driver: amdgpu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1916406/+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
