Bug#1029126: Wishing for Emacs 29 in Debian
Dear Maintenars, Now that emacs 29.1 reached Debian testing (huge thanks for that!), I have attempted a simple backport to bookworm. To my delight, with a minimal set of changes, one can successfully build and use emacs 29.1 on bookworm. I hope that the initial patch what I have attached could help you create a proper backport in the main Debian archive. Regards, János PásztorFrom 29ac2f4a88846d0ba251df960fc3255870dd32d8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1sztor=20J=C3=A1nos?= Date: Sun, 10 Sep 2023 10:27:33 +0200 Subject: [PATCH] Initial attempt of a simple backport --- debian/changelog | 6 ++ debian/control | 4 ++-- debian/rules | 2 +- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/debian/changelog b/debian/changelog index 0aa4aa439d5..1fb9a568d6e 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +emacs (1:29.1+1-5~bpo12+1) bookworm-backports; urgency=medium + + * Rebuild for bookworm-backports. + + -- Pásztor János Sun, 10 Sep 2023 10:21:03 +0200 + emacs (1:29.1+1-5) unstable; urgency=medium * Don't try to build with native compilation on riscv64 (Closes: #1050653). diff --git a/debian/control b/debian/control index 2d2a96a2471..5a06bfdc0c4 100644 --- a/debian/control +++ b/debian/control @@ -9,7 +9,7 @@ Build-Depends: bsd-mailx | mailx, ca-certificates, dbus-x11, - gcc-13, + gcc-12, debhelper-compat (= 13), dpkg-dev (>> 1.10.0), git, @@ -19,7 +19,7 @@ Build-Depends: libasound2-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], libcairo-dev, libdbus-1-dev, - libgccjit-13-dev, + libgccjit-12-dev, libgif-dev, libgmp-dev, libgnutls28-dev, diff --git a/debian/rules b/debian/rules index f7cf5e5820e..e75abf74338 100755 --- a/debian/rules +++ b/debian/rules @@ -315,7 +315,7 @@ confflags_lucid += --without-gsettings define cfg_tree cd $(1) && \ CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" \ -CC=gcc-13 \ +CC=gcc-12 \ REL_ALLOC=no \ $(CURDIR)/debian/build-src/configure $(confflags) $(2) endef -- 2.39.2
Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure
Dear Bastian, On 2023-05-11 17:42, Bastian Blank wrote: Control: tags -1 wontfix On Wed, May 10, 2023 at 03:09:04AM +0200, Guilhem Moulin wrote: Please consider the enclosed patch. The aim is to also activate incomplete VGs at early boot stage, like lvm2 used to do before 2.03.15-1, and be a no op on “normal systems” once execution has been handed over to init(1). Nope, not really. Half VG was never a real thing. It might work in some cases. Well, it was a thing between 2014 and 2023, as based on my logs my machine has that config since then. The patch doesn't break src:cryptsetup's autopkgtests. It also solves the present regression AFAICT, at least for the reproducers I tested. I'm actually closing that report. Because half configs are hard to handle. Bastian I would kindly ask you to reconsider this and give a second chance to similar configs. Or at least add an entry to here: https://www.debian.org/releases/testing/amd64/release-notes/ch-information.en.html so that people could avoid a boot error right after the upgrade. Regards, János Pásztor
Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Dear Guilheim, On 2023-05-10 02:38, Guilhem Moulin wrote: Control: tag -1 - unreproducible Control: reassign -1 lvm2 2.03.15-1 Control: forcemerge 1018730 -1 Control: affects -1 cryptsetup-initramfs Thanks for the the reproducer! Much appreciated. So the problem is that your VG spans over multiple PVs, but the LVs that are required at early boot stage (the ones holding the root FS and the resume device) reside only on the first PV so cryptsetup-initramfs rightfully never tries to unlock the second one (which only holds /home hence is not needed that early). This used to work, but it looks like lvm2's udev rules never try to activate complete LVs residing on incomplete VGs, hence the deadlock. This mostly affects cryptsetup-initramfs and perhaps the issue could be mitigated there, but this is an lvm2 regression and non-luks systems can be affected too [0] so I'm reassign the bug accordingly. (Turns out it was already reported, hence also merging.) A quick fix for your particular setup is to edit crypttab(5), add the ‘initramfs’ option for the ‘4Tsolid’, and rebuild the initramfs image. That should force the device to be considered at initramfs stage. Thanks for highlighting the 'initramfs' option, it did the trick! Finally I could remove the custom hook from initramfs generation and go back to a mainline setup. Regards, János Pásztor
Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Dear Guilhem, On 2023-05-09 17:34, Guilhem Moulin wrote: Control: tag -1 + unreproducible moreinfo On Tue, 09 May 2023 at 17:10:03 +0200, Pásztor János wrote: The machine and the disks are having two snapshots named 'good' and 'bad' so it is easy to jump between the states. I am willing to share with you the VM(disks + virsh dump) via a filesharing service. Would you be interested in it? Yes please; I still cannot reproduce the issue. I have attached the machine definition and already sent the vm images for you (via filesender.hu). You can restore the machine by following these steps: - virsh define path/to/debian11.xml - extract the contents of the repro.tar.gz file to '/var/lib/libvirt' (as root) - systemctl restart libvirtd.service (so it re-reads the snapshot xmls) After that you should be able to start the machine via virt-manager and see the snapshots as well. I have just tested this procedure on my machine. The pw for luks and root are the same: 'titkos' (without the quotes) Regards, János Pásztor p.s.: I think that if we solve this, then we solve also #1023716 For my eyes they look very similar... debian11 3ed4a074-10f8-4272-9070-b7cf92707954 http://libosinfo.org/xmlns/libvirt/domain/1.0;> http://debian.org/debian/11"/> 4192256 4192256 4 hvm destroy restart destroy /usr/bin/qemu-system-x86_64 /dev/urandom
Bug#1034836: {Spam?} Bug#1034836: {Spam?} Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Control: tag -1 - unreproducible - moreinfo Dear Dennis, On 2023-05-05 18:10, Dennis Filder wrote: X-Debbugs-CC: Pásztor János On Wed, May 03, 2023 at 11:20:07PM +0200, Pásztor János wrote: I have checked #902943 and the fine print from /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz Based on that I have made an attempt to replace the UUIDs with `traditional` disk device paths. [...] However this fails spectacularly, as during the boot process the ordering is not stable, sometimes it is sdb1 or sda1 instead of sdc1 :/ If your device order is not stable during boot you need to use PARTUUID instead of UUID. You might argue that you should be able to use UUID because it worked before Bookworm if you overwrote the crypttab. However, it might be that your LUKS containers were created with an old version of cryptsetup that did not wipe the start of the partition properly. libblkid has had "behavioural changes" in the past under such circumstances wrt. to block device probing and making decisions [1]. It might be that whatever component is used to create /dev/disk/by-* symlinks in the initramfs has changed behaviour, too. According to your initramfs.debug log it's systemd-udevd. + /scripts/init-top/udev Starting systemd-udevd version 252.6-1 You'd have to try to get access to its log output. You should also take copies of the first 1 MiB of your partitions that hold the LUKS containers so libblkid (or whatever the culprit) can be debugged with before you overwrite anything. You'll have to provide copies of some sort if you want someone else to debug this for you -- no idea how to sanitize/dekey them. "cryptsetup luksErase" might render the LUKS header unrecognizable. You'll have to try it out. If you feel like it you can investigate further with: LIBBLKID_DEBUG=all blkid -p lsblk -o NAME,SIZE,TYPE,UUID,PARTUUID The next-heavier cannons would be ltrace/strace and gdb. I think that we can let that option(libblkid changes) go, as I have managed to reproduce this issue in a virtual machine, freshly installed from `firmware-11.7.0-amd64-netinst.iso` With that we have get rid of: - the possible fallout from the history of my old install - the underlying hw dependencies The big lesson what I have learned from it that you need to install and enable plymouth to have the magic password sharing between the LUKS devices. If you do not have that, then it will ask the pw twice (on bullseye) but besides that it boots properly The machine and the disks are having two snapshots named 'good' and 'bad' so it is easy to jump between the states. I am willing to share with you the VM(disks + virsh dump) via a filesharing service. Would you be interested in it? Regards, János Pásztor
Bug#1034836: {Spam?} Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Dear Dennis,
On 2023-05-03 08:15, Dennis Filder wrote:
Control: reassign -1 cryptsetup-initramfs
X-Debbugs-CC: Pásztor János
I having doubts that your issue is due to a bug because of this:
...
root@asgard ~ # more /etc/initramfs-tools/hooks/crypttab-fix.sh
#!/bin/sh
cp /etc/crypttab "${DESTDIR}/cryptroot/crypttab"
exit 0
...
Why did you add this? Did you notice that during update-initramfs
runs no cryptroot/crypttab file was placed into the initramfs?
I have got a crypttab file in initramfs, but the contents were not the
same as on my booted machine.
The script is an attempt from a shutgun-debugging session with the goal
to reach a stable boot process.
Please see the its contents in my previous reply to this case.
If yes
then you should have investigated why not because it was indicative
that something in your setup was broken enough for
/usr/share/initramfs-tools/hooks/cryptroot to properly generate its
part of the initramfs. FYI: That script does not simply copy
/etc/crypttab, but parses it and generates a sanitized version because
it relies on /scripts/local-block/lvm2 which does not work with UUIDs
(see #902943). Sure enough your crypttab contains UUID= entries:
-- /etc/crypttab
1Tnvme UUID=1cb8215e-4bb9-479b-ad06-36ae1b3fc957 none luks,discard
4Tsolid UUID=2c3dd479-7f24-4aa9-8850-ee5e970e7d32 none luks
I have checked #902943 and the fine print from
/usr/share/doc/cryptsetup-initramfs/README.initramfs.gz
Based on that I have made an attempt to replace the UUIDs with
`traditional` disk device paths.
See my modified /etc/crypttab below.
-8<BEGIN--->8---
1Tnvme /dev/nvme0n1p3 none luks,discard
4Tsolid /dev/sdc1 none luks
-8<--END--->8---
However this fails spectacularly, as during the boot process the
ordering is not stable, sometimes it is sdb1 or sda1 instead of sdc1 :/
Also tried a mashup config
-8<BEGIN--->8---
1Tnvme /dev/nvme0n1p3 none luks,discard
4Tsolid UUID=2c3dd479-7f24-4aa9-8850-ee5e970e7d32 none luks
-8<--END--->8---
But with this I am back at the original issue.
During this I have spotted an interesting thing.
Even tough I put `traditional` disk device paths into /etc/crypttab, the
generated initramfs has the UUID version of it, even after multiple
regeneration!
Going even forward, I have seen this in the source code of
`/usr/share/initramfs-tools/hooks/cryptroot`:
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/blob/debian/latest/debian/initramfs/hooks/cryptroot#L43
That contradicts with your previous statement of no UUID shall be
present in crypttab
But the comments gave me a hint, so I have tried the `/dev/disk/by-` option
-8<BEGIN--->8---
1Tnvme /dev/disk/by-id/nvme-Samsung_SSD_980_1TB_S649NF0RC06547P-part3
none luks,discard
4Tsolid /dev/disk/by-id/ata-WDC_WD40EZRZ-22GXCB0_WD-WCC7K6YN7DZJ-part1
none luks
-8<--END--->8---
And indeed, the crypttab in initramfs does not get mangled if I use this
path specification.
But the problem still persists in its original form.
Adding some kind of warning in a comment to the generated
cryptroot/crypttab to not manually edit or overwrite it sure would
have been helpful. Or if that's not possible at least a brief README
file in the same directory. One could even lint for this during
initramfs generation and emit a warning, e.g. with:
grep -e '\(etc\|cryptroot\)/crypttab' /etc/initramfs-tools/hooks/*
Regards.
This day could hold only so much reboot...
During the weekend I will try to repro it in a VM, which would enable a
better trial-error-inspect cycle.
Please let me know if you need any further information!
Regards,
János Pásztor
Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Dear Guilhem,
On 2023-05-03 10:40, Guilhem Moulin wrote:
Control: tag -1 unreproducible moreinfo
What does `lsinitramfs /initrd.img | grep -e{crypt,lvm}` return (after
removing your hook and rebuilding the initramfs image)? And also
1.) Initramfs hook has been removed
`mv /etc/initramfs-tools/hooks/crypttab-fix.sh /root`
2.) Initramfs has been rebuild
`update-initramfs -c -k all`
3.) Output of `lsinitramfs /initrd.img | grep -e{crypt,lvm}`
-88---
cryptroot
cryptroot/crypttab
etc/lvm
etc/lvm/archive
etc/lvm/archive/asgardfs_00032-752010180.vg
etc/lvm/archive/asgardfs_00033-423131292.vg
etc/lvm/archive/asgardfs_00034-1808867818.vg
etc/lvm/archive/asgardfs_00035-432007737.vg
etc/lvm/archive/asgardfs_00036-1768906316.vg
etc/lvm/archive/asgardfs_00037-220665657.vg
etc/lvm/archive/asgardfs_00038-1744649197.vg
etc/lvm/archive/asgardfs_00039-1539207819.vg
etc/lvm/archive/asgardfs_00040-1386491380.vg
etc/lvm/archive/asgardfs_00041-15080506.vg
etc/lvm/archive/backupvg_0-1958666398.vg
etc/lvm/archive/backupvg_1-2094833855.vg
etc/lvm/archive/backupvg_2-2077817437.vg
etc/lvm/backup
etc/lvm/backup/asgardfs
etc/lvm/backup/backupvg
etc/lvm/lvm.conf
etc/lvm/lvm.conf~
etc/lvm/lvmlocal.conf
etc/lvm/profile
etc/lvm/profile/cache-mq.profile
etc/lvm/profile/cache-smq.profile
etc/lvm/profile/command_profile_template.profile
etc/lvm/profile/lvmdbusd.profile
etc/lvm/profile/metadata_profile_template.profile
etc/lvm/profile/thin-generic.profile
etc/lvm/profile/thin-performance.profile
etc/lvm/profile/vdo-small.profile
scripts/local-block/cryptroot
scripts/local-bottom/cryptgnupg-sc
scripts/local-bottom/cryptopensc
scripts/local-bottom/cryptroot
scripts/local-top/cryptopensc
scripts/local-top/cryptroot
usr/bin/cryptroot-unlock
usr/lib/cryptsetup
usr/lib/cryptsetup/askpass
usr/lib/cryptsetup/functions
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/aegis128-aesni.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/aesni-intel.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/blowfish-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/camellia-aesni-avx-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/camellia-aesni-avx2.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/camellia-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/cast5-avx-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/cast6-avx-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/chacha-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/crc32-pclmul.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/crc32c-intel.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/crct10dif-pclmul.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/curve25519-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/des3_ede-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/ghash-clmulni-intel.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/nhpoly1305-avx2.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/nhpoly1305-sse2.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/poly1305-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/serpent-avx-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/serpent-avx2.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/serpent-sse2-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/sha1-ssse3.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/sha256-ssse3.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/sha512-ssse3.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/twofish-avx-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/twofish-x86_64-3way.ko
usr/lib/modules/6.1.0-7-amd64/kernel/arch/x86/crypto/twofish-x86_64.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/adiantum.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/aegis128.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/aes_ti.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/af_alg.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/algif_aead.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/algif_hash.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/algif_rng.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/algif_skcipher.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/ansi_cprng.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/asymmetric_keys
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/asymmetric_keys/pkcs8_key_parser.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/async_tx
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/async_tx/async_memcpy.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/async_tx/async_pq.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/async_tx/async_raid6_recov.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/async_tx/async_tx.ko
usr/lib/modules/6.1.0-7-amd64/kernel/crypto/async_tx/async_xor.ko
Bug#1034836: initramfs-tools: After bullseye -> bookworm upgrade boot stuck in the initramfs shell
Package: initramfs-tools Version: 0.142 Severity: critical Justification: breaks the whole system X-Debbugs-Cc:pasztor.ja...@it.ppke.hu Dear Maintainer * What led up to the situation? I have upgraded my desktop machine (which is an old install, started with stretch ) from bullseye to bookworm * What was the outcome of this action? The boot process halts in the initramfs shell and I have to issue 'vgchange -ay' manually in order to continue. After that it asks for the LUKS password again for the second disk in the machine (both disks are having the same LUKS pw) * What outcome did you expect instead? Machine boots properly and asks only once for the LUKS pw during boot (as it has done it during bullseye) * Workaround I have installed the following hook to the initramfs generator in order to have a proper boot (pw asked twice still) -88--- root@asgard ~ # more /etc/initramfs-tools/hooks/crypttab-fix.sh #!/bin/sh cp /etc/crypttab "${DESTDIR}/cryptroot/crypttab" exit 0 -8<--END--->8--- * disk setup (nvme0n1 and sda are relevant) -8 8--- root@asgard ~ # lsblk NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:00 3.6T 0 disk └─sda18:10 3.6T 0 part └─4Tsolid 254:30 3.6T 0 crypt └─asgardfs-home 254:40 3.3T 0 lvm /home/pasja/solid sdb 8:16 0 931.5G 0 disk ├─sdb18:17 016M 0 part └─sdb28:18 0 904.2G 0 part sdc 8:32 0 119.2G 0 disk ├─sdc18:33 016M 0 part ├─sdc28:34 0 113.7G 0 part ├─sdc38:35 0 100M 0 part └─sdc48:36 0 1M 0 part nvme0n1 259:00 931.5G 0 disk ├─nvme0n1p1 259:10 550M 0 part /boot/efi ├─nvme0n1p2 259:20 2G 0 part /boot └─nvme0n1p3 259:30 829G 0 part └─1Tnvme 254:00 829G 0 crypt ├─asgardfs-root 254:10 504.7G 0 lvm /gnu/store │ / └─asgardfs-swap 254:20 952M 0 lvm [SWAP] -8<--END--->8--- * fstab -8 8--- root@asgard ~ # more /etc/fstab /dev/mapper/asgardfs-root / xfs defaults0 1 UUID=6b9e331f-9f78-42fa-99af-04e587e3bf6d /boot xfsdefaults 0 2 /dev/mapper/asgardfs-home /home/pasja/solid xfs defaults0 2 /dev/mapper/asgardfs-swap noneswapsw 0 0 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 UUID=FAA7-BDB0 /boot/efi vfat defaults 0 2 -8<--END--->8--- * logs and other remarks Please find attached an initramfs.debug log from my last boot attempt. I also have the output of 'journalctl -b'. Please let me know if that would help the investigation. I have diff-ed both systemd (bullseye backports) and initramfs-tools (bullseye) to bookworm, but I have not spotted anything relevant which could explain this regression. Will try to reproduce it in a vm in order to have an environment where I can investigate it easier. Any pointers / questions would be appreciated here. Regards, János Pásztor -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 75M Apr 25 18:55 /boot/initrd.img-6.1.0-7-amd64 -- /proc/cmdline BOOT_IMAGE=/vmlinuz-6.1.0-7-amd64 root=/dev/mapper/asgardfs-root ro debug -- resume RESUME=/dev/mapper/asgardfs-swap -- /proc/filesystems xfs fuseblk vfat -- lsmod Module Size Used by rfcomm 94208 16 snd_seq_dummy 16384 0 snd_hrtimer16384 1 snd_seq90112 7 snd_seq_dummy snd_seq_device 16384 1 snd_seq cfg80211 1134592 0 cmac 16384 2 8021q 40960 0 algif_hash 16384 1 garp 16384 1 8021q algif_skcipher 16384 1 stp16384 1 garp af_alg 36864 6 algif_hash,algif_skcipher mrp20480 1 8021q bnep 28672 2 llc16384 2 stp,garp binfmt_misc24576 1 nls_ascii 16384 1 nls_cp437 20480 1 vfat 24576 1 fat90112 1 vfat btusb 69632 0 snd_hda_codec_realtek 172032 1 btrtl 28672 1 btusb snd_hda_codec_generic98304 1 snd_hda_codec_realtek btbcm
Bug#1020641: dhcpcd5: dhcpcd fails to chroot during start
Hello Everybody, Allow me to give you a longer update on my progress. 1.) Managed to reproduce the issue on my machine. Big thanks to martintxo for the detailed repro steps. 2.) Checked dhcpcd-gtk with the bad case and based on the logs it seems that it has issues with the wpa_supplicant connection -88--- pasja@bifrost ~ % dhcpcd-gtk (dhcpcd-gtk:346063): Gtk-WARNING **: 18:43:01.100: Theme parsing error: gtk-widgets.css:1214:18: Not using units is deprecated. Assuming 'px'. ** Message: 18:43:01.145: Connecting ... ** Message: 18:43:01.145: Status changed to down ** Message: 18:43:01.145: Status changed to opened ** Message: 18:43:01.145: Connected to dhcpcd-9.4.1 ** Message: 18:43:01.145: Status changed to connected ** Message: 18:43:01.145: wlo1: Associated with Ibn Tufajl ** Message: 18:43:01.145: wlo1: Configured 192.168.1.122/24 ** Message: 18:43:01.145: wlo1: Configured 2001:::e700:4bdb:3e4:cd05:b45/64 ** Message: 18:43:01.145: wlo1: Configured 2001:::e700::64f/128 ** Message: 18:43:01.145: eno2: Link is down ** Message: 18:43:03.148: wlo1: WPA status down ** Message: 18:43:05.152: wlo1: WPA status down -8<--END--->8--- 3.) Went to check dhcpcd-gtk source and I have found out that there is a socket based communication between dhcpcd-gtk and wpa_supplicant https://salsa.debian.org/debian/dhcpcd-ui/-/blob/master/src/libdhcpcd/wpa.c#L56 4.) After that I have tried to connect to wpa_supplicant with wpa_cli, without any success. Based on that I have ruled out that the issue is in dhcpcd-gtk -8 8--- root@bifrost /tmp # wpa_cli wpa_cli v2.10 Copyright (c) 2004-2022, Jouni Malinen and contributors This software may be distributed under the terms of the BSD license. See README for more details. Selected interface 'wlo1' Interactive mode Warning: Failed to attach to wpa_supplicant. Could not connect to wpa_supplicant: wlo1 - re-trying Warning: Failed to attach to wpa_supplicant. Warning: Failed to attach to wpa_supplicant. Warning: Failed to attach to wpa_supplicant. Warning: Failed to attach to wpa_supplicant. Warning: Failed to attach to wpa_supplicant. ^Celoop: could not process SIGINT or SIGTERM in two seconds. Looks like there is a bug that ends up in a busy loop that prevents clean shutdown. Killing program forcefully. -8<--END--->8--- 5.) Using strace on both programs revealed a similar socket based communication what I have seen between dhcpcd-gtk and wpa_supplicant The interesting part comes below from wpa_supplicant -8 8--- recvfrom(11, "ATTACH", 8193, 0, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_346236-2"}, [128->25]) = 6 getsockopt(11, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 ioctl(11, TIOCOUTQ, [0]) = 0 sendto(11, "OK\n", 3, 0, {sa_family=AF_UNIX, sun_path="/tmp/wpa_ctrl_346236-2"}, 25) = -1 ENOENT (No such file or directory) -8<--END--->8--- See the file not found error in the last line. However that file does exist in my /tmp !! -8 8--- pasja@bifrost ~ % l /tmp/wpa_ctrl_346236-2 srwxr-xr-x 1 root root 0 Feb 7 18:49 /tmp/wpa_ctrl_346236-2 -8<--END--->8--- 6.) My understanding was partial at that time, so I went back and checked what Privatetmp does exactly, and it turned out that it creates a new mount namespace. With `systemd-cgls` I was able to confirm that both wpa_supplicant and dhcpcd are living in the same namespace -8 8--- pasja@bifrost ~ % systemd-cgls Control group /: -.slice [redacted output] ├─dhcpcd.service (#15832) │ → user.invocation_id: fb283568273843dbb14259f938137d6a │ ├─298963 dhcpcd: [manager] [ip4] [ip6] │ ├─298964 dhcpcd: [privileged proxy] │ ├─298965 dhcpcd: [network proxy] │ ├─298966 dhcpcd: [control proxy] │ ├─298984 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant-wlo1.conf -iwlo1 │ ├─310014 dhcpcd: [BPF ARP] wlo1 192.168.9.182 │ └─310585 dhcpcd: [BPF ARP] enxc03ebac7d8c3 192.168.10.248 -8<--END--->8--- 7.) The final step was that I have compared the mountinfo in the working and the non-working case for wpa_supplicant and see that in the non-working case /tmp does get an extra mount from the Privatetmp config -8 8--- root@bifrost /tmp # cat /proc/$(pidof wpa_supplicant)/mountinfo | grep '/tmp' 365 349 254:1
Bug#1020641: Repro attempt
Dear Colleagues,
I have done my fair share of tests regarding this, please see my remarks
below.
Used system:
-8<>8---
root@asgard ~ # more /etc/debian_version
11.6
-8<>8---
dhcpcd & dhcpcd-gtk version
-8<>8---
root@asgard ~ # apt show dhcpcd5
Package: dhcpcd5
Version: 9.4.1-4
root@asgard ~ # apt show dhcpcd-gtk
Package: dhcpcd-gtk
Version: 0.7.8-1
-8<>8---
dhcpcd has been started without the chroot fix, a.k.a. with the current
debian systemd unit
-8<>8---
root@asgard ~ # systemctl revert dhcpcd.service
Removed "/etc/systemd/system/dhcpcd.service".
root@asgard ~ # systemctl daemon-reload dhcpcd.service
root@asgard ~ # systemctl restart dhcpcd.service
-8<>8---
dhcpcd-gtk has been started from a terminal
-8<>8---
pasja@asgard ~ % dhcpcd-gtk
(dhcpcd-gtk:16980): Gtk-WARNING **: 18:34:48.939: Theme parsing error:
gtk-widgets.css:1214:18: Not using units is deprecated. Assuming 'px'.
** Message: 18:34:48.956: Connecting ...
** Message: 18:34:48.956: Status changed to down
** Message: 18:34:48.956: Status changed to opened
** Message: 18:34:48.956: Connected to dhcpcd-9.4.1
** Message: 18:34:48.956: Status changed to connected
** Message: 18:34:48.956: eno1: CARRIER
** Message: 18:34:48.956: eno1: Configured 192.168.1.238/24
** Message: 18:34:48.956: eno1: Configured
2001:4c4e:1e94:::1580:cf90:77bb/64
** Message: 18:34:48.956: eno1: Configured 2001:4c4e:1e94:::/128
-8<>8---
Looks great for me, which means that I was not able to reproduce the
issue what martintxo reported.
A couple of differences are there, namely:
- Version: 9.4.1-4 vs. 9.4.1-9
- I am using wpa_supplicant differently on this machine (started from an
interface specific systemd unit vs. starting from a dhcpcd hook)
Based on that I think that my chroot patch from bug #1029437 does not
matter in this case :(
In order to get a better picture about this it would be great if
martintxo could:
- having a strace output from dhcpcd-gtk ('strace -ff -y dhcpcd-gtk' in
a console, be careful this might produce a huge output!) when the issue
occures so that we can see the connection attemps from dhcpcd-gtk
- pinpoint the exact systemd hardening which causes this problem, a.k.a.
adding the lines back one-by-one until the issue occures
Besides that when I chased through the linked issues, I have found an
upstream commit which was linked to this issue
(https://bugs.gentoo.org/846515#c5) It just missed 9.4.1 and the
upstream author used the expression 'might be' which does not mean 100%
resolution for me... Still it might worth a shot to compile a new
version with that commit and see whether the issue occures or not.
I will try to have a second round of repro, where I reconfigure my
machine to get closer to martintxo's setup and see what happens.
Regards,
János Pásztor
Bug#1029437: dhcpcd5: dhcpcd fails to chroot during start
Package: dhcpcd5 Version: 9.4.1-4 Severity: normal Tags: patch X-Debbugs-Cc: pasztor.ja...@it.ppke.hu Dear Martin-Éric, This is kind of a continuation from 1014277, where I have mentioned that it still logs some chroot related issues. Now I have the time to create a proper patch and attach it to this bug. It would be great if it could make it to bookworm, as the freeze is coming :) Reporting that to upstream does not make sense right now, as the systemd unit files are debian specific additions. Regards, János Pásztor ps.: some privsep related errors are still lingering, but those are handled by upstream based on the github activites. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dhcpcd5 depends on: ii dhcpcd-base 9.4.1-4 ii lsb-base 11.1.0 dhcpcd5 recommends no packages. Versions of packages dhcpcd5 suggests: ii dhcpcd-gtk 0.7.8-1 ii openresolv [resolvconf] 3.12.0-1 -- no debconf information diff --git a/debian/dhcpcd.dhcpcd.service b/debian/dhcpcd.dhcpcd.service index 740a569c..0060adf5 100644 --- a/debian/dhcpcd.dhcpcd.service +++ b/debian/dhcpcd.dhcpcd.service @@ -27,7 +27,7 @@ LockPersonality=true MemoryDenyWriteExecute=true RestrictRealtime=true RestrictSUIDSGID=true -SystemCallFilter=@system-service +SystemCallFilter=@system-service chroot SystemCallErrorNumber=EPERM SystemCallArchitectures=native
Bug#1014277: Fix chroot error in dhcpcd
Dear Colleagues, After some further investigation I think I have found the solution for the chroot error as well. In the unit file the syscall filtering is a little bit too strict. Besides the already configured list of '@system-service' for the 'SystemCallFilter' stanza, the 'chroot' syscall has to be added as well. After having a cursory glance over the source code (and mind you, I am not a C developer :-) ) I have found 'src/privsep.c' where the design details are documented in the beginning. Based on that I think it is a fair thing to grant that extra syscall for the service. With that I have managed to reduce the number of errors in the dhcpcd unit logs to one on my machine, namely control_free: No such file or directory which might not fit the scope of this ticket. Regards, János Pásztor
Bug#1014277: Fix for dhcpcd systemd timeout
Dear Colleagues, I have faced this issue as well, and managed to find the root cause of this issue. It seems that the culprit is caused by the systemd unit file, as systemd itself can not found the configured pid file and eventually kills dhcpcd. dhcpcd works just fine if you are starting it in foreground mode. To check where dhcpcd put its pidfile, run 'dhcpcd -P' in the cli. On my system it prints this: '/run/dhcpcd/pid' After changing the PIDFile stanza in the unit file from '/run/dhcpcd.pid' to '/run/dhcpcd/pid' and do the necessary 'systemctl daemon-reload' dance, dhcpcd starts just fine. Some troubling logs are still there, like: ps_dropprivs: chroot: /usr/lib/dhcpcd: Operation not permitted which might need further actions, but the basic functionality has been restored with this small change. Regards, János Pásztor
