Bug#993578: 90gpg-agent generator: `gpgconf --check-programs` can hang
Hi, I had this issue occur on several nodes running bullseye, where it severely affected operations (automated remote management). The patch by Raphaël Hertzog looks great. Reviewed the patch and gpgconf source: - it should lead to gpgconf calling gc_component_check_options() - same as if using "gpgconf --check-programs", but for the "gpg-agent" backend only I thought the bug could also be filed for/fixed in dirmgr: -> various login events -> systemd-environment-generator/90gpg-agent -> gpgconf --check-programs -> ...gc_component_check_options() -> dirmngr --gpgconf-test // IMHO shouldn't perform blocking network IO, but does -> hang on TCP connect localhost:9050 Thus I checked the dirmngr source code and found this: > /* Note that we do not run set_tor_mode in --gpgconf-list mode > * because it will attempt to connect to the tor client and that can > * be time consuming. */ > post_option_parsing (); > if (cmd != aGPGConfTest && cmd != aGPGConfList && cmd != aGPGConfVersions) >set_tor_mode (); This seems to be to be intended behavior for dirmngr and could be considered a feature. I think many people are waiting for the updated "gpg-agent" package to arrive for stable (bullseye). Kind regards, Jonas
Bug#960355: Invalid serial console blocks system boot
Package: initramfs-tools-core Version: 0.137 Putting a serial console on a non-existent/broken serial port via the last "console=" argument of the kernel command line causes the initrd to hang without completing the boot process. If the problematic serial console argument comes first in the kernel command line, the system boots without issues. ***To reproduce:*** 1. Check for a non-connected/disabled serial port. On the problematic system running [$] stty -a -F /dev/ttyS1 stty: /dev/ttyS1: Input/output error The serial ports are registered by the "serial8250" driver but are probably not wired to anything. 2. Boot with a kernel command line that puts serial console on a non-existent/broken serial port via last "console=" argument: console=tty0 console=ttyS1,115200n8 3. Check if system boots successfully I am using Debian GNU/Linux 11 (bullseye/testing), vanilla kernel 5.7-rc5. This issue was initially reported multiple times for Debian and Ubuntu to the systemd maintainers as: https://github.com/systemd/systemd/issues/15656 (for Ubuntu) https://github.com/systemd/systemd/issues/15783 (for Debian, duplicate) I am not sure if the _exact_ cause of both issues is the same, because I observed the problem on a very minimal system without console-setup or kbd.
Bug#956174: Patch
This is the patch I use to workaround the issue:
diff -Naur a/btrfs-progs-5.4.1/debian/local/btrfs.local-premount
b/btrfs-progs-5.4.1/debian/local/btrfs.local-premount
--- a/btrfs-progs-5.4.1/debian/local/btrfs.local-premount 2020-01-09
17:49:59.0 +0100
+++ b/btrfs-progs-5.4.1/debian/local/btrfs.local-premount 2020-04-08
04:19:49.719861972 +0200
@@ -18,7 +18,7 @@
if [ -x /bin/btrfs ]
then
- modprobe btrfs
+ modprobe btrfs || true
# If asked to be quiet, show only errors
[ "${quiet}" = "y" ] && exec >/dev/null
/bin/btrfs device scan
Bug#956174: initramfs fails to call "btrfs dev scan" when btrfs is a builtin not a module
Package: btrfs-progs Version: 5.4.1-2 When booting a kernel with BTRFS builtin (not as module) the initramfs fails to correctly chttps://talpidae.net/roundcube/?_task=mail&_action=compose&_id=804132815e8d2a15ae439#all the required "btrfs dev scan". That is due to the call to "modprobe btrfs" failing and thus cancelling the premount script early without properly discovering the devices. I would suggest changing btrfs-progs-5.4.1-2/debian/btrfs-progs/usr/share/initramfs-tools/scripts/local-premount/btrfs line 21 as follows: -modprobe btrfs +modprobe btrfs || true This will ensure compatibility with custom kernels and still report an error in case the module is not present (when btrfs device scan is called). Thank you!
Bug#579783: xserver-xorg: Mouse pointer grabbed inside windows of specific applications on right-click
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, you're running xserver-xorg-core 2:1.7.6-2, could you please try with xserver-xorg-core 2:1.7.6.901-3 to see if you can still reproduce this bug? I upgraded to xserver-xorg-core 2:1.7.6.901-3 and the bug is not reproducible with this version. I can't reproduce that behaviour with 2:1.7.6.901-3 (although I didn't try to downgrade to your version to confirm). Thanks for your work, sorry for not upgrading before reporting. Regards, Jonas Zeiger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvb6jAACgkQIimFgjcQ8OnYvwCdGUF8fz3WEdhzS2OuF5gx+b+7 8vwAoJyZyTPOP4xj9ouzcBVHijx0/MhF =EKX2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
