[Touch-packages] [Bug 1894356] Re: could not acquire name on session bus by simultaneous login by XDMCP and keyboard
** Bug watch added: Debian Bug tracker #969564 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969564 ** Also affects: lightdm (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969564 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1894356 Title: could not acquire name on session bus by simultaneous login by XDMCP and keyboard Status in Light Display Manager: New Status in Ubuntu MATE: New Status in lightdm package in Ubuntu: New Status in lightdm package in Debian: Unknown Bug description: This symptom is observed with Ubuntu Mate 20.04. 1. Create /etc/lightdm/lightdm.conf.d/10-xdmcp.conf as [XDMCPServer] enabled=true and restart lightdm. 2. Login as a normal user from keyboard. 3. Login as the same user as 2 from XDMCP gives "Could not acquire name on session bus" and I cannot login from XDMCP. Without Step 2, XDMCP login succeeds. The same symptom is reported at https://github.com/neutrinolabs/xrdp/issues/1559#issuecomment-623977001 which recommends removal of "dbus-user-session" Ubuntu package. I worked around the above issue by putting "unset DBUS_SESSION_BUS_ADDRESS" in /etc/X11/Xsession.d/ The same issue is also reported at https://bugs.launchpad.net/ubuntu-mate/+bug/1769353 To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1894356/+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 1894356] [NEW] could not acquire name on session bus by simultaneous login by XDMCP and keyboard
Public bug reported: This symptom is observed with Ubuntu Mate 20.04. 1. Create /etc/lightdm/lightdm.conf.d/10-xdmcp.conf as [XDMCPServer] enabled=true and restart lightdm. 2. Login as a normal user from keyboard. 3. Login as the same user as 2 from XDMCP gives "Could not acquire name on session bus" and I cannot login from XDMCP. Without Step 2, XDMCP login succeeds. The same symptom is reported at https://github.com/neutrinolabs/xrdp/issues/1559#issuecomment-623977001 which recommends removal of "dbus-user-session" Ubuntu package. I worked around the above issue by putting "unset DBUS_SESSION_BUS_ADDRESS" in /etc/X11/Xsession.d/ The same issue is also reported at https://bugs.launchpad.net/ubuntu-mate/+bug/1769353 ** Affects: lightdm Importance: Undecided Status: New ** Affects: ubuntu-mate Importance: Undecided Status: New ** Affects: lightdm (Ubuntu) Importance: Undecided Status: New ** Tags: ubuntu ** Also affects: lightdm (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-mate Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1894356 Title: could not acquire name on session bus by simultaneous login by XDMCP and keyboard Status in Light Display Manager: New Status in Ubuntu MATE: New Status in lightdm package in Ubuntu: New Bug description: This symptom is observed with Ubuntu Mate 20.04. 1. Create /etc/lightdm/lightdm.conf.d/10-xdmcp.conf as [XDMCPServer] enabled=true and restart lightdm. 2. Login as a normal user from keyboard. 3. Login as the same user as 2 from XDMCP gives "Could not acquire name on session bus" and I cannot login from XDMCP. Without Step 2, XDMCP login succeeds. The same symptom is reported at https://github.com/neutrinolabs/xrdp/issues/1559#issuecomment-623977001 which recommends removal of "dbus-user-session" Ubuntu package. I worked around the above issue by putting "unset DBUS_SESSION_BUS_ADDRESS" in /etc/X11/Xsession.d/ The same issue is also reported at https://bugs.launchpad.net/ubuntu-mate/+bug/1769353 To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1894356/+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 1829568] Re: [GL703VD, Realtek ALC295, Black Headphone left and right ] No sound at all
The same issue on ASUS GL703GE, headphones doesn't work. It was working some how on Ubuntu 18.04. Now I have installed Ubuntu 20 and this headache back again. Anybody, please help. -- 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/1829568 Title: [GL703VD, Realtek ALC295, Black Headphone left and right ] No sound at all Status in alsa-driver package in Ubuntu: Won't Fix Bug description: Built-in speakers work fine. When testing headphones in sound settings, The sound indicator bar in Pulse-Audio moves. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.0.0-15.16-generic 5.0.6 Uname: Linux 5.0.0-15-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: galactic 13345 F pulseaudio /dev/snd/pcmC0D0p: galactic 13345 F...m pulseaudio CurrentDesktop: ubuntu:GNOME Date: Fri May 17 12:05:57 2019 InstallationDate: Installed on 2019-05-16 (1 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:PCH failed Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: root 8064 F pulseaudio galactic 13345 F pulseaudio /dev/snd/pcmC0D0p: galactic 13345 F...m pulseaudio Symptom_Jack: Black Headphone Out, Left Symptom_Type: No sound at all Title: [GL703VD, Realtek ALC295, Black Headphone Out, Left] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/15/2018 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: GL703VD.308 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: GL703VD dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrGL703VD.308:bd08/15/2018:svnASUSTeKCOMPUTERINC.:pnGL703VD:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnGL703VD:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.family: ROG dmi.product.name: GL703VD dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1829568/+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 1698388] Autopkgtest regression report (systemd/229-4ubuntu21.29)
All autopkgtests for the newly accepted systemd (229-4ubuntu21.29) for xenial have finished running. The following regressions have been reported in tests triggered by the package: systemd/229-4ubuntu21.29 (i386, amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/xenial/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- 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/1698388 Title: Assertion failure in journal-remote-parse.c Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: [impact] assertion failure in systemd-journal-remote [test case] only happens under specific circumstances, which is unclear exactly how to reproduce it [regression potential] any regression would likely result in the failure/crash of systemd- journal-remote program while processing data from a remote source. [scope] this is needed only for x. this is fixed by commit 9ba37525d0ef3d144a50ed5fd4710573e92b7ec1 which is included upstream starting in v230, so this is already included in b and later. [original description] I am observing the following assertion failure in systemd-journal- remote: Assertion 'source->filled <= source->size' failed at ../src/journal- remote/journal-remote-parse.c:95, function get_line(). Aborting. Systemd version: systemd 229 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN Ubuntu release: Description: Ubuntu 16.04.1 LTS Release: 16.04 Package version: systemd: Installed: 229-4ubuntu13 Candidate: 229-4ubuntu17 It looks like this issue has been fixed upstream in v230, specifically in commit 9ba37525d0ef3d144a50ed5fd4710573e92b7ec1. Could this particular commit be backported? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1698388/+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 1876018] Autopkgtest regression report (systemd/229-4ubuntu21.29)
All autopkgtests for the newly accepted systemd (229-4ubuntu21.29) for xenial
have finished running.
The following regressions have been reported in tests triggered by the package:
systemd/229-4ubuntu21.29 (i386, amd64)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/xenial/update_excuses.html#systemd
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
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/1876018
Title:
40-vm-hotadd.rules attempts to set non-existent sysfs parameters
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Xenial:
Fix Committed
Status in systemd source package in Bionic:
Fix Released
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
40-vm-hotadd.rules unconditionally tries onlining memory, which
results in logged error messages if the memory is already online
[test case]
since this rules file restricts operation to only hyper-v or xen
guests, boot a hyper-v or xen vm guest, and check for logged error
msgs like:
Apr 29 22:36:46 focal01 systemd-udevd[266]: memory7:
/usr/lib/udev/rules.d/40-vm-hotadd.rules:9 Failed to write
ATTR{/sys/devices/system/memory/memory7/state}, ignoring: Invalid
argument
alternately, to test on a vm guest other than hyper-v or xen,
comment/remove the 'GOTO="vm_hotadd_end"' line from the rules file and
reboot.
[regression potential]
as this adds a check before attempting to online memory for hyper-v
and xen vm guests, any regression would likely involve failure to
correctly online all memory on those guest platforms.
[scope]
this rule has been around for a long time, so is needed for x/b/f/g.
[original description]
In focal, udev's 40-vm-hotadd.rules (from debian/extra/rules-ubuntu)
tries to write to invalid (as of 5.4.0-1010-azure) sysfs nodes
resulting in warnings such as:
Apr 29 22:36:46 focal01 systemd-udevd[266]: memory7:
/usr/lib/udev/rules.d/40-vm-hotadd.rules:9 Failed to write
ATTR{/sys/devices/system/memory/memory7/state}, ignoring: Invalid
argument
Perhaps 40-vm-hotadd.rules needs to be updated for 5.4 semantics,
removed, or something else. This behavior is present on systems
upgraded from 18.04 (via d-r-u) as well as new focal systems, upon
first reboot of the VM.
udev: 245.4-4ubuntu3
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876018/+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 1876600] Autopkgtest regression report (systemd/229-4ubuntu21.29)
All autopkgtests for the newly accepted systemd (229-4ubuntu21.29) for xenial have finished running. The following regressions have been reported in tests triggered by the package: systemd/229-4ubuntu21.29 (i386, amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/xenial/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- 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/1876600 Title: cookie overruns can cause org.freedesktop.systemd1 dbus to hang Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Status in systemd source package in Bionic: Fix Released Bug description: [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. For services that run for longer periods of time and keep communicating through dbus, it's possible to overflow the cookie value, causing further messages to the org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue has been fixed upstream by the commit below: - sd-bus: deal with cookie overruns (1f82f5bb4237) $ git describe --contains 1f82f5bb4237 v242-rc1~228 $ rmadison systemd systemd | 229-4ubuntu4 | xenial | source, ... systemd | 229-4ubuntu21.27 | xenial-security | source, ... systemd | 229-4ubuntu21.27 | xenial-updates | source, ... systemd | 229-4ubuntu21.28 | xenial-proposed | source, ... systemd | 237-3ubuntu10| bionic | source, ... systemd | 237-3ubuntu10.38 | bionic-security | source, ... systemd | 237-3ubuntu10.39 | bionic-updates | source, ... systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... < systemd | 242-7ubuntu3 | eoan| source, ... Releases starting with Eoan already have this fix. [Test Case] There doesn't seem to be an easy test case for this, as the cookie values start at zero and won't overflow until (1<<32). There have been reports from users hitting this on Kubernetes clusters continuously running for longer periods (~5 months). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects It's essentially the example code from the sd_bus_message_new_method_call() manpage, with minor modifications: this is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x1, and set its value to 0xff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x0001reply-cookie: 0x0001 Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, , $1 = 0x1 $2 = 0xff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. Both test.c and test.gdb source code are attached to this LP bug. [Regression Potential] This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or
[Touch-packages] [Bug 1881312] Autopkgtest regression report (systemd/229-4ubuntu21.29)
All autopkgtests for the newly accepted systemd (229-4ubuntu21.29) for xenial have finished running. The following regressions have been reported in tests triggered by the package: systemd/229-4ubuntu21.29 (i386, amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/xenial/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- 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/1881312 Title: systemd-run does not make the new scope unit part of the slice specified via the --slice arg Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: [impact] running 'systemd-run --scope --slice=$SLICE $PROGRAM' does not start the program under $SLICE, instead it starts it under system.slice [test case] root:~# systemd-run --scope --slice=user-1000.slice sleep 1000 Running scope as unit run-r16d872f1b0894b88a79421a890269e6c.scope. ^Z [3]+ Stopped systemd-run --scope --slice=user-1000.slice sleep 1000 root:~# bg [3]+ systemd-run --scope --slice=user-1000.slice sleep 1000 & root:~# systemctl show -p Slice run-r16d872f1b0894b88a79421a890269e6c.scope Slice=system.slice [regression potential] This defers running the manager unit load queue when setting the slice for a transient unit, as well as actually passing the slice parameter over the bus when using --scope, so any regression would very likely involve incorrectly setting the slice for a scope and/or problems when processing transient units that specify a slice. [scope] this is needed only for Xenial. this is fixed upstream by https://github.com/systemd/systemd/pull/3094 which is included starting in v230, so is included in Bionic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1881312/+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 1877176] Autopkgtest regression report (systemd/229-4ubuntu21.29)
All autopkgtests for the newly accepted systemd (229-4ubuntu21.29) for xenial have finished running. The following regressions have been reported in tests triggered by the package: systemd/229-4ubuntu21.29 (i386, amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/xenial/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- 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/1877176 Title: 64-char hostname causes dhcp server to reject lease Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: [impact] a systemd with a 64-character hostname (the maximum hostname length for Linux) will cause a dhcp server to reject its dhcp lease due to passing the invalid hostname in the dhcp lease request. [test case] $ cat /etc/systemd/network/10-ens3.network [Match] Name=ens3 [Network] DHCP=yes set hostname to 64-char name, e.g.: $ sudo hostnamectl set-hostname a123456789b123456789c123456789d123456789e123456789f123456789g123 restart networkd: $ sudo systemctl restart systemd-networkd check logs: root@a123456789b123456789c123456789d123456789e123456789f123456789g123:~# journalctl -b -u systemd-networkd --no-pager | grep 'DHCP error' May 06 19:01:30 a123456789b123456789c123456789d123456789e123456789f123456789g123 systemd-networkd[737]: ens3: DHCP error: Client failed: Invalid argument [regression potential] Any regression would likely result in failure configuring/processing dhcpv4 server response, or rejection from the dhcpv4 server. [scope] this is fixed by commit 9740eae694e93b06658ff3b3045b22b591561e7c which is included in Bionic and later. This is needed only for Xenial. [other info] this is a follow on to bug 1862232, which corrected sd-dhcp-client.c to continue networkd dhcp even if the hostname is invalid, however the older code in Xenial doesn't correctly detect the invalid hostname, so this additional patch is needed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1877176/+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 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
I'm marking the dnsmasq bug as Invalid since this is a problem with squid/systemd. ** Changed in: squid (Ubuntu Xenial) Assignee: (unassigned) => Sergio Durigan Junior (sergiodj) ** Changed in: dnsmasq (Ubuntu Xenial) Status: Confirmed => Invalid -- 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/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in dnsmasq source package in Xenial: Invalid Status in squid source package in Xenial: Confirmed Bug description: [Impact] When using dnsmasq along with squid on Ubuntu Xenial, the user will experience a deadlock while performing on every second execution of the "systemctl start dnsmasq.service" command. The deadlock will be caused by an attempt to invoke, by nss-lookup.target, a "systemctl reload squid.service", which will itself try to start the nss- lookup.target, which will be waiting on squid, therefore eventually leading to a timeout. The underlying cause of this deadlock is related to how systemd used to handle dependencies between multiple jobs being started in the same transaction. [Test Case] One can reproduce the issue on a Xenial container: $ lxc launch ubuntu-daily:xenial squid-bug1761096 $ lxc shell squid-bug1761096 # apt update # apt install squid dnsmasq -y It is quite possible that during "apt install" the bug will manifest, and dnsmasq will fail to start due to a timeout. The user might see a message like: Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. If the bug doesn't manifest itself during installation, the following commands in sequence should trigger it: # systemctl restart dnsmasq.service # systemctl restart dnsmasq.service [Regression Potential] This change only touches the mechanism by which squid has its configuration reloaded in case of a DNS resolver change. Because "systemctl reload --no-block" returns practically immediately, if squid's configuration file is invalid the user won't see any notifications. However, this behaviour is already present currently, because "systemctl reload squid" invokes "/etc/init.d/squid reload"; the user has to check "journalctl -u squid.service" if she wants to verify whether there were any failures during the reload. Other than that, and because systemctl will offload the service to the SysV script as usual (in the case of squid), I don't foresee any potential regressions. [Original Description] Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:44:56 CEST 2018 and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s timeout Complete journalctl -xe output attached To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1761096/+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 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
** Merge proposal linked: https://code.launchpad.net/~sergiodj/ubuntu/+source/squid3/+git/squid3/+merge/390333 -- 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/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in dnsmasq source package in Xenial: Invalid Status in squid source package in Xenial: Confirmed Bug description: [Impact] When using dnsmasq along with squid on Ubuntu Xenial, the user will experience a deadlock while performing on every second execution of the "systemctl start dnsmasq.service" command. The deadlock will be caused by an attempt to invoke, by nss-lookup.target, a "systemctl reload squid.service", which will itself try to start the nss- lookup.target, which will be waiting on squid, therefore eventually leading to a timeout. The underlying cause of this deadlock is related to how systemd used to handle dependencies between multiple jobs being started in the same transaction. [Test Case] One can reproduce the issue on a Xenial container: $ lxc launch ubuntu-daily:xenial squid-bug1761096 $ lxc shell squid-bug1761096 # apt update # apt install squid dnsmasq -y It is quite possible that during "apt install" the bug will manifest, and dnsmasq will fail to start due to a timeout. The user might see a message like: Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. If the bug doesn't manifest itself during installation, the following commands in sequence should trigger it: # systemctl restart dnsmasq.service # systemctl restart dnsmasq.service [Regression Potential] This change only touches the mechanism by which squid has its configuration reloaded in case of a DNS resolver change. Because "systemctl reload --no-block" returns practically immediately, if squid's configuration file is invalid the user won't see any notifications. However, this behaviour is already present currently, because "systemctl reload squid" invokes "/etc/init.d/squid reload"; the user has to check "journalctl -u squid.service" if she wants to verify whether there were any failures during the reload. Other than that, and because systemctl will offload the service to the SysV script as usual (in the case of squid), I don't foresee any potential regressions. [Original Description] Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:44:56 CEST 2018 and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s timeout Complete journalctl -xe output attached To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1761096/+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 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
** Description changed: + [Impact] + + When using dnsmasq along with squid on Ubuntu Xenial, the user will + experience a deadlock while performing on every second execution of the + "systemctl start dnsmasq.service" command. The deadlock will be caused + by an attempt to invoke, by nss-lookup.target, a "systemctl reload + squid.service", which will itself try to start the nss-lookup.target, + which will be waiting on squid, therefore eventually leading to a + timeout. + + The underlying cause of this deadlock is related to how systemd used to + handle dependencies between multiple jobs being started in the same + transaction. + + [Test Case] + + One can reproduce the issue on a Xenial container: + + $ lxc launch ubuntu-daily:xenial squid-bug1761096 + $ lxc shell squid-bug1761096 + # apt update + # apt install squid dnsmasq -y + + It is quite possible that during "apt install" the bug will manifest, + and dnsmasq will fail to start due to a timeout. The user might see a + message like: + + Job for dnsmasq.service failed because a timeout was exceeded. See + "systemctl status dnsmasq.service" and "journalctl -xe" for details. + + If the bug doesn't manifest itself during installation, the following + commands in sequence should trigger it: + + # systemctl restart dnsmasq.service + # systemctl restart dnsmasq.service + + [Regression Potential] + + This change only touches the mechanism by which squid has its + configuration reloaded in case of a DNS resolver change. Because + "systemctl reload --no-block" returns practically immediately, if + squid's configuration file is invalid the user won't see any + notifications. However, this behaviour is already present currently, + because "systemctl reload squid" invokes "/etc/init.d/squid reload"; the + user has to check "journalctl -u squid.service" if she wants to verify + whether there were any failures during the reload. + + Other than that, and because systemctl will offload the service to the + SysV script as usual (in the case of squid), I don't foresee any + potential regressions. + + [Original Description] + Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:44:56 CEST 2018 and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s timeout Complete journalctl -xe output attached -- 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/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in dnsmasq source package in Xenial: Invalid Status in squid source package in Xenial: Confirmed Bug description: [Impact] When using dnsmasq along with squid on Ubuntu Xenial, the user will experience a deadlock while performing on every second execution of the "systemctl start dnsmasq.service" command. The deadlock will be caused by an attempt to invoke, by nss-lookup.target, a "systemctl reload squid.service", which will itself try to start the nss- lookup.target, which will be waiting on squid, therefore eventually leading to a timeout. The underlying cause of this deadlock is related to how systemd used to handle dependencies between multiple jobs being started in the same transaction. [Test
[Touch-packages] [Bug 1894338] [NEW] Earphones Volume Control doesn't work
Public bug reported: My earphones are the one coming with Samsung Galaxy S8 (here: https://www.samsung.com/us/mobile/mobile-accessories/phones/samsung- earphones-tuned-by-akg--gray-eo-ig955bsegus) and on my Ubuntu 18.04 (dual-boot with Windows 10, Secure Boot enabled) I have two issues with them (possibly should report a new bug for the second one?) 1) Trying to set the volume from my earphones' controls doesn't work, no modification on the volume, the sound bar on Ubuntu doesn't appear in order to indicate volume change. I would like to change the master volume, or whatever my common laptop controls do when I up/down the volume controls on my earphones, like it happens on Windows 10. Why does the erroneous behavior of being unable to set volume from my earphones happen? 2) Every time I boot or reboot my system and leave the earphones on, without unplugging them, i.e. when Ubuntu boots with the headphone plug already occupied, I don't get any sound from my headphones, no matter how much up and down I turn the volume (from my laptop sound controls), i.e. the sound bar moves up and down and I hear no sound. I have to unplug and re-plug my earphones and only then does Ubuntu recognize them and ask me to select "Headset/Headset with mic/Mic". How can I fix it, so that I don't have to replug every time I boot? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: pulseaudio 1:11.1-1ubuntu7.10 ProcVersionSignature: Ubuntu 4.15.0-115.116-generic 4.15.18 Uname: Linux 4.15.0-115-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.17 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: jason 3523 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Fri Sep 4 23:29:52 2020 InstallationDate: Installed on 2018-09-28 (706 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=el_GR.UTF-8 SHELL=/bin/bash SourcePackage: pulseaudio UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/17/2020 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.16.0 dmi.board.name: 02P5YY dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.16.0:bd02/17/2020:svnDellInc.:pnInspiron7570:pvr:rvnDellInc.:rn02P5YY:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: Inspiron dmi.product.name: Inspiron 7570 dmi.sys.vendor: Dell Inc. ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1894338 Title: Earphones Volume Control doesn't work Status in pulseaudio package in Ubuntu: New Bug description: My earphones are the one coming with Samsung Galaxy S8 (here: https://www.samsung.com/us/mobile/mobile-accessories/phones/samsung- earphones-tuned-by-akg--gray-eo-ig955bsegus) and on my Ubuntu 18.04 (dual-boot with Windows 10, Secure Boot enabled) I have two issues with them (possibly should report a new bug for the second one?) 1) Trying to set the volume from my earphones' controls doesn't work, no modification on the volume, the sound bar on Ubuntu doesn't appear in order to indicate volume change. I would like to change the master volume, or whatever my common laptop controls do when I up/down the volume controls on my earphones, like it happens on Windows 10. Why does the erroneous behavior of being unable to set volume from my earphones happen? 2) Every time I boot or reboot my system and leave the earphones on, without unplugging them, i.e. when Ubuntu boots with the headphone plug already occupied, I don't get any sound from my headphones, no matter how much up and down I turn the volume (from my laptop sound controls), i.e. the sound bar moves up and down and I hear no sound. I have to unplug and re-plug my earphones and only then does Ubuntu recognize them and ask me to select "Headset/Headset with mic/Mic". How can I fix it, so that I don't have to replug every time I boot? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: pulseaudio 1:11.1-1ubuntu7.10 ProcVersionSignature: Ubuntu 4.15.0-115.116-generic 4.15.18 Uname: Linux 4.15.0-115-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.17 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: jason 3523 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Fri Sep 4 23:29:52 2020 InstallationDate: Installed on 2018-09-28 (706 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=el_GR.UTF-8 SHELL=/bin/bash SourcePackage: pulseaudio UpgradeStatus: No
[Touch-packages] [Bug 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES
see also https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1774342 Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1894172 Title: isc-dhcp-server using wrong env variable for INTERFACES Status in isc-dhcp package in Ubuntu: Triaged Status in isc-dhcp source package in Bionic: Triaged Status in isc-dhcp source package in Focal: Confirmed Bug description: When checking isc-dhcp-server unit file I saw isc-dhcp-server is being started by: ConditionPathExists=/etc/default/isc-dhcp-server ConditionPathExists=|/etc/ltsp/dhcpd.conf ConditionPathExists=|/etc/dhcp/dhcpd.conf [Service] EnvironmentFile=/etc/default/isc-dhcp-server RuntimeDirectory=dhcp-server # The leases files need to be root:dhcpd even when dropping privileges ExecStart=/bin/sh -ec '\ CONFIG_FILE=/etc/dhcp/dhcpd.conf; \ if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; fi; \ [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \ chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \ chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \ exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf $CONFIG_FILE $INTERFACES' But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and $INTERFACESv6. This has only been working because cmdline sets -4 and subnet declaration in dhcpd.conf file makes dhcp-server to bind to the correct interfaces, as it looks like. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1894172/+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 1880853] Autopkgtest regression report (initramfs-tools/0.130ubuntu3.10)
All autopkgtests for the newly accepted initramfs-tools (0.130ubuntu3.10) for bionic have finished running. The following regressions have been reported in tests triggered by the package: zfs-linux/0.7.5-1ubuntu16.10 (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/bionic/update_excuses.html#initramfs-tools [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1880853 Title: libc6-lse lets update-initramfs fail on AWS m6g instances Status in cloud-images: New Status in btrfs-progs package in Ubuntu: Invalid Status in glibc package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Fix Released Status in btrfs-progs source package in Bionic: Invalid Status in glibc source package in Bionic: Invalid Status in initramfs-tools source package in Bionic: Fix Committed Status in btrfs-progs source package in Focal: Invalid Status in glibc source package in Focal: Invalid Status in initramfs-tools source package in Focal: Fix Released Bug description: [Impact] * update-initramfs -u fails on arm64 m6g instances in AWS [Test Case] * launch m6g instance in AWS * install libc6-lse (if not installed) * run $ update-initramfs -u * It should suceed * It should contain pthread, and libgcc_s libraries [Regression Potential] * Adding one more path to libgcc_s1 resolution. This will still fail if something compiles libc6 for _two_ optimisations like /lib/$arch/foo/bar/libpthread. [Other Info] * libphtread dlopens libgcc_s1, thus whenever libpthread is needed in the initrd libgcc_s1 must be copied in too. However the logic to find matching libgcc_s1 is broken for optimizied builds of libc6 without optimized build of libgcc_s1. I think libpthread should link against libgcc_s1 to prevent these issues. * Original bug report With Ubuntu 20.04 on AWS m6g.* instance family, installing libc6-lse lets update-initramfs always fail with the following error: ubuntu@ip-10-18-23-79:~$ sudo update-initramfs -u update-initramfs: Generating /boot/initrd.img-5.4.0-1011-aws E: /usr/share/initramfs-tools/hooks/btrfs failed with return 1. update-initramfs: failed for /boot/initrd.img-5.4.0-1011-aws with 1. ## Steps to reproduce (on AWS) ### With focal 20200423 AMI 1. Find the following AMI and launch on m6g instance family ubuntu/images/hvm-ssd/ubuntu-focal-20.04-arm64-server-20200423 2. Run: sudo apt update && sudo apt install libc6-lse 3. Try: sudo update-initramfs -u ### With focal 20200522 AMI 1. Find the following AMI and launch on m6g instance family ubuntu/images/hvm-ssd/ubuntu-focal-20.04-arm64-server-20200522 2. Try: sudo update-initramfs -u ## Note - The entire log of the above steps performed on 20200423 AMI is attached. - Latest cloud-image AMI "ubuntu/images/hvm-ssd/ubuntu-focal-20.04-arm64-server-20200522" includes libc6-lse. On 20200522 AMI, this doesn't reproduce after removing libc6-lse manually. - This doesn't reproduce on EC2 a1.* instance family. ## Expected behavior Does not fail. ## Background to find this bug As the 20200522 AMI includes libc6-lse out-of-the-box & apt-get upgrade pulls newer package that triggers update-initramfs, apt-get upgrade always fail on 20200522 AMI. the following is an apport report on 20200423 AMI: ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27 Architecture: arm64 CasperMD5CheckResult: skip Date: Wed May 27 09:52:16 2020 Dependencies: gcc-10-base 10-20200411-0ubuntu1 libc6 2.31-0ubuntu9 libcrypt1 1:4.4.10-10ubuntu4 libgcc-s1 10-20200411-0ubuntu1 libidn2-0 2.2.0-2 libunistring2 0.9.10-2 DistroRelease: Ubuntu 20.04 Ec2AMI: ami-061102f51d47b1c24 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: ap-northeast-1c Ec2InstanceType: m6g.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Package: libc6-lse 2.31-0ubuntu9 PackageArchitecture: arm64 ProcCpuinfoMinimal: processor : 0 BogoMIPS : 243.75 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs CPU implementer: 0x41 CPU architecture: 8 CPU variant: 0x3 CPU part : 0xd0c CPU revision : 1 ProcEnviron: LANG=C.UTF-8 TERM=screen-256color PATH=(custom, no user) SHELL=/bin/bash ProcVersionSignature: Ubuntu 5.4.0-1009.9-aws 5.4.30 SourcePackage: glibc Tags: focal ec2-images Uname: Linux 5.4.0-1009-aws aarch64 UpgradeStatus: No upgrade log present (probably fresh install)
[Touch-packages] [Bug 1222356] Re: WARNING: Couldn't register with accessibility bus: Did not receive a reply.
All GTK programs are broken. Same message: x@warp:~$ export LANG="ru_RU.UTF-8"; leafpad (leafpad:18666): dbind-WARNING **: 23:43:20.266: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Geany, Leafpad, Gedit and Opera save file dialogs don't allow Russian language input. Qt programs works fine. Launching with sudo fix problem: x@warp:~$ sudo leafpad (leafpad:28016): GLib-GIO-CRITICAL **: 00:27:57.489: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed Dbus is running. x@warp:~$ echo $DBUS_SESSION_BUS_ADDRESS unix:path=/run/user/1000/bus x@warp:~$ echo $DBUS_SESSION_BUS_PID (empty string) This happen after upgrade from 16.04.6 to 18.04.5 . Kernel 5.4.0-42-generic. I have old kernels and can test with it. PC on MSI P67S motherboard, no suspends, just XscreenSaver. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to at-spi2-core in Ubuntu. https://bugs.launchpad.net/bugs/1222356 Title: WARNING: Couldn't register with accessibility bus: Did not receive a reply. Status in at-spi2-core package in Ubuntu: Fix Released Status in at-spi2-core package in Debian: Fix Released Bug description: The following warnings/errors appear after calling ubuntu-bug ** (apport-gtk:3020): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (process:4192): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: apport-gtk 2.12.1-0ubuntu3 ProcVersionSignature: Ubuntu 3.11.0-4.9-generic 3.11.0-rc7 Uname: Linux 3.11.0-4-generic x86_64 ApportVersion: 2.12.1-0ubuntu3 Architecture: amd64 Date: Sun Sep 8 10:54:01 2013 EcryptfsInUse: Yes InstallationDate: Installed on 2012-09-01 (371 days ago) InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1) MarkForUpload: True PackageArchitecture: all SourcePackage: apport UpgradeStatus: Upgraded to saucy on 2013-09-05 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/at-spi2-core/+bug/1222356/+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 1894124] Re: Merge gtk 3.24.22 from Debian
Ah, sorry, I thought the update fell through the cracks as the 20.10 release approaches. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1894124 Title: Merge gtk 3.24.22 from Debian Status in gtk+3.0 package in Ubuntu: New Bug description: Please merge gtk 3.24.22 from Debian. It supposedly fixes bug #1891761 and improves frame clock smoothness and fixes frame clock monotonicity. https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/NEWS Overview of Changes in GTK+ 3.24.22 === * GtkTextView: - Fix some corner cases of pixelcache invalidation - Make select-all work on touch * Fix print portal support * Adwaita: - Tweak title style class - Add a public color for text view background * Windows: - Limit the size of the corner mask cache - Use native API for keycode conversion - Use GLES on arm64 * Wayland: Add a way to change the application id (LP: #1891761) * Quartz: Add axes to master devices * Add --enable-tracker3 option to configure * Translation updates: Catalan German Indonesian Italian Kazakh Spanish Turkish Overview of Changes in GTK+ 3.24.21 === * Wayland: - Prevent crashes with offscreen windows - Handle disorderly tablet/pad disconnects * GtkFileChooser: - Translate the type column - Add a tracker3 search engine - Rate-limit trash monitoring - Make get_filter work for native chooser * GtkGLArea: - Fix a redraw problem * GtkScrolledWindow: - Fix kinetic scrolling * Add a gtk-cursor-aspect-ratio setting * GDK: - Improve frame clock smoothness - Fix frame clock monotonicity * OS X: - Support Pen / Eraser input - Support openfiles in GtkApplication * Adwaita: - Improve notebook tab legibility * Translation updates: Basque Brazilian Portuguese Catalan Chinese (Taiwan) German Indonesian Italian Japanese Kazakh Lithuanian Polish Romanian Slovak Slovenian Swedish Ukrainian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1894124/+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 1893675] Autopkgtest regression report (initramfs-tools/0.136ubuntu6.3)
All autopkgtests for the newly accepted initramfs-tools (0.136ubuntu6.3) for focal have finished running. The following regressions have been reported in tests triggered by the package: initramfs-tools/0.136ubuntu6.3 (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/focal/update_excuses.html#initramfs-tools [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1893675 Title: Autopkgtest failure on latest version of initramfs-tools - lack of partprobe Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Focal: Fix Committed Status in initramfs-tools source package in Groovy: Fix Released Bug description: [Impact] * Currently the initramfs-tools autopkgtest fails for at least AMD64, with the following signature: "mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device /dev/loop0p1 does not exist." * The reason for that is the test trying immediately to use that partition on the loop device, but kernel may not have a partition re- read ioctl issued, so the test may fail as observing a nonexistent partition. * The fix proposed here is just to manually run "partprobe" before using the new to-be-discovered loop partition in the net autopkgtest. [Test Case] * Run the autopkgtest suite in the initramfs-tools package and observe the failure aforementioned. [Regression Potential] * Extremely low potential, we are just introducing a partition re-read/probe operation during autopkgtest phase, in order to keep the partition table of loop devices consistent before the test uses it. * The only potential issue I see with that is if for some reason we don't have partprobe in the autopkgtest environment, but that shouldn't happen since parted package is on ubuntu-standard. * Notice that this test is not executed in Debian CI given that CI has no support for VMs, and this test requires that. [See the Rectification below] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+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 1879987] Autopkgtest regression report (initramfs-tools/0.136ubuntu6.3)
All autopkgtests for the newly accepted initramfs-tools (0.136ubuntu6.3) for focal have finished running. The following regressions have been reported in tests triggered by the package: initramfs-tools/0.136ubuntu6.3 (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/focal/update_excuses.html#initramfs-tools [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879987 Title: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist. Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Trusty: Won't Fix Status in initramfs-tools source package in Xenial: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in initramfs-tools source package in Eoan: Won't Fix Status in initramfs-tools source package in Focal: Fix Committed Status in initramfs-tools source package in Groovy: Fix Released Bug description: [Impact] * Currently, if users provide the wrong console in kernel command-line (like console=ttyS1, when the right one is ttyS0) *and* "quiet" parameter is not provided, we may face an infinite loop on initramfs- tools, effectively blocking the boot. * Details are: the _log_msg() functions is "void" typed, which means it returns whatever its last command returns; this function is the basic building block for all error/warning messages in initramfs-tools. In case a bad console was provided to kernel on command-line, printf (and apparently all write()-related functions) returns error, and so this error is carried over in _log_msg(). * Happens that checkfs() function has a loop that runs forever in this scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is not provided in the command-line). The situation is easily reproducible. * This SRU proposes a pretty simple fix: return zero on _log_msg(). We should definitely not brake the boot due to error log functions. [Test Case] * To reproduce this, one must boot a system (virtual machine is good) with the wrong console set on kernel command-line through the "console=" parameter *and* not pass the "quiet" parameter. * Also, e2fsck tool shouldn't be present in the initrd - for that, the 6th field of /etc/fstab (fs_passno) should be 0 and initrd must be recreated after that. This is the default in Ubuntu, though. [Regression Potential] * The regression potential is small, we're just returning 0 after a printf that is executed in error paths, so I don't expect any issues from that. But in case something bad happens after this change, I expect a more friendly" breakage, like an initramfs panic (drop to a shell), not a silent failure or boot-loop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+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 1879980] Autopkgtest regression report (initramfs-tools/0.136ubuntu6.3)
All autopkgtests for the newly accepted initramfs-tools (0.136ubuntu6.3) for focal have finished running. The following regressions have been reported in tests triggered by the package: initramfs-tools/0.136ubuntu6.3 (armhf) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/focal/update_excuses.html#initramfs-tools [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Committed Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1
[Touch-packages] [Bug 1890270] Re: SRU: update gdb 9.2 for 20.04 LTS
** Description changed: SRU: update gdb 9.2 for 20.04 LTS + + according to https://sourceware.org/gdb/ this is a bug fix release: + + """ + This is a minor corrective release over GDB 9.1, fixing the following issues: + + PR tui/25586 (Resizing the source/disassembly or command window produces corrupted display) + PR gdb/25650 (GDB can't 'printf' a convenience variable holding an inferior address) + PR build/25981 (Use of short i386 register names breaks compilation on recent Solaris 11.4) + PR symtab/26003 (infinite loop loading symbols from separate debug objfile) + PR build/26029 (GDB build failure on SPARC) + """ + + Regression potential: minimal, package also not used by normal users, + but for development. + + Acceptence criteria: Package builds, no regressions in the testsuite. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1890270 Title: SRU: update gdb 9.2 for 20.04 LTS Status in gdb package in Ubuntu: New Bug description: SRU: update gdb 9.2 for 20.04 LTS according to https://sourceware.org/gdb/ this is a bug fix release: """ This is a minor corrective release over GDB 9.1, fixing the following issues: PR tui/25586 (Resizing the source/disassembly or command window produces corrupted display) PR gdb/25650 (GDB can't 'printf' a convenience variable holding an inferior address) PR build/25981 (Use of short i386 register names breaks compilation on recent Solaris 11.4) PR symtab/26003 (infinite loop loading symbols from separate debug objfile) PR build/26029 (GDB build failure on SPARC) """ Regression potential: minimal, package also not used by normal users, but for development. Acceptence criteria: Package builds, no regressions in the testsuite. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1890270/+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 1089070] Re: Could not open file /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_quantal_main_binary-amd64_Packages - open (24: Too many open files)
Check that you have less files in /var/lib/apt/lists than ulimit -n has a value. You probably have too many repositories or too low a ulimit. Otherwise, open a new bug with ubuntu-bug/apport. -- 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/1089070 Title: Could not open file /var/lib/apt/lists/archive.ubuntu .com_ubuntu_dists_quantal_main_binary-amd64_Packages - open (24: Too many open files) Status in apt package in Ubuntu: Fix Released Status in apt package in Debian: Fix Released Bug description: Apt fails if more than 40 keyrings are in use. Old description: "sudo apt-get build-dep" fails every single time with a big list of errors like the one below: E: Could not open file /var/lib/apt/lists/archive.ubuntu .com_ubuntu_dists_quantal_main_binary-amd64_Packages - open (24: Too many open files) ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: apt 0.9.7.5ubuntu5.1 ProcVersionSignature: Ubuntu 3.5.0-20.31-generic 3.5.7.1 Uname: Linux 3.5.0-20-generic x86_64 ApportVersion: 2.6.1-0ubuntu9 Architecture: amd64 Date: Tue Dec 11 20:58:30 2012 InstallationDate: Installed on 2012-09-14 (88 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120914) MarkForUpload: True SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1089070/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1884887] Re: rsyslogd dmesg unit leaves /var/log/dmesg* world readable
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: rsyslog (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1884887 Title: rsyslogd dmesg unit leaves /var/log/dmesg* world readable Status in rsyslog package in Ubuntu: Confirmed Bug description: [Impact] The rsyslog dmesg systemd unit /lib/systemd/system/dmesg.service in eoan, focal, and groovy create /var/log/dmesg* with the following permissions: -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg Most other system logs in /var/log/ are only readable by root and group adm. While it's true that the kernel dmesg buffer by default can be read by anyone using the dmesg(1) command, this can be disabled by setting the sysctl kernel.dmesg_restrict to 1, but doing so as a hardening measure is thwarted by the world readable nature of /var/log/dmesg. The reason dmesg output is sensitive is that it sometimes contains kernel addresses for diagnosing kernel problems, but attackers looking to attack a kernel are also interested in kernel addresses and other information that shows up there. [Test Case] To reproduce: $ ls -l /var/log/dmesg* should show only root and group adm access like so: -rw-r- 1 root adm 50178 Jun 23 12:55 /var/log/dmesg -rw-r- 1 root adm 50217 Jun 23 12:55 /var/log/dmesg.0 -rw-r- 1 root adm 13941 Jun 23 12:47 /var/log/dmesg.1.gz and not world readable: -rw-r--r-- 1 root adm 45146 Jun 16 12:32 /var/log/dmesg [Regression Potential] It's possible tools like apport and others might expect /var/log/dmesg to be world-readable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1884887/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1880853] Re: libc6-lse lets update-initramfs fail on AWS m6g instances
Hello Sorah, or anyone else affected, Accepted initramfs-tools into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs- tools/0.130ubuntu3.10 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: initramfs-tools (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags removed: verification-done ** Tags added: verification-needed verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1880853 Title: libc6-lse lets update-initramfs fail on AWS m6g instances Status in cloud-images: New Status in btrfs-progs package in Ubuntu: Invalid Status in glibc package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Fix Released Status in btrfs-progs source package in Bionic: Invalid Status in glibc source package in Bionic: Invalid Status in initramfs-tools source package in Bionic: Fix Committed Status in btrfs-progs source package in Focal: Invalid Status in glibc source package in Focal: Invalid Status in initramfs-tools source package in Focal: Fix Released Bug description: [Impact] * update-initramfs -u fails on arm64 m6g instances in AWS [Test Case] * launch m6g instance in AWS * install libc6-lse (if not installed) * run $ update-initramfs -u * It should suceed * It should contain pthread, and libgcc_s libraries [Regression Potential] * Adding one more path to libgcc_s1 resolution. This will still fail if something compiles libc6 for _two_ optimisations like /lib/$arch/foo/bar/libpthread. [Other Info] * libphtread dlopens libgcc_s1, thus whenever libpthread is needed in the initrd libgcc_s1 must be copied in too. However the logic to find matching libgcc_s1 is broken for optimizied builds of libc6 without optimized build of libgcc_s1. I think libpthread should link against libgcc_s1 to prevent these issues. * Original bug report With Ubuntu 20.04 on AWS m6g.* instance family, installing libc6-lse lets update-initramfs always fail with the following error: ubuntu@ip-10-18-23-79:~$ sudo update-initramfs -u update-initramfs: Generating /boot/initrd.img-5.4.0-1011-aws E: /usr/share/initramfs-tools/hooks/btrfs failed with return 1. update-initramfs: failed for /boot/initrd.img-5.4.0-1011-aws with 1. ## Steps to reproduce (on AWS) ### With focal 20200423 AMI 1. Find the following AMI and launch on m6g instance family ubuntu/images/hvm-ssd/ubuntu-focal-20.04-arm64-server-20200423 2. Run: sudo apt update && sudo apt install libc6-lse 3. Try: sudo update-initramfs -u ### With focal 20200522 AMI 1. Find the following AMI and launch on m6g instance family ubuntu/images/hvm-ssd/ubuntu-focal-20.04-arm64-server-20200522 2. Try: sudo update-initramfs -u ## Note - The entire log of the above steps performed on 20200423 AMI is attached. - Latest cloud-image AMI "ubuntu/images/hvm-ssd/ubuntu-focal-20.04-arm64-server-20200522" includes libc6-lse. On 20200522 AMI, this doesn't reproduce after removing libc6-lse manually. - This doesn't reproduce on EC2 a1.* instance family. ## Expected behavior Does not fail. ## Background to find this bug As the 20200522 AMI includes libc6-lse out-of-the-box & apt-get upgrade pulls newer package that triggers update-initramfs, apt-get upgrade always fail on 20200522 AMI. the following is an apport report on 20200423 AMI: ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27 Architecture: arm64 CasperMD5CheckResult: skip Date: Wed May 27 09:52:16 2020 Dependencies: gcc-10-base 10-20200411-0ubuntu1 libc6 2.31-0ubuntu9 libcrypt1 1:4.4.10-10ubuntu4 libgcc-s1 10-20200411-0ubuntu1 libidn2-0 2.2.0-2 libunistring2 0.9.10-2 DistroRelease: Ubuntu 20.04
[Touch-packages] [Bug 1089070] Re: Could not open file /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_quantal_main_binary-amd64_Packages - open (24: Too many open files)
@juliank It's not fixed : $ aptitude search -F '%p' "?origin(jonathonf-vim) ( ?architecture(amd64) | ?architecture(all) ) ?installed" E: Could not open file /var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_trusty_universe_binary-i386_Packages - open (24: Too many open files) E: Could not open file /var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_trusty_restricted_binary-i386_Packages - open (24: Too many open files) E: Could not open file /var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_trusty_main_binary-i386_Packages - open (24: Too many open files) E: Could not open file /var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_trusty_multiverse_binary-amd64_Packages - open (24: Too many open files) E: Could not open file /var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_trusty_universe_binary-amd64_Packages - open (24: Too many open files) E: Could not open file /var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_trusty_restricted_binary-amd64_Packages - open (24: Too many open files) E: Could not open file /var/lib/apt/lists/fr.archive.ubuntu.com_ubuntu_dists_trusty_main_binary-amd64_Packages - open (24: Too many open files) $ echo $? 255 Can you please change the status back to "Confirmed" ? -- 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/1089070 Title: Could not open file /var/lib/apt/lists/archive.ubuntu .com_ubuntu_dists_quantal_main_binary-amd64_Packages - open (24: Too many open files) Status in apt package in Ubuntu: Fix Released Status in apt package in Debian: Fix Released Bug description: Apt fails if more than 40 keyrings are in use. Old description: "sudo apt-get build-dep" fails every single time with a big list of errors like the one below: E: Could not open file /var/lib/apt/lists/archive.ubuntu .com_ubuntu_dists_quantal_main_binary-amd64_Packages - open (24: Too many open files) ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: apt 0.9.7.5ubuntu5.1 ProcVersionSignature: Ubuntu 3.5.0-20.31-generic 3.5.7.1 Uname: Linux 3.5.0-20-generic x86_64 ApportVersion: 2.6.1-0ubuntu9 Architecture: amd64 Date: Tue Dec 11 20:58:30 2012 InstallationDate: Installed on 2012-09-14 (88 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120914) MarkForUpload: True SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1089070/+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 1877078] Re: Please ship empty /etc/fstab in LXD images
** Changed in: systemd (Ubuntu) Status: Triaged => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1877078 Title: Please ship empty /etc/fstab in LXD images Status in livecd-rootfs package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Invalid Bug description: Systemd boots degraded because of the invalid content of /etc/fstab: $ lxc shell gg-test root@gg-test:~# systemctl is-system-running degraded root@gg-test:~# systemctl list-units --failed UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-remount-fs.service loaded failed failed Remount Root and Kernel File Systems LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB= The low-level unit activation state, values depend on unit type. 1 loaded units listed. root@gg-test:~# cat /etc/fstab LABEL=cloudimg-rootfs /ext4 defaults0 0 root@gg-test:~# echo "" > /etc/fstab root@gg-test:~# reboot Session terminated, killing shell... ...killed. rbalint@yogi:~$ lxc shell gg-test root@gg-test:~# systemctl is-system-running running root@gg-test:~# systemctl list-units --failed UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. Not shipping is also fixing the issue, but some programs (such as systemd autopkgtes) reads fstab and a missing fstab should be special-cased, thus that would cause more breakages. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1877078/+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 1847738] Re: Empty item in folder context menu
The issue was reported upstream as https://gitlab.gnome.org/GNOME/nautilus/-/issues/1394 and flagged as a GTK bug ** Bug watch added: gitlab.gnome.org/GNOME/nautilus/-/issues #1394 https://gitlab.gnome.org/GNOME/nautilus/-/issues/1394 ** Package changed: nautilus (Ubuntu) => gtk+3.0 (Ubuntu) ** Changed in: gtk+3.0 (Ubuntu) Importance: Undecided => Low ** Changed in: gtk+3.0 (Ubuntu) Status: Confirmed => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1847738 Title: Empty item in folder context menu Status in gtk+3.0 package in Ubuntu: Triaged Bug description: Installed 19.10 from a daily image today (also issue on my current laptop which was upgraded from 19.04). Steps to reproduce Open nautilus Right click a file (example.desktop for example) Note the context menu looks okay Right click a folder (such as Downloads) Note the context menu has a blank entry at the bottom, beneath "Properties" Expected No blank line ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: nautilus 1:3.34.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-17.18-generic 5.3.1 Uname: Linux 5.3.0-17-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Oct 11 11:01:25 2019 GsettingsChanges: b'org.gnome.nautilus.preferences' b'default-folder-viewer' b"'list-view'" InstallationDate: Installed on 2019-10-11 (0 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Beta amd64 (20191011) SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1847738/+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 1847738] [NEW] Empty item in folder context menu
You have been subscribed to a public bug: Installed 19.10 from a daily image today (also issue on my current laptop which was upgraded from 19.04). Steps to reproduce Open nautilus Right click a file (example.desktop for example) Note the context menu looks okay Right click a folder (such as Downloads) Note the context menu has a blank entry at the bottom, beneath "Properties" Expected No blank line ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: nautilus 1:3.34.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-17.18-generic 5.3.1 Uname: Linux 5.3.0-17-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Oct 11 11:01:25 2019 GsettingsChanges: b'org.gnome.nautilus.preferences' b'default-folder-viewer' b"'list-view'" InstallationDate: Installed on 2019-10-11 (0 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Beta amd64 (20191011) SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: ** Affects: gtk+3.0 (Ubuntu) Importance: Low Status: Triaged ** Tags: amd64 apport-bug eoan -- Empty item in folder context menu https://bugs.launchpad.net/bugs/1847738 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 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 1888352] Re: use builtin dump_acpi_tables.py in hookutils
Hello Yuan-Chen, or anyone else affected, Accepted apport into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apport/2.20.11-0ubuntu27.9 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: apport (Ubuntu Focal) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1888352 Title: use builtin dump_acpi_tables.py in hookutils Status in Apport: New Status in OEM Priority Project: Confirmed Status in apport package in Ubuntu: Fix Released Status in apport source package in Focal: Fix Committed Status in apport source package in Groovy: Fix Released Bug description: 1. add apcidump to hookutils.py:attach_hardware and use the builtin dump_acpi_tables.py. 2. remove explicit acpidump from oem-getlogs to use the builtin one. 3. refine usage string in oem-getlogs. To SRU to focal: [Impact] * for OEM project, lts is been used. And collect log is important. With built-in tool to get acpidump, we don't need to install extra tool in the end-customer's machine. That make it much easier for the oem process. * By call built-in utility, we no lounger need to install extra tools to collect data that's both complete and convenient for HWE people to work on. [Test Case] * before this applied, run oem-getlog without install acpidump. we can't get the dump data. After this applied, we can just dump the data HWE need. * test step: install the new package, run sudo -E oem-getlogs [-c case_id] to get the use apport-unpack to unpack the apport file. check the acpidump file. HWE people know much better on check the acpidump file. Give the dump_acpi_tables.py just updated and SRUed by HWE/ACPI/UEFI expert, it's pretty safe to do so. [Regression Potential] * Given the modification change the way to collect log, even it failed, it won't break apport itself. Just the collected log might contain data not so valid. * Given acpidump mostly used by HWE/ACIP/UEFI expert, and they just reviewed and updated the dump_acpi_tables.py script, I believe it will have good quality. To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1888352/+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 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.
Hello Eric, or anyone else affected, Accepted initramfs-tools into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs- tools/0.136ubuntu6.3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: initramfs-tools (Ubuntu Focal) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879987 Title: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist. Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Trusty: Won't Fix Status in initramfs-tools source package in Xenial: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in initramfs-tools source package in Eoan: Won't Fix Status in initramfs-tools source package in Focal: Fix Committed Status in initramfs-tools source package in Groovy: Fix Released Bug description: [Impact] * Currently, if users provide the wrong console in kernel command-line (like console=ttyS1, when the right one is ttyS0) *and* "quiet" parameter is not provided, we may face an infinite loop on initramfs- tools, effectively blocking the boot. * Details are: the _log_msg() functions is "void" typed, which means it returns whatever its last command returns; this function is the basic building block for all error/warning messages in initramfs-tools. In case a bad console was provided to kernel on command-line, printf (and apparently all write()-related functions) returns error, and so this error is carried over in _log_msg(). * Happens that checkfs() function has a loop that runs forever in this scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is not provided in the command-line). The situation is easily reproducible. * This SRU proposes a pretty simple fix: return zero on _log_msg(). We should definitely not brake the boot due to error log functions. [Test Case] * To reproduce this, one must boot a system (virtual machine is good) with the wrong console set on kernel command-line through the "console=" parameter *and* not pass the "quiet" parameter. * Also, e2fsck tool shouldn't be present in the initrd - for that, the 6th field of /etc/fstab (fs_passno) should be 0 and initrd must be recreated after that. This is the default in Ubuntu, though. [Regression Potential] * The regression potential is small, we're just returning 0 after a printf that is executed in error paths, so I don't expect any issues from that. But in case something bad happens after this change, I expect a more friendly" breakage, like an initramfs panic (drop to a shell), not a silent failure or boot-loop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+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 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
Hello Guilherme, or anyone else affected, Accepted initramfs-tools into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs- tools/0.136ubuntu6.3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: initramfs-tools (Ubuntu Focal) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Committed Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential
[Touch-packages] [Bug 1893675] Re: Autopkgtest failure on latest version of initramfs-tools - lack of partprobe
Hello Guilherme, or anyone else affected, Accepted initramfs-tools into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs- tools/0.136ubuntu6.3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: initramfs-tools (Ubuntu Focal) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1893675 Title: Autopkgtest failure on latest version of initramfs-tools - lack of partprobe Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Focal: Fix Committed Status in initramfs-tools source package in Groovy: Fix Released Bug description: [Impact] * Currently the initramfs-tools autopkgtest fails for at least AMD64, with the following signature: "mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device /dev/loop0p1 does not exist." * The reason for that is the test trying immediately to use that partition on the loop device, but kernel may not have a partition re- read ioctl issued, so the test may fail as observing a nonexistent partition. * The fix proposed here is just to manually run "partprobe" before using the new to-be-discovered loop partition in the net autopkgtest. [Test Case] * Run the autopkgtest suite in the initramfs-tools package and observe the failure aforementioned. [Regression Potential] * Extremely low potential, we are just introducing a partition re-read/probe operation during autopkgtest phase, in order to keep the partition table of loop devices consistent before the test uses it. * The only potential issue I see with that is if for some reason we don't have partprobe in the autopkgtest environment, but that shouldn't happen since parted package is on ubuntu-standard. * Notice that this test is not executed in Debian CI given that CI has no support for VMs, and this test requires that. [See the Rectification below] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
On Friday, September 04 2020, Christian Ehrhardt wrote: > Thanks for --no-ask-password Sergio. > > I like the suggestion of making /etc/resolvconf/update-libc.d/squid systemd > aware. >>From similar checks I know that you also want to check if it is active: > > if [ -d /run/systemd/system ]; then > ! systemctl is-active -q squid.service || systemctl reload squid.service > >/dev/null > > The above is untested, but you get my point - don't reload if it isn't > active. Thanks, Christian. Good point about checking whether the service is active; I'll incorporate that into the solution. I'll prepare an MP soon, then. Cheers, -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14 -- 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/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in dnsmasq source package in Xenial: Confirmed Status in squid source package in Xenial: Confirmed Bug description: Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:44:56 CEST 2018 and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s timeout Complete journalctl -xe output attached To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1761096/+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 1894195] Re: FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main)
** Description changed: Please merge iptables 1.8.5-3 (main) from Debian sid (main) Explanation of FeatureFreeze exception: - Current iptables is using the same upstream version in focal, which had problem with the nft backend and was then reverted to the legacy backend. - 1.8.5 has many fixed for the -nft backend. + Current iptables is using the same upstream version in focal, which had problems with the nft backend and was then reverted to the legacy backend. + 1.8.5 has many fixed for the nft backend. + For example these Debian bugs are fixed in 1.8.5: + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950535 + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961117 + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968457 Please merge it. Changelog entries since current groovy version 1.8.4-3ubuntu3: iptables (1.8.5-3) unstable; urgency=medium - * [2d587e5] src:iptables: bump build-dep version on libnftnl to 1.1.6 + * [2d587e5] src:iptables: bump build-dep version on libnftnl to 1.1.6 - -- Arturo Borrero Gonzalez Tue, 25 Aug 2020 + -- Arturo Borrero Gonzalez Tue, 25 Aug 2020 11:56:55 +0200 iptables (1.8.5-2) unstable; urgency=medium - [ Alberto Molina Coballes ] - * [d90516d] d/control: modify breaks and replaces fields (Closes: #949576) - * [4754a45] d/not-installed: arch independ files - * [780330f] d/tests/control: Run iptables-legacy-* tests explicitly + [ Alberto Molina Coballes ] + * [d90516d] d/control: modify breaks and replaces fields (Closes: #949576) + * [4754a45] d/not-installed: arch independ files + * [780330f] d/tests/control: Run iptables-legacy-* tests explicitly - [ Arturo Borrero Gonzalez ] - * [6fb6557] d/patches: add -upstream-fix-xtables-translate.patch - (Closes: #962724) + [ Arturo Borrero Gonzalez ] + * [6fb6557] d/patches: add -upstream-fix-xtables-translate.patch + (Closes: #962724) - -- Arturo Borrero Gonzalez Wed, 24 Jun 2020 + -- Arturo Borrero Gonzalez Wed, 24 Jun 2020 10:56:19 +0200 iptables (1.8.5-1) unstable; urgency=medium - [ Debian Janitor ] - * [c3deeb3] Wrap long lines in changelog entries: 1.8.2-1, 1.8.0-1~exp1, - 1.6.0-1. - * [214468e] Update standards version to 4.5.0, no changes needed. + [ Debian Janitor ] + * [c3deeb3] Wrap long lines in changelog entries: 1.8.2-1, 1.8.0-1~exp1, + 1.6.0-1. + * [214468e] Update standards version to 4.5.0, no changes needed. - [ Arturo Borrero Gonzalez ] - * [eb1d7c5] New upstream version 1.8.5 (Closes: #950535) - * [7a119db] d/patches: drop all patches - * [ec63c87] libxtables12.symbols: add new symbol - * [4056ce6] iptables: bump debhelper-compat to 13 + [ Arturo Borrero Gonzalez ] + * [eb1d7c5] New upstream version 1.8.5 (Closes: #950535) + * [7a119db] d/patches: drop all patches + * [ec63c87] libxtables12.symbols: add new symbol + * [4056ce6] iptables: bump debhelper-compat to 13 - -- Arturo Borrero Gonzalez Thu, 04 Jun 2020 + -- Arturo Borrero Gonzalez Thu, 04 Jun 2020 13:33:22 +0200 ** Description changed: Please merge iptables 1.8.5-3 (main) from Debian sid (main) Explanation of FeatureFreeze exception: Current iptables is using the same upstream version in focal, which had problems with the nft backend and was then reverted to the legacy backend. - 1.8.5 has many fixed for the nft backend. - For example these Debian bugs are fixed in 1.8.5: + 1.8.5 has many fixes for the nft backend. For example these Debian bugs are fixed in 1.8.5: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950535 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961117 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968457 Please merge it. Changelog entries since current groovy version 1.8.4-3ubuntu3: iptables (1.8.5-3) unstable; urgency=medium * [2d587e5] src:iptables: bump build-dep version on libnftnl to 1.1.6 -- Arturo Borrero Gonzalez Tue, 25 Aug 2020 11:56:55 +0200 iptables (1.8.5-2) unstable; urgency=medium [ Alberto Molina Coballes ] * [d90516d] d/control: modify breaks and replaces fields (Closes: #949576) * [4754a45] d/not-installed: arch independ files * [780330f] d/tests/control: Run iptables-legacy-* tests explicitly [ Arturo Borrero Gonzalez ] * [6fb6557] d/patches: add -upstream-fix-xtables-translate.patch (Closes: #962724) -- Arturo Borrero Gonzalez Wed, 24 Jun 2020 10:56:19 +0200 iptables (1.8.5-1) unstable; urgency=medium [ Debian Janitor ] * [c3deeb3] Wrap long lines in changelog entries: 1.8.2-1, 1.8.0-1~exp1, 1.6.0-1. * [214468e] Update standards version to 4.5.0, no changes needed. [ Arturo Borrero Gonzalez ] * [eb1d7c5] New upstream version 1.8.5 (Closes: #950535) * [7a119db] d/patches: drop all patches * [ec63c87] libxtables12.symbols: add new symbol * [4056ce6] iptables: bump debhelper-compat to 13 --
[Touch-packages] [Bug 1887186] Re: Please switch to nftables as the default backend
Done in 1.8.4-3ubuntu3. ** Changed in: iptables (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1887186 Title: Please switch to nftables as the default backend Status in iptables package in Ubuntu: Fix Released Bug description: The iptables package in Ubuntu already made the switch but it was reverted in LP: #1843468 due to breaking reverse dependencies and software not packaged in the Ubuntu Archive. The switch of the default backend is also a preparation for making the nftables frontend to be the preferred tool for interfacing the Netfilter framework, thus please Recommend: it. Inclusion of the nftables package in main is traced at LP: #1887187. I've prepared a Bileto ticket for staging and testing the packages which need to be changed: https://bileto.ubuntu.com/#/ticket/4044 The updated package break any package or project, please mark them affected and/or leave a commend in this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1887186/+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 1893958] Re: [FFe] Please accept iptables 1.8.4-3ubuntu3 switching to nftables backend
> If 1.8.5 fixes bugs then we should take that for sure - please could you make > sure to do that (can be later, but not much later)? See bug 1894195. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1893958 Title: [FFe] Please accept iptables 1.8.4-3ubuntu3 switching to nftables backend Status in iptables package in Ubuntu: Fix Released Bug description: The change is a planned change for this development cycle and the fix has been tested as described in LP: #1887186 and https://lists.ubuntu.com/archives/ubuntu-devel/2020-August/041142.html . Changes: iptables (1.8.4-3ubuntu3) groovy; urgency=medium . * Swap alternative priority and prefer nftables backend over legacy (LP: #1887186) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1893958/+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 1894195] [NEW] FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main)
Public bug reported: Please merge iptables 1.8.5-3 (main) from Debian sid (main) Explanation of FeatureFreeze exception: Current iptables is using the same upstream version in focal, which had problem with the nft backend and was then reverted to the legacy backend. 1.8.5 has many fixed for the -nft backend. Please merge it. Changelog entries since current groovy version 1.8.4-3ubuntu3: iptables (1.8.5-3) unstable; urgency=medium * [2d587e5] src:iptables: bump build-dep version on libnftnl to 1.1.6 -- Arturo Borrero Gonzalez Tue, 25 Aug 2020 11:56:55 +0200 iptables (1.8.5-2) unstable; urgency=medium [ Alberto Molina Coballes ] * [d90516d] d/control: modify breaks and replaces fields (Closes: #949576) * [4754a45] d/not-installed: arch independ files * [780330f] d/tests/control: Run iptables-legacy-* tests explicitly [ Arturo Borrero Gonzalez ] * [6fb6557] d/patches: add -upstream-fix-xtables-translate.patch (Closes: #962724) -- Arturo Borrero Gonzalez Wed, 24 Jun 2020 10:56:19 +0200 iptables (1.8.5-1) unstable; urgency=medium [ Debian Janitor ] * [c3deeb3] Wrap long lines in changelog entries: 1.8.2-1, 1.8.0-1~exp1, 1.6.0-1. * [214468e] Update standards version to 4.5.0, no changes needed. [ Arturo Borrero Gonzalez ] * [eb1d7c5] New upstream version 1.8.5 (Closes: #950535) * [7a119db] d/patches: drop all patches * [ec63c87] libxtables12.symbols: add new symbol * [4056ce6] iptables: bump debhelper-compat to 13 -- Arturo Borrero Gonzalez Thu, 04 Jun 2020 13:33:22 +0200 ** Affects: iptables (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1894195 Title: FFe: Merge iptables 1.8.5-3 (main) from Debian sid (main) Status in iptables package in Ubuntu: New Bug description: Please merge iptables 1.8.5-3 (main) from Debian sid (main) Explanation of FeatureFreeze exception: Current iptables is using the same upstream version in focal, which had problem with the nft backend and was then reverted to the legacy backend. 1.8.5 has many fixed for the -nft backend. Please merge it. Changelog entries since current groovy version 1.8.4-3ubuntu3: iptables (1.8.5-3) unstable; urgency=medium * [2d587e5] src:iptables: bump build-dep version on libnftnl to 1.1.6 -- Arturo Borrero Gonzalez Tue, 25 Aug 2020 11:56:55 +0200 iptables (1.8.5-2) unstable; urgency=medium [ Alberto Molina Coballes ] * [d90516d] d/control: modify breaks and replaces fields (Closes: #949576) * [4754a45] d/not-installed: arch independ files * [780330f] d/tests/control: Run iptables-legacy-* tests explicitly [ Arturo Borrero Gonzalez ] * [6fb6557] d/patches: add -upstream-fix-xtables-translate.patch (Closes: #962724) -- Arturo Borrero Gonzalez Wed, 24 Jun 2020 10:56:19 +0200 iptables (1.8.5-1) unstable; urgency=medium [ Debian Janitor ] * [c3deeb3] Wrap long lines in changelog entries: 1.8.2-1, 1.8.0-1~exp1, 1.6.0-1. * [214468e] Update standards version to 4.5.0, no changes needed. [ Arturo Borrero Gonzalez ] * [eb1d7c5] New upstream version 1.8.5 (Closes: #950535) * [7a119db] d/patches: drop all patches * [ec63c87] libxtables12.symbols: add new symbol * [4056ce6] iptables: bump debhelper-compat to 13 -- Arturo Borrero Gonzalez Thu, 04 Jun 2020 13:33:22 +0200 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1894195/+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 1698388] Please test proposed package
Hello Ruud, or anyone else affected, Accepted systemd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu21.29 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-xenial. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. -- 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/1698388 Title: Assertion failure in journal-remote-parse.c Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: [impact] assertion failure in systemd-journal-remote [test case] only happens under specific circumstances, which is unclear exactly how to reproduce it [regression potential] any regression would likely result in the failure/crash of systemd- journal-remote program while processing data from a remote source. [scope] this is needed only for x. this is fixed by commit 9ba37525d0ef3d144a50ed5fd4710573e92b7ec1 which is included upstream starting in v230, so this is already included in b and later. [original description] I am observing the following assertion failure in systemd-journal- remote: Assertion 'source->filled <= source->size' failed at ../src/journal- remote/journal-remote-parse.c:95, function get_line(). Aborting. Systemd version: systemd 229 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN Ubuntu release: Description: Ubuntu 16.04.1 LTS Release: 16.04 Package version: systemd: Installed: 229-4ubuntu13 Candidate: 229-4ubuntu17 It looks like this issue has been fixed upstream in v230, specifically in commit 9ba37525d0ef3d144a50ed5fd4710573e92b7ec1. Could this particular commit be backported? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1698388/+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 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang
Hello Heitor, or anyone else affected, Accepted systemd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu21.29 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-xenial. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: systemd (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags removed: verification-done ** Tags added: verification-needed verification-needed-xenial -- 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/1876600 Title: cookie overruns can cause org.freedesktop.systemd1 dbus to hang Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Status in systemd source package in Bionic: Fix Released Bug description: [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. For services that run for longer periods of time and keep communicating through dbus, it's possible to overflow the cookie value, causing further messages to the org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue has been fixed upstream by the commit below: - sd-bus: deal with cookie overruns (1f82f5bb4237) $ git describe --contains 1f82f5bb4237 v242-rc1~228 $ rmadison systemd systemd | 229-4ubuntu4 | xenial | source, ... systemd | 229-4ubuntu21.27 | xenial-security | source, ... systemd | 229-4ubuntu21.27 | xenial-updates | source, ... systemd | 229-4ubuntu21.28 | xenial-proposed | source, ... systemd | 237-3ubuntu10| bionic | source, ... systemd | 237-3ubuntu10.38 | bionic-security | source, ... systemd | 237-3ubuntu10.39 | bionic-updates | source, ... systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... < systemd | 242-7ubuntu3 | eoan| source, ... Releases starting with Eoan already have this fix. [Test Case] There doesn't seem to be an easy test case for this, as the cookie values start at zero and won't overflow until (1<<32). There have been reports from users hitting this on Kubernetes clusters continuously running for longer periods (~5 months). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects It's essentially the example code from the sd_bus_message_new_method_call() manpage, with minor modifications: this is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x1, and set its value to 0xff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x0001reply-cookie: 0x0001 Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, , $1 = 0x1 $2 = 0xff00 Call failed: Operation not supported Sleeping and
[Touch-packages] [Bug 1876018] Re: 40-vm-hotadd.rules attempts to set non-existent sysfs parameters
Hello Jose, or anyone else affected,
Accepted systemd into xenial-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu21.29 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
xenial to verification-done-xenial. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-xenial. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Changed in: systemd (Ubuntu Xenial)
Status: In Progress => Fix Committed
** Tags removed: verification-done
** Tags added: verification-needed verification-needed-xenial
--
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/1876018
Title:
40-vm-hotadd.rules attempts to set non-existent sysfs parameters
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Xenial:
Fix Committed
Status in systemd source package in Bionic:
Fix Released
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
40-vm-hotadd.rules unconditionally tries onlining memory, which
results in logged error messages if the memory is already online
[test case]
since this rules file restricts operation to only hyper-v or xen
guests, boot a hyper-v or xen vm guest, and check for logged error
msgs like:
Apr 29 22:36:46 focal01 systemd-udevd[266]: memory7:
/usr/lib/udev/rules.d/40-vm-hotadd.rules:9 Failed to write
ATTR{/sys/devices/system/memory/memory7/state}, ignoring: Invalid
argument
alternately, to test on a vm guest other than hyper-v or xen,
comment/remove the 'GOTO="vm_hotadd_end"' line from the rules file and
reboot.
[regression potential]
as this adds a check before attempting to online memory for hyper-v
and xen vm guests, any regression would likely involve failure to
correctly online all memory on those guest platforms.
[scope]
this rule has been around for a long time, so is needed for x/b/f/g.
[original description]
In focal, udev's 40-vm-hotadd.rules (from debian/extra/rules-ubuntu)
tries to write to invalid (as of 5.4.0-1010-azure) sysfs nodes
resulting in warnings such as:
Apr 29 22:36:46 focal01 systemd-udevd[266]: memory7:
/usr/lib/udev/rules.d/40-vm-hotadd.rules:9 Failed to write
ATTR{/sys/devices/system/memory/memory7/state}, ignoring: Invalid
argument
Perhaps 40-vm-hotadd.rules needs to be updated for 5.4 semantics,
removed, or something else. This behavior is present on systems
upgraded from 18.04 (via d-r-u) as well as new focal systems, upon
first reboot of the VM.
udev: 245.4-4ubuntu3
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876018/+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 1698388] Re: Assertion failure in journal-remote-parse.c
It's a bit unfortunate that we don't have a test case for this assertion failure. That being said, the fix for it seems rather safe and sane. Still, I would like us to try and contact with the original reporter and ask him to test it, if possible. ** Changed in: systemd (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-xenial -- 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/1698388 Title: Assertion failure in journal-remote-parse.c Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: [impact] assertion failure in systemd-journal-remote [test case] only happens under specific circumstances, which is unclear exactly how to reproduce it [regression potential] any regression would likely result in the failure/crash of systemd- journal-remote program while processing data from a remote source. [scope] this is needed only for x. this is fixed by commit 9ba37525d0ef3d144a50ed5fd4710573e92b7ec1 which is included upstream starting in v230, so this is already included in b and later. [original description] I am observing the following assertion failure in systemd-journal- remote: Assertion 'source->filled <= source->size' failed at ../src/journal- remote/journal-remote-parse.c:95, function get_line(). Aborting. Systemd version: systemd 229 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN Ubuntu release: Description: Ubuntu 16.04.1 LTS Release: 16.04 Package version: systemd: Installed: 229-4ubuntu13 Candidate: 229-4ubuntu17 It looks like this issue has been fixed upstream in v230, specifically in commit 9ba37525d0ef3d144a50ed5fd4710573e92b7ec1. Could this particular commit be backported? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1698388/+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 1877176] Re: 64-char hostname causes dhcp server to reject lease
Hello Dan, or anyone else affected, Accepted systemd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu21.29 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-xenial. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: systemd (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-xenial -- 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/1877176 Title: 64-char hostname causes dhcp server to reject lease Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: [impact] a systemd with a 64-character hostname (the maximum hostname length for Linux) will cause a dhcp server to reject its dhcp lease due to passing the invalid hostname in the dhcp lease request. [test case] $ cat /etc/systemd/network/10-ens3.network [Match] Name=ens3 [Network] DHCP=yes set hostname to 64-char name, e.g.: $ sudo hostnamectl set-hostname a123456789b123456789c123456789d123456789e123456789f123456789g123 restart networkd: $ sudo systemctl restart systemd-networkd check logs: root@a123456789b123456789c123456789d123456789e123456789f123456789g123:~# journalctl -b -u systemd-networkd --no-pager | grep 'DHCP error' May 06 19:01:30 a123456789b123456789c123456789d123456789e123456789f123456789g123 systemd-networkd[737]: ens3: DHCP error: Client failed: Invalid argument [regression potential] Any regression would likely result in failure configuring/processing dhcpv4 server response, or rejection from the dhcpv4 server. [scope] this is fixed by commit 9740eae694e93b06658ff3b3045b22b591561e7c which is included in Bionic and later. This is needed only for Xenial. [other info] this is a follow on to bug 1862232, which corrected sd-dhcp-client.c to continue networkd dhcp even if the hostname is invalid, however the older code in Xenial doesn't correctly detect the invalid hostname, so this additional patch is needed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1877176/+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 1881312] Re: systemd-run does not make the new scope unit part of the slice specified via the --slice arg
Hello Dan, or anyone else affected, Accepted systemd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu21.29 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-xenial. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: systemd (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-xenial -- 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/1881312 Title: systemd-run does not make the new scope unit part of the slice specified via the --slice arg Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: [impact] running 'systemd-run --scope --slice=$SLICE $PROGRAM' does not start the program under $SLICE, instead it starts it under system.slice [test case] root:~# systemd-run --scope --slice=user-1000.slice sleep 1000 Running scope as unit run-r16d872f1b0894b88a79421a890269e6c.scope. ^Z [3]+ Stopped systemd-run --scope --slice=user-1000.slice sleep 1000 root:~# bg [3]+ systemd-run --scope --slice=user-1000.slice sleep 1000 & root:~# systemctl show -p Slice run-r16d872f1b0894b88a79421a890269e6c.scope Slice=system.slice [regression potential] This defers running the manager unit load queue when setting the slice for a transient unit, as well as actually passing the slice parameter over the bus when using --scope, so any regression would very likely involve incorrectly setting the slice for a scope and/or problems when processing transient units that specify a slice. [scope] this is needed only for Xenial. this is fixed upstream by https://github.com/systemd/systemd/pull/3094 which is included starting in v230, so is included in Bionic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1881312/+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 1893958] Re: [FFe] Please accept iptables 1.8.4-3ubuntu3 switching to nftables backend
** Changed in: iptables (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1893958 Title: [FFe] Please accept iptables 1.8.4-3ubuntu3 switching to nftables backend Status in iptables package in Ubuntu: Fix Released Bug description: The change is a planned change for this development cycle and the fix has been tested as described in LP: #1887186 and https://lists.ubuntu.com/archives/ubuntu-devel/2020-August/041142.html . Changes: iptables (1.8.4-3ubuntu3) groovy; urgency=medium . * Swap alternative priority and prefer nftables backend over legacy (LP: #1887186) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1893958/+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 1894124] Re: Merge gtk 3.24.22 from Debian
Thanks, that was mentioed in the past but there is no need to open bugs about desktop updates or merges, we have tools already set up to list the components that have an available update upstream or in Debian ** Changed in: gtk+3.0 (Ubuntu) Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1894124 Title: Merge gtk 3.24.22 from Debian Status in gtk+3.0 package in Ubuntu: New Bug description: Please merge gtk 3.24.22 from Debian. It supposedly fixes bug #1891761 and improves frame clock smoothness and fixes frame clock monotonicity. https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/NEWS Overview of Changes in GTK+ 3.24.22 === * GtkTextView: - Fix some corner cases of pixelcache invalidation - Make select-all work on touch * Fix print portal support * Adwaita: - Tweak title style class - Add a public color for text view background * Windows: - Limit the size of the corner mask cache - Use native API for keycode conversion - Use GLES on arm64 * Wayland: Add a way to change the application id (LP: #1891761) * Quartz: Add axes to master devices * Add --enable-tracker3 option to configure * Translation updates: Catalan German Indonesian Italian Kazakh Spanish Turkish Overview of Changes in GTK+ 3.24.21 === * Wayland: - Prevent crashes with offscreen windows - Handle disorderly tablet/pad disconnects * GtkFileChooser: - Translate the type column - Add a tracker3 search engine - Rate-limit trash monitoring - Make get_filter work for native chooser * GtkGLArea: - Fix a redraw problem * GtkScrolledWindow: - Fix kinetic scrolling * Add a gtk-cursor-aspect-ratio setting * GDK: - Improve frame clock smoothness - Fix frame clock monotonicity * OS X: - Support Pen / Eraser input - Support openfiles in GtkApplication * Adwaita: - Improve notebook tab legibility * Translation updates: Basque Brazilian Portuguese Catalan Chinese (Taiwan) German Indonesian Italian Japanese Kazakh Lithuanian Polish Romanian Slovak Slovenian Swedish Ukrainian To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1894124/+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 1886814] Comment bridged from LTC Bugzilla
--- Comment From heinz-werner_se...@de.ibm.com 2020-09-04 03:04 EDT--- IBM Bugzilla status->closed, Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to make-dfsg in Ubuntu. https://bugs.launchpad.net/bugs/1886814 Title: posix_spawn usage in gnu make causes failures on s390x Status in Ubuntu on IBM z Systems: Fix Released Status in flatpak package in Ubuntu: Fix Released Status in glibc package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in make-dfsg package in Ubuntu: Invalid Bug description: posix_spawn usage in gnu make causes failures on s390x Recently in gnu-make v4.3 https://paste.ubuntu.com/p/tYhbJFKN76/ it started to use posix_spawn, instead of fork()/exec(). This has caused failure of an unrelated package flatpak-builder autopkgtests on s390x only, like so echo Building make: echo: Operation not permitted make: *** [Makefile:2: all] Error 127 Julian Klaude investigated this in-depth. His earlier research also indicated that this is a heisenbug, if one tries to print to stderr before printing to stdout, no issue occurs. We are configuring GNU make to be build with --disable-posix-spawn on s390x only. We passed these details to Debian https://bugs.debian.org /cgi-bin/bugreport.cgi?bug=964541 too. But I do wonder, if there is something different or incorrect about posix_spawn() implementation in either glibc, or linux kernel, on s390x. Or gnu-make's usage of posix_spawn(). As otherise, using posix_spawn() in gnu-make works on other architectures, and flatpak-builder autopkgtests pass too. It seems very weird that stdout does not appear to be functional, unless stderr was opened/written to, from gnu-make execution compiled with posix-spawn feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1886814/+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 1713803] Re: replacement of resolvconf with systemd needs integration
** Tags added: resolved-resolvconf
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1713803
Title:
replacement of resolvconf with systemd needs integration
Status in android-androresolvd package in Ubuntu:
Triaged
Status in avahi package in Ubuntu:
Triaged
Status in bind9 package in Ubuntu:
Triaged
Status in cloud-init package in Ubuntu:
Incomplete
Status in cloud-initramfs-tools package in Ubuntu:
Invalid
Status in dhcpcd5 package in Ubuntu:
Confirmed
Status in dibbler package in Ubuntu:
Won't Fix
Status in dnscrypt-proxy package in Ubuntu:
Confirmed
Status in dnsmasq package in Ubuntu:
Invalid
Status in dnssec-trigger package in Ubuntu:
Invalid
Status in fetchmail package in Ubuntu:
Confirmed
Status in freedombox-setup package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Fix Released
Status in isc-dhcp package in Ubuntu:
Fix Released
Status in ndisc6 package in Ubuntu:
Fix Released
Status in netscript-2.4 package in Ubuntu:
Won't Fix
Status in open-iscsi package in Ubuntu:
Triaged
Status in openvpn package in Ubuntu:
Confirmed
Status in postfix package in Ubuntu:
Invalid
Status in pppconfig package in Ubuntu:
Confirmed
Status in pump package in Ubuntu:
Confirmed
Status in resolvconf package in Ubuntu:
Invalid
Status in sendmail package in Ubuntu:
Invalid
Status in squid3 package in Ubuntu:
Invalid
Status in systemd package in Ubuntu:
Invalid
Status in unbound package in Ubuntu:
Triaged
Status in vpnc package in Ubuntu:
Invalid
Status in vpnc-scripts package in Ubuntu:
Invalid
Status in whereami package in Ubuntu:
Triaged
Bug description:
There is a plan to remove resolvconf from the Ubuntu Server image.
resolvconf integrated with other parts of the system in 2 ways:
* hooks invoked on change (/etc/resolvconf/update.d/)
* resolvconf tool (invoked with -a and -d or -u)
Packages which install files into /etc/resolvconf/update.d are:
- dnsmasq: This may be mostly covered by systemd-resolved itself (the dns
caching path).
- resolvconf: This probably isn't necessary in systemd-resolved path.
- unbound: This is another "validating, recursive, caching DNS resolver".
The list of Depends/Suggests/Recommends on resolvconf.
# for pkg in $(apt-cache rdepends resolvconf | grep -v openreso | grep -v
Reverse); do out=$(apt-cache show $pkg | grep resolvconf); src=$(apt-cache show
$pkg | awk '$1 == "Source:" { print $2 }'); [ -n "$src" ] || src=$pkg; case
"$out" in Depends:*resolvconf) r=depends;; Suggests:*) r=suggests;;
Recommends:*) r=recommends;; esac; echo "$r $src"; done | sort -u
depends android-androresolvd
recommends avahi
recommends dhcpcd5
recommends dibbler
recommends ndisc6
recommends whereami
suggests bind9
suggests dnscrypt-proxy
suggests dnsmasq
suggests dnssec-trigger
suggests fetchmail
suggests freedombox-setup
suggests isc-dhcp
suggests netscript-2.4
suggests openvpn
suggests postfix
suggests pppconfig
suggests pump
suggests resolvconf
suggests sendmail
suggests squid3
suggests vpnc
suggests vpnc-scripts
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: systemd 234-2ubuntu9
ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
Uname: Linux 4.12.0-11-generic x86_64
ApportVersion: 2.20.6-0ubuntu7
Architecture: amd64
Date: Tue Aug 29 18:53:50 2017
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.12.0-11-generic
root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=7
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.vendor: Intel Corporation
Related bugs:
* bug 1698181: Switch to netplan renderer in Artful
* bug 1714308: dns does not work in initramfs after configure_networking
* bug 1717983 replacement of isc-dhcp-client with with systemd-networkd for
dhclient needs integration
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/android-androresolvd/+bug/1713803/+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 1888598] Re: pulseaudio has is buggy with hdmi audio and sleep/wake
So if you only plug the monitor and don't plug the home theater, and choose the output to hdmi monitor, suspend and resume, does the output still on hdmi monitor? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1888598 Title: pulseaudio has is buggy with hdmi audio and sleep/wake Status in pulseaudio package in Ubuntu: Confirmed Bug description: on a fresh Ubuntu 20.04 x64 install, I've noticed some troubling bugs with pulseaudio after putting my system to sleep and then waking it up. these bugs aren't present on a fresh boot, only after resuming from sleep: - it forgets which sound output device it's set to, and always reverse to the motherboard's S/PDIF output. - I have two devices connected to my video card, one is a displayport monitor, and one is a home theater receiver via HDMI. it confuses the two, and randomly switches which device it thinks is capable of surround sound. - it sometimes refuses to switch to the correct audio device, and just resets any choice back to the internal S/PDIF, until the system is rebooted. as you can imagine, this a pretty frustrating state of affairs. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: pulseaudio 1:13.99.1-1ubuntu3.4 ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44 Uname: Linux 5.4.0-40-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.4 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: tessa 3387 F pulseaudio /dev/snd/pcmC1D7p: tessa 3387 F...m pulseaudio /dev/snd/controlC2: tessa 3387 F pulseaudio /dev/snd/controlC0: tessa 3387 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Jul 22 18:38:42 2020 InstallationDate: Installed on 2020-07-15 (7 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: pulseaudio UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/18/2018 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 3503 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: GRYPHON Z97 dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3503:bd04/18/2018:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnGRYPHONZ97:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: ASUS MB dmi.product.name: All Series dmi.product.sku: All dmi.product.version: System Version dmi.sys.vendor: ASUS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1888598/+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 1761096] Re: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
Thanks for --no-ask-password Sergio. I like the suggestion of making /etc/resolvconf/update-libc.d/squid systemd aware. >From similar checks I know that you also want to check if it is active: if [ -d /run/systemd/system ]; then ! systemctl is-active -q squid.service || systemctl reload squid.service >/dev/null The above is untested, but you get my point - don't reload if it isn't active. -- 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/1761096 Title: dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed Status in dnsmasq package in Ubuntu: Fix Released Status in squid package in Ubuntu: Fix Released Status in dnsmasq source package in Xenial: Confirmed Status in squid source package in Xenial: Confirmed Bug description: Setup to reproduce: Ubuntu Xenial amd64 net install iso from http://archive.ubuntu.com/ubuntu/dists/xenial/main/installer- amd64/current/images/netboot/mini.iso Install system with mostly defaults + LVM + OpenSSH server Note that this bug applies to both DHCP and static IP+DNS network configurations Once server rebooted and is available, log in and install dnsmasq + squid: apt-get update && apt-get install squid dnsmasq output of this can be found at https://pastebin.com/9Atuipju journalctl -xe output at https://pastebin.com/uLhfM4jN Furthermore at this point I can run alternating errors root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:18:07 CEST 2018 Wed Apr 4 09:18:07 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:18:39 CEST 2018 Wed Apr 4 09:18:39 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:19:10 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:20:40 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:42:57 CEST 2018 Wed Apr 4 09:42:57 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq stop ; date Wed Apr 4 09:43:14 CEST 2018 Wed Apr 4 09:43:14 CEST 2018 root@ubuntu-min:~# date ; service dnsmasq start ; date Wed Apr 4 09:43:26 CEST 2018 Job for dnsmasq.service failed because a timeout was exceeded. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. Wed Apr 4 09:44:56 CEST 2018 and so on... Each and every 1 out of 2 stop/start cycle fails in 1m30s timeout Complete journalctl -xe output attached To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1761096/+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
