[Touch-packages] [Bug 1905166] Re: systemd-shutdown cannot detach DM
Same issue here. 5.8.0-36-generic #40~20.04.1-Ubuntu SMP Wed Jan 6 10:15:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux I had issue with glxgears and some other apps that failed to start. When restarting then the computer(Lenovo P73) hanged. I think the same hanging behaviour has happened before. Not sure if this OpenGL issue is somehow related. pi-imager.desktop[624532]: Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) ** Attachment added: "IMG_20210114_091322.jpg" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905166/+attachment/5452873/+files/IMG_20210114_091322.jpg -- 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/1905166 Title: systemd-shutdown cannot detach DM Status in systemd package in Ubuntu: Incomplete Bug description: when powering down the system systemd cannot unmount / systemd-shutdown[1]: Could not detach DM /dev/dm-0: Device or resource busy systemd-shutdown[1]: Failed to finalize DM devices, ignoring reboot: Power down as a result at each startup the filesystem is checked: Press Ctrl+C to cancel all filesystem checks in progress If systemd cannot unmount / that might not be a problem but it should be less noisy and not result in a filesystem check after each reboot. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.3 ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65 Uname: Linux 5.4.0-54-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.12 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sun Nov 22 11:40:05 2020 MachineType: Dell Inc. Latitude 7410 ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-54-generic root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/11/2020 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.4.1 dmi.board.name: 0M5G57 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 31 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.4.1:bd10/11/2020:svnDellInc.:pnLatitude7410:pvr:rvnDellInc.:rn0M5G57:rvrA00:cvnDellInc.:ct31:cvr: dmi.product.family: Latitude dmi.product.name: Latitude 7410 dmi.product.sku: 09CD dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1905166/+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 675560] Re: Home dirs shouldn't be world readable
*** This bug is a duplicate of bug 48734 *** https://bugs.launchpad.net/bugs/48734 ** This bug has been marked a duplicate of bug 48734 Home permissions too open -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to adduser in Ubuntu. https://bugs.launchpad.net/bugs/675560 Title: Home dirs shouldn't be world readable Status in adduser package in Ubuntu: Invalid Bug description: Binary package hint: adduser By default, home dirs are world readable. From a privacy and security perspective, this should not be the case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/675560/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911614] Re: Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic
Thank you for taking the time to report this bug and helping to make Ubuntu better. If you look at the Ubuntu 20.04 LTS (focal fossa) release notes you'll see https://wiki.ubuntu.com/FocalFossa/ReleaseNotes "Ubuntu Desktop flavour now always tracks HWE kernel (hardware enablement). It means that from 20.04.2 release Ubuntu Desktop will gain new major kernel versions every 6 months through to summer of 2022." You haven't indicated if you're talking Ubuntu Desktop, if so that was announced & is expected behavior (at least as I understand it). Please execute the following command only once, as it will automatically gather debugging information, in a terminal: apport-collect 1911614 When reporting bugs in the future please use apport by using 'ubuntu- bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1911614 Title: Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic Status in ubuntu-meta package in Ubuntu: New Bug description: Just as the title says, the 20.04 and 20.04.1 images use the HWE version of linux-generic resulting in upgrades to the 5.8 series kernel. This seems to effect Ubuntu only, or I should say I checked the Kubuntu, Ubuntu Mate, Xubuntu, and Lubuntu iso manifests which all correctly list linux-generic. Also HWE is not truly complete without the accompanying HWE Xstack. I checked all the documentation I could find and this was clearly not intentional. In fact the manifest for Ubuntu Focal Beta still used linux-generic, so this got messed up some time between April 3, 2020 and April 23, 2020. Here's just one example of the documentation for kernel support in Focal LTS: https://ubuntu.com/about/release-cycle#ubuntu-kernel-release-cycle Installations performed with 20.04 and 20.04.1 media were supposed to remain on the 5.4 series kernel throughout Focal's 5 year lifespan as had been the case since HWE was introduced. The first step in fixing this needs to be stopping fresh installs of Focal using the 20.04 and 20.04.1 media from immediately upgrading to the 5.8 series kernel. It might be a little tricky to revert users from 5.8 to 5.4, but there have been reports of breakage, particularly concerning Broadcom wifi drivers and some graphics problems. But the graphics problems could also be exacerbated by the lack of the matching HWE Xstack? At any rate it's a bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1911614/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890448] Re: hwdb: Add EliteBook to use micmute hotkey
Enable proposed and do apt dist-upgrade. Micmute hotkey can now mute
microphone.
** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1890448
Title:
hwdb: Add EliteBook to use micmute hotkey
Status in HWE Next:
New
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Focal:
Fix Committed
Bug description:
[Impact]
Micmute hotkey on many HP EliteBooks don't work.
[Fix]
Commit b6eb208b29ae ("hwdb: Add EliteBook to use micmute hotkey"), to map AT
keyboard's scancode to micmute hotkey.
[Test]
With the one-liner fix, micmute hotkey works on all the EliteBooks I tested.
[Regression Potential]
The hwdb originally only matches a few EliteBook, and fix changes that to
match all EliteBook models. So if there's an EliteBook that uses the scancode
for other purpose, there will be a regression.
However, the risk is rather slim because HP is confident that all EliteBooks
use the same scancode for mic mute hotkey.
[scope]
this is needed for f and earlier.
this is fixed upstream by commit b6eb208b29ae which is included
starting in v246, so g and later are already fixed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1890448/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
groovy: root@lp1902960-g:~# dpkg -l systemd|grep systemd ii systemd246.6-1ubuntu1 amd64system and service manager root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER E: ID_NET_DRIVER=virtio_net root@lp1902960-g:~# rm /run/udev/data/n2 root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER root@lp1902960-g:~# udevadm trigger -c change /sys/class/net/ens3 root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER root@lp1902960-g:~# udevadm trigger -c add /sys/class/net/ens3 root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER E: ID_NET_DRIVER=virtio_net root@lp1902960-g:~# dpkg -l systemd|grep systemd ii systemd246.6-1ubuntu1.1 amd64system and service manager root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER E: ID_NET_DRIVER=virtio_net root@lp1902960-g:~# rm /run/udev/data/n2 root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER root@lp1902960-g:~# udevadm trigger -c change /sys/class/net/ens3 root@lp1902960-g:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER E: ID_NET_DRIVER=virtio_net -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases Status in cloud-images: New Status in systemd: New Status in cloud-init package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Focal: Incomplete Status in systemd source package in Focal: Fix Committed Status in cloud-init source package in Groovy: Incomplete Status in systemd source package in Groovy: Fix Committed Bug description: [impact] on boot of a specific azure instance, the ID_NET_DRIVER parameter of the instance's eth0 interface is not set. That leads to a failure of systemd-networkd to take control of the interface after a restart of systemd-networkd, which results in DNS failures (at first) and eventually complete loss of networking (once the DHCP lease expires). [test case] this occurs on first boot of an instance using the specific image; it is not reproducable using the latest ubuntu image nor any reboot of the affected image, and it has not been reproducable (for me) when using debug-enabled images based on the affected image. So, while the problem is reproducable using the specific image in question, it's not possible to verify the fix since any change to the image removes reproducability. however, while the problem itself can't be reproduced and then verified, if the assumption is correct (that the 'add' uevent is being missed on boot), that is possible to test and verify: $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc $ sudo rm /run/udev/data/n2 (note, change 'n2' to whichever network interface index is correct) $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER $ sudo udevadm trigger -c change /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER (note the 'change' uevent did not populate ID_NET_DRIVER property) $ sudo udevadm trigger -c add /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc (note the 'add' uevent did populate ID_NET_DRIVER) the test verification should result in ID_NET_DRIVER being populated for a 'change' uevent. [regression potential] any regression would likely involve problems with systemd-udevd processing 'change' events from network devices, and/or incorrect udevd device properties. [scope] this is needed only for focal and groovy. this is fixed by upstream commit e0e789c1e97 which is first included in v247, so this is fixed already in hirsute. while this commit is not included in bionic, due to the difficult nature of reproducing (and verifying) this, and the fact it has only been seen once on a focal image, I don't think it's appropriate to SRU to bionic at this point; possibly it may be appropriate if this is ever reproduced with a bionic image. [other info] note that this bug's subject and description, as well as the upstream systemd bug subject and description, talk about the problem being DNS resolution. However that is strictly a side-effect of the real problem and is not the actual issue. [original description] The systemd upgrade 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to have broken DNS resolution across much of our Azure fleet earlier today. We ended up mitigating this by forcing reboots on the associated instances, no combination of networkctl reload, reconfigure, systemctl daemon-reexec, systemctl daemon-reload, netplan generate, netplan apply would get resolvectl to have a DNS server
[Touch-packages] [Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak
** Tags added: sts-sponsor-mfo
--
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/1908473
Title:
rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
leads to file descriptor leak
Status in librelp package in Ubuntu:
In Progress
Status in rsyslog package in Ubuntu:
Fix Released
Status in librelp source package in Focal:
In Progress
Status in rsyslog source package in Focal:
Won't Fix
Status in librelp source package in Groovy:
In Progress
Status in rsyslog source package in Groovy:
Fix Released
Status in librelp source package in Hirsute:
In Progress
Status in rsyslog source package in Hirsute:
Fix Released
Bug description:
[Impact]
In recent versions of rsyslog and librelp, the imrelp module leaks
file descriptors due to a bug where it does not correctly close
sockets, and instead, leaves them in the CLOSE_WAIT state.
This causes rsyslogd on busy servers to eventually hit the limit of
maximum open files allowed, which locks rsyslogd up until it is
restarted.
A workaround is to restart rsyslogd every month or so to manually
close all of the open sockets.
Only users of the imrelp module are affected, and not rsyslog users in
general.
[Testcase]
Install the rsyslog-relp module like so:
$ sudo apt install rsyslog rsyslog-relp
Next, generate a working directory, and make a config file that loads
the relp module.
$ sudo mkdir /workdir
$ cat << EOF >> ./spool.conf
\$LocalHostName spool
\$AbortOnUncleanConfig on
\$PreserveFQDN on
global(
workDirectory="/workdir"
maxMessageSize="256k"
)
main_queue(queue.type="Direct")
module(load="imrelp")
input(
type="imrelp"
name="imrelp"
port="601"
ruleset="spool"
MaxDataSize="256k"
)
ruleset(name="spool" queue.type="direct") {
}
# Just so rsyslog doesn't whine that we do not have outputs
ruleset(name="noop" queue.type="direct") {
action(
type="omfile"
name="omfile"
file="/workdir/spool.log"
)
}
EOF
Verify that the config is valid, then start a rsyslog server.
$ sudo rsyslogd -f ./spool.conf -N9
$ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
Fetch the rsyslogd PID and check for open files.
$ RLOGPID=$(cat /workdir/rsyslogd.pid)
$ sudo ls -l /proc/$RLOGPID/fd
total 0
lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
We have 3 sockets open by default. Next, use netcat to open 100
connections:
$ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
Now check for open file descriptors, and there will be an extra 100 sockets
in the list:
$ sudo ls -l /proc/$RLOGPID/fd
https://paste.ubuntu.com/p/f6NQVNbZcR/
We can check the state of these sockets with:
$ ss -t
https://paste.ubuntu.com/p/7Ts2FbxJrg/
The listening sockets will be in CLOSE-WAIT, and the netcat sockets
will be in FIN-WAIT-2.
$ ss -t | grep CLOSE-WAIT | wc -l
100
If you install the test package available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
When you open connections with netcat, these will be closed properly,
and the file descriptor leak will be fixed.
[Where problems could occur]
If a regression were to occur, it would be limited to users of the
imrelp module, which is a part of the rsyslogd-relp package, and
depends on librelp.
rsyslog-relp is not part of a default installation of rsyslog, and is
opt in by changing a configuration file to enable imrelp.
The changes to rsyslog implement a testcase which exercises the
problematic code to ensure things are working as expected, and should
run during autopkgtest time.
[Other]
Upstream bug list:
https://github.com/rsyslog/rsyslog/issues/4350
https://github.com/rsyslog/rsyslog/issues/4005
https://github.com/rsyslog/librelp/issues/188
https://github.com/rsyslog/librelp/pull/193
The following commits fix the problem:
rsyslogd
commit baee0bd5420649329793746f0daf87c4f59fe6a6
Author: Andre lorbach
Date: Thu Apr 9 13:00:35 2020 +0200
Subject: testbench: Add test for imrelp to check broken session handling.
Link:
https://github.com/rsyslog/rsyslog/commit/baee0bd5420649329793746f0daf87c4f59fe6a6
librelp
===
commit 7907c9c57f6ed94c8ce5a4e63c3c4e019f71cff0
Author: Andre lorbach
Date: Mon May 11 14:59:55 2020 +0200
Subject: fix memory leak on session break.
Link:
https://github.com/rsyslog/librelp/commit/7907c9c57f6ed94c8ce5a4e63c3c4e019f71cff0
commit 4a6ad8637c244fd3a1caeb9a93950826f58e956a
[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst
I verified that this is fixed in both Focal and Hirsute by examining the
source (so presumably Groovy too).
** Also affects: audit (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: audit (Ubuntu)
Status: In Progress => Fix Released
** Changed in: audit (Ubuntu Bionic)
Status: New => Fix Committed
** 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 audit in Ubuntu.
https://bugs.launchpad.net/bugs/1848330
Title:
Installing auditd sometimes fails in post-inst
Status in audit package in Ubuntu:
Fix Released
Status in audit source package in Bionic:
Fix Committed
Status in audit package in Debian:
New
Bug description:
[Impact]
Sometimes, auditd will get stuck when starting up, causing systemd to
kill it after a while since it (systemd) never got the start
notification.
Upstream troubleshooted this to be caused by calling a syslog()
function inside a signal handler.
[Test Case]
There is no reliable test case to reproduce the bug, other than trying the
fixed packages on an affected system where the hang occurs more frequently.
Basically:
sudo systemctl stop auditd
sudo systemctl start auditd
should work reliably. Do not run that in a tight loop, however, as
that will trigger a it's-restarting-too-frequently failure.
[Where problems could occur]
- if auditd fails to start, then the first fallback is syslog, and if that is
not picking up the audit messages, the last resort is the kernel buffer, which
can fill up. In the case it fills up, audit logs will be lost.
- it's possible to configure the audit system to panic() the machine
if audit messages are lost or otherwise not able to be recorded
(auditctl -f 2; default is 1 which is printk())
- the update restarts auditd as expected. Misconfiguration on very
very busy systems could mean that audit logs would be lost during the
brief moment the service is restarted. If that's the case, this update
would just be one more way to trigger it, but not be the root cause of
the problem
- similarly, as is usual with updates that restart services, it's
possible than an incorrect configuration for auditd is present, but
was never loaded before. The restart will load the config, and will
fail in such a case.
- this update removes a logging statement that occurs during startup:
("dispatcher %d reaped", pid)
It's unlikely, but possible, that some monitoring software could be
looking for that message in the logs. It won't be there anymore after
this update.
[Other Info]
The patch is committed upstream and part of the 2.8.5 release, which is
present in Focal and later.
The real fix for this bug is just dropping the audit_msg() call in the signal
handler code. But the original reporter of the bug, who is also who came up
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4)
stated that with the 3 changes in the patch the startup hang didn't happen to
him anymore. Since this bug is difficult to reproduce elsewhere (either you
have it, or you don't), I chose to keep the 3 changes instead of just the
removal of the audit_msg() call.
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most
installations work successfully, though. Re-running the install also
fixes the issue, but the failure breaks our automation. The log from
the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service →
/lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor
preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms
ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing
Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher:
/sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation
timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State
'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process
9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process
9703
[Touch-packages] [Bug 1848330] Please test proposed package
Hello Dr., or anyone else affected,
Accepted audit into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/audit/1:2.8.2-1ubuntu1.1 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.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1848330
Title:
Installing auditd sometimes fails in post-inst
Status in audit package in Ubuntu:
Fix Released
Status in audit source package in Bionic:
Fix Committed
Status in audit package in Debian:
New
Bug description:
[Impact]
Sometimes, auditd will get stuck when starting up, causing systemd to
kill it after a while since it (systemd) never got the start
notification.
Upstream troubleshooted this to be caused by calling a syslog()
function inside a signal handler.
[Test Case]
There is no reliable test case to reproduce the bug, other than trying the
fixed packages on an affected system where the hang occurs more frequently.
Basically:
sudo systemctl stop auditd
sudo systemctl start auditd
should work reliably. Do not run that in a tight loop, however, as
that will trigger a it's-restarting-too-frequently failure.
[Where problems could occur]
- if auditd fails to start, then the first fallback is syslog, and if that is
not picking up the audit messages, the last resort is the kernel buffer, which
can fill up. In the case it fills up, audit logs will be lost.
- it's possible to configure the audit system to panic() the machine
if audit messages are lost or otherwise not able to be recorded
(auditctl -f 2; default is 1 which is printk())
- the update restarts auditd as expected. Misconfiguration on very
very busy systems could mean that audit logs would be lost during the
brief moment the service is restarted. If that's the case, this update
would just be one more way to trigger it, but not be the root cause of
the problem
- similarly, as is usual with updates that restart services, it's
possible than an incorrect configuration for auditd is present, but
was never loaded before. The restart will load the config, and will
fail in such a case.
- this update removes a logging statement that occurs during startup:
("dispatcher %d reaped", pid)
It's unlikely, but possible, that some monitoring software could be
looking for that message in the logs. It won't be there anymore after
this update.
[Other Info]
The patch is committed upstream and part of the 2.8.5 release, which is
present in Focal and later.
The real fix for this bug is just dropping the audit_msg() call in the signal
handler code. But the original reporter of the bug, who is also who came up
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4)
stated that with the 3 changes in the patch the startup hang didn't happen to
him anymore. Since this bug is difficult to reproduce elsewhere (either you
have it, or you don't), I chose to keep the 3 changes instead of just the
removal of the audit_msg() call.
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most
installations work successfully, though. Re-running the install also
fixes the issue, but the failure breaks our automation. The log from
the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service →
/lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor
preset: enabled)
Active: failed (Result: timeout)
[Touch-packages] [Bug 1825186] Re: gpgv-win32 autopkgtest always fails
** Changed in: gnupg2 (Ubuntu Cosmic) Status: New => Won't Fix ** Changed in: gnupg (Ubuntu Xenial) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnupg in Ubuntu. https://bugs.launchpad.net/bugs/1825186 Title: gpgv-win32 autopkgtest always fails Status in gnupg package in Ubuntu: Invalid Status in gnupg2 package in Ubuntu: Opinion Status in gnupg source package in Xenial: Won't Fix Status in gnupg2 source package in Bionic: New Status in gnupg2 source package in Cosmic: Won't Fix Status in gnupg2 source package in Disco: Fix Released Bug description: [impact] gpgv-win32 autopkgtest always fails [test case] check http://autopkgtest.ubuntu.com/packages/g/gnupg2 or run autopkgtest manually note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and has been removed from d/t/control entirely in d [regression potential] little to none; this affects the test case only [other info] as mentioned, in disco, the gpgv-win32 test has been removed from the tests/control completely. not sure if that is a better approach than fixing the test case. For now, I marked this Fix Released for disco since it doesn't fail there (since the testcase was removed). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1892358] Re: autopkgtest success rate dropped inhibiting proposed migration
autopkgtests pass for b/f/g ** Tags removed: verification-needed verification-needed-groovy ** Tags added: verification-done verification-done-groovy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1892358 Title: autopkgtest success rate dropped inhibiting proposed migration Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Committed Bug description: [impact] autopkgtests are failing/flaky and prevent other packages from migrating to -updates [test case] check autopkgtest history [regression potential] in regard to the changed test cases, any regression would likely result in either an incorrectly passed test, or an incorrectly failed test. [scope] for systemd, this is needed for x, b, and f. tests in g appear to be mostly stable, but I've opened MR (linked from this bug) to update the tests there as well. i don't plan to update x, as it's reaching ESM in ~6 months, and backporting the test fixes is more work than just a simple code copy, since there are additional differences/changes needed in the older version of systemd (and python3). the failing/flaky tests in x have been like that forever, and people have just retried them; we can keep retrying them until x moves into ESM next year. [original description] Hi, we had such cases in the past like bug 1817721 for bionic and maybe bug 1892130 is about the same as well. There were more but I didn't want to search for all of them - what I checked is that there are no open ones clearly pointing out the recent further drop in already flaky subtests. In particular the tests "tests-in-lxd" and "systemd-fsckd" were known to be flaky before, but got even worse. Here stats of the last 40 runs, it might be a coincidences that this is after 246-2ubuntu1 landed. Could as well be any other change groovy amd64 tests-in-lxd (F 42% S 0% B 10% => P 45%/) BFFFBFF.B.F.F...FBF build-login(F 0% S 0% B 10% => P 87%/) B...B...BB. unit-config(F 0% S 0% B 10% => P 87%/) B...B...BB. networkd-testpy(F 0% S 0% B 10% => P 87%/) B...B...BB. boot-and-services (F 0% S 0% B 10% => P 87%/) B...B...BB. boot-smoke (F 0% S 0% B 10% => P 87%/) B...B...BB. logind (F 0% S 0% B 10% => P 87%/) B...B...BB. storage(F 0% S 0% B 10% => P 87%/) B...B...BB. upstream (F 35% S 0% B 10% => P 52%/) ..FFB.FFF.FFBFF.B.F.F..FFBF udev (F 0% S 0% B 10% => P 87%/) B...B...BB. systemd-fsckd (F 37% S 0% B 10% => P 50%/) BFFFB.FF...FB.F..B. root-unittests (F 0% S 0% B 10% => P 87%/) B...B...BB. ppc64el tests-in-lxd (F 25% S 0% B 0% => P 75%/) FFFFF.F. systemd-fsckd (F 35% S 0% B 0% => P 65%/) FFF...FFFFF.F..F root-unittests (F 2% S 0% B 0% => P 97%/) ..F. s390x tests-in-lxd (F 52% S 0% B 0% => P 47%/) FFF.FFF.FF....F. timedated (F 2% S 0% B 0% => P 97%/) ...F upstream (F 17% S 0% B 0% => P 82%/) .F..F.F.FFF...F. systemd-fsckd (F 32% S 0% B 0% => P 67%/) FFF..FF..F.FF..F root-unittests (F 10% S 0% B 0% => P 90%/) FFF...F. arm64 tests-in-lxd (F 40% S 0% B 2% => P 57%/) F.B...FFF.FF..F..F.FFF.F logind (F 2% S 0% B 2% => P 95%/) ..B...F. upstream (F 22% S 0% B 2% => P 75%/) ...F.FB.F.F.F..FFF.F root-unittests (F 12% S 0% B 2% => P 85%/) ..B.F...F.FF...F (I'm sure LP will make this unreadable, but is is nice in monospace) Whatever the root cause is - the success rate of these has reduced so much that the (even formerly questionable) practice of retry-until- success won't work anymore. I have run the two tests in a local VM and systemd-fsckd
[Touch-packages] [Bug 1881947] Re: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting.
autopkgtests pass for b/f/g ** Tags removed: verification-needed verification-needed-bionic verification-needed-focal verification-needed-groovy ** Tags added: verification-done verification-done-bionic verification-done-focal verification-done-groovy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1881947 Title: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. Status in systemd: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Committed Status in systemd source package in Hirsute: In Progress Bug description: [Impact] * Autopkgtest fails due to corrupted journal file [Test Case] * Observe autopkgtest root-unittests not failing with: Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. [Where problems could occur] * The change has no impact on the systemd binary packages. The relaxed test could hide a journal corruption problem, but it seems the corrupted journal files occur only on arm64 probably due to arm64 reboots being resets: LP: #1748280. [Original Bug Text] Observed in an focal/arm64 autopkgtest failure of systemd 245.4-4ubuntu3.1: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/s/systemd/20200603_071743_738b2@/log.gz [...] PASS: test-journal-enum == test-journal-flush === Root directory /var/log/journal removed. Directory /var/log/journal/3286b2469d224077b1026d239d625b0d removed. mmap cache statistics: 739 hit, 5 miss journal_file_copy_entry failed: Bad message Assertion 'r >= 0' failed at src/journal/test-journal-flush.c:52, function main(). Aborting. FAIL: test-journal-flush (code: 134) Aborted (core dumped) == test-journal-importer === [...] autopkgtest [07:17:29]: summary timedatedPASS hostnamedPASS localed-locale PASS localed-x11-keymap PASS logind PASS unit-config PASS storage PASS networkd-test.py PASS build-login PASS boot-and-servicesPASS udev PASS root-unittests FAIL non-zero exit status 134 upstream PASS boot-smoke PASS systemd-fsckdPASS Exit request sent. [...] To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1881947/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1908167] Re: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic
I asked on IRC for confirmation that the regression fix has landed in Hirsute. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1908167 Title: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic Status in HWE Next: New Status in OEM Priority Project: New Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Focal: Fix Committed Status in pulseaudio source package in Groovy: Fix Committed Status in pulseaudio source package in Hirsute: Fix Released Bug description: [Impact] On the Dell AIO machines, there is no internal mic, after plugging a headset, users expect the headset-mic or headphone-mic could be selected automatically. But with the current rule, the headset-mic/headphone-mic will not be selected automatically and even users manually select them, they will not show up in the gnome sound setting, and users could not record sound by headset-mic/headphone-mic. [Fix] backport a patch from pulseaudio mergerequest, the patch is going to be merged to pulseaudio 14.1. This patch could be backported to hirsute without any change, but need to be changed if backport it to groovy and focal. [Test] With the old pulseaudio (prior to 1:13.99.1-1ubuntu3.10), plugging in a headset to the problematic Dell AIO machine will not automatically select headset-mic/headphone-mic, and they also do not show up in Gnome sound settings, leading to failure to record any sound. With the new proposed package, on those Dell AIO, plug a headset, open the gnome sound setting, the headset-mic is selected automatically, use the headset-mic to record the sound, the sound could be recorded and the sound quality is good. [Where problems could occur] This patch could change the policy of audio device switching, it will not affect all audio devices, but only the devices which has AVAIL_UNKNOWN available status, that means it has possibility to introduce the regression on headphone-mic ,headset-mic, internal mic and internal speaker's switching since they all has AVAIL_UNKNOWN status. For example, after unpluging the headset, the input device will not switch to internal mic automatically or after unplug the headphone, the output device will not switch to internal speaker automatically. But this possibility is very low, we have tested the patch on many Dell and Lenovo machines, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1908167/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1908167] Re: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic
** Description changed: [Impact] On the Dell AIO machines, there is no internal mic, after plugging a headset, users expect the headset-mic or headphone-mic could be selected automatically. But with the current rule, the headset-mic/headphone-mic will not be selected automatically and even users manually select them, they will not show up in the gnome sound setting, and users could not record sound by headset-mic/headphone-mic. [Fix] backport a patch from pulseaudio mergerequest, the patch is going to be merged to pulseaudio 14.1. This patch could be backported to hirsute without any change, but need to be changed if backport it to groovy and focal. [Test] - On those Dell AIO, plug a headset, open the gnome sound setting, the headset-mic is selected automatically, use the headset-mic to record the sound, the sound could be recorded and the sound quality is good. + With the old pulseaudio (prior to 1:13.99.1-1ubuntu3.10), plugging in a headset to the problematic Dell AIO machine will not automatically select headset-mic/headphone-mic, and they also do not show up in Gnome sound settings, leading to failure to record any sound. + + With the new proposed package, on those Dell AIO, plug a headset, open + the gnome sound setting, the headset-mic is selected automatically, use + the headset-mic to record the sound, the sound could be recorded and the + sound quality is good. [Where problems could occur] This patch could change the policy of audio device switching, it will not affect all audio devices, but only the devices which has AVAIL_UNKNOWN available status, that means it has possibility to introduce the regression on headphone-mic ,headset-mic, internal mic and internal speaker's switching since they all has AVAIL_UNKNOWN status. For example, after unpluging the headset, the input device will not switch to internal mic automatically or after unplug the headphone, the output device will not switch to internal speaker automatically. But this possibility is very low, we have tested the patch on many Dell and Lenovo machines, all worked well. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1908167 Title: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic Status in HWE Next: New Status in OEM Priority Project: New Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Focal: Fix Committed Status in pulseaudio source package in Groovy: Fix Committed Status in pulseaudio source package in Hirsute: Fix Released Bug description: [Impact] On the Dell AIO machines, there is no internal mic, after plugging a headset, users expect the headset-mic or headphone-mic could be selected automatically. But with the current rule, the headset-mic/headphone-mic will not be selected automatically and even users manually select them, they will not show up in the gnome sound setting, and users could not record sound by headset-mic/headphone-mic. [Fix] backport a patch from pulseaudio mergerequest, the patch is going to be merged to pulseaudio 14.1. This patch could be backported to hirsute without any change, but need to be changed if backport it to groovy and focal. [Test] With the old pulseaudio (prior to 1:13.99.1-1ubuntu3.10), plugging in a headset to the problematic Dell AIO machine will not automatically select headset-mic/headphone-mic, and they also do not show up in Gnome sound settings, leading to failure to record any sound. With the new proposed package, on those Dell AIO, plug a headset, open the gnome sound setting, the headset-mic is selected automatically, use the headset-mic to record the sound, the sound could be recorded and the sound quality is good. [Where problems could occur] This patch could change the policy of audio device switching, it will not affect all audio devices, but only the devices which has AVAIL_UNKNOWN available status, that means it has possibility to introduce the regression on headphone-mic ,headset-mic, internal mic and internal speaker's switching since they all has AVAIL_UNKNOWN status. For example, after unpluging the headset, the input device will not switch to internal mic automatically or after unplug the headphone, the output device will not switch to internal speaker automatically. But this possibility is very low, we have tested the patch on many Dell and Lenovo machines, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1908167/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1725618] Re: pulseaudio crashed with SIGABRT in pa_mainloop_dispatch()
*** This bug is a duplicate of bug 1366819 *** https://bugs.launchpad.net/bugs/1366819 Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: pulseaudio (Ubuntu) Status: New => Confirmed -- 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/1725618 Title: pulseaudio crashed with SIGABRT in pa_mainloop_dispatch() Status in pulseaudio package in Ubuntu: Confirmed Bug description: Watching youtube videos in firefox triggers this error and either the whole browser or just the one tab to crash. Everything works fine in chromium. Clicking through the "encountered an error" dialogue created this bug ProblemType: Crash DistroRelease: Ubuntu 17.10 Package: pulseaudio 1:10.0-2ubuntu3 ProcVersionSignature: Ubuntu 4.13.0-16.19-lowlatency 4.13.4 Uname: Linux 4.13.0-16-lowlatency x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC1D0p: geoff 2344 F...m pulseaudio /dev/snd/controlC1: geoff 2344 F pulseaudio /dev/snd/controlC0: geoff 2344 F pulseaudio CrashCounter: 1 CurrentDesktop: XFCE Date: Sat Oct 21 20:40:18 2017 EcryptfsInUse: Yes ExecutablePath: /usr/bin/pulseaudio InstallationDate: Installed on 2014-09-23 (1123 days ago) InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2) ProcCmdline: /usr/bin/pulseaudio --start --log-target=syslog Signal: 6 SourcePackage: pulseaudio StacktraceTop: ?? () from /usr/lib/pulse-10.0/modules/module-stream-restore.so ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecore-10.0.so pa_mainloop_dispatch () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 pa_mainloop_run () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 Title: pulseaudio crashed with SIGABRT in pa_mainloop_dispatch() UpgradeStatus: Upgraded to artful on 2017-10-21 (0 days ago) UserGroups: adm cdrom dialout dip docker lpadmin plugdev sambashare sudo vboxusers www-data dmi.bios.date: 07/17/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: G750JS.208 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: G750JS 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.:bvrG750JS.208:bd07/17/2014:svnASUSTeKCOMPUTERINC.:pnG750JS:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnG750JS:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.family: G dmi.product.name: G750JS 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/pulseaudio/+bug/1725618/+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 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak
This bug was fixed in the package librelp - 1.9.0-1ubuntu1
---
librelp (1.9.0-1ubuntu1) hirsute; urgency=medium
* Merge from Debian unstable. (LP: #1910307)
Remaining changes:
[ William Grant ]
- d/p/shrink-receiver-abort-tests.sh: Reduce message count
so tests pass on slow platforms like riscv64.
Dropped changes:
- d/p/python2.diff: No longer needed due to tests being
ported to python3 in recent versions.
* Fix file descriptor leak as sockets are stuck in CLOSE_WAIT
due to not being closed properly due to memory leak. (LP: #1908473)
-- Matthew Ruffell Thu, 26 Nov 2020
21:52:43 +
** Changed in: librelp (Ubuntu Hirsute)
Status: In Progress => Fix Released
--
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/1908473
Title:
rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
leads to file descriptor leak
Status in librelp package in Ubuntu:
Fix Released
Status in rsyslog package in Ubuntu:
Fix Released
Status in librelp source package in Focal:
In Progress
Status in rsyslog source package in Focal:
Won't Fix
Status in librelp source package in Groovy:
In Progress
Status in rsyslog source package in Groovy:
Fix Released
Status in librelp source package in Hirsute:
Fix Released
Status in rsyslog source package in Hirsute:
Fix Released
Bug description:
[Impact]
In recent versions of rsyslog and librelp, the imrelp module leaks
file descriptors due to a bug where it does not correctly close
sockets, and instead, leaves them in the CLOSE_WAIT state.
This causes rsyslogd on busy servers to eventually hit the limit of
maximum open files allowed, which locks rsyslogd up until it is
restarted.
A workaround is to restart rsyslogd every month or so to manually
close all of the open sockets.
Only users of the imrelp module are affected, and not rsyslog users in
general.
[Testcase]
Install the rsyslog-relp module like so:
$ sudo apt install rsyslog rsyslog-relp
Next, generate a working directory, and make a config file that loads
the relp module.
$ sudo mkdir /workdir
$ cat << EOF >> ./spool.conf
\$LocalHostName spool
\$AbortOnUncleanConfig on
\$PreserveFQDN on
global(
workDirectory="/workdir"
maxMessageSize="256k"
)
main_queue(queue.type="Direct")
module(load="imrelp")
input(
type="imrelp"
name="imrelp"
port="601"
ruleset="spool"
MaxDataSize="256k"
)
ruleset(name="spool" queue.type="direct") {
}
# Just so rsyslog doesn't whine that we do not have outputs
ruleset(name="noop" queue.type="direct") {
action(
type="omfile"
name="omfile"
file="/workdir/spool.log"
)
}
EOF
Verify that the config is valid, then start a rsyslog server.
$ sudo rsyslogd -f ./spool.conf -N9
$ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
Fetch the rsyslogd PID and check for open files.
$ RLOGPID=$(cat /workdir/rsyslogd.pid)
$ sudo ls -l /proc/$RLOGPID/fd
total 0
lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
We have 3 sockets open by default. Next, use netcat to open 100
connections:
$ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
Now check for open file descriptors, and there will be an extra 100 sockets
in the list:
$ sudo ls -l /proc/$RLOGPID/fd
https://paste.ubuntu.com/p/f6NQVNbZcR/
We can check the state of these sockets with:
$ ss -t
https://paste.ubuntu.com/p/7Ts2FbxJrg/
The listening sockets will be in CLOSE-WAIT, and the netcat sockets
will be in FIN-WAIT-2.
$ ss -t | grep CLOSE-WAIT | wc -l
100
If you install the test package available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
When you open connections with netcat, these will be closed properly,
and the file descriptor leak will be fixed.
[Where problems could occur]
If a regression were to occur, it would be limited to users of the
imrelp module, which is a part of the rsyslogd-relp package, and
depends on librelp.
rsyslog-relp is not part of a default installation of rsyslog, and is
opt in by changing a configuration file to enable imrelp.
The changes to rsyslog implement a testcase which exercises the
problematic code to ensure things are working as expected, and should
run during autopkgtest time.
[Other]
Upstream bug list:
https://github.com/rsyslog/rsyslog/issues/4350
https://github.com/rsyslog/rsyslog/issues/4005
https://github.com/rsyslog/librelp/issues/188
[Touch-packages] [Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
focal: root@lp1902960-f:~# dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.3 amd64system and service manager root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER E: ID_NET_DRIVER=virtio_net root@lp1902960-f:~# rm /run/udev/data/n2 root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER root@lp1902960-f:~# udevadm trigger -c change /sys/class/net/ens3 root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER root@lp1902960-f:~# udevadm trigger -c add /sys/class/net/ens3 root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER E: ID_NET_DRIVER=virtio_net root@lp1902960-f:~# dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.4 amd64system and service manager root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER E: ID_NET_DRIVER=virtio_net root@lp1902960-f:~# rm /run/udev/data/n2 root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER root@lp1902960-f:~# udevadm trigger -c change /sys/class/net/ens3 root@lp1902960-f:~# udevadm info /sys/class/net/ens3 | grep ID_NET_DRIVER E: ID_NET_DRIVER=virtio_net ** Tags removed: verification-needed verification-needed-focal verification-needed-groovy ** Tags added: verification-done verification-done-focal verification-done-groovy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases Status in cloud-images: New Status in systemd: New Status in cloud-init package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Focal: Incomplete Status in systemd source package in Focal: Fix Committed Status in cloud-init source package in Groovy: Incomplete Status in systemd source package in Groovy: Fix Committed Bug description: [impact] on boot of a specific azure instance, the ID_NET_DRIVER parameter of the instance's eth0 interface is not set. That leads to a failure of systemd-networkd to take control of the interface after a restart of systemd-networkd, which results in DNS failures (at first) and eventually complete loss of networking (once the DHCP lease expires). [test case] this occurs on first boot of an instance using the specific image; it is not reproducable using the latest ubuntu image nor any reboot of the affected image, and it has not been reproducable (for me) when using debug-enabled images based on the affected image. So, while the problem is reproducable using the specific image in question, it's not possible to verify the fix since any change to the image removes reproducability. however, while the problem itself can't be reproduced and then verified, if the assumption is correct (that the 'add' uevent is being missed on boot), that is possible to test and verify: $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc $ sudo rm /run/udev/data/n2 (note, change 'n2' to whichever network interface index is correct) $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER $ sudo udevadm trigger -c change /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER (note the 'change' uevent did not populate ID_NET_DRIVER property) $ sudo udevadm trigger -c add /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc (note the 'add' uevent did populate ID_NET_DRIVER) the test verification should result in ID_NET_DRIVER being populated for a 'change' uevent. [regression potential] any regression would likely involve problems with systemd-udevd processing 'change' events from network devices, and/or incorrect udevd device properties. [scope] this is needed only for focal and groovy. this is fixed by upstream commit e0e789c1e97 which is first included in v247, so this is fixed already in hirsute. while this commit is not included in bionic, due to the difficult nature of reproducing (and verifying) this, and the fact it has only been seen once on a focal image, I don't think it's appropriate to SRU to bionic at this point; possibly it may be appropriate if this is ever reproduced with a bionic image. [other info] note that this bug's subject and description, as well as the upstream systemd bug subject and description, talk about the problem being DNS resolution. However that is strictly a side-effect of the real problem and is not the actual issue. [original description] The systemd upgrade 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to have broken DNS resolution across much of our Azure fleet earlier today. We ended up mitigating this by forcing reboots on the associated instances, no
[Touch-packages] [Bug 1878955] Re: resolved dhclient-enter-hook complains about an empty file
focal: root@lp1878955-f:~# dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.3 amd64system and service manager root@lp1878955-f:~# dhclient -i ens8 cmp: EOF on /tmp/tmp.4YGbdTC8iI which is empty root@lp1878955-f:~# dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.4 amd64system and service manager root@lp1878955-f:~# dhclient -i ens8 root@lp1878955-f:~# -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1878955 Title: resolved dhclient-enter-hook complains about an empty file Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Bug description: [impact] When starting/using `dhclient`, it will often return an error such as: cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty [test case] run dhclient for the first time (for the current boot) on a bionic/focal system, or remove the file(s) in /run/systemd/resolved.conf.d/ starting with 'isc-dhcp-*', and then run dhclient. [regression potential] any regression would likely cause the DNS configuration that dhclient gets to not be properly reported to systemd-resolved, resulting in problematic/broken systemd DNS resolution. [scope] this is needed in b/f this hook was removed from systemd starting in g, and the hook was not yet added in x, so this change is needed only in b and f. [original description] When starting/using `dhclient`, it will often return an error such as: cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty This is due to the use of `cmp` in "/etc/dhcp/dhclient-enter- hooks.d/resolved" Because the $oldstate file can be empty, or different, it should use `cmp --quiet` This happens when "/run/systemd/resolved.conf.d/isc- dhcp-v*-$interface.conf" files do not exist, or when the content changes. This is very loosely related to https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1878955/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1410618] Re: MacBook Air 6, 2 TRRS Headset Mic Not Working
Unfortunately I was never able to solve this. It appears the Windows issue (referenced above) remains as well. Maybe an examination of the Apple/OSX driver (if that's even possible) would lead to a solution here. As a work-around I purchased a small USB sound card and plugged into that. -- 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/1410618 Title: MacBook Air 6,2 TRRS Headset Mic Not Working Status in alsa-driver package in Ubuntu: Confirmed Bug description: Hello, I'm running Ubuntu Gnome 14.04 on a new MacBookAir6,2 with the Cirrus Logic CS4208 and would love to get the microphone part of the TRRS connector working. Mac OS picks up and utilizes the TRRS headset mic without issue so I know the hardware is a go. With the headset plugged in, running sudo hdajacksensetest -a results in: Pin 0x05 ( Digital Out, HDMI): present = No Pin 0x06 ( Digital Out, HDMI): present = No Pin 0x07 ( Digital Out, HDMI): present = No AlsaInfo output here: http://www.alsa-project.org/db/?f=cabc8cab44d308c8a3898c66d48d9be4fc5ccf83 I opened up hdajackretask to find four pins: Green Headphone Pin ID: 0x10 Headphone Internal Speaker Pin ID: 0x12 Internal speaker Pink Mic Pin ID: 0x18 Not connected Internal Mic Pin ID: 0x1c Internal mic Unplugging and replugging the headset changes the Output device in sound settings from Headphones to Speakers so that works, but nothing in the input tab ever changes. It always lists two devices: Internal Microphone and Microphone. Both of these seem to actually be the internal microphone in the mac - either works without the headset connected at all. So I'm not really sure how to proceed from here, but I'd be happy to run whatever diagnostic tests might prove useful and/or even contribute code toward a fix - but I just have no idea where to start. Is it as simple as just finding the right pin and telling the system to use it as a microphone? Similar bug report here: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/950494 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1410618/+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 1911472] [NEW] ubuntu 16.04.7 timedatectl
Public bug reported: Hello, after recent tzdata update in ubuntu 16.04.7 (Desktop), the "timedatectl" command shows this error: user@host:~$ timedatectl Assertion 'xstrftime: a[] must be big enough' failed at ../src/timedate/timedatectl.c:113, function print_status_info(). Aborting. Aborted (core dumped) ** Affects: tzdata (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu. https://bugs.launchpad.net/bugs/1911472 Title: ubuntu 16.04.7 timedatectl Status in tzdata package in Ubuntu: New Bug description: Hello, after recent tzdata update in ubuntu 16.04.7 (Desktop), the "timedatectl" command shows this error: user@host:~$ timedatectl Assertion 'xstrftime: a[] must be big enough' failed at ../src/timedate/timedatectl.c:113, function print_status_info(). Aborting. Aborted (core dumped) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1911472/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907306] Re: networkd dhcpv4 client never attempts more than 2 renew and 2 rebind
groovy: root@lp1907306-g:~# dpkg -l systemd|grep systemd ii systemd246.6-1ubuntu1.1 amd64system and service manager root@lp1907306-g:~# journalctl -b -u systemd-networkd | grep 'ifindex 3' Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): STARTED on ifindex 3 root@lp1907306-g:~# journalctl -b -u systemd-networkd | grep 0x39b455d6 Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): STARTED on ifindex 3 Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): DISCOVER Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): OFFER Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (requesting) Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): ACK Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): lease expires in 59min 59s Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): T2 expires in 52min 30s Jan 13 18:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): T1 expires in 29min 59s Jan 13 19:27:25 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (renewing) Jan 13 19:38:41 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (renewing) Jan 13 19:44:18 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (renewing) Jan 13 19:47:07 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (renewing) Jan 13 19:48:32 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (renewing) Jan 13 19:49:32 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (renewing) Jan 13 19:49:56 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (rebinding) Jan 13 19:53:41 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (rebinding) Jan 13 19:55:33 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (rebinding) Jan 13 19:56:33 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): REQUEST (rebinding) Jan 13 19:57:26 lp1907306-g systemd-networkd[22430]: DHCP CLIENT (0x39b455d6): EXPIRED focal: root@lp1907306-f:~# dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.4 amd64system and service manager root@lp1907306-f:~# journalctl -b -u systemd-networkd | grep 'ifindex 3' Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): STARTED on ifindex 3 root@lp1907306-f:~# journalctl -b -u systemd-networkd | grep 0xf2c32973 Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): STARTED on ifindex 3 Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): DISCOVER Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): OFFER Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (requesting) Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): ACK Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): lease expires in 59min 59s Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): T2 expires in 52min 29s Jan 13 18:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): T1 expires in 30min Jan 13 19:27:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (renewing) Jan 13 19:38:39 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (renewing) Jan 13 19:44:16 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (renewing) Jan 13 19:47:04 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (renewing) Jan 13 19:48:29 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (renewing) Jan 13 19:49:29 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (renewing) Jan 13 19:49:53 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (rebinding) Jan 13 19:53:38 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (rebinding) Jan 13 19:55:31 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (rebinding) Jan 13 19:56:31 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): REQUEST (rebinding) Jan 13 19:57:24 lp1907306-f systemd-networkd[23394]: DHCP CLIENT (0xf2c32973): EXPIRED bionic: root@lp1907306-b:~# dpkg -l systemd|grep systemd ii systemd237-3ubuntu10.44 amd64system and service manager root@lp1907306-b:~# journalctl -b -u systemd-networkd | grep 'ifindex 3' Jan 13 18:57:22 lp1907306-b systemd-networkd[25911]: DHCP CLIENT (0x9b4dacd8): STARTED on ifindex 3 root@lp1907306-b:~# journalctl -b -u systemd-networkd | grep 0x9b4dacd8 Jan 13 18:57:22 lp1907306-b systemd-networkd[25911]: DHCP CLIENT (0x9b4dacd8): STARTED on ifindex 3 Jan 13 18:57:22 lp1907306-b
[Touch-packages] [Bug 1903300] Re: systemd-networkd silently fails to set vxlan multicast group
** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1903300 Title: systemd-networkd silently fails to set vxlan multicast group Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Bug description: [impact] setting VXLAN.Group does not correctly configure multicast group [test case] taken from upstream bug, example networkd config: [NetDev] Kind=vxlan Name=myvx [VXLAN] VNI=1 Group=ff02::42:1 DestinationPort=8472 After restarting systemd-networkd the VXLAN device is created, but the group address is not assigned. Use ip -d link show myvx and networkctl show myvx to verify. [regression potential] any regression would likely cause problems only with VXLAN netdevs created by networkd. [scope] this is needed only for f. this was introduced by upstream commit 83cb24ac20b which was first in v243, so this bug does not exist in b and earlier. this was fixed by upstream commit 7c9b26900cc33daf080627daf5904de74c1ef267 (and two following commits) which were first included in v246, so this is already fixed in g and later. [original description] Fixed upstream, please include [1]. Thank you. [1] https://github.com/systemd/systemd/pull/15397 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.3 ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65 Uname: Linux 5.4.0-52-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.11 Architecture: amd64 CasperMD5CheckResult: skip Date: Fri Nov 6 14:16:19 2020 MachineType: QEMU Standard PC (Q35 + ICH9, 2009) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-52-generic root=UUID=97786d27-c04a-4592-a087-f19a689468a9 ro console=tty1 console=ttyS0 SourcePackage: systemd UpgradeStatus: Upgraded to focal on 2020-08-27 (70 days ago) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-5.1 dmi.modalias: dmi:bvnSeaBIOS:bvrrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-5.1:cvnQEMU:ct1:cvrpc-q35-5.1: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-5.1 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1903300/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890448] Re: hwdb: Add EliteBook to use micmute hotkey
@kaihengfeng can you verify this for focal?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1890448
Title:
hwdb: Add EliteBook to use micmute hotkey
Status in HWE Next:
New
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Focal:
Fix Committed
Bug description:
[Impact]
Micmute hotkey on many HP EliteBooks don't work.
[Fix]
Commit b6eb208b29ae ("hwdb: Add EliteBook to use micmute hotkey"), to map AT
keyboard's scancode to micmute hotkey.
[Test]
With the one-liner fix, micmute hotkey works on all the EliteBooks I tested.
[Regression Potential]
The hwdb originally only matches a few EliteBook, and fix changes that to
match all EliteBook models. So if there's an EliteBook that uses the scancode
for other purpose, there will be a regression.
However, the risk is rather slim because HP is confident that all EliteBooks
use the same scancode for mic mute hotkey.
[scope]
this is needed for f and earlier.
this is fixed upstream by commit b6eb208b29ae which is included
starting in v246, so g and later are already fixed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1890448/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835660] Missing required logs.
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window: apport-collect 1835660 and then change the status of the bug to 'Confirmed'. If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'. This change has been made by an automated script, maintained by the Ubuntu Kernel Team. ** Changed in: linux (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed Status in OEM Priority Project: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Incomplete Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. [Impact] * Decoding failure messages in dmsg with a single lz4 initrd * Multiple lz4 compressed initrds cannot be decompressed by kernel, when loaded by grub * Multiple lz4 compressed initrds cannot be decompressed by kernel, when there is padding between them [Test Case] * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4 * Create an lz4 compressed initrd with a single test-file in it with some content. I.e. echo "second-initrd" > test-file, and then pack that with cpio hewc owned by root & lz4 -l. * Create a combined padded initrd of stock initrd, pad4, and the test-marker initrd created above. * Boot above with "break=top" kernel command line. * With broken kernels, there should be dmesg error message that decoding failed, and one will observe that /test-file does not exist in the shell. * With fixed kernel, /test-file in the initrd shell should exist, and should have the expected content "second-initrd". * The alignment and padding in the above test case depends on the size of the first initrd => if a given padded initrd does not reproduce the problem, try varying the size of the first initrd or that of the padding between 0..4. [Where problems could occur] * This changes compatible lz4 decompressor in the kernel, which can also be used by other kernel modules such as cryptography, squashfs, zram, f2fs, comprssed kernel image, pstore. For example, previously rejected files with "bogus" length and extra padding may now be accepted, whereas they were previously getting rejected by the decompressor. * Ideally kernel should switch to the stable lz4 format which has better specification of end of stream. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1908067] Re: systemd-fsckd test fails on groovy checking plymouth-start isactive
autopkgtest passes on groovy: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/s/systemd/20210112_092742_83d2c@/log.gz ** Tags removed: verification-needed verification-needed-groovy ** Tags added: verification-done verification-done-groovy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1908067 Title: systemd-fsckd test fails on groovy checking plymouth-start isactive Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Groovy: Fix Committed Bug description: [impact] systemd-fsckd test fails on groovy because plymouth-start service is active [test case] check autopkgtest logs of systemd-fsckd test case on groovy [regression potential] incorrectly passed, or failed, systemd-fsckd test [scope] this is needed only for groovy. the plymouth-start.service did not include RemainAfterExit=true before groovy, so the service is expected to be inactive when checked by the test before groovy. this is already fixed in hirsute: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c46eda821e97df5595a4cdc5f5c41a9b49a51745 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1908067/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1878955] Re: resolved dhclient-enter-hook complains about an empty file
bionic: root@lp1878955-b:~# dpkg -l systemd|grep systemd ii systemd237-3ubuntu10.43 amd64system and service manager root@lp1878955-b:~# dhclient -i ens8 cmp: EOF on /tmp/tmp.poVVjvvwPp which is empty root@lp1878955-b:~# dpkg -l systemd|grep systemd ii systemd237-3ubuntu10.44 amd64system and service manager root@lp1878955-b:~# dhclient -i ens8 root@lp1878955-b:~# ** Tags removed: verification-needed verification-needed-bionic verification-needed-focal ** Tags added: verification-done verification-done-bionic verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1878955 Title: resolved dhclient-enter-hook complains about an empty file Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Bug description: [impact] When starting/using `dhclient`, it will often return an error such as: cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty [test case] run dhclient for the first time (for the current boot) on a bionic/focal system, or remove the file(s) in /run/systemd/resolved.conf.d/ starting with 'isc-dhcp-*', and then run dhclient. [regression potential] any regression would likely cause the DNS configuration that dhclient gets to not be properly reported to systemd-resolved, resulting in problematic/broken systemd DNS resolution. [scope] this is needed in b/f this hook was removed from systemd starting in g, and the hook was not yet added in x, so this change is needed only in b and f. [original description] When starting/using `dhclient`, it will often return an error such as: cmp: EOF on /tmp/tmp.yCyV6zBzhB which is empty This is due to the use of `cmp` in "/etc/dhcp/dhclient-enter- hooks.d/resolved" Because the $oldstate file can be empty, or different, it should use `cmp --quiet` This happens when "/run/systemd/resolved.conf.d/isc- dhcp-v*-$interface.conf" files do not exist, or when the content changes. This is very loosely related to https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1878955/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1905245] Re: "Failed to parse bus message: Invalid argument" with Linux 5.8
focal host reproduction: root@lp1905245-f:~# uname -a Linux lp1905245-f 5.8.0-36-generic #40~20.04.1-Ubuntu SMP Wed Jan 6 10:15:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux root@lp1905245-f:~# dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.3 amd64system and service manager root@lp1905245-f:~# systemctl show -p CapabilityBoundingSet apparmor Failed to parse bus message: Invalid argument root@lp1905245-f:~# echo $? 1 focal container repro: root@lp1905245-f:~# lxc shell focal root@focal:~# dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.3 amd64system and service manager root@focal:~# systemctl show -p CapabilityBoundingSet apparmor Failed to parse bus message: Invalid argument root@focal:~# echo $? 1 bionic container repro: root@lp1905245-f:~# lxc shell bionic root@bionic:~# dpkg -l systemd|grep systemd ii systemd237-3ubuntu10.43 amd64system and service manager root@bionic:~# systemctl show -p CapabilityBoundingSet apparmor Failed to parse bus message: Invalid argument root@bionic:~# echo $? 1 focal host verification: root@lp1905245-f:~# dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.4 amd64system and service manager root@lp1905245-f:~# systemctl show -p CapabilityBoundingSet apparmor CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock cap_ipc_owner cap_sys_module cap_sys_> root@lp1905245-f:~# echo $? 0 focal container verification: root@focal:~# dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.4 amd64system and service manager root@focal:~# systemctl show -p CapabilityBoundingSet apparmor CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock cap_ipc_owner cap_sys_module cap_sys_> root@focal:~# echo $? 0 bionic container verification: root@bionic:~# dpkg -l systemd|grep systemd ii systemd237-3ubuntu10.44 amd64system and service manager root@bionic:~# systemctl show -p CapabilityBoundingSet apparmor CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock cap_ipc_owner cap_sys_module cap_sys_r root@bionic:~# echo $? 0 ** Tags removed: verification-needed verification-needed-bionic verification-needed-focal ** Tags added: verification-done verification-done-bionic verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1905245 Title: "Failed to parse bus message: Invalid argument" with Linux 5.8 Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Bug description: [impact] newer kernels introduced a new capability, and existing systemd doesn't have the name mapping for the new cap (since the mapping table is generated at systemd compile time), so it fails when trying to map the capability to a user-facing name, which causes failure when running commands like 'systemctl show' [test case] install a focal system, and install the 5.8 (or newer) kernel, e.g. from linux-generic-hwe-20.04-edge, and reboot into the new kernel. Find any service that does not specify its CapabilityBoundingSet; e.g. 'apparmor', and run systemctl show on it: ubuntu@lp1905245-f:~$ systemctl show -p CapabilityBoundingSet apparmor Failed to parse bus message: Invalid argument the command should correctly show the value, e.g.: $ systemctl show -p CapabilityBoundingSet apparmor CapabilityBoundingSet=cap_chown cap_dac_override ...etc... [regression potential] a regression would likely occur while systemd is parsing or printing or otherwise handling kernel capabilities. A regression could happen when running systemd commands, such as systemctl, or when pid1 is managing services. [scope] this is needed only in focal and bionic. This is fixed upstream by PR 16424: https://github.com/systemd/systemd/pull/16424 which was first included in v246, so this is already fixed in groovy and later. This was introduced upstream in systemd by commit 52610b020c077ee769c6923249f7e6c4e99d2980 which was first included in v235, so this bug does not exist in Xenial. This bug will reproduce on any system running under the 5.8 kernel, with the new capability, if the systemd binary was compiled with kernel headers that do not include the new capability. This
Re: [Touch-packages] [Bug 1835660] Missing required logs.
I want to sincerely thank you for your information. I assume that you are referring to my ubuntu based Linux Mint 20.04 problem. Since yesterday, I have removed and installed Mint 20.1 and find a little error with my initramfs but I have nothing to worry about. I will file this in my archive of Mint/Ubuntu remedies. Thank you for your input. On Wed, Jan 13, 2021, 3:41 PM Ubuntu Kernel Bot <1835...@bugs.launchpad.net> wrote: > This bug is missing log files that will aid in diagnosing the problem. > While running an Ubuntu kernel (not a mainline or third-party kernel) > please enter the following command in a terminal window: > > apport-collect 1835660 > > and then change the status of the bug to 'Confirmed'. > > If, due to the nature of the issue you have encountered, you are unable > to run this command, please add a comment stating that fact and change > the bug status to 'Confirmed'. > > This change has been made by an automated script, maintained by the > Ubuntu Kernel Team. > > ** Changed in: linux (Ubuntu) >Status: New => Incomplete > > -- > You received this bug notification because you are subscribed to a > duplicate bug report (1870260). > https://bugs.launchpad.net/bugs/1835660 > > Title: > initramfs unpacking failed > > Status in OEM Priority Project: > New > Status in grub2 package in Ubuntu: > Invalid > Status in initramfs-tools package in Ubuntu: > Invalid > Status in linux package in Ubuntu: > Incomplete > > Bug description: > "initramfs unpacking failed: Decoding failed", message appears on > boot up. > > If I "update-initramfs" using gzip instead of lz, then boot up passes > without decoding failed message. > > --- > > However, we currently believe that the decoding error reported in > dmesg is actually harmless and has no impact on usability on the > system. > > Switching from lz4 to gzip compression, simply papers over the > warning, without any benefits, and slows down boot. > > Kernel should be fixed to correctly parse lz4 compressed initrds, or > at least lower the warning, to not be user visible as an error. > > [Impact] > >* Decoding failure messages in dmsg with a single lz4 initrd > >* Multiple lz4 compressed initrds cannot be decompressed by kernel, > when loaded by grub > >* Multiple lz4 compressed initrds cannot be decompressed by kernel, > when there is padding between them > > [Test Case] > >* Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4 > >* Create an lz4 compressed initrd with a single test-file in it with > some content. I.e. echo "second-initrd" > test-file, and then pack > that with cpio hewc owned by root & lz4 -l. > >* Create a combined padded initrd of stock initrd, pad4, and the > test-marker initrd created above. > >* Boot above with "break=top" kernel command line. > >* With broken kernels, there should be dmesg error message that > decoding failed, and one will observe that /test-file does not exist > in the shell. > >* With fixed kernel, /test-file in the initrd shell should exist, and > should have the expected content "second-initrd". > >* The alignment and padding in the above test case depends on the > size of the first initrd => if a given padded initrd does not > reproduce the problem, try varying the size of the first initrd or > that of the padding between 0..4. > > > [Where problems could occur] > >* This changes compatible lz4 decompressor in the kernel, which can > also be used by other kernel modules such as cryptography, squashfs, > zram, f2fs, comprssed kernel image, pstore. For example, previously > rejected files with "bogus" length and extra padding may now be > accepted, whereas they were previously getting rejected by the > decompressor. > >* Ideally kernel should switch to the stable lz4 format which has > better specification of end of stream. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed Status in OEM Priority Project: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Incomplete Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4
[Touch-packages] [Bug 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: docker.io (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in snapd: Confirmed Status in docker.io package in Ubuntu: Confirmed Status in lxc package in Ubuntu: Fix Released Status in lxcfs package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Fix Released Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1850667/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1850667] Re: cgroup v2 is not fully supported yet, proceeding with partial confinement
** Also affects: snapd Importance: Undecided Status: New ** Changed in: snapd Status: New => Confirmed ** Changed in: snapd Importance: Undecided => High ** Changed in: snapd Assignee: (unassigned) => Maciej Borzecki (maciek-borzecki) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1850667 Title: cgroup v2 is not fully supported yet, proceeding with partial confinement Status in snapd: Confirmed Status in docker.io package in Ubuntu: Confirmed Status in lxc package in Ubuntu: Fix Released Status in lxcfs package in Ubuntu: Fix Released Status in lxd package in Ubuntu: Fix Released Status in snapd package in Ubuntu: In Progress Bug description: Systemd upstream switched the default cgroup hierarchy to unified with v243. This change is reverted by the Ubuntu systemd packages, but as unified is the way to go per upstream support should be added to all relevant Ubuntu packges (and snaps): https://github.com/systemd/systemd/blob/v243/NEWS#L56 * systemd now defaults to the "unified" cgroup hierarchy setup during build-time, i.e. -Ddefault-hierarchy=unified is now the build-time default. Previously, -Ddefault-hierarchy=hybrid was the default. This change reflects the fact that cgroupsv2 support has matured substantially in both systemd and in the kernel, and is clearly the way forward. Downstream production distributions might want to continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for their builds as unfortunately the popular container managers have not caught up with the kernel API changes. Systemd is rebuilt using the new default and is available from the following PPA for testing: https://launchpad.net/~rbalint/+archive/ubuntu/systemd-unified-cgh The autopkgtest results against other packges are available here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified-cgh/?format=plain https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-focal-rbalint-systemd-unified-cgh/?format=plain lxc autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz snapd autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/s/snapd/20191030_161354_94b26@/log.gz docker.io autopkgtest failing: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-eoan-rbalint-systemd-unified- cgh/eoan/amd64/d/docker.io/20191030_155944_2331e@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1850667/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 48734] Re: Home permissions too open
Updates for adduser and shadow were both uploaded to hirsute-proposed
yesterday as per https://lists.ubuntu.com/archives/ubuntu-devel-
discuss/2021-January/018901.html:
https://launchpad.net/ubuntu/+source/shadow/1:4.8.1-1ubuntu8
https://launchpad.net/ubuntu/+source/adduser/3.118ubuntu5
shadow has already migrated to the release pocket, and with any luck
adduser will migrate soon too which should resolve this issue.
** Also affects: shadow (Ubuntu)
Importance: Undecided
Status: New
** Also affects: adduser (Ubuntu Hirsute)
Importance: Medium
Status: Opinion
** Also affects: shadow (Ubuntu Hirsute)
Importance: Undecided
Status: New
** Changed in: adduser (Ubuntu Hirsute)
Status: Opinion => Fix Committed
** Changed in: shadow (Ubuntu Hirsute)
Status: New => Fix Committed
** Changed in: shadow (Ubuntu Hirsute)
Status: Fix Committed => Fix Released
** Changed in: shadow (Ubuntu Hirsute)
Assignee: (unassigned) => Alex Murray (alexmurray)
** Changed in: adduser (Ubuntu Hirsute)
Assignee: (unassigned) => Alex Murray (alexmurray)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/48734
Title:
Home permissions too open
Status in adduser package in Ubuntu:
Fix Committed
Status in shadow package in Ubuntu:
Fix Released
Status in adduser source package in Hirsute:
Fix Committed
Status in shadow source package in Hirsute:
Fix Released
Status in Ubuntu RTM:
Opinion
Bug description:
Binary package hint: debian-installer
On a fresh dapper install i noticed that the file permissons for the
home directory for the user created by the installer is set to 755,
giving read access to everyone on the system.
Surely this is a bad idea? If your set on the idea can we atleast have
a option during the boot proccess?
Also new files that are created via the console ('touch' etc.) are
done so with '644' permissons, is there anything that can be done
here? nautlius seems to create files at '600', which is a better
setting.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1908167] Re: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic
@Robie, The Hirsute doesn't have this regression since I cherry-picked the upstream patch to Hirsute, all needed patches are in the Hirsute already. But for groovy and focal, the patch can't be applied to them without changing, so I backported the patch to groovy and focal, the regression is introduced when backporting. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1908167 Title: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic Status in HWE Next: New Status in OEM Priority Project: New Status in pulseaudio package in Ubuntu: Fix Released Status in pulseaudio source package in Focal: Fix Committed Status in pulseaudio source package in Groovy: Fix Committed Status in pulseaudio source package in Hirsute: Fix Released Bug description: [Impact] On the Dell AIO machines, there is no internal mic, after plugging a headset, users expect the headset-mic or headphone-mic could be selected automatically. But with the current rule, the headset-mic/headphone-mic will not be selected automatically and even users manually select them, they will not show up in the gnome sound setting, and users could not record sound by headset-mic/headphone-mic. [Fix] backport a patch from pulseaudio mergerequest, the patch is going to be merged to pulseaudio 14.1. This patch could be backported to hirsute without any change, but need to be changed if backport it to groovy and focal. [Test] With the old pulseaudio (prior to 1:13.99.1-1ubuntu3.10), plugging in a headset to the problematic Dell AIO machine will not automatically select headset-mic/headphone-mic, and they also do not show up in Gnome sound settings, leading to failure to record any sound. With the new proposed package, on those Dell AIO, plug a headset, open the gnome sound setting, the headset-mic is selected automatically, use the headset-mic to record the sound, the sound could be recorded and the sound quality is good. [Where problems could occur] This patch could change the policy of audio device switching, it will not affect all audio devices, but only the devices which has AVAIL_UNKNOWN available status, that means it has possibility to introduce the regression on headphone-mic ,headset-mic, internal mic and internal speaker's switching since they all has AVAIL_UNKNOWN status. For example, after unpluging the headset, the input device will not switch to internal mic automatically or after unplug the headphone, the output device will not switch to internal speaker automatically. But this possibility is very low, we have tested the patch on many Dell and Lenovo machines, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1908167/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911614] [NEW] Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic
Public bug reported: Just as the title says, the 20.04 and 20.04.1 images use the HWE version of linux-generic resulting in upgrades to the 5.8 series kernel. This seems to effect Ubuntu only, or I should say I checked the Kubuntu, Ubuntu Mate, Xubuntu, and Lubuntu iso manifests which all correctly list linux-generic. Also HWE is not truly complete without the accompanying HWE Xstack. I checked all the documentation I could find and this was clearly not intentional. In fact the manifest for Ubuntu Focal Beta still used linux-generic, so this got messed up some time between April 3, 2020 and April 23, 2020. Here's just one example of the documentation for kernel support in Focal LTS: https://ubuntu.com/about/release-cycle#ubuntu-kernel-release-cycle Installations performed with 20.04 and 20.04.1 media were supposed to remain on the 5.4 series kernel throughout Focal's 5 year lifespan as had been the case since HWE was introduced. The first step in fixing this needs to be stopping fresh installs of Focal using the 20.04 and 20.04.1 media from immediately upgrading to the 5.8 series kernel. It might be a little tricky to revert users from 5.8 to 5.4, but there have been reports of breakage, particularly concerning Broadcom wifi drivers and some graphics problems. But the graphics problems could also be exacerbated by the lack of the matching HWE Xstack? At any rate it's a bug. ** Affects: ubuntu-meta (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1911614 Title: Ubuntu 20.04 and 20.04.1 images use linux-generic-hwe-20.04 instead of linux-generic Status in ubuntu-meta package in Ubuntu: New Bug description: Just as the title says, the 20.04 and 20.04.1 images use the HWE version of linux-generic resulting in upgrades to the 5.8 series kernel. This seems to effect Ubuntu only, or I should say I checked the Kubuntu, Ubuntu Mate, Xubuntu, and Lubuntu iso manifests which all correctly list linux-generic. Also HWE is not truly complete without the accompanying HWE Xstack. I checked all the documentation I could find and this was clearly not intentional. In fact the manifest for Ubuntu Focal Beta still used linux-generic, so this got messed up some time between April 3, 2020 and April 23, 2020. Here's just one example of the documentation for kernel support in Focal LTS: https://ubuntu.com/about/release-cycle#ubuntu-kernel-release-cycle Installations performed with 20.04 and 20.04.1 media were supposed to remain on the 5.4 series kernel throughout Focal's 5 year lifespan as had been the case since HWE was introduced. The first step in fixing this needs to be stopping fresh installs of Focal using the 20.04 and 20.04.1 media from immediately upgrading to the 5.8 series kernel. It might be a little tricky to revert users from 5.8 to 5.4, but there have been reports of breakage, particularly concerning Broadcom wifi drivers and some graphics problems. But the graphics problems could also be exacerbated by the lack of the matching HWE Xstack? At any rate it's a bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1911614/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1910576] Re: [MIR] libbpf (dependency of iproute2)
** Description changed: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] [Quality assurance] + At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. [Dependencies] + libc6: main + libelf1: main + zlib1g: main [Standards compliance] [Maintenance] [Background information] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1910576 Title: [MIR] libbpf (dependency of iproute2) Status in iproute2 package in Ubuntu: New Status in libbpf package in Ubuntu: Incomplete Bug description: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] [Quality assurance] At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. [Dependencies] libc6: main libelf1: main zlib1g: main [Standards compliance] [Maintenance] [Background information] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1910576/+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 1910576] Re: [MIR] libbpf (dependency of iproute2)
** Description changed: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] [Quality assurance] At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. [Dependencies] libc6: main libelf1: main zlib1g: main [Standards compliance] + $ lintian --pedantic libbpf_0.3-2.dsc + P: libbpf source: no-homepage-field + P: libbpf source: silent-on-rules-requiring-root [Maintenance] [Background information] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1910576 Title: [MIR] libbpf (dependency of iproute2) Status in iproute2 package in Ubuntu: New Status in libbpf package in Ubuntu: Incomplete Bug description: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] [Quality assurance] At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. [Dependencies] libc6: main libelf1: main zlib1g: main [Standards compliance] $ lintian --pedantic libbpf_0.3-2.dsc P: libbpf source: no-homepage-field P: libbpf source: silent-on-rules-requiring-root [Maintenance] [Background information] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1910576/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1902960] Re: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases
I confirm I got it working at first boot on azure with systemd-245.4-4ubuntu3.4 ``` ubuntu@machine-3:~$ sudo networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 etherroutableconfigured 2 links listed. ubuntu@machine-3:~$ sudo apt update Hit:1 http://ppa.launchpad.net/telegraf-devs/ppa/ubuntu focal InRelease Hit:2 http://us.archive.ubuntu.com/ubuntu focal InRelease Get:3 http://us.archive.ubuntu.com/ubuntu focal-updates InRelease [114 kB] Get:4 http://us.archive.ubuntu.com/ubuntu focal-backports InRelease [101 kB] Get:5 http://us.archive.ubuntu.com/ubuntu focal-security InRelease [109 kB] Get:6 http://us.archive.ubuntu.com/ubuntu focal-proposed InRelease [267 kB] Fetched 591 kB in 3s (225 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date. ubuntu@machine-3:~$ dpkg -l systemd Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii systemd245.4-4ubuntu3.4 amd64system and service manager ``` -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1902960 Title: Upgrade from 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to break DNS resolution in some cases Status in cloud-images: New Status in systemd: New Status in cloud-init package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Focal: Incomplete Status in systemd source package in Focal: Fix Committed Status in cloud-init source package in Groovy: Incomplete Status in systemd source package in Groovy: Fix Committed Bug description: [impact] on boot of a specific azure instance, the ID_NET_DRIVER parameter of the instance's eth0 interface is not set. That leads to a failure of systemd-networkd to take control of the interface after a restart of systemd-networkd, which results in DNS failures (at first) and eventually complete loss of networking (once the DHCP lease expires). [test case] this occurs on first boot of an instance using the specific image; it is not reproducable using the latest ubuntu image nor any reboot of the affected image, and it has not been reproducable (for me) when using debug-enabled images based on the affected image. So, while the problem is reproducable using the specific image in question, it's not possible to verify the fix since any change to the image removes reproducability. however, while the problem itself can't be reproduced and then verified, if the assumption is correct (that the 'add' uevent is being missed on boot), that is possible to test and verify: $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc $ sudo rm /run/udev/data/n2 (note, change 'n2' to whichever network interface index is correct) $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER $ sudo udevadm trigger -c change /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER (note the 'change' uevent did not populate ID_NET_DRIVER property) $ sudo udevadm trigger -c add /sys/class/net/eth0 $ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER E: ID_NET_DRIVER=hv_netvsc (note the 'add' uevent did populate ID_NET_DRIVER) the test verification should result in ID_NET_DRIVER being populated for a 'change' uevent. [regression potential] any regression would likely involve problems with systemd-udevd processing 'change' events from network devices, and/or incorrect udevd device properties. [scope] this is needed only for focal and groovy. this is fixed by upstream commit e0e789c1e97 which is first included in v247, so this is fixed already in hirsute. while this commit is not included in bionic, due to the difficult nature of reproducing (and verifying) this, and the fact it has only been seen once on a focal image, I don't think it's appropriate to SRU to bionic at this point; possibly it may be appropriate if this is ever reproduced with a bionic image. [other info] note that this bug's subject and description, as well as the upstream systemd bug subject and description, talk about the problem being DNS resolution. However that is strictly a side-effect of the real problem and is not the actual issue. [original description] The systemd upgrade 245.4-4ubuntu3.3 to 245.4-4ubuntu3.2 appears to have broken DNS resolution across much of our Azure fleet earlier today. We ended up mitigating this by forcing reboots on the associated instances, no combination of
[Touch-packages] [Bug 1627564] Re: Debconf crash due to assertion failure in ensure_surface_for_gicon [gtkiconhelper.c:493] (when png loader is missing/during upgrades)
> OTOH I think there is an easy fix for GTK+ to always include an
"image-missing" icon at compile time
I'm sorry, it's not that easy. A PNG icon is indeed included, and it
gets found properly (also from the actual icon theme; that is a
dependency of GTK). The problem is the ability to load PNGs *at all* is
not available sometimes during the middle of dist-upgrades.
I think extending that test program in Debconf (referred to in the IRC
log above) to do a bit more work - trying to load an icon - might make
the fallback trigger in this case too.
e.g:
my $window = Gtk3::Window->new('toplevel');
my $icontheme = Gtk3::IconTheme::get_default;
my $icon = $icontheme->load_icon('image-missing', 32, []);
If you manually remove '/usr/lib/*/gdk-pixbuf-2.0/2.10.0/loaders.cache'
(suggest doing this in a VM) then you can reproduce this by extracting
the program out of Debconf.
** Changed in: gtk+3.0 (Ubuntu)
Status: New => Invalid
** Changed in: gtk+3.0 (Ubuntu Focal)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to debconf in Ubuntu.
https://bugs.launchpad.net/bugs/1627564
Title:
Debconf crash due to assertion failure in ensure_surface_for_gicon
[gtkiconhelper.c:493] (when png loader is missing/during upgrades)
Status in debconf package in Ubuntu:
Confirmed
Status in gtk+3.0 package in Ubuntu:
Invalid
Status in debconf source package in Focal:
Confirmed
Status in gtk+3.0 source package in Focal:
Invalid
Bug description:
https://errors.ubuntu.com/problem/2b11576fed59ad23c640bc85a266cc82ec30a689
https://errors.ubuntu.com/problem/9d612b3f25168e76adb91fa4eedc301ffa632383
---
bubble opened up indicating there was a failure during the latest
update.
ProblemType: Crash
DistroRelease: Ubuntu 16.10
Package: lightdm-gtk-greeter 2.0.1-2ubuntu4
ProcVersionSignature: Ubuntu 4.8.0-16.17-generic 4.8.0-rc7
Uname: Linux 4.4.0-9136-generic i686
ApportVersion: 2.20.3-0ubuntu7
Architecture: i386
Date: Sun Sep 25 20:37:06 2016
ExecutablePath: /usr/sbin/lightdm-gtk-greeter
InstallationDate: Installed on 2016-08-04 (52 days ago)
InstallationMedia: Lubuntu 16.10 "Yakkety Yak" - Alpha i386 (20160727)
ProcCmdline: /usr/sbin/lightdm-gtk-greeter
ProcEnviron:
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=en_US.UTF-8
SHELL=/bin/false
Signal: 6
SourcePackage: lightdm-gtk-greeter
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:
modified.conffile..etc.lightdm.lightdm-gtk-greeter.conf:
[greeter]
theme-name = Lubuntu-dark-panel
mtime.conffile..etc.lightdm.lightdm-gtk-greeter.conf:
2016-08-14T22:33:57.293011
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1627564/+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 1910537] Re: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer)
> Please try running this command: > xrandr --output HDMI-1 --set audio on > If it still doesn't work then try logging in again after that. Neither did help... -- 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/1910537 Title: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer) Status in pulseaudio package in Ubuntu: Incomplete Bug description: This is a complicated thing. I have a very specific problem with audio output on HDMI. I want to use an older notebook with Lubuntu 20.04 as a video source for libreoffice slides, videos etc. to feed them over HDMI into a Blackmagic Design ATEM Mini Pro ISO (video mixer) as one input. Configured on the desktop just like a second screen or beamer. Video works well and rock-stable, no problem at all. But not audio. Although I carefully configured audio with pavucontrol to be directed to the HDMI output, the ATEM switcher does not recognize it as an audio source (like when connecting a digital camera) and does not receive or indicate any audio input. Note: But when I use the very same computer, same HDMI cable, same video with a cheap chinese portable LCD screen with speakers (i.e. pull the cable from the ATEM and plug it into the screen) it immediately starts playing both video and audio. So there is evidence that the ubuntu notebook definitely passes it's sound to HDMI and there's really an audio signal on the HDMI. I've opened a bug at Blackmagic Design, and got their reply that they can't help and have never heard of such a problem before. Their guess is that the linux notebook is not setting EDID configuration correctly and thus not recognized by the ATEM, while the cheap LCD screen propably does not care about EDID and just plays everything, therefore a wrong EDID information would not matter. Although I have decades of experience with Linux, I am not too familiar with details of HDMI and the internals of the X11 driver, so I'm not sure where to start debugging, not even, whether this is a problem of Xorg/X11 or pulseaudio. I've checked this with another notebook with much more recent (intel) hardware, which offers dozens of HDMI audio options in the pavucontrol selection menu, but same problem: Video works, but the ATEM does not recognize it as a audio source. Blackmagic Design (they're good in Windows and MacOS, but not Linux) recommended to use an edid manager, whatever this means. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-58.64-generic 5.4.73 Uname: Linux 5.4.0-58-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: LXQt Date: Thu Jan 7 13:16:26 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DpkgLog: ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0742] InstallationDate: Installed on 2020-05-16 (235 days ago) InstallationMedia: Lubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 04f2:b336 Chicony Electronics Co., Ltd Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer AO756 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-58-generic root=UUID=a69345e2-b61e-4d25-baab-b23f75273af6 ro quiet cryptdevice=UUID=d132b97b-f47a-4432-88b5-42aca187b9ff:luks-d132b97b-f47a-4432-88b5-42aca187b9ff root=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff resume=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/19/2012 dmi.bios.vendor: Acer dmi.bios.version: V1.05 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: Mimic dmi.board.vendor: Acer dmi.board.version: Type2 - Board Version dmi.chassis.type: 10 dmi.chassis.vendor: Acer dmi.chassis.version: V1.05 dmi.modalias: dmi:bvnAcer:bvrV1.05:bd07/19/2012:svnAcer:pnAO756:pvrV1.05:rvnAcer:rnMimic:rvrType2-BoardVersion:cvnAcer:ct10:cvrV1.05: dmi.product.family: Type1Family dmi.product.name: AO756 dmi.product.sku: Type1Sku0 dmi.product.version: V1.05 dmi.sys.vendor: Acer version.compiz:
[Touch-packages] [Bug 1910576] Re: [MIR] libbpf (dependency of iproute2)
** Description changed: - [MIR] libbpf (dependency of iproute2) + [Availability] + libbpf | 0.1.0-1 | groovy/universe | source + libbpf | 0.3-2 | hirsute/universe | source + + [Rationale] + Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) + + [Security] + + [Quality assurance] + + [Dependencies] + + [Standards compliance] + + [Maintenance] + + [Background information] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1910576 Title: [MIR] libbpf (dependency of iproute2) Status in iproute2 package in Ubuntu: New Status in libbpf package in Ubuntu: Incomplete Bug description: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] [Quality assurance] [Dependencies] [Standards compliance] [Maintenance] [Background information] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1910576/+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 1904793] Re: upower abruptly thinks battery has gone to 1% and hibernates
Thanks! ** Changed in: upower (Ubuntu) Importance: Undecided => Low ** Changed in: upower (Ubuntu) Status: New => Triaged ** Also affects: upower via https://gitlab.freedesktop.org/upower/upower/-/issues/136 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upower in Ubuntu. https://bugs.launchpad.net/bugs/1904793 Title: upower abruptly thinks battery has gone to 1% and hibernates Status in Upower: Unknown Status in upower package in Ubuntu: Triaged Bug description: Whenever I go on battery after 20-30 minutes upower will very abruptly think my battery is at 1% and force my laptop to hibernate. This seems to happen at random times, I've seen it when my battery was reported to be 90%, 76%, 45%, 25%, etc. If I try to resume Ubuntu locks up forcing me to hard reset the machine. I suspect this is because upower thinks my battery is still at 1% when its not. My laptops firmware correctly reports the battery level and shows that I have plenty of power remaining. The last few times this happened I kept powertop up which shows that I do have plenty of power even when upower thinks I have none. Essentially this makes my laptop unusable on battery. Laptop: Lenovo X1 Carbon Extreme Gen 2 ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: upower 0.99.11-2 ProcVersionSignature: Ubuntu 5.8.0-29.31-generic 5.8.14 Uname: Linux 5.8.0-29-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu50.1 Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Nov 18 13:59:24 2020 InstallationDate: Installed on 2019-12-29 (325 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20191220) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: upower UpgradeStatus: Upgraded to groovy on 2020-10-23 (25 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/upower/+bug/1904793/+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 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)
can anyone attach a coredump from a crashed systemd-resolved? ** Changed in: systemd (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1906331 Title: systemd-resolve crashes fairly often (and reports various assertions) Status in systemd package in Ubuntu: Incomplete Bug description: (Tested on regularly updated Ubuntu 20.04, currently i use systemd 245.4-4ubuntu3.2) I observe fairly lot of segfaults of systemd-resolve. Frequency vary but … see below. I have no clue what is the reason. Specific feature of my machine is that apart from normal cable connection (to OpenWRT router) I use OpenVPN for business network (and this submits specific nameserver for myorg.local domain). ~ $ LC_ALL=C dmesg -T --level=info | grep systemd-resolve [Sun Nov 29 11:47:37 2020] systemd-resolve[1629307]: segfault at 190eed7bdc6 ip 7fd98f771dc9 sp 7ffc2352a100 error 4 in libsystemd-shared-245.so[7fd98f74c000+16e000] [Sun Nov 29 11:57:27 2020] systemd-resolve[1629787]: segfault at 1f ip 55ab7b0cb686 sp 7fff78ce4bd0 error 4 in systemd-resolved[55ab7b0a4000+3e000] [Sun Nov 29 12:07:37 2020] systemd-resolve[1630481]: segfault at 191 ip 55ca69fed91c sp 7ffc4d757dc0 error 6 in systemd-resolved[55ca69fc2000+3e000] [Sun Nov 29 13:12:26 2020] systemd-resolve[1638829]: segfault at 19224162371 ip 7fc1bc9b9dc9 sp 7ffc21378170 error 4 in libsystemd-shared-245.so[7fc1bc994000+16e000] [Sun Nov 29 13:32:57 2020] systemd-resolve[1639886]: segfault at 1926d8126d3 ip 7f7ed17e9dc9 sp 7ffda2cea0b0 error 4 in libsystemd-shared-245.so[7f7ed17c4000+16e000] [Sun Nov 29 13:42:37 2020] systemd-resolve[1640246]: segfault at 61 ip 558d992e2686 sp 7fff08906af0 error 4 in systemd-resolved[558d992bb000+3e000] [Sun Nov 29 15:42:26 2020] systemd-resolve[1645397]: segfault at 1943c92afc7 ip 7fd4c1721dc9 sp 7fff25259ce0 error 4 in libsystemd-shared-245.so[7fd4c16fc000+16e000] [Sun Nov 29 16:02:36 2020] systemd-resolve[1646052]: segfault at 1947ecb3726 ip 7f1008549dc9 sp 7fff44a6db70 error 4 in libsystemd-shared-245.so[7f1008524000+16e000] [Sun Nov 29 17:42:35 2020] systemd-resolve[1649403]: segfault at 71 ip 55a37fe5a686 sp 7ffd9a160440 error 4 in systemd-resolved[55a37fe33000+3e000] [Sun Nov 29 17:52:35 2020] systemd-resolve[1649759]: segfault at 558d292947d0 ip 558d292947d0 sp 7ffec7ab3bf8 error 15 [Sun Nov 29 19:17:55 2020] systemd-resolve[1652349]: segfault at 558995b77cf0 ip 558995b77cf0 sp 7ffe545ae4a8 error 15 [Sun Nov 29 19:32:35 2020] systemd-resolve[1652640]: segfault at 19773c20194 ip 7f66bb529dc9 sp 7fffd7066fc0 error 4 in libsystemd-shared-245.so[7f66bb504000+16e000] [Sun Nov 29 20:03:54 2020] systemd-resolve[1653715]: segfault at 197e3aee918 ip 7fdc40b51dc9 sp 7ffde484fbf0 error 4 in libsystemd-shared-245.so[7fdc40b2c000+16e000] [Sun Nov 29 20:22:24 2020] systemd-resolve[1654540]: segfault at 19820a05297 ip 7f6a92839dc9 sp 7ffe4ba00440 error 4 in libsystemd-shared-245.so[7f6a92814000+16e000] [Sun Nov 29 21:13:10 2020] systemd-resolve[1660272]: segfault at 555f9a5915e0 ip 555f9a5915e0 sp 7fff053e5e68 error 15 [Sun Nov 29 21:32:34 2020] systemd-resolve[1661026]: segfault at 1991af73f2e ip 7ff194021dc9 sp 7fffa6d61680 error 4 in libsystemd-shared-245.so[7ff193ffc000+16e000] [Sun Nov 29 22:03:20 2020] systemd-resolve[1661941]: segfault at 5625966828e0 ip 5625966828e0 sp 7ffdf5a8bb48 error 15 [Sun Nov 29 22:32:44 2020] systemd-resolve[1662604]: segfault at 199f18ae01d ip 7f457c9d1dc9 sp 7ffc62b80ef0 error 4 in libsystemd-shared-245.so[7f457c9ac000+16e000] [Sun Nov 29 23:12:23 2020] systemd-resolve[1664072]: segfault at 73b8 ip 562619f8c93a sp 7ffd527b7ef0 error 6 in systemd-resolved[562619f61000+3e000] [Sun Nov 29 23:22:34 2020] systemd-resolve[1664423]: segfault at 19aaa4d4c00 ip 7f2621539dc9 sp 7ffc73102280 error 4 in libsystemd-shared-245.so[7f2621514000+16e000] [Mon Nov 30 00:12:23 2020] systemd-resolve[1666158]: segfault at 19b5c72000a ip 7f530b5c1dc9 sp 7ffc6007ccf0 error 4 in libsystemd-shared-245.so[7f530b59c000+16e000] [Mon Nov 30 00:47:54 2020] systemd-resolve[1667280]: segfault at 10036 ip 7f0736b8bbe8 sp 7fffed4d3cb0 error 4 in libsystemd-shared-245.so[7f0736acc000+16e000] [Mon Nov 30 01:57:53 2020] systemd-resolve[1669463]: segfault at 558d6b61c0c0 ip 558d6b61c0c0 sp 7ffc68df7198 error 15 [Mon Nov 30 02:58:08 2020] traps: systemd-resolve[1672553] general protection fault ip:55b967d86760 sp:7fffaecf4468 error:0 in systemd-resolved[55b967d5f000+3e000] [Mon Nov 30 03:38:08 2020] systemd-resolve[1673682]: segfault at 19e3c4d5050 ip 7fdf0ba29dc9 sp 7ffe4d561430
[Touch-packages] [Bug 1726124] Re: DNS domain search paths not updated when VPN started
Still an issue in 20.10 -- 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/1726124 Title: DNS domain search paths not updated when VPN started Status in network-manager package in Ubuntu: Confirmed Status in network-manager-openvpn package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I connect to work with openvpn through network-manager-openvpn. I'm selecting automatic (DHCP) to get an IP address, and "Use this connection only for resources on its network" to support split tunneling. In the last few versions of Ubuntu I used, this all worked fine. In Ubuntu 17.10 (fresh install, not upgrade) I can access hosts on both my VPN network and the internet, BUT I have to use FQDN for my VPN network hosts: the updates to the DNS search path provided by my VPN DHCP server are never being applied. Investigating the system I see that /etc/resolv.conf is pointing to /run/systemd/resolve/stub-resolv.conf and that resolv.conf does not have any of the VPN's search path settings in it: # This file is managed by man:systemd-resolved(8). Do not edit. # # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53 search home In previous versions of Ubuntu, where NetworkManager controlled the resolver not systemd, /etc/resolv.conf pointed to /run/NetworkManager/resolv.conf and there was a local dnsmasq instance that managed all the complexity. In Ubuntu 17.10 when I look in /run/NetworkManager/resolv.conf file, I see that the search paths ARE properly updated there: $ cat /run/NetworkManager/resolv.conf # Generated by NetworkManager search internal.mycorp.com other.mycorp.com home nameserver 127.0.1.1 However this file isn't being used, and also there's no dnsmasq running on the system so if I switch my /etc/resolv.conf to point to this file instead, then all lookups fail. Strangely, if I look at the systemd-resolv status I see that in theory systemd-resolve does seem to know about the proper search paths: $ systemd-resolve --status ... Link 3 (tun0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.3.0.10 10.8.42.2 DNS Domain: ~internal.mycorp.com ~other.mycorp.com but for whatever reason the search domains are not getting put into the resolv.conf file: $ host mydesk ;; connection timed out; no servers could be reached $ host mydesk.internal.mycorp.com mydesk.internal.mycorp.com has address 10.8.37.74 (BTW, the timeout in the failed attempt above takes 10s: it is SUPER frustrating when all your host lookups are taking that long just to fail). ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: systemd 234-2ubuntu12 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 22 15:08:57 2017 InstallationDate: Installed on 2017-10-21 (1 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018) MachineType: System manufacturer System Product Name ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-16-generic root=UUID=4384306c-5fed-4b48-97a6-a6d594c4f72b ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/02/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2101 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: M5A78L-M/USB3 dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2101:bd12/02/2014:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM5A78L-M/USB3:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: System Product Name dmi.product.version: System Version dmi.sys.vendor: System manufacturer To manage notifications
[Touch-packages] [Bug 1813394] Re: DROPBEAR_IFDOWN=* takes interface down but leaves netplan config
Which version of Mint (or which upstream Ubuntu it is based on?) I
wonder if there is a way to get those rows into the configs rather than
editing packaged files?
--
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/1813394
Title:
DROPBEAR_IFDOWN=* takes interface down but leaves netplan config
Status in dropbear package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Bug description:
On bionic, setting the network interface up (e.g. eno1) with DHCP now
causes a /run/netplan/eno1.yaml and a /run/net-eno1.conf file to be
written. The former gets imported by netplan after boot and causes the
DHCP lease from the initrd to be around forever, which I think goes
against the intent of DROPBEAR_IFDOWN=*.
I have brewed up a workaround script that lives in /etc/initramfs-
tools/scripts/init-bottom/hack-delete-netif-netplan.sh for now:
8< cut >8
#!/bin/sh
PREREQ=""
prereqs() {
echo "$PREREQ"
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
. /scripts/functions
log_begin_msg "Deleting all network configuration that systemd could try to
import"
rm /run/net-*.conf
rm /run/netplan/*.yaml
log_end_msg
8< cut >8
I think that dropbear-intiramfs's init-bottom script should do this in
addition to downing the interfaces that it finds via the
DROPBEAR_IFDOWN pattern. Do you agree?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dropbear/+bug/1813394/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911059] Re: gce: 247.1-4ubuntu1 causes loss of networking
** Changed in: systemd (Ubuntu) Assignee: Balint Reczey (rbalint) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1911059 Title: gce: 247.1-4ubuntu1 causes loss of networking Status in systemd package in Ubuntu: New Bug description: Summary === On Hirsute, upgrading or using to systemd 247.1-4ubuntu1 causes Google Cloud instance to loose network access. Expected Result === Working network access Actual Result === After upgrade, network access is lost and serial console is filled with messages about IPv4 martian source and ll header, see below. Steps to Reproduce === 1. Launch `daily-ubuntu-2104-hirsute-v20210107` the last known good image 2. sudo apt update 3. sudo apt install systemd 4. ssh is lost The images, built with this version do not appear to be able to start networking. Logs === Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915720] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.915724] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978762] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 483.978803] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042242] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.042302] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105412] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.105448] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168141] IPv4: martian source 10.138.0.56 from 169.254.169.254, on dev ens4 Jan 11 21:38:32 powersj-hirsuite-20210107 kernel: [ 484.168178] ll header: : 42 01 0a 8a 00 38 42 01 0a 8a 00 01 08 00 $ journalctl --no-pager -u systemd-net -- Journal begins at Mon 2021-01-11 21:30:31 UTC, ends at Mon 2021-01-11 21:52:03 UTC. -- Jan 11 21:30:35 ubuntu systemd[1]: Starting Network Service... Jan 11 21:30:35 ubuntu systemd-networkd[413]: Enumeration completed Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Interface name change detected, ens4 has been renamed to eth0. Jan 11 21:30:35 ubuntu systemd[1]: Started Network Service. Jan 11 21:30:35 ubuntu systemd-networkd[413]: eth0: Interface name change detected, eth0 has been renamed to ens4. Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: IPv6 successfully enabled Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Link UP Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Gained carrier Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 Jan 11 21:30:35 ubuntu systemd-networkd[413]: ens4: Classless static routes received from DHCP server: ignoring router option Jan 11 21:30:37 ubuntu systemd-networkd[413]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[413]: ens4: DHCPv6 lease lost Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopping Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: systemd-networkd.service: Succeeded. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Stopped Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Starting Network Service... Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: Gained IPv6LL Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: Enumeration completed Jan 11 21:37:27 powersj-hirsuite-20210107 systemd[1]: Started Network Service. Jan 11 21:37:27 powersj-hirsuite-20210107 systemd-networkd[2446]: ens4: DHCPv4 address 10.138.0.56/32 via 10.138.0.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911059/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1910576] Re: [MIR] libbpf (dependency of iproute2)
** Description changed: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] + Since the code is taken out of the Linux kernel, this should be treated similar to the kernel for security. Research uncovered no records about security issues. [Quality assurance] - At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. + At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. Project is taken from the kernel source and claims static analysis via LGTM and Coverty. Also has CI via Travis (https://travis-ci.com/github/libbpf/libbpf). + Right now there are no dep-8 tests. Though potentially it should be possible to create those, would this really add additional benefit beyond having upstream CI? + A test build on hirsute was showing no warnings beyond lintian complaining about things which would be changed if we had delta (unstable as series for example). Otherwise was clean. [Dependencies] libc6: main libelf1: main zlib1g: main [Standards compliance] $ lintian --pedantic libbpf_0.3-2.dsc P: libbpf source: no-homepage-field P: libbpf source: silent-on-rules-requiring-root [Maintenance] + As this is only taking out code from the kernel into a separate library package, the maintenance effort should be minimal. Packaging is done in Debian and is synced into Ubuntu (no delta). [Background information] + A discourse about why this is packaged outside the kernel can be found at https://lwn.net/Articles/836911/. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1910576 Title: [MIR] libbpf (dependency of iproute2) Status in iproute2 package in Ubuntu: Invalid Status in libbpf package in Ubuntu: New Bug description: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] Since the code is taken out of the Linux kernel, this should be treated similar to the kernel for security. Research uncovered no records about security issues. [Quality assurance] At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. Project is taken from the kernel source and claims static analysis via LGTM and Coverty. Also has CI via Travis (https://travis-ci.com/github/libbpf/libbpf). Right now there are no dep-8 tests. Though potentially it should be possible to create those, would this really add additional benefit beyond having upstream CI? A test build on hirsute was showing no warnings beyond lintian complaining about things which would be changed if we had delta (unstable as series for example). Otherwise was clean. [Dependencies] libc6: main libelf1: main zlib1g: main [Standards compliance] $ lintian --pedantic libbpf_0.3-2.dsc P: libbpf source: no-homepage-field P: libbpf source: silent-on-rules-requiring-root [Maintenance] As this is only taking out code from the kernel into a separate library package, the maintenance effort should be minimal. Packaging is done in Debian and is synced into Ubuntu (no delta). [Background information] A discourse about why this is packaged outside the kernel can be found at https://lwn.net/Articles/836911/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1910576/+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 1881142] Re: Installation on clean 20.04 LTS system results in "/usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:6 Unknown group 'pcscd', ignoring"
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: pcsc-cyberjack (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pcsc-lite in Ubuntu. https://bugs.launchpad.net/bugs/1881142 Title: Installation on clean 20.04 LTS system results in "/usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:6 Unknown group 'pcscd', ignoring" Status in pcsc-cyberjack package in Ubuntu: Confirmed Status in pcsc-lite package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu 20.04 LTS installed 2. Install "libifd-cyberjack6" package 3. Reload udev Expected results: * log contains no errors or warnings Actual results: * log contains messages: May 28 18:03:19 focal systemd[1]: Stopping udev Kernel Device Manager... May 28 18:03:19 focal systemd[1]: systemd-udevd.service: Succeeded. May 28 18:03:19 focal systemd[1]: Stopped udev Kernel Device Manager. May 28 18:03:19 focal systemd[1]: Starting udev Kernel Device Manager... May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:6 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:7 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:8 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:9 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:10 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:11 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:12 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:13 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:14 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:15 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:16 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:17 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:18 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:19 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:20 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:21 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:22 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:23 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:24 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd[1]: Started udev Kernel Device Manager. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: libifd-cyberjack6 3.99.5final.sp13+dfsg-2build1 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: MATE Date: Thu May 28 18:06:52 2020 InstallationDate: Installed on 2020-04-23 (34 days ago) InstallationMedia: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: pcsc-cyberjack UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pcsc-cyberjack/+bug/1881142/+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 1881142] Re: Installation on clean 20.04 LTS system results in "/usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:6 Unknown group 'pcscd', ignoring"
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: pcsc-lite (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pcsc-lite in Ubuntu. https://bugs.launchpad.net/bugs/1881142 Title: Installation on clean 20.04 LTS system results in "/usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:6 Unknown group 'pcscd', ignoring" Status in pcsc-cyberjack package in Ubuntu: Confirmed Status in pcsc-lite package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu 20.04 LTS installed 2. Install "libifd-cyberjack6" package 3. Reload udev Expected results: * log contains no errors or warnings Actual results: * log contains messages: May 28 18:03:19 focal systemd[1]: Stopping udev Kernel Device Manager... May 28 18:03:19 focal systemd[1]: systemd-udevd.service: Succeeded. May 28 18:03:19 focal systemd[1]: Stopped udev Kernel Device Manager. May 28 18:03:19 focal systemd[1]: Starting udev Kernel Device Manager... May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:6 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:7 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:8 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:9 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:10 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:11 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:12 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:13 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:14 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:15 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:16 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:17 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:18 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:19 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:20 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:21 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:22 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:23 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd-udevd[11464]: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules:24 Unknown group 'pcscd', ignoring May 28 18:03:19 focal systemd[1]: Started udev Kernel Device Manager. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: libifd-cyberjack6 3.99.5final.sp13+dfsg-2build1 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: MATE Date: Thu May 28 18:06:52 2020 InstallationDate: Installed on 2020-04-23 (34 days ago) InstallationMedia: Ubuntu-MATE 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: pcsc-cyberjack UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pcsc-cyberjack/+bug/1881142/+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 1911369] Re: [radeon] Horizontal lines of screen corruption after last update.
tried an older kernel. No change. 5.4.0-42-generic ** Attachment added: "screen_corruption.png" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1911369/+attachment/5452713/+files/screen_corruption.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1911369 Title: [radeon] Horizontal lines of screen corruption after last update. Status in linux package in Ubuntu: Confirmed Status in mesa package in Ubuntu: New Bug description: A clean install is fine if I don't take updates. If I do take the updates and reboot then I get heavy video corruption. This just started today. This is a dual boot system. The windows system has no issues. Appears to be software and not a hardware issue. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.8.0-36.40~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-36-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Jan 12 21:18:27 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] [1002:679a] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti PRO2 [Radeon HD 7950 Boost] [1002:3000] InstallationDate: Installed on 2021-01-13 (0 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) MachineType: Hewlett-Packard HP Z420 Workstation ProcEnviron: LANGUAGE=en_CA:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_CA.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-36-generic root=UUID=e1d90a30-a65a-46c5-bae3-c39bbf1a4e0e ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/29/2019 dmi.bios.release: 3.96 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: J61 v03.96 dmi.board.name: 1589 dmi.board.vendor: Hewlett-Packard dmi.board.version: 0.00 dmi.chassis.type: 6 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvrJ61v03.96:bd10/29/2019:br3.96:svnHewlett-Packard:pnHPZ420Workstation:pvr:rvnHewlett-Packard:rn1589:rvr0.00:cvnHewlett-Packard:ct6:cvr: dmi.product.family: 103C_53335X G=D dmi.product.name: HP Z420 Workstation dmi.product.sku: D8N02UC#ABA dmi.sys.vendor: Hewlett-Packard version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.102-1ubuntu1~20.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.1~20.04.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1911369/+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 1910576] Re: [MIR] libbpf (dependency of iproute2)
** Changed in: iproute2 (Ubuntu) Assignee: Kernel Packages (kernel-packages) => (unassigned) ** Changed in: libbpf (Ubuntu) Assignee: Kernel Packages (kernel-packages) => Christian Ehrhardt (paelzer) ** Changed in: iproute2 (Ubuntu) Status: New => Invalid ** Changed in: libbpf (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1910576 Title: [MIR] libbpf (dependency of iproute2) Status in iproute2 package in Ubuntu: Invalid Status in libbpf package in Ubuntu: New Bug description: [Availability] libbpf | 0.1.0-1 | groovy/universe | source libbpf | 0.3-2 | hirsute/universe | source [Rationale] Libbpf is (or is about to become) a dependency for building iproute2 which already is in main. Using BPF is becoming more wide-spread. The library allows to load and use eBPF programs from user-space (functionality provided by the kernel). It is already maintained in main for Debian (https://tracker.debian.org/pkg/libbpf) [Security] Since the code is taken out of the Linux kernel, this should be treated similar to the kernel for security. Research uncovered no records about security issues. [Quality assurance] At this point there are no open bug reports against libbpf (except this one) in Ubuntu. Also no open bugs found in Debian. Project is taken from the kernel source and claims static analysis via LGTM and Coverty. Also has CI via Travis (https://travis-ci.com/github/libbpf/libbpf). Right now there are no dep-8 tests. Though potentially it should be possible to create those, would this really add additional benefit beyond having upstream CI? A test build on hirsute was showing no warnings beyond lintian complaining about things which would be changed if we had delta (unstable as series for example). Otherwise was clean. [Dependencies] libc6: main libelf1: main zlib1g: main [Standards compliance] $ lintian --pedantic libbpf_0.3-2.dsc P: libbpf source: no-homepage-field P: libbpf source: silent-on-rules-requiring-root [Maintenance] As this is only taking out code from the kernel into a separate library package, the maintenance effort should be minimal. Packaging is done in Debian and is synced into Ubuntu (no delta). [Background information] A discourse about why this is packaged outside the kernel can be found at https://lwn.net/Articles/836911/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1910576/+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 1911441] Re: Bluetooth headphones and microphone not detected
** Package changed: ubuntu => alsa-driver (Ubuntu) -- 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/1911441 Title: Bluetooth headphones and microphone not detected Status in alsa-driver package in Ubuntu: New Bug description: Trouble when connecting paired bluetooth headphones on Ubuntu 20.04. The bluetooth headphones can be paired, but not connected. ``` $ bluetoothctl # scan on Discovery started [CHG] Controller F0:85:C1:FF:BD:A8 Discovering: yes [NEW] Device FC:58:FA:CF:D0:01 BT-1100 # scan off Discovery stopped [CHG] Controller F0:85:C1:FF:BD:A8 Discovering: no [CHG] Device FC:58:FA:CF:D0:01 RSSI is nil # devices Device FC:58:FA:CF:D0:01 BT-1100 # pair FC:58:FA:CF:D0:01 Attempting to pair with FC:58:FA:CF:D0:01 [CHG] Device FC:58:FA:CF:D0:01 Connected: yes [CHG] Device FC:58:FA:CF:D0:01 Connected: no [CHG] Device FC:58:FA:CF:D0:01 Connected: yes [CHG] Device FC:58:FA:CF:D0:01 UUIDs: 1108--1000-8000-00805f9b34fb [CHG] Device FC:58:FA:CF:D0:01 UUIDs: 110b--1000-8000-00805f9b34fb [CHG] Device FC:58:FA:CF:D0:01 UUIDs: 110e--1000-8000-00805f9b34fb [CHG] Device FC:58:FA:CF:D0:01 UUIDs: 111e--1000-8000-00805f9b34fb [CHG] Device FC:58:FA:CF:D0:01 ServicesResolved: yes [CHG] Device FC:58:FA:CF:D0:01 Paired: yes Pairing successful [CHG] Device FC:58:FA:CF:D0:01 ServicesResolved: no [CHG] Device FC:58:FA:CF:D0:01 Connected: no # connect FC:58:FA:CF:D0:01 Attempting to connect to FC:58:FA:CF:D0:01 [CHG] Device FC:58:FA:CF:D0:01 Connected: yes [CHG] Device FC:58:FA:CF:D0:01 Connected: no Failed to connect: org.bluez.Error.Failed [CHG] Device FC:58:FA:CF:D0:01 Connected: yes [CHG] Device FC:58:FA:CF:D0:01 Connected: no ``` Logs: ``` Jan 05 00:59:00 host1 bluetoothd[536]: Unable to get connect data for Headset Voice gateway: getpeername: Transport endpoint is not connected (107) Jan 05 00:59:02 host1 bluetoothd[536]: connect error: Connection reset by peer (104) Jan 05 00:59:37 host1 bluetoothd[536]: connect error: Connection reset by peer (104) ``` Pulseaudio configs: ``` $ grep -P '(bluetooth|bluez)' /etc/pulse/default.pa /etc/pulse/system.pa /etc/pulse/default.pa:#.ifexists module-bluetooth-policy.so /etc/pulse/default.pa:load-module module-bluetooth-policy /etc/pulse/default.pa:#.ifexists module-bluetooth-discover.so /etc/pulse/default.pa:load-module module-bluetooth-discover /etc/pulse/system.pa:load-module module-bluez5-device /etc/pulse/system.pa:load-module module-bluez5-discover ``` Packages installed: ``` $ dpkg -l | grep -P '(bluetooth|bluez)' ii blueman 2.1.2-1ubuntu0.2 amd64Graphical bluetooth manager ii bluez5.53-0ubuntu3 amd64Bluetooth tools and daemons ii bluez-obexd 5.53-0ubuntu3 amd64bluez obex daemon ii bluez-tools 2.0~20170911.0.7cb788c-2build1 amd64Set of tools to manage Bluetooth devices for linux ii libbluetooth3:amd64 5.53-0ubuntu3 amd64Library to use the BlueZ Linux Bluetooth stack ii pulseaudio-module-bluetooth 1:13.99.1-1ubuntu3.8 amd64Bluetooth module for PulseAudio sound server ``` ``` $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.1 LTS Release:20.04 Codename: focal $ uname -a Linux host1 5.4.0-59-generic #65-Ubuntu SMP Thu Dec 10 12:01:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ``` Please help. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.4.0-60.67-generic 5.4.78 Uname: Linux 5.4.0-60-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 AudioDevicesInUse: Error: [Errno 2] No such file or directory: 'fuser' CasperMD5CheckResult: skip Date: Wed Jan 13 17:18:39 2021 PackageArchitecture: all ProcEnviron: TERM=st-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Title: Bluetooth sound card not detected UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/14/2018 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 8.17 dmi.board.asset.tag: Default string dmi.board.name: CITI E202 ES2002EW dmi.board.vendor: Digma dmi.board.version: 1.0 dmi.chassis.asset.tag: Default string dmi.chassis.type: 31 dmi.chassis.vendor: Digma dmi.chassis.version: Default string dmi.modalias:
[Touch-packages] [Bug 1410618] Re: MacBook Air 6, 2 TRRS Headset Mic Not Working
The problem is still present in Ubuntu 20.10 :( -- 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/1410618 Title: MacBook Air 6,2 TRRS Headset Mic Not Working Status in alsa-driver package in Ubuntu: Confirmed Bug description: Hello, I'm running Ubuntu Gnome 14.04 on a new MacBookAir6,2 with the Cirrus Logic CS4208 and would love to get the microphone part of the TRRS connector working. Mac OS picks up and utilizes the TRRS headset mic without issue so I know the hardware is a go. With the headset plugged in, running sudo hdajacksensetest -a results in: Pin 0x05 ( Digital Out, HDMI): present = No Pin 0x06 ( Digital Out, HDMI): present = No Pin 0x07 ( Digital Out, HDMI): present = No AlsaInfo output here: http://www.alsa-project.org/db/?f=cabc8cab44d308c8a3898c66d48d9be4fc5ccf83 I opened up hdajackretask to find four pins: Green Headphone Pin ID: 0x10 Headphone Internal Speaker Pin ID: 0x12 Internal speaker Pink Mic Pin ID: 0x18 Not connected Internal Mic Pin ID: 0x1c Internal mic Unplugging and replugging the headset changes the Output device in sound settings from Headphones to Speakers so that works, but nothing in the input tab ever changes. It always lists two devices: Internal Microphone and Microphone. Both of these seem to actually be the internal microphone in the mac - either works without the headset connected at all. So I'm not really sure how to proceed from here, but I'd be happy to run whatever diagnostic tests might prove useful and/or even contribute code toward a fix - but I just have no idea where to start. Is it as simple as just finding the right pin and telling the system to use it as a microphone? Similar bug report here: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/950494 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1410618/+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 1911441] [NEW] Bluetooth headphones and microphone not detected
You have been subscribed to a public bug: Trouble when connecting paired bluetooth headphones on Ubuntu 20.04. The bluetooth headphones can be paired, but not connected. ``` $ bluetoothctl # scan on Discovery started [CHG] Controller F0:85:C1:FF:BD:A8 Discovering: yes [NEW] Device FC:58:FA:CF:D0:01 BT-1100 # scan off Discovery stopped [CHG] Controller F0:85:C1:FF:BD:A8 Discovering: no [CHG] Device FC:58:FA:CF:D0:01 RSSI is nil # devices Device FC:58:FA:CF:D0:01 BT-1100 # pair FC:58:FA:CF:D0:01 Attempting to pair with FC:58:FA:CF:D0:01 [CHG] Device FC:58:FA:CF:D0:01 Connected: yes [CHG] Device FC:58:FA:CF:D0:01 Connected: no [CHG] Device FC:58:FA:CF:D0:01 Connected: yes [CHG] Device FC:58:FA:CF:D0:01 UUIDs: 1108--1000-8000-00805f9b34fb [CHG] Device FC:58:FA:CF:D0:01 UUIDs: 110b--1000-8000-00805f9b34fb [CHG] Device FC:58:FA:CF:D0:01 UUIDs: 110e--1000-8000-00805f9b34fb [CHG] Device FC:58:FA:CF:D0:01 UUIDs: 111e--1000-8000-00805f9b34fb [CHG] Device FC:58:FA:CF:D0:01 ServicesResolved: yes [CHG] Device FC:58:FA:CF:D0:01 Paired: yes Pairing successful [CHG] Device FC:58:FA:CF:D0:01 ServicesResolved: no [CHG] Device FC:58:FA:CF:D0:01 Connected: no # connect FC:58:FA:CF:D0:01 Attempting to connect to FC:58:FA:CF:D0:01 [CHG] Device FC:58:FA:CF:D0:01 Connected: yes [CHG] Device FC:58:FA:CF:D0:01 Connected: no Failed to connect: org.bluez.Error.Failed [CHG] Device FC:58:FA:CF:D0:01 Connected: yes [CHG] Device FC:58:FA:CF:D0:01 Connected: no ``` Logs: ``` Jan 05 00:59:00 host1 bluetoothd[536]: Unable to get connect data for Headset Voice gateway: getpeername: Transport endpoint is not connected (107) Jan 05 00:59:02 host1 bluetoothd[536]: connect error: Connection reset by peer (104) Jan 05 00:59:37 host1 bluetoothd[536]: connect error: Connection reset by peer (104) ``` Pulseaudio configs: ``` $ grep -P '(bluetooth|bluez)' /etc/pulse/default.pa /etc/pulse/system.pa /etc/pulse/default.pa:#.ifexists module-bluetooth-policy.so /etc/pulse/default.pa:load-module module-bluetooth-policy /etc/pulse/default.pa:#.ifexists module-bluetooth-discover.so /etc/pulse/default.pa:load-module module-bluetooth-discover /etc/pulse/system.pa:load-module module-bluez5-device /etc/pulse/system.pa:load-module module-bluez5-discover ``` Packages installed: ``` $ dpkg -l | grep -P '(bluetooth|bluez)' ii blueman 2.1.2-1ubuntu0.2 amd64Graphical bluetooth manager ii bluez5.53-0ubuntu3 amd64Bluetooth tools and daemons ii bluez-obexd 5.53-0ubuntu3 amd64bluez obex daemon ii bluez-tools 2.0~20170911.0.7cb788c-2build1 amd64Set of tools to manage Bluetooth devices for linux ii libbluetooth3:amd64 5.53-0ubuntu3 amd64Library to use the BlueZ Linux Bluetooth stack ii pulseaudio-module-bluetooth 1:13.99.1-1ubuntu3.8 amd64Bluetooth module for PulseAudio sound server ``` ``` $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04.1 LTS Release:20.04 Codename: focal $ uname -a Linux host1 5.4.0-59-generic #65-Ubuntu SMP Thu Dec 10 12:01:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ``` Please help. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.4.0-60.67-generic 5.4.78 Uname: Linux 5.4.0-60-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 AudioDevicesInUse: Error: [Errno 2] No such file or directory: 'fuser' CasperMD5CheckResult: skip Date: Wed Jan 13 17:18:39 2021 PackageArchitecture: all ProcEnviron: TERM=st-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Title: Bluetooth sound card not detected UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/14/2018 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 8.17 dmi.board.asset.tag: Default string dmi.board.name: CITI E202 ES2002EW dmi.board.vendor: Digma dmi.board.version: 1.0 dmi.chassis.asset.tag: Default string dmi.chassis.type: 31 dmi.chassis.vendor: Digma dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr8.17:bd03/14/2018:svnDigma:pnCITIE202ES2002EW:pvrDefaultstring:rvnDigma:rnCITIE202ES2002EW:rvr1.0:cvnDigma:ct31:cvrDefaultstring: dmi.product.family: EMI30P3S6M22L18B320T4C00W1H2G0G3A1C2P1C0D0C1801M0N1X1WOS dmi.product.name: CITI E202 ES2002EW dmi.product.sku: 20180313288 dmi.product.version: Default string dmi.sys.vendor: Digma ** Affects: alsa-driver (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- Bluetooth headphones and microphone not detected
[Touch-packages] [Bug 1908502] Re: [MIR] libtiff5 dependency on libdeflate0
** Also affects: tiff (Ubuntu Hirsute) Importance: Undecided Assignee: Olivier Tilloy (osomon) Status: Confirmed ** Also affects: libdeflate (Ubuntu Hirsute) Importance: Undecided Status: Incomplete ** Tags removed: rls-hh-incoming -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tiff in Ubuntu. https://bugs.launchpad.net/bugs/1908502 Title: [MIR] libtiff5 dependency on libdeflate0 Status in libdeflate package in Ubuntu: Incomplete Status in tiff package in Ubuntu: Confirmed Status in libdeflate source package in Hirsute: Incomplete Status in tiff source package in Hirsute: Confirmed Bug description: tiff 4.1.0+git201212-1 enabled deflate support, adding libdeflate0 as a dependency to libtiff5, making the package uninstallable. Therefor I uploaded 4.1.0+git201212-1ubuntu1 disabling the deflate support to make libtiff5 installable again. Either this package stays this way, or it needs a MIR for libdeflate. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libdeflate/+bug/1908502/+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
