Bug#1055694: initramfs-tools: After updating coreutils cp: not replacing in console when running update-initramfs
On Wed, Jan 03, 2024 at 04:59:15PM -0500, Michael Stone wrote: > On Sat, Nov 11, 2023 at 01:32:59AM +0100, Thorsten Glaser wrote: > > On Fri, 10 Nov 2023, Sven Joachim wrote: > > > > > | 'cp -n' and 'mv -n' now exit with nonzero status if they skip their > > > | action because the destination exists, and likewise for 'cp -i', > > > > Ouch! Nonzero? That’s harsh, and bad as it’s impossible to distinguish > > between error and declining to copy/move. > > > > There is a good example in diff(1) for how to handle this better: > > use distinct errorlevels for each case. > > > > Michael, could you perhaps throw that upstream? > > Where do we stand on this after coreutils 9.4-3? The autopkgtest is failing, > but I think at this point that's bogus (because of the new deprecation > warning), and the functionality is actually ok? Failing autopkgtest: https://ci.debian.net/packages/i/initramfs-tools/testing/amd64/41469415/ "Good" reference: https://ci.debian.net/packages/i/initramfs-tools/testing/amd64/41379006/ The autopkgtest now probably "just" fails because of the deprecation warning on stderr. Might be best to update cp usage in /usr/share/initramfs-tools/hooks/klibc-utils, then it should be good? Chris
Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port
Hi Daniel,
hope you are good, had peaceful Christmas time, entering yet better NY 2024
hope so... sorry for overlooking this, even wanted to respond early December,
then got delayed again.. Now I do so as its still interesting to me!
1) yes, my sole quick method was "ip nei" command to confirm the ARP passthrough
2) no firewall at all, plain Debian installation
3) you will not believe --> but before Xmas and now, it all works and MAC is
passed e2e. That's so pitty. Only change I made was my underlay change of
vSwitch uplink to another port... because I re-considered my overall lab setup,
yet it hardly could improve this as the external MAC made it to external (VLAN)
iface of the bridge, before/. Anyhow, possibly I understand the "bridge fbd"
only shows learned MACs on given interface (my VLAN199) and is not supposed to
attribute it to all others all way up to NS, like I attempted to guess..
Finally, either this of MACVLAN setup (where I found this), I have new finding
which I don’t like as it creates a hell of duplicate traffic into network. The
problem is, that either VETH or MACVLAN-configured IP host's VM duplicates
incoming packets on its receiving port, connected to vSphere vSwitch, which in
turn just dully floods it to uplinks, where my Wireshark sniffer sees it. This
is how I discovered that.
I prepared this diagram for you to see and tell.
https://docs.google.com/document/d/1mNkZswDSG_OjLnsgXJvIX2tUGSEebcZf720eS29eFCA/edit?usp=sharing
BR, all the best wishes in NY2024!
Peter
-Original Message-
From: Daniel Gröber
Sent: nedeľa 3. decembra 2023 11:09
To: GASPAROVIC Peter OBS/MKT
Cc: 1054...@bugs.debian.org
Subject: Re: Bug#1054642: Failing ARP relay from external -> Linux bridge ->
veth port --> NS veth port
Hi Peter,
> So now we move to VLAN level?
Yeah, but I'm still waiting for the answers to my questions from two emails
ago:
> I'd be happy to still track this bug down but I need you to
> investigate the behaviour in your environment. If you've torn down the
> lab already we can also just call it quits.
>
> If you do want to continue some questions are still pending, see quoted below.
>
> > On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> > > 1) As was reported, foreign external world MAC@ does not pass into
> > > network namespace, just external border point "vlan199"
> >
> > How did you check this?
> >
> > > 2) now collecting data for you, honestly I don’t see external mac
> > > address on "inet-br" object, so my previous statement was incorrect..
> > > {ossibly I might mixed this up with another "labinet-br" (working
> > > in its limited
> > > scope) which is IP-defined, while "inet-br" in question is not.
> > >
> > > 3) so question is, if the MACs learnt via vlan199 are supposed to
> > > be paired (displayed) with "inet-br" object and all way up into NS
> >
> > I want to make sure we're on the same page, how do you check if the
> > MAC is reaching into the NS? I assume using `ip neigh`? I'd have a
> > look at tcpdump this will tell you whether ARP is even reaching the NS or
> > not.
> >
> > Something simple like
> >
> > $ tcpdump -enli $IFACE 'arp or icmp'
> >
> > optionally you can filter by MAC (`ether host` in pcap-filter speak):
> >
> > $ tcpdump -enli $IFACE ('arp or icmp) and ether host
> > aa:00:00:00:00:01
> >
> > Oh and one last thing: please double and tripple check that a firewall
> > isn't interfering.
--Daniel
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
Processed: Re: Bug#1059939: linux-image-6.1.0-17-rt-amd64: dkms will not build zfs module for rt-amd64
Processing control commands: > reassign -1 dkms Bug #1059939 [src:linux] linux-image-6.1.0-17-rt-amd64: dkms will not build zfs module for rt-amd64 Bug reassigned from package 'src:linux' to 'dkms'. No longer marked as found in versions linux/6.1.69-1. Ignoring request to alter fixed versions of bug #1059939 to the same values previously set -- 1059939: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059939 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1059939: linux-image-6.1.0-17-rt-amd64: dkms will not build zfs module for rt-amd64
Control: reassign -1 dkms dkms fails the kernel installation. On Wed, Jan 03, 2024 at 10:54:12PM +0100, T. J. Pinkert wrote: > Error! The /var/lib/dkms/zfs/2.1.11/6.1.0-17-rt-amd64/x86_64/dkms.conf for > module zfs includes a BUILD_EXCLUSIVE directive which does not match this > kernel/arch/config. > This indicates that it should not be built. > Error! One or more modules failed to install during autoinstall. > Refer to previous errors for more information. > dkms: autoinstall for kernel: 6.1.0-17-rt-amd64 failed! > run-parts: /etc/kernel/postinst.d/dkms exited with return code 11 > dpkg: error processing package linux-image-6.1.0-17-rt-amd64 (--configure): > installed linux-image-6.1.0-17-rt-amd64 package post-installation script > subprocess returned error exit status 1 > dpkg: dependency problems prevent configuration of linux-image-rt-amd64: > linux-image-rt-amd64 depends on linux-image-6.1.0-17-rt-amd64 (= 6.1.69-1); > however: > Package linux-image-6.1.0-17-rt-amd64 is not configured yet.
Bug#1055694: initramfs-tools: After updating coreutils cp: not replacing in console when running update-initramfs
On Sat, Nov 11, 2023 at 01:32:59AM +0100, Thorsten Glaser wrote: On Fri, 10 Nov 2023, Sven Joachim wrote: | 'cp -n' and 'mv -n' now exit with nonzero status if they skip their | action because the destination exists, and likewise for 'cp -i', Ouch! Nonzero? That’s harsh, and bad as it’s impossible to distinguish between error and declining to copy/move. There is a good example in diff(1) for how to handle this better: use distinct errorlevels for each case. Michael, could you perhaps throw that upstream? bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-) Where do we stand on this after coreutils 9.4-3? The autopkgtest is failing, but I think at this point that's bogus (because of the new deprecation warning), and the functionality is actually ok?
Bug#1059939: linux-image-6.1.0-17-rt-amd64: dkms will not build zfs module for rt-amd64
Package: src:linux Version: 6.1.69-1 Severity: normal X-Debbugs-Cc: t.j.pink...@alumnus.utwente.nl Dear Maintainer, I tried to install linux-image-6.1.0-17-rt-amd64, building zfs modules with dkms failed. The output of aptitude while installing the packages is appended to this report. The important line seems to be: Error! The /var/lib/dkms/zfs/2.1.11/6.1.0-17-rt-amd64/x86_64/dkms.conf for module zfs includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch/config Somehow the directory 6.1.0-17-rt-amd64 seems to be missing. --- $ ls /var/lib/dkms/zfs/2.1.11/ 6.1.0-16-amd64 6.1.0-17-amd64 source --- whether this is a flaw in the installer script or in the zfs package is unclear to me. The expected outcome is, logically, that the dkms modules would all compile as they do on the normal amd64 kernel image. Best regards, Tjeerd Pinkert Output of aptitude install process on the terminal: - Performing actions... Selecting previously unselected package linux-headers-6.1.0-17-rt-amd64. (Reading database ... 744179 files and directories currently installed.) Preparing to unpack .../linux-headers-6.1.0-17-rt-amd64_6.1.69-1_amd64.deb ... Unpacking linux-headers-6.1.0-17-rt-amd64 (6.1.69-1) ... Selecting previously unselected package linux-image-6.1.0-17-rt-amd64. Preparing to unpack .../linux-image-6.1.0-17-rt-amd64_6.1.69-1_amd64.deb ... Unpacking linux-image-6.1.0-17-rt-amd64 (6.1.69-1) ... Selecting previously unselected package linux-image-rt-amd64. Preparing to unpack .../linux-image-rt-amd64_6.1.69-1_amd64.deb ... Unpacking linux-image-rt-amd64 (6.1.69-1) ... Setting up linux-image-6.1.0-17-rt-amd64 (6.1.69-1) ... I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.1.0-17-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-6.1.0-17-amd64 I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-17-rt-amd64 I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-17-rt-amd64 /etc/kernel/postinst.d/dkms: dkms: running auto installation service for kernel 6.1.0-17-rt-amd64. Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file Signing key: /var/lib/dkms/mok.key Public certificate (MOK): /var/lib/dkms/mok.pub Error! The /var/lib/dkms/zfs/2.1.11/6.1.0-17-rt-amd64/x86_64/dkms.conf for module zfs includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch/config. This indicates that it should not be built. Error! One or more modules failed to install during autoinstall. Refer to previous errors for more information. dkms: autoinstall for kernel: 6.1.0-17-rt-amd64 failed! run-parts: /etc/kernel/postinst.d/dkms exited with return code 11 dpkg: error processing package linux-image-6.1.0-17-rt-amd64 (--configure): installed linux-image-6.1.0-17-rt-amd64 package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of linux-image-rt-amd64: linux-image-rt-amd64 depends on linux-image-6.1.0-17-rt-amd64 (= 6.1.69-1); however: Package linux-image-6.1.0-17-rt-amd64 is not configured yet. dpkg: error processing package linux-image-rt-amd64 (--configure): dependency problems - leaving unconfigured Setting up linux-headers-6.1.0-17-rt-amd64 (6.1.69-1) ... /etc/kernel/header_postinst.d/dkms: dkms: running auto installation service for kernel 6.1.0-17-rt-amd64. Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file Signing key: /var/lib/dkms/mok.key Public certificate (MOK): /var/lib/dkms/mok.pub Error! The /var/lib/dkms/zfs/2.1.11/6.1.0-17-rt-amd64/x86_64/dkms.conf for module zfs includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch/config. This indicates that it should not be built. Error! One or more modules failed to install during autoinstall. Refer to previous errors for more information. dkms: autoinstall for kernel: 6.1.0-17-rt-amd64 failed! run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11 Failed to process /etc/kernel/header_postinst.d at /var/lib/dpkg/info/linux- headers-6.1.0-17-rt-amd64.postinst line 11. dpkg: error processing package linux-headers-6.1.0-17-rt-amd64 (--configure): installed linux-headers-6.1.0-17-rt-amd64 package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: linux-image-6.1.0-17-rt-amd64 linux-image-rt-amd64 linux-headers-6.1.0-17-rt-amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) Setting up linux-image-6.1.0-17-rt-amd64 (6.1.69-1) ... /etc/kernel/postinst.d/dkms: dkms: running auto installation service for kernel 6.1.0-17-rt-amd64. /usr/sbin/dkms: line 2497: echo: write error: Broken pipe Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file Signing key: /var/lib/dkms/mok.key Public certificate (MOK): /var/lib/dkms/mok.pub Error! The /var/lib/dkms/zfs/2.1.11/6.1.0-17-rt-amd64/x86_64/dkms.conf for module zfs includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch/config. This indicates that it should not be built. Error! One or more
Bug#1059936: initramfs-tools: update-initramfs yields "cp: warning: behavior of -n is non-portable and may change in future"
Package: initramfs-tools Version: 0.142 Severity: normal I get the following warnings with coreutils 9.4-3: Processing triggers for initramfs-tools (0.142) ... update-initramfs: Generating /boot/initrd.img-6.5.0-5-amd64 [...] cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead [...] -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 62M 2023-12-19 03:08:02 /boot/initrd.img-6.1.0-16-amd64 -rw-r--r-- 1 root root 66M 2024-01-03 22:25:04 /boot/initrd.img-6.5.0-5-amd64 -- /proc/cmdline BOOT_IMAGE=/vmlinuz-6.5.0-5-amd64 root=/dev/mapper/qaa--vg-root ro quiet -- resume RESUME=/dev/mapper/qaa--vg-swap_1 -- /proc/filesystems ext3 ext2 ext4 fuseblk vfat -- lsmod Module Size Used by tls 151552 0 nfnetlink 20480 1 rfcomm102400 4 ctr12288 1 ccm20480 3 snd_seq_dummy 12288 0 snd_hrtimer12288 1 snd_seq 114688 7 snd_seq_dummy snd_seq_device 16384 1 snd_seq cmac 12288 3 algif_hash 12288 1 algif_skcipher 12288 1 af_alg 36864 6 algif_hash,algif_skcipher snd_hda_codec_hdmi 90112 1 qrtr 57344 4 bnep 36864 2 binfmt_misc28672 1 dell_rbtn 20480 0 snd_sof_pci_intel_tgl12288 0 snd_sof_intel_hda_common 204800 1 snd_sof_pci_intel_tgl soundwire_intel61440 1 snd_sof_intel_hda_common soundwire_generic_allocation12288 1 soundwire_intel snd_sof_intel_hda_mlink40960 2 soundwire_intel,snd_sof_intel_hda_common soundwire_cadence 45056 1 soundwire_intel snd_sof_intel_hda 24576 1 snd_sof_intel_hda_common intel_uncore_frequency12288 0 snd_sof_pci24576 2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl intel_uncore_frequency_common16384 1 intel_uncore_frequency snd_sof_xtensa_dsp 16384 1 snd_sof_intel_hda_common x86_pkg_temp_thermal16384 0 btusb 81920 0 snd_sof 356352 3 snd_sof_pci,snd_sof_intel_hda_common,snd_sof_intel_hda intel_powerclamp 16384 0 btrtl 28672 1 btusb snd_sof_utils 16384 1 snd_sof coretemp 16384 0 snd_soc_hdac_hda 24576 1 snd_sof_intel_hda_common btbcm 24576 1 btusb snd_hda_ext_core 36864 4 snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda_mlink,snd_sof_intel_hda iwlmvm589824 0 snd_ctl_led24576 0 btintel57344 1 btusb snd_soc_acpi_intel_match90112 2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl btmtk 12288 1 btusb kvm_intel 413696 0 snd_hda_codec_realtek 192512 1 snd_soc_acpi 12288 2 snd_soc_acpi_intel_match,snd_sof_intel_hda_common snd_hda_codec_generic 114688 1 snd_hda_codec_realtek bluetooth1134592 34 btrtl,btmtk,btintel,btbcm,bnep,btusb,rfcomm snd_soc_core 421888 4 soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hda mac80211 1392640 1 iwlmvm snd_compress 28672 1 snd_soc_core kvm 1359872 1 kvm_intel soundwire_bus 114688 3 soundwire_intel,soundwire_generic_allocation,soundwire_cadence libarc412288 1 mac80211 snd_hda_intel 61440 1 snd_intel_dspcfg 32768 3 snd_hda_intel,snd_sof,snd_sof_intel_hda_common snd_intel_sdw_acpi 16384 2 snd_sof_intel_hda_common,snd_intel_dspcfg sha3_generic 16384 1 dell_laptop32768 0 snd_hda_codec 225280 6 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek,snd_soc_hdac_hda,snd_sof_intel_hda jitterentropy_rng 20480 1 uvcvideo 147456 0 irqbypass 12288 1 kvm ledtrig_audio 12288 3 snd_ctl_led,snd_hda_codec_generic,dell_laptop iwlwifi 544768 1 iwlmvm joydev 24576 0 hid_sensor_als 16384 1 videobuf2_vmalloc 20480 1 uvcvideo rapl 20480 0 snd_hda_core 147456 9 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda uvc12288 1 uvcvideo drbg 49152 1 dell_wmi 16384 0 hid_sensor_trigger 20480 2 hid_sensor_als mei_hdcp 28672 0 mei_wdt12288 0 mei_pxp16384 0 nls_ascii 12288 1 intel_cstate 20480 0 snd_hwdep 20480 1 snd_hda_codec videobuf2_memops 16384 1 videobuf2_vmalloc intel_rapl_msr
Bug#1057656: firmware-amd-graphics: System hangs indefinitely with DMUB status=2 messages
Package: firmware-amd-graphics Version: 20230625-2 Followup-For: Bug #1057656 Dear Maintainer, the current status of AMD GPU firmware in SID renders my system completely unusable. Issues started with upgdate to kernel 6.5.0-5 but going back to 6.5.0-4 was usable. After firmware update going back to 6.5.0-4 failed, too. None of the following kernel updates fixed the issue. https://gitlab.freedesktop.org/drm/amd/-/issues/2921 seems related, indicating missing patches in 6.6 firmware. Manually obtained (amdgpu) firmware from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/linux-firmware-20231211.tar.gz updated initramfs and rebooted - issue appears to be fixed. Please package the latest upstream linux-firmware version. Thanks for the effort. Cheers. Chris. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 firmware-amd-graphics depends on no packages. firmware-amd-graphics recommends no packages. Versions of packages firmware-amd-graphics suggests: ii initramfs-tools 0.142 -- no debconf information
