Bug#1076309: [s390x] lots of "User process fault: interruption code XXXX"
Hi waldi, On 24-07-2024 10:57 a.m., Bastian Blank wrote: On Thu, Jul 18, 2024 at 08:06:46AM +0200, Paul Gevers wrote: However, that doesn't seem to work on our s390x host as it seems to freeze instead. Is this something known? Something I'm doing wrong (E.g. these options behaving differently on s390x)? Is this a s390x kernel bug? This now points to a kernel bug. Which requires a new kernel first for further debugging. What does "freeze" mean"? Also no sysrq? With freeze I mean I have no connection anymore. And when I reboot, there's nothing in the journal since I lost connection. I don't know yet what sysrq means, so I'll look into that. See https://www.kernel.org/doc/html/v5.3/s390/debugging390.html#sysrq, but you need to enable that before. Maybe tomorrow. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive
Hi all, On 14-07-2024 9:47 a.m., Paul Gevers wrote: For the record: I have installed the unstable kernel on one of the workers (ci-worker-arm64-11 [1]). Let's see how it behaves. The host has been running fine so far, I have installed the current unstable kernel on all arm64 hosts now. Paul Linux ci-worker-arm64-03 6.9.10-arm64 #1 SMP Debian 6.9.10-1 (2024-07-19) aarch64 GNU/Linux OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1076309: [s390x] lots of "User process fault: interruption code XXXX"
Hi all, On Sun, 14 Jul 2024 09:22:32 +0200 Paul Gevers wrote: Today I restarted the s390x host of ci.d.n because I lost access. I have been fighting with the host for several days now, and I think I finally found the culprit. Several days ago I configured the host to do: # panic kernel on OOM vm.panic_on_oom=1 # reboot after 10 sec on panic kernel.panic=10 An idea I got from h01ger last year when discussing issues on arm64 and that has been working well there [1]. (See also https://www.debuntu.org/how-to-reboot-on-oom/) However, that doesn't seem to work on our s390x host as it seems to freeze instead. Is this something known? Something I'm doing wrong (E.g. these options behaving differently on s390x)? Is this a s390x kernel bug? Paul PS: the package that triggers this is hisat2. If you look at it's history [2] you see that the test was always Terminated (ignoring the run from 2024-07-17), I now assume by the OOM killer. I filed bug 1076524 against hisat2 to tell them they are using an insane amount of memory on s390x. [1] See e.g. the period around February/March 2024 on https://ci.debian.net/munin/ci-worker-arm64-11/ci-worker-arm64-11/uptime.html where a lot of reboots happened automatically. [2] https://ci.debian.net/packages/h/hisat2/testing/s390x/ OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive
Hi, On 09-07-2024 12:23 p.m., Paul Gevers wrote: I'll see what I can do. For the record: I have installed the unstable kernel on one of the workers (ci-worker-arm64-11 [1]). Let's see how it behaves. Paul [1] https://ci.debian.net/munin/ci-worker-arm64-11/ci-worker-arm64-11/index.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1076309: [s390x] lots of "User process fault: interruption code XXXX"
Package: src:linux Version: 6.7.12-1~bpo12+1 X-Debbugs-CC: debian...@lists.debian.org, debian-s...@lists.debian.org Severity: normal X-Debbugs-Cc: elb...@debian.org Hi linux maintainers, Today I restarted the s390x host of ci.d.n because I lost access. I inspected the journal and noticed there were a lot kernel messages (several tens to hundreds per day) like "User process fault: interruption code 003b ilc:3 in my_kmcdump[2aa0798+f000]". I attached the first block I found in the journal after the reboot. Please let me know if you need more information. Paul PS: I checked with carnil before filing this report, he thought it was worth reporting. -- Package-specific info: ** Version: Linux version 6.7.12+bpo-s390x (debian-kernel@lists.debian.org) (s390x-linux-gnu-gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 6.7.12-1~bpo12+1 (2024-05-06) ** Command line: root=/dev/mapper/sysvg-root BOOT_IMAGE=0 ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information processor 0: version = FF, identification = 01, machine = 8561 processor 1: version = FF, identification = 02, machine = 8561 processor 2: version = FF, identification = 03, machine = 8561 processor 3: version = FF, identification = 04, machine = 8561 processor 4: version = FF, identification = 05, machine = 8561 processor 5: version = FF, identification = 06, machine = 8561 processor 6: version = FF, identification = 07, machine = 8561 processor 7: version = FF, identification = 08, machine = 8561 processor 8: version = FF, identification = 09, machine = 8561 processor 9: version = FF, identification = 0A, machine = 8561 ** Loaded modules: nfsd auth_rpcgss nfs_acl lockd grace tls sunrpc tcp_diag inet_diag veth nft_masq nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink binfmt_misc qeth_l2 bridge s390_trng prng stp ctr llc sg xts aes_s390 des_s390 libdes sha512_s390 qeth sha256_s390 sha1_s390 sha_common vmur ccwgroup scsi_dh_alua dm_service_time dm_multipath loop configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_common dm_mod zfcp scsi_transport_fc dasd_eckd_mod scsi_mod chacha_s390 libchacha dasd_fba_mod dasd_mod scsi_common ** PCI devices: ** USB devices: not available -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable'), (1, 'experimental') Architecture: s390x Kernel: Linux 6.7.12+bpo-s390x (SMP w/10 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-6.7.12+bpo-s390x depends on: ii initramfs-tools [linux-initramfs-tool] 0.142 ii kmod30+20221128-1 ii linux-base 4.9 Versions of packages linux-image-6.7.12+bpo-s390x recommends: ii apparmor 3.0.8-3 ii firmware-linux-free 20200122-1 Versions of packages linux-image-6.7.12+bpo-s390x suggests: pn debian-kernel-handbook pn linux-doc-6.7 ii s390-tools 2.16.0-2 Versions of packages linux-image-6.7.12+bpo-s390x is related to: pn firmware-amd-graphics pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas pn firmware-linux-nonfree pn firmware-misc-nonfree pn firmware-myricom pn firmware-netxen pn firmware-qlogic pn firmware-realtek pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information Jul 14 06:34:09 ci-worker-s390x-01 kernel: User process fault: interruption code 0007 ilc:2 in libm.so[3ff8cb0+8] Jul 14 06:34:09 ci-worker-s390x-01 kernel: CPU: 0 PID: 699155 Comm: ld64.so.1 Not tainted 6.7.12+bpo-s390x #1 Debian 6.7.12-1~bpo12+1 Jul 14 06:34:09 ci-worker-s390x-01 kernel: Hardware name: IBM 8561 LT1 400 (z/VM 7.2.0) Jul 14 06:34:09 ci-worker-s390x-01 kernel: User PSW : 070530018000 03ff8cb0d17a Jul 14 06:34:09 ci-worker-s390x-01 kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:3 PM:0 RI:0 EA:3 Jul 14 06:34:09 ci-worker-s390x-01 kernel: User GPRS: f000 03ff8cb0d150 0040 0004 Jul 14 06:34:09 ci-worker-s390x-01 kernel:03ffc52f8d50 03ff8cb4c690
Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive
Hi, On 08-07-2024 10:07 p.m., Salvatore Bonaccorso wrote: If you think it worth enough knowing if either is the case, I can install the backports kernel again on the arm64 hosts, but obviously that will be annoying for us. Please let me know if I should pursue this (I would be expecting a bit quicker turn around on this bug if you say yes now ;) ). If you can test with the unstable kernel that would be great. If you are limited to only stable and backports, then you should probably wait until 6.8 is in backports rather than testing the current 6.7 backport that has only one of the fixes. In the last weekly kernel team meeting we discussed about some of the open issues, and we wondered if you were able to test again with either a unstable kernel, or if that's not possible with the current versions available trough backports? Grr, sorry, I forgot about this. Unfortunately for the 6.8.y series though the package is not yet out of backports-new. I'll see what I can do. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072004: linux: regression in the 9p protocol in 6.8 breaks autopkgtest qemu jobs (affecting debci)
Hi, On 28-05-2024 10:54 a.m., Luca Boccassi wrote: If 6.8 migrates to testing, it will break amd64 debci for unrelated packages for migration tests too. I don't think that's something we want? Paul, wouldn't that qualify as RC? With the kernel team being aware of the issue, I trust the kernel team to balance the options appropriately. I defer to make a call as a Release Team member. Options that I'm aware of: 1) accept the kernel package as is in testing where it will cause some regression in some autopkgtest on ci.d.n infrastructure in testing. We have (only) 56 packages tested with qemu and I could disable qemu based testing on ci.d.n until this bug is resolved (which means that isolation-machine tests will not be run, but also not cause unnecessary failures). 2) update the kernel package with the bisected commit reverted. I understand that the kernel team tries to follow upstream as much as possible to avoid Debian delta's that might be hard to get rid of. 3) update the kernel package with a proposed (but not accepted) patch. 4) wait with updating the kernel package in testing until this issue is solved upstream, causing all kernel fixes to hit testing later. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive
Hi Ben (and all the rest), On 15-05-2024 9:56 p.m., Ben Hutchings wrote: Apologies for leaving this bug for so long. NP, part of live I guess. Is this bug still occurring? I don't know. The problem was severe enough for us to abandon the idea of running the backport kernels on our arm64 hosts, so we went back to the stable kernel there. I had a look for possibly related fixes, and found: commit 22e111ed6c83dcde3037fc81176012721bc34c0b [...] The fix went into 6.8-rc1 and was backported to 6.6.15, so Debian versions 6.6.15-1 onward should have it. commit a8b0026847b8c43445c921ad2c85521c92eb175f [...] which went into 6.8 but was *not* backported. If you think it worth enough knowing if either is the case, I can install the backports kernel again on the arm64 hosts, but obviously that will be annoying for us. Please let me know if I should pursue this (I would be expecting a bit quicker turn around on this bug if you say yes now ;) ). If the bug is still occurring, can you say what type of filesystem rsync is being run on? I'm not sure if this is the answer you're looking for, we use ext4. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: What to do with d-i on armel?
Hi, On 03-03-2024 9:01 p.m., Cyril Brulebois wrote: Maybe have it marked Not-For-Us on armel, also requesting the binary to be dropped there? And maybe poke the ftp team to have installer-armel/ cleaned up? Those actions sound appropriate to me, but I don't know the inner details well enough to see if there are traps set out. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063364: nvidia-cuda-samples: autopkgtest needs update for new version of linux
Source: nvidia-cuda-samples Version: 12.1~dfsg-1 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-cuda-samples fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-cuda-samplesfrom testing12.1~dfsg-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-cuda-samples/42760273/log.gz 1664s I: Testing binary package nvidia-fs-dkms 1664s I: Trying to install build dependency nvidia-current/525.147.05 for 6.6.15-amd64 1664s Sign command: /lib/modules/6.6.15-amd64/build/scripts/sign-file 1664s Signing key: /var/lib/dkms/mok.key 1664s Public certificate (MOK): /var/lib/dkms/mok.pub 1664s Certificate or key are missing, generating self signed certificate for MOK... 1664s Creating symlink /var/lib/dkms/nvidia-current/525.147.05/source -> /usr/src/nvidia-current-525.147.05 1664s 1664s Building module: 1665s Cleaning build area... 1686s env NV_VERBOSE=1 make -j64 modules KERNEL_UNAME=6.6.15-amd64..(bad exit status: 2) 1686s Error! Bad return status for module build on kernel: 6.6.15-amd64 (x86_64) 1686s Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more information. 1686s autopkgtest [06:12:31]: test dkms-autopkgtest-nvidia-fs OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063363: nvidia-graphics-drivers: autopkgtest needs update for new version of linux
Source: nvidia-graphics-drivers Version: 525.147.05-5 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-graphics-drivers fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-graphics-drivers from testing525.147.05-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers/42760274/log.gz 810s # MODPOST /usr/src/modules/nvidia-kernel/Module.symvers 810sscripts/mod/modpost -M -m -o /usr/src/modules/nvidia-kernel/Module.symvers -T /usr/src/modules/nvidia-kernel/modules.order -i Module.symvers -e 811s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock' 811s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' 811s make[6]: *** [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.modpost:145: /usr/src/modules/nvidia-kernel/Module.symvers] Error 1 811s make[5]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:1890: modpost] Error 2 811s make[4]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:246: __sub-make] Error 2 811s make[4]: Leaving directory '/usr/src/linux-headers-6.6.15-cloud-amd64' 811s make[3]: *** [Makefile:246: __sub-make] Error 2 811s make[3]: Leaving directory '/usr/src/linux-headers-6.6.15-common' 811s make[2]: *** [Makefile:82: modules] Error 2 811s make[2]: Leaving directory '/usr/src/modules/nvidia-kernel' 811s make[1]: *** [debian/rules:39: binary-modules] Error 2 811s make[1]: Leaving directory '/usr/src/modules/nvidia-kernel' 811s make: *** [/usr/share/modass/include/common-rules.make:56: kdist_build] Error 2 811s tput: No value for $TERM and no -T specified 811s BUILD FAILED! 811s tput: No value for $TERM and no -T specified 811s See /var/cache/modass/nvidia-kernel-source.buildlog.6.6.15-cloud-amd64.1707198843 for details. 811s Build failed. Press Return to continue... 811s I: nvidia-kernel does not support the 6.6.15-rt-amd64 kernel (!CONFIG_PREEMPT_RT) 811s I: Summary: 811s I: FAIL nvidia-kernel 6.6.15-amd64 (7) 811s I: FAIL nvidia-kernel 6.6.15-cloud-amd64 (7) 811s I: SKIP nvidia-kernel 6.6.15-rt-amd64 (!CONFIG_PREEMPT_RT) 811s autopkgtest [05:58:24]: test m-a-autopkgtest OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063362: nvidia-graphics-drivers-tesla: autopkgtest needs update for new version of linux
Source: nvidia-graphics-drivers-tesla Version: 525.147.05-5 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-graphics-drivers-tesla fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-graphics-drivers-tesla from testing525.147.05-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers-tesla/42735533/log.gz 202s # MODPOST /usr/src/modules/nvidia-tesla-kernel/Module.symvers 202sscripts/mod/modpost -M -m -o /usr/src/modules/nvidia-tesla-kernel/Module.symvers -T /usr/src/modules/nvidia-tesla-kernel/modules.order -i Module.symvers -e 203s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock' 203s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' 203s make[6]: *** [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.modpost:145: /usr/src/modules/nvidia-tesla-kernel/Module.symvers] Error 1 203s make[5]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:1890: modpost] Error 2 203s make[4]: *** [/usr/src/linux-headers-6.6.15-common/Makefile:246: __sub-make] Error 2 203s make[4]: Leaving directory '/usr/src/linux-headers-6.6.15-cloud-amd64' 203s make[3]: *** [Makefile:246: __sub-make] Error 2 203s make[3]: Leaving directory '/usr/src/linux-headers-6.6.15-common' 203s make[2]: *** [Makefile:82: modules] Error 2 203s make[2]: Leaving directory '/usr/src/modules/nvidia-tesla-kernel' 203s make[1]: *** [debian/rules:39: binary-modules] Error 2 203s make[1]: Leaving directory '/usr/src/modules/nvidia-tesla-kernel' 203s make: *** [/usr/share/modass/include/common-rules.make:56: kdist_build] Error 2 203s tput: No value for $TERM and no -T specified 203s BUILD FAILED! 203s tput: No value for $TERM and no -T specified 203s See /var/cache/modass/nvidia-tesla-kernel-source.buildlog.6.6.15-cloud-amd64.1707107102 for details. 203s Build failed. Press Return to continue... 203s I: nvidia-tesla-kernel does not support the 6.6.15-rt-amd64 kernel (!CONFIG_PREEMPT_RT) 203s I: Summary: 203s I: FAIL nvidia-tesla-kernel 6.6.15-amd64 (7) 203s I: FAIL nvidia-tesla-kernel 6.6.15-cloud-amd64 (7) 203s I: SKIP nvidia-tesla-kernel 6.6.15-rt-amd64 (!CONFIG_PREEMPT_RT) 203s autopkgtest [04:25:29]: test m-a-autopkgtest OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063361: nvidia-graphics-drivers-tesla-470: autopkgtest needs update for new version of linux
Source: nvidia-graphics-drivers-tesla-470 Version: 470.223.02-3 Severity: serious X-Debbugs-CC: li...@packages.debian.org Tags: sid trixie User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:linux Dear maintainer(s), With a recent upload of linux the autopkgtest of nvidia-graphics-drivers-tesla-470 fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing6.6.15-2 nvidia-graphics-drivers-tesla-470 from testing470.223.02-3 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Of course, linux shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in linux was intended and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from linux should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/n/nvidia-graphics-drivers-tesla-470/42735534/log.gz 320s # MODPOST /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers 320sscripts/mod/modpost -M -m -o /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers -T /var/lib/dkms/nvidia-tesla-470/470.223.02/build/modules.order -i Module.symvers -e 320s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock' 320s ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' 320s make[4]: *** [/usr/src/linux-headers-6.6.15-common/scripts/Makefile.modpost:145: /var/lib/dkms/nvidia-tesla-470/470.223.02/build/Module.symvers] Error 1 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059765: linux: isolation-machine autopkgtest fails for multiple reasons
Hi On 01-01-2024 22:33, Bastian Blank wrote: Do we have serial of the machines? Do you mean of the system where the VM's run, or of the VM itself? IIRC the qemu backend of autopkgtest is talking to the VM over serial, but if you want to be sure, I'll need to check. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059765: linux: isolation-machine autopkgtest fails for multiple reasons
Hi Bastian,
On 31-12-2023 18:33, Bastian Blank wrote:
Do you have a handy script available to try this by hand? I was just
looking at this test (to unravel the loop logic and replace it with one
test per kernel), but I'm not sure if this ever worked before.
It was nearly completely attached at the bottom of the e-mail. Writing
it out and providing a patch (from memory, so untested) as well.
# in path with src:linux unpacked
# Apply patch
export ADT_REBOOT_MARK=step0 # or whatever number matches your kernel
export AUTOPKGTEST_TMP=$(mktemp -d)
chmod a+x debian/tests/selftests
debian/tests/selftests
Paul
diff --git a/debian/tests/selftests b/debian/tests/selftests
index 02cc29372e..ff12a0cd17 100644
--- a/debian/tests/selftests
+++ b/debian/tests/selftests
@@ -1,4 +1,4 @@
-#!/bin/bash -eu
+#!/bin/bash -eux
PATH=/usr/sbin:/sbin:/usr/bin:/bin
@@ -81,8 +81,8 @@ step=$((step + 1))
if [ "$step" -lt "$steps" ]; then
# Load the next kernel
ver=$abiname${localversion[$step]}
-kexec -l /boot/vmlinuz-$ver --initrd /boot/initrd.img-$ver --reuse-cmdline
-/tmp/autopkgtest-reboot step$step
+#kexec -l /boot/vmlinuz-$ver --initrd /boot/initrd.img-$ver --reuse-cmdline
+#/tmp/autopkgtest-reboot step$step
fi
exit 0
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1059765: linux: isolation-machine autopkgtest fails for multiple reasons
Source: linux Version: 6.6.8-1 Severity: normal Dear linux maintainers, Recently I added some isolation-machine support to ci.debian.net and one of the first packages I tried to run the test for is src:linux. Unfortunately, the isolation-machine based test (selftests) fails (the reboot that autopgtest schedules just hangs until it times out). I haven't used kexec before in my life, so I'm not totally sure what to expect from $(kexec -l ...) but I *suspect* (after reading the autopkgtest spec [1]) that the call after kexec in selftests is wrong: """ In some cases your test needs to do the reboot by itself, e. g. through kexec, or a reboot command that is hardcoded in the piece of software that you want to test. To support those, you need to call /tmp/autopkgtest-reboot-prepare my_mark at a point as close as possible to the reboot instead; this will merely save the state but not issue the actual reboot by itself """ (so /tmp/autopkgtest-reboot-prepare instead of /tmp/autopkgtest-reboot, and maybe it should be *before* the kexec call) On the other hand, when I run $(uname -a) after a $(manual kexec -l ..) call, it looks like I'm still running the "old" kernel, so I'm not sure if that line does what I would hope it to do either (it's extremely quick too). When I play a bit and finally can get the test to run for the current kernel (manually passing the right step number in ADT_REBOOT_MARK for the current kernel and an appropriate AUTOPKGTEST_TMP [2]) I also notice that $(make headers_install) ends with: """ /bin/sh: 1: rsync: not found """ so that's a missing test dependency. After all that, the test (for the rt kernel) runs nice although it seems to hang on (maybe just a very long running test with no output, I waited several minutes, is that timeout referenced in seconds or minutes?): """ ok 7 selftests: cgroup: test_cpuset # timeout set to 45 # selftests: cgroup: test_zswap """ Second time I ran this was for the regular kernel used by autopkgtest-build-qemu and that passed that stage with ease and seemed to run to the end (with failures, but those you can iron out once we get decent logs). Also, I suspect the total test will timeout (after 2:47) if we test all desired kernel flavors in one test. So instead of squeezing everything in one autopkgtest (stanza) it's probably smarter to generate a stanza per kernel you want to run (because then you're only limited by the overall timeout of 8.5 hours). Paul [1] https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst [2] # emacs debian/tests/selftests # to disable kexec and /tmp/autopkgtest-reboot call and to set -x chmod a+x debian/tests/selftests # export ADT_REBOOT_MARK=step0 # export root@host:/tmp/autopkgtest.Y35OYd/build.rih/src# export AUTOPKGTEST_TMP=$(mktemp -d) # debian/tests/selftests # testing the default installed kernel OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
Hi, On Mon, 18 Sep 2023 20:54:17 +0200 Paul Gevers wrote: On 09-09-2023 13:06, Paul Gevers wrote: > All ci.d.n workers (except riscv64) now run the kernel from > bookworm-backports. systemd passes it's autopkgtest again in unstable, > testing and stable. We're having issues [1] with the (backports and) unstable kernel on our main amd64 host, so we reverted back to the stable kernel for amd64. Paul [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052130 We're having issues [2] with the backports kernel on arm64 so our arm64, armhf and armel hosts are back to the previous backports (arm64) kernel. I'm slightly wondering if the next point release (on Saturday) will bring us a fixed kernel for this issue? Given that this is the second time in 3 months we experience an issue with backports kernels, I think we'll have to revert our hosts back to stable kernels for maintainability reasons. Paul [2] https://bugs.debian.org/1057282 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive
Control: tags -1 - moreinfo Hi Ben and the rest, On 04-12-2023 15:10, Ben Hutchings wrote: CPU: 6 PID: 15039 Comm: lxc-start Tainted: G D WL 6.5.0-0.deb12.1-arm64 #1 Debian 6.5.3-1~bpo12+1 The D and W flags mean there were prior BUG and WARN errors logged. Please send those as well. Please find attached the content of the journal since the reboot. I filtered out "debci". Paul kernel-bug-part0.log.xz Description: application/xz OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050256: autopkgtest fails on debci
Hi all, On 09-09-2023 13:06, Paul Gevers wrote: All ci.d.n workers (except riscv64) now run the kernel from bookworm-backports. systemd passes it's autopkgtest again in unstable, testing and stable. We're having issues [1] with the (backports and) unstable kernel on our main amd64 host, so we reverted back to the stable kernel for amd64. Paul [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052130 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1052130: linux-image-6.5.0-1-amd64: kernel complains about general protection fault several times before host goes down
Package: linux-image-6.5.0-1-amd64 Version: 6.5.3-1 Severity: normal Dear linux maintainers, We recently switched the main amd64 worker for ci.d.n to the backports kernel due to bug 1050256. However, I had the host become unaccessible twice, so I upgraded to the unstable kernel (not totally my intention but due to wrong apt pinning). Since I ran the unstable kernel (about three days ago, the host has become non responsive several times. Just before the journal stops logging things, the kernel logs about a "general protection fault" several times. See the attached log for more details. I'm sending this from my laptop, if I should collect information from the host, please let me know. Paul Sep 17 07:43:48 ci-worker13 kernel: general protection fault, probably for non-canonical address 0xcb9d265a04e18934: [#1] PREEMPT SMP NOPTI Sep 17 07:43:48 ci-worker13 kernel: CPU: 18 PID: 3374089 Comm: rsync Not tainted 6.5.0-1-amd64 #1 Debian 6.5.3-1 Sep 17 07:43:48 ci-worker13 kernel: Hardware name: Dell Inc. PowerEdge R6515/07PXPY, BIOS 2.2.4 04/12/2021 Sep 17 07:43:48 ci-worker13 kernel: RIP: 0010:kmem_cache_alloc_node+0x1cf/0x380 Sep 17 07:43:48 ci-worker13 kernel: Code: d8 5b 41 5c 41 5d 41 5e 41 5f 5d e9 5b ca 82 00 41 8b 44 24 28 4d 8b 14 24 49 89 f8 49 89 d1 49 8b 9c 24 b8 00 00 00 48 01 f8 <48> 33 18 48 89 c1 48 89 f8 48 0f c9 48 31 cb 48 8d 8a 00 20 00 00 Sep 17 07:43:48 ci-worker13 kernel: RSP: 0018:962a8ee33af0 EFLAGS: 00010282 Sep 17 07:43:48 ci-worker13 kernel: RAX: cb9d265a04e18934 RBX: bb883960d76814e0 RCX: Sep 17 07:43:48 ci-worker13 kernel: RDX: 000172e38012 RSI: 9e44f718 RDI: cb9d265a04e188c4 Sep 17 07:43:48 ci-worker13 kernel: RBP: 962a8ee33b40 R08: cb9d265a04e188c4 R09: 000172e38012 Sep 17 07:43:48 ci-worker13 kernel: R10: 0003b4d0 R11: R12: 89fcd6251800 Sep 17 07:43:48 ci-worker13 kernel: R13: 89ca134f3d80 R14: 00400cc0 R15: Sep 17 07:43:48 ci-worker13 kernel: FS: 7f9416f7fb80() GS:8a087e88() knlGS: Sep 17 07:43:48 ci-worker13 kernel: CS: 0010 DS: ES: CR0: 80050033 Sep 17 07:43:48 ci-worker13 kernel: CR2: 7f94167e9fe8 CR3: 000e13f3c000 CR4: 00350ee0 Sep 17 07:43:48 ci-worker13 kernel: Call Trace: Sep 17 07:43:48 ci-worker13 kernel: Sep 17 07:43:48 ci-worker13 kernel: ? die_addr+0x36/0x90 Sep 17 07:43:48 ci-worker13 kernel: ? exc_general_protection+0x1c5/0x430 Sep 17 07:43:48 ci-worker13 kernel: ? asm_exc_general_protection+0x26/0x30 Sep 17 07:43:48 ci-worker13 kernel: ? kmem_cache_alloc_node+0x1cf/0x380 Sep 17 07:43:48 ci-worker13 kernel: ? __alloc_skb+0x161/0x1a0 Sep 17 07:43:48 ci-worker13 kernel: __alloc_skb+0x161/0x1a0 Sep 17 07:43:48 ci-worker13 kernel: alloc_skb_with_frags+0x50/0x200 Sep 17 07:43:48 ci-worker13 kernel: sock_alloc_send_pskb+0x1fa/0x240 Sep 17 07:43:48 ci-worker13 kernel: ? srso_return_thunk+0x5/0x10 Sep 17 07:43:48 ci-worker13 kernel: unix_stream_sendmsg+0x19d/0x690 Sep 17 07:43:48 ci-worker13 kernel: sock_write_iter+0x175/0x180 Sep 17 07:43:48 ci-worker13 kernel: vfs_write+0x39a/0x440 Sep 17 07:43:48 ci-worker13 kernel: ksys_write+0xbb/0xf0 Sep 17 07:43:48 ci-worker13 kernel: do_syscall_64+0x60/0xc0 Sep 17 07:43:48 ci-worker13 kernel: ? do_pselect.constprop.0+0xfd/0x180 Sep 17 07:43:48 ci-worker13 kernel: ? srso_return_thunk+0x5/0x10 Sep 17 07:43:48 ci-worker13 kernel: ? fpregs_assert_state_consistent+0x26/0x50 Sep 17 07:43:48 ci-worker13 kernel: ? srso_return_thunk+0x5/0x10 Sep 17 07:43:48 ci-worker13 kernel: ? exit_to_user_mode_prepare+0x40/0x1d0 Sep 17 07:43:48 ci-worker13 kernel: ? srso_return_thunk+0x5/0x10 Sep 17 07:43:48 ci-worker13 kernel: ? syscall_exit_to_user_mode+0x2b/0x40 Sep 17 07:43:48 ci-worker13 kernel: ? srso_return_thunk+0x5/0x10 Sep 17 07:43:48 ci-worker13 kernel: ? do_syscall_64+0x6c/0xc0 Sep 17 07:43:48 ci-worker13 kernel: ? srso_return_thunk+0x5/0x10 Sep 17 07:43:48 ci-worker13 kernel: ? syscall_exit_to_user_mode+0x2b/0x40 Sep 17 07:43:48 ci-worker13 kernel: ? srso_return_thunk+0x5/0x10 Sep 17 07:43:48 ci-worker13 kernel: ? do_syscall_64+0x6c/0xc0 Sep 17 07:43:48 ci-worker13 kernel: ? syscall_exit_to_user_mode+0x2b/0x40 Sep 17 07:43:48 ci-worker13 kernel: ? srso_return_thunk+0x5/0x10 Sep 17 07:43:48 ci-worker13 kernel: ? do_syscall_64+0x6c/0xc0 Sep 17 07:43:48 ci-worker13 kernel: entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Sep 17 07:43:48 ci-worker13 kernel: RIP: 0033:0x7f9416917120 Sep 17 07:43:48 ci-worker13 kernel: Code: 40 00 48 8b 15 e1 9c 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d c1 24 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89 Sep 17 07:43:48 ci-worker13 kernel: RSP: 002b:7fffad5a6d68 EFLAGS: 0202 ORIG_RAX: 0001 Sep 17 07:43:48 ci-worker13 kernel: RAX: ffda RBX: 0005 RCX: 7f9416917120 Sep 17
Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems
Hi Salvatore, On 09-09-2023 10:15, Salvatore Bonaccorso wrote: but should have been support for armel been dropped earlier and should we do it for trixie The kernel for armel went over some hardware limits before (I was affected with my NAS, where I couldn't upgrade the kernel to bullseye as documented in the release notes [1]). Is the current situation reaching the limit for all armel devices, or "just" for some and are the others probably fine for some years to come? If we're now reaching the final limit and if it was foreseeable that we would reach that limit, then yes it would have made sense to drop armel *before* the bookworm release, but alas. If the kernel team can't support the kernel on armel, than armel shouldn't be a release architecture for trixie. If it's only some devices, than we "just" need to communicate that clearly. I don't have a clear advice for the current situation in security and the next point release, let's hope you can stretch the situation a bit longer. I recall that the kernel package has safety checks in place and refuses to *try* to install the kernel if it doesn't fit on the hardware. That means that you don't cripple the hardware of affected people, but "merely" can't give them security support? I guess it would be possible (as long as support lasts; no LTS support) for effected systems to run the security supported bullseye kernel. Paul [1] https://www.debian.org/releases/bullseye/armel/release-notes/ch-information.en.html#no-longer-supported-hardware OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1049448: new kernel updating problem
Control: reassign -1 linux-image-6.1.0-11-amd64 6.1.38-4 Hi slimshady, Given that it's linux-image-6.1.0-11-amd64 failing to install, I reassign this bug to that package. However, I wonder if you noticed this in your error log: raspi-firmware: missing /boot/firmware, did you forget to mount it? I'm not familiar with raspi-firmware nor run-parts, but isn't this likely pointing at a problem with your system that you need to fix first? Paul On 15-08-2023 23:02, slimshady wrote: Package: upgrade-reports Severity: important X-Debbugs-Cc: slimshad...@zohomail.eu (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) My previous release is: I am upgrading to: Archive date: Upgrade date: 15/08/2023 uname -a before upgrade: 6.1.0-9-amd64 uname -a after upgrade: 6.1.0-11-amd64 Method: discover Contents of /etc/apt/sources.list: - Were there any non-Debian packages installed before the upgrade? If so, what were they? no - Was the system pre-update a 'pure' system only containing packages from the previous release? If not, which packages were not from that release? - Did any packages fail to upgrade? - Were there any problems with the system after upgrading? Further Comments/Problems: Please attach the output of "COLUMNS=200 dpkg -l" (or "env COLUMNS ...", depending on your shell) from before and after the upgrade so that we know what packages were installed on your system. Setting up initramfs-tools (0.142) ... update-initramfs: deferring update (trigger activated) Setting up linux-image-6.1.0-11-amd64 (6.1.38-4) ... /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-6.1.0-11-amd64 raspi-firmware: missing /boot/firmware, did you forget to mount it? run-parts: /etc/initramfs/post-update.d//z50-raspi-firmware exited with return code 1 run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 dpkg: error processing package linux-image-6.1.0-11-amd64 (--configure): installed linux-image-6.1.0-11-amd64 package post-installation script subprocess returned error exit status 1 Setting up python3-charset-normalizer (3.0.1-2) ... dpkg: dependency problems prevent configuration of linux-image-amd64: linux-image-amd64 depends on linux-image-6.1.0-11-amd64 (= 6.1.38-4); however: Package linux-image-6.1.0-11-amd64 is not configured yet. dpkg: error processing package linux-image-amd64 (--configure): dependency problems - leaving unconfigured OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1038105: upgrade-reports: resume from suspend/hibernate broken by upgrade from bullseye to bookworm
control: reassign -1 src:linux Hi, Although it was suggested that this may be due to firmware updates too, let's reassign to the linux source package for first triaging. Paul On 15-06-2023 15:26, Jeffrey Mark Siskind wrote: Package: upgrade-reports Severity: important (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) My previous release is: bullseye I am upgrading to: bookworm Upgrade date: Tuesday 13 Jun 2023 uname -a after upgrade: Linux sapiencia 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux Method: apt dist-upgrade Contents of /etc/apt/sources.list: deb https://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware deb-src https://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware deb https://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware deb-src https://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware deb https://deb.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware deb-src https://deb.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware # deb https://apt.repos.intel.com/oneapi all main # deb-src https://apt.repos.intel.com/oneapi all main - Were there any non-Debian packages installed before the upgrade? If so, what were they? https://apt.repos.intel.com/oneapi qobi@sapiencia>ls /etc/apt/sources.list.d google-chrome.listneurodebian.sources.list-bullseye teams.list neurodebian.sources.list skype-stable.list qobi@sapiencia> - Was the system pre-update a 'pure' system only containing packages from the previous release? If not, which packages were not from that release? No. it had https://apt.repos.intel.com/oneapi google-chrome.list neurodebian.sources.list skype-stable.list teams.list - Did any packages fail to upgrade? At first, it didn't upgrade nvidia-driver. It did after I added non-free-firmware. - Were there any problems with the system after upgrading? Yes. My machine is a Lenovo P71. I run gnome. Under bullseye, it properly suspended/hibernated with I closed the lid and properly resumed when I opened the lid. After the upgrade to bookworm, it appears to properly suspend/hibernat with I close the lid. Sometimes (about 30% of the time) it properly resumes when I open the lid. But about 70% of the time, when I open the lid, the disk light flashes a few times for about 20 seconds, then stops. The screen remains blank. It doesn't respond to any keypresses or mouse movements. If I press the power button briefly, nothing happens. If I press and hold the power button for about 10 seconds, it turns off. The I can power on and boot up fresh. I don't know if I should file against pm-tools. Jeff (http: //engineering.purdue.edu/~qobi) OpenPGP_signature Description: OpenPGP digital signature
Re: release notes mentioning dropped support?
Hi Kernel team, Last release I sent out the message below and in the end we included something [1] in the Release Notes mentioning dropped support. Is there something like that worth mentioning this time around? Paul [1] https://www.debian.org/releases/bullseye/armel/release-notes/ch-information.en.html#no-longer-supported-hardware On 24-05-2021 06:55, Paul Gevers wrote: Hi Kernel team, I happen to own a QNAP (armel) and I spotted in the changelog that it's not going to be supported in bullseye. I was wondering, is that something that should be mentioned in the release notes? Obviously I don't mean because I own it, but I'm betting that support for particular hardware pieces has been dropped in the past too. I don't recall something like that in the buster release notes, but even if we didn't do it in the past, now could be a good moment to start if we think we should add it. Either way, I was wondering what would happen if I try to upgrade such a device. I'm *assuming* that the linux package would detect that the image is too big, but what would that leave me? A fully upgraded system with an old kernel, or is there any detection before any upgrade happens? For owners of such devices, is their only option to stay at buster? E.g. is there any chance in building a smaller custom kernel with less options enabled or is that impossible because nearly everything is build as module? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1032104: linux: ppc64el iouring corrupted read
Hi Otto, On 09-04-2023 03:54, Otto Kekäläinen wrote: Paul Gevers asked if the issues are gone as well with 6.1.12-1 (or later 6.1.y series versions, which will land in bookworm). That would be valuable information to know as well to exclude we do not have the issue as well in bookworm. Were you able to verify this? No, not yet. I have not done new uploads to experimental after the one I mentioned and linked above from March 18th. I don't understand this point, so I wonder if you understood my question. Maybe you did, but in my view no new uploads are needed to answer the bookworm question. The builds for unstable are passing because I forced the tests to run with regular fsync instead of native I/O in https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/fc1358087b39ac6520420c7bbae2e536bc86748d. I will test this again later but right now I don't want to do any extra uploads as the package is pending unblock and inclusion in Bullseye (Bug#1033811) and I don't want one single minor issue to jeopardize getting fixes for multiple major issues forward. My point was that I upgraded the ppc64el hosts where ci.debian.net runs the autopkgtests (so *not* the Debian build infrastructure). Since that upgrade, all tests on ci.debian.net *in every suite* have been using the bookworm (6.1.y) kernel. E.g. in unstable MariaDb 1:10.11.2-1 (so before the "Prevent mariadb-test-run from using native I/O on ppc64el and s390x due to Linux kernel bug" change) passed on 2023-03-26 10:39 but failed on the same day at 14:40. Is any of the failures on ppc64el before 1:10.11.2-2 and after 2023-03-09 from the same kernel issue we're discussing here (and thus the kernel still needs fixing in bookworm). Or are all the failures in that time-span from something else, and thus can we conclude that the kernel *probably* (no proof of course) got fixed between the version of the kernel in bullseye and the version in bookworm. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1033674: unblock: linux/6.1.20-1
Hi, On 29-03-2023 23:38, Cyril Brulebois wrote: unblock linux/6.1.20-1 ACK on the unblock/age-days 10 request for the d-i team, happy to build the installer against it. :) Done. In the passing I also took along the signed versions. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1032104: linux: ppc64el iouring corrupted read
On Mon, 6 Mar 2023 13:25:36 +1100 Daniel Black wrote: Since revering to linux-image-5.10.0-20 we've been free of the same errors. On ci.debian.net I upgraded all ppc64el hosts to bookworm on 2023-03-09. debian@ci-worker-ppc64el-04:~$ uname -a Linux ci-worker-ppc64el-04 6.1.0-5-powerpc64le #1 SMP Debian 6.1.12-1 (2023-02-15) ppc64le GNU/Linux Can you check if the errors are still the same (yes, there's still intermittent failures). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1015272: liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11
Hi, On 04-03-2023 17:19, Salvatore Bonaccorso wrote: So would agree, it make sense to update all remaining hosts and then look into it again in case the problem arise again. All but s390x are up-to-date and liburing testing works. I can't upgrade s390x because of bug #1031753 (which is worse for ci.d.n than this bug as far as I see). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1015272: liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11
Control: fixed -1 5.10.162-1 6.1.8-1 Hi, On Sun, 21 Aug 2022 21:35:58 +0200 Bastian Blank wrote: On Sun, Aug 21, 2022 at 07:42:10PM +0200, Guillem Jover wrote: > It seems like there was a regression with the latest stable update > that affects the autopkgtest for liburing. Reassigning. Please provide enough information to make isolating the problem possible. https://ci.debian.net/packages/libu/liburing/ is completely silent as there are not results for any of the failed runs. I decided to try again to see if I could collect more information. The test now passes on amd64, arm64, i386 and ppc64el, all running 5.10.162-1 and on riscv64 running unstable. However, on armhf, armel (amd64 kernel) and s390x (all running 5.10.158-2), it seems that the observation of brian is still true, some test in test-unit test segfaults, the test exits and hangs. @Guillem, do you see something more in the output below (armhf log) that may be of interest? And maybe spot something to run in isolation? When I try to destroy the lxc, that fails and in ps output I see this: root 3053528 0.0 0.0 5388 3072 ?Ss 03:34 0:00 [lxc monitor] /var/lib/lxc ci-061-8c60e21c root 3061512 0.0 0.0 0 0 ?Ss 03:35 0:00 \_ [systemd] debian 3110684 0.0 0.0 2140 192 ?DL 03:37 0:00 \_ ./iopoll-leak.t Note the "D" state. Reading the changelog of 5.10.162-1 I see io_uring mentioned a couple of times. Therefor I assume this bug is fixed in that version. Is it worth pursuing the real issue here? Paul root@ci-061-705317d0:/tmp/autopkgtest-lxc.v8gx_5j5/downtmp# cat test-unit-stdout + [ -n ] + CC=gcc + ./configure --cc=gcc prefix/usr includedir/usr/include libdir/usr/lib libdevdir /usr/lib relativelibdir mandir/usr/man datadir /usr/share stringop_overflow yes array_bounds yes __kernel_rwf_tyes __kernel_timespec yes open_how yes statx yes glibc_statx yes C++ yes has_ucontext yes NVMe uring command supportyes liburing_nolibc no CCgcc CXX g++ + make runtests make[1]: Entering directory '/tmp/autopkgtest-lxc.v8gx_5j5/downtmp/build.ksh/src/src' CC setup.ol CC queue.ol CC register.ol CC syscall.ol AR liburing.a ar: creating liburing.a RANLIB liburing.a CC setup.os CC queue.os CC register.os CC syscall.os CC liburing.so.2.3 make[1]: Leaving directory '/tmp/autopkgtest-lxc.v8gx_5j5/downtmp/build.ksh/src/src' make[1]: Entering directory '/tmp/autopkgtest-lxc.v8gx_5j5/downtmp/build.ksh/src/test' CC helpers.o CC 232c93d07b74.t CC 35fa71a030ca.t CC 500f9fbadef8.t CC 7ad0e4b2f83c.t CC 8a9973408177.t CC 917257daa0fe.t CC a0908ae19763.t CC a4c0b3decb33.t CC accept.t CC accept-link.t CC accept-reuse.t CC accept-test.t CC across-fork.t CC b19062a56726.t CC b5837bd5311d.t CC buf-ring.t CC ce593a6c480a.t CC close-opath.t CC connect.t CC cq-full.t CC cq-overflow.t CC cq-peek-batch.t CC cq-ready.t CC cq-size.t CC d4ae271dfaae.t CC d77a67ed5f27.t CC defer.t CC defer-taskrun.t CC double-poll-crash.t CC drop-submit.t CC eeed8b54e0df.t CC empty-eownerdead.t CC eventfd.t CC eventfd-disable.t CC eventfd-reg.t CC eventfd-ring.t CC exec-target.t CC exit-no-cleanup.t CC fadvise.t CC fallocate.t CC fc2a85cb02ef.t CC fd-pass.t CC file-register.t CC files-exit-hang-poll.t CC files-exit-hang-timeout.t CC file-update.t CC file-verify.t CC fixed-buf-iter.t CC fixed-link.t CC fixed-reuse.t CC fpos.t CC fsync.t CC hardlink.t CC io-cancel.t CC iopoll.t CC iopoll-leak.t CC io_uring_enter.t CC io_uring_passthrough.t CC io_uring_register.t CC io_uring_setup.t CC lfs-openat.t CC lfs-openat-write.t CC link.t CC link_drain.t CC link-timeout.t CC madvise.t CC mkdir.t CC msg-ring.t CC multicqes_drain.t CC nolibc.t CC nop-all-sizes.t CC nop.t CC openat2.t CC open-close.t CC open-direct-link.t CC open-direct-pick.t CC personality.t CC pipe-eof.t CC pipe-reuse.t CC poll.t CC poll-cancel.t CC poll-cancel-all.t CC poll-cancel-ton.t CC poll-link.t CC poll-many.t CC poll-mshot-update.t CC poll-mshot-overflow.t CC poll-ring.t CC poll-v-poll.t CC pollfree.t CC probe.t CC read-before-exit.t CC read-write.t CC recv-msgall.t CC
Re: Uploading linux (6.1.8-1)
Hi Salvatore, On 28-01-2023 17:48, Salvatore Bonaccorso wrote: [On a related note, if you, release team can unblock an let 6.1.7-1 still migrate to testing earlier that that, that would be welcome so we have several important fixes in already for testing. Though there is a regressions for i386. Help from people interested in i386 would be very welcome.] I've added the hint, but are these regressions in cryptsetup and libguestfs tracked somewhere? As a bare minimum I've CC'd their maintainers in this message so that they are aware, and I've added our i386 porter explicitly too. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1028451: 2nd DisplayPort doesn't get video
Hi, On 17-01-2023 07:14, Salvatore Bonaccorso wrote: I will bite the bullet (taking full responsibility for it if necessary, don't blame the other kernel team members) and ask here now the release team: Can we let linux 6.1.4-1 despite the RC bug reported, migrate to testing, so we can move on to 6.1.y? I have added the hints. linux should migrate in the 22:00 UTC britney run. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1020441: linux: autopkgtest needs update for new version of gcc-11
Source: linux Version: 5.19.6-1 Severity: serious X-Debbugs-CC: gcc...@packages.debian.org Tags: sid bookworm User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:gcc-11 Dear maintainer(s), With a recent upload of gcc-11 the autopkgtest of linux fails in testing when that autopkgtest is run with the binary packages of gcc-11 from unstable. It passes when run with only packages from testing (it also fails in testing). In tabular form: passfail gcc-11 from testing11.3.0-6 linux from testing5.19.6-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of gcc-11 to testing [1]. Of course, gcc-11 shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the test "only" fails on "Unexpected warning" and your package needs to update to the new situation. If this is a real problem in your package (and not only in your autopkgtest), the right binary package(s) from gcc-11 should really add a versioned Breaks on the unfixed version of (one of your) package(s). Note: the Breaks is nice even if the issue is only in the autopkgtest as it helps the migration software to figure out the right versions to combine in the tests. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=gcc-11 https://ci.debian.net/data/autopkgtest/testing/amd64/l/linux/26272813/log.gz I: Found quick flavour cloud-amd64 I: Build for 5.19.0-1-cloud-amd64 make: Entering directory '/usr/src/linux-headers-5.19.0-1-cloud-amd64' test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo >&2;\ echo >&2 " ERROR: Kernel configuration is invalid."; \ echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo >&2 ; \ /bin/false) warning: the compiler differs from the one used to build the kernel The kernel was built by: gcc-11 (Debian 11.3.0-5) 11.3.0 You are using: gcc-11 (Debian 11.3.0-6) 11.3.0 make -f /usr/src/linux-headers-5.19.0-1-common/scripts/Makefile.build obj=/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo \ single-build= \ need-builtin=1 need-modorder=1 gcc-11 -Wp,-MMD,/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo/.foo.o.d -nostdinc -I/usr/src/linux-headers-5.19.0-1-common/arch/x86/include -I./arch/x86/include/generated -I/usr/src/linux-headers-5.19.0-1-common/include -I./include -I/usr/src/linux-headers-5.19.0-1-common/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/usr/src/linux-headers-5.19.0-1-common/include/uapi -I./include/generated/uapi -include /usr/src/linux-headers-5.19.0-1-common/include/linux/compiler-version.h -include /usr/src/linux-headers-5.19.0-1-common/include/linux/kconfig.h -include /usr/src/linux-headers-5.19.0-1-common/include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-5.19.0-1-common/= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables -mharden-sls=all -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-stack-clash-protection -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -g -DMODULE -DKBUILD_BASENAME='"foo"' -DKBUILD_MODNAME='"foo"' -D__KBUILD_MODNAME=kmod_foo -c -o /tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo/foo.o
Re: linux migration to testing
Hi Ben, On 18-08-2022 23:09, Ben Hutchings wrote: For your info, s390x still fails: https://ci.debian.net/data/autopkgtest/testing/s390x/l/linux/24628411/log.gz Also for ppc64el. I noticed right after sending. These two are fixed by: https://salsa.debian.org/kernel-team/linux/-/commit/8d439f0beb3f97ff0e11dae3d70da33597642f9f Thanks a lot for the quick fix. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: linux migration to testing
Hi Ben, On 01-08-2022 23:09, Ben Hutchings wrote: On Mon, 2022-08-01 at 22:53 +0200, Paul Gevers wrote: On 01-08-2022 22:46, Ben Hutchings wrote: Could you please allow this version to enter testing despite the test failures? If you promise to fix it in the next upload. Yes, the fix is already in the git repo. For your info, s390x still fails: https://ci.debian.net/data/autopkgtest/testing/s390x/l/linux/24628411/log.gz Paul OpenPGP_signature Description: OpenPGP digital signature
Re: linux migration to testing
Hi Ben, On 01-08-2022 22:46, Ben Hutchings wrote: linux 5.18.14-1 is currently blocked from migration due to a test regression on some architectures. This is actually not a regression: there's a new test case, and it was defined wrongly for architectures other than amd64 and arm64. That should be fixed with the next upload, but I'd rather not go through another build/sign/build/wait cycle. Could you please allow this version to enter testing despite the test failures? If you promise to fix it in the next upload. hint added. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!
Hi all, Just a minor follow-up. I just had to restart one of my arm64 workers again. root@ci-worker-arm64-05:~# uname -a Linux ci-worker-arm64-05 5.10.0-15-arm64 #1 SMP Debian 5.10.120-1 (2022-06-09) aarch64 GNU/Linux Anything you want me to extract from the current logs? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!
Hi Diederik, On 22-06-2022 23:15, Diederik de Haas wrote: Hmm ...interesting. AFAIK that is a watchdog's task. And I was certain I saw sth about it as I've seen (a yet to be reported) an issue related to watchdog myself, hence why I remembered it. On Saturday, 4 December 2021 22:44:38 CEST Paul Gevers wrote: I noticed in the logs that *after* the reported kernel bug but before the actual hang, I see multiple instances of: watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [apt-get:2204621] and watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kcompactd0:40] on ci-worker-arm64-07. And here is where I saw it. (My watchdog issue doesn't cause a hang btw) That might be, but this doesn't result in a successful reboot (of the system, maybe you meant a reboot of the core?). If you have access to the host, APT should be able to tell you. Depends on what you mean with "the host". Our VM (our host) is provisioned by Huawei (their host). I have access to our host. root@ci-worker-arm64-02:~# apt list *qemu* --installed Listing... Done qemu-utils/stable-security,now 1:5.2+dfsg-11+deb11u2 arm64 [installed,automatic] N: There is 1 additional version. Please use the '-a' switch to see it Via sources.list.erb I found that "<%= node['debian_release'] %>-backports" gets enabled, which I assume results in Stable-backports. Correct, but currently we don't install anything from there. It appears that various tools get installed (but I don't see qemu mentioned (explicitly), but I do see 'virt-what' and the package description seems to indicate it may be useful to figure out detail of the VM. root@ci-worker-arm64-02:~# virt-what qemu root@ci-worker-arm64-02:~# virt-what --version 1.19 Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!
Hi Diederik, On 21-06-2022 23:19, Diederik de Haas wrote: I think that the install logs aren't that important (anymore) as the issue/ symptoms appear to be the same: - some swap action resulting in some failure - CPU gets stuck - watchdog triggers a reboot If the reboot would actually happen/finish, I wouldn't have problems of the hanging host. The issues I spotted required a manual reboot (and that's why I spotted them). How is swap configured on these devices? https://salsa.debian.org/ci-team/debian-ci-config/-/blob/master/cookbooks/basics/default.rb#L3 until line 11 Yeah, I _assumed_ as such, but assumptions can be dangerous ;-) Total ACK. Normally I scroll (hard) by the hardware listings as that rarely says anything to me. And I did that before too, but just now I made an important discovery. I *assumed* it was running on arm64 (native) hardware and was about to ask specifics about it and then I noticed this: Host bridge [0600]: Red Hat, Inc. QEMU PCIe Host bridge [1b36:0008] Qemu. Quite likely unrelated, but a while back I had an issue with qemu in building arm64 images: https://bugs.debian.org/988174 hmm, OK, right (I forgot that I knew this). I think it would be useful to know which qemu version(s) were used. Is there any way to know from inside the VM? If the issue does occur again, I think it would be useful to bring 'upstream' into the conversation. They likely can bring much more useful input into this then (f.e.) I could. Also, if upstream is made aware there is an issue (even infrequent), then they can make the most informed choice what to do with it. Ack. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!
Hi Diederik, On 21-06-2022 22:07, Diederik de Haas wrote: Do these errors still occur? Still with 5.10.103-1 or a later one? The last occurrence of a machine hang I had is from 5 May 2022, but I'm not sure if I checked if it was this same issue. Normally our kernels are up-to-date, but I don't recall what we had at the time. We have recommissioned our arm64 hosts, so the install logs are lost by now. Is it only on arm64 machines? Or is this just an example which also occurs on other arches? I'm pretty sure I haven't seen this on other arches, otherwise I'm sure I would have reported it to this bug. If it still occurs, then the likely only way to get a possible resolve is reporting it to upstream. 1.5 months is quite long for it to be gone, although, before that it was 2.5 months. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1013241: upgrade-reports: kernel upgrade 5.10.0.9 to 5.10.0.15
Control: reassign -1 src:linux Hi Norman, On 19-06-2022 21:48, NormanMurray wrote: Package: upgrade-reports Severity: normal X-Debbugs-Cc: nmur...@telusplanet.net With 5.10.0.9, randomsound worked well to keep /proc/sys/kernel/random/entropy_avail up at set point and /proc/sys/kernel/random/poolsize at 4096 With 5.10.0.15, randomsound did not work to keep /proc/sys/kernel/random/entropy_avail up at set point and /proc/sys/kernel/random/poolsize was set at 256 I down graded back to 5.10.0.9 I've seen the same drop in entropy_avail, but the changelog mentioned a lot of changes to random, so I interpreted that as being intended. I've reassigned to the linux source package, as they can confirm that this is not a bug, or treat it appropriately. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1008760: upgrade-reports: Mouse touchpad elantech broken edge scrolling after upgrade to bullseye
Control: reassign -1 src:linux Hi Umut, After asking around, the suspicion is that this is mostly likely due to the kernel, hence I'm reassigning to the linux source package. If this was wrong, the kernel maintainers can hopefully help to point where it should go. Paul On 31-03-2022 22:51, Umut Erdogan wrote: Package: upgrade-reports Severity: important Tags: upstream Hi debian maintainers! As by upgrading from buster to bullseye as also by using bullseye live image I have about 70% of touchpad width acting as edgescrolling area. I tried the debian 11 gnome and kde images and in both the same effect. At first I thought that the mouse would not work at all. But than I realized, that it just was in that area in scrolling mode. Only if I start to touch it at the remaining left area the mouse pointer worked as before. If I do so I can also swipe to the right most areas of the pad. That means that between buster and bullseye something got broken. Either from linux kernel or the firmware for elantech. So for now I switched back from bullseye to buster again until this gets fixed. Hope this happens until EOL of buster. Kind regards. Umut Erdogan -- System Information: Debian Release: 10.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: armhf, i386 Kernel: Linux 4.19.0-19-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled OpenPGP_signature Description: OpenPGP digital signature
Bug#1001001: closed by Salvatore Bonaccorso (Re: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!)
Hi all, On 20-02-2022 13:44, Paul Gevers wrote: Sad to say, but this week we had two hangs again. And this week another two. ci-worker-arm64-07 == Mar 26 10:15:55 ci-worker-arm64-07 kernel: kernel BUG at include/linux/swapops.h:204! Mar 26 10:15:55 ci-worker-arm64-07 kernel: Internal error: Oops - BUG: 0 [#1] SMP Linux kernel from before the last point release: Linux version 5.10.0-12-arm64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2> ci-worker-arm64-08 == Mar 25 22:13:44 ci-worker-arm64-08 kernel: kernel BUG at include/linux/swapops.h:204! Mar 25 22:13:44 ci-worker-arm64-08 kernel: Internal error: Oops - BUG: 0 [#1] SMP Paul OpenPGP_signature Description: OpenPGP digital signature
checking on bookworm freeze dates proposal
Dear colleagues, The Release Team would like to propose a bookworm freeze timeline. Don't worry, the timeline is a plan, if serious (timing) issues come up we will adapt. However, before making the plan public in a wider audience, we'd like to know from you if you already foresee clashes in timing from the kernel, gcc, binutils and glibc that we should take into account. Does the following timeline seem reasonable to you considering plans of your upstream? (the bullseye schedule + 2 years): 2023-01-12 - Milestone 1 - Transition and Toolchain freeze 2023-02-12 - Milestone 2 - Soft Freeze 2023-03-12 - Milestone 3 - Hard Freeze TBA- Milestone 4 - Full Freeze On behalf of the Release Team, Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001001: closed by Salvatore Bonaccorso (Re: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!)
Control: reopen -1 Control: found -1 5.10.84-1 Hi, Sad to say, but this week we had two hangs again. The one on ci-worker-arm64-06 had this: Feb 15 08:51:12 ci-worker-arm64-06 kernel: kernel BUG at include/linux/swapops.h:204! Feb 15 08:51:12 ci-worker-arm64-06 kernel: Internal error: Oops - BUG: 0 [#1] SMP root@ci-worker-arm64-06:~# uname -a Linux ci-worker-arm64-06 5.10.0-10-arm64 #1 SMP Debian 5.10.84-1 (2021-12-08) aarch64 GNU/Linux I'm upgrading the workers to the latest kernel now. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#983357: Bug# 983357: Why is it not mentioned in bullseye release notes / installation guide?
Hi Chuck, On 10-02-2022 01:34, Chuck Zmudzinski wrote: The problem as I see it is that the debian installer team is already aware of the problem and has been aware of it for over six months because #983357 is marked as affecting d-i. So I do not understand why #983357 is not included on the d-i bullseye errata page. Please assume good faith. I would go for the most obvious possibility, that while being aware of this issue, they just didn't think at the same time of the installation guide. Do I need to file another bug in addition to #983357 to get this problem listed on the bullseye (and also RC versions) d-i errata pages? This is the most establish process, so yes, I suggest you just go and follow that route, even without a reply here. Than it's documented in the right place [1]. Paul [1] unless I'm much mistaken, that would be against the installation-guide package, but it can be reassigned if I'm wrong. OpenPGP_signature Description: OpenPGP digital signature
Bug#983357: Bug# 983357: Why is it not mentioned in bullseye release notes / installation guide?
Hi, Subject: 983357: Why is it not mentioned in bullseye release notes / installation guide? For at least the release notes, because nobody asked the editors to include it. On 09-02-2022 21:04, Chuck Zmudzinski wrote: However, this is a well-known problem, but neither the Bullseye release notes nor the Bullseye installation guide mentions this known problem that has not yet been fixed. Is this issue also present after an upgrade? Then, if you have a proposal for the text to include, we can update the release notes. If this is *only* influencing the installation the installation guide might be a better place. Either way, I read the bug, but I don't have any knowledge on xen, so I feel uncomfortable proposing a text. If it should go into the release notes, please file a bug against the release-notes package. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!
Hi all, On 04-12-2021 22:44, Paul Gevers wrote: On Thu, 02 Dec 2021 13:44:15 +0100 Paul Gevers wrote: The last couple of days, two of the ci.debian.net arm64 workers became unresponsive. The systems were rebooted and I found the message in the journal pasted below. Of course the absence of these failures doesn't prove the bug is gone, but since upgrading our systems to 5.10.84-1 (on 20 December 2021), I have not seen this failure again. Maybe it's about time we close this bug and assume it's fixed in version 5.10.84-1? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1000481: upgrade-reports: Bullseye kernel hangs while initialising i915 gpu driver on old intel graphic chip
Control: reassign -1 src:linux 5.10.70-1 Hi Ben, On 23-12-2021 23:46, Ben Mueller wrote: On 12/23/21 9:05 PM, Paul Gevers wrote: I solved the problem by inserting a boot parameter "intel_iommu=off" to grub. With this parameter the kernel from bullseye linux-image-5.10.0-9-amd64 was able to boot properly and the graphic was fine on console and with x. The kernel from buster did not need this boot parameter. Which package has the driver you're using? I propose we reassign this package to that package for further investigation. The i915 gpu driver belongs to the kernel: linux-image-amd64. So, I reassign the bug report to the linux source package. I first saw the problem with version 5.10.70-1 (linux-image-5.10.0-9-amd64). Now I'm using version 5.10.84-1 (linux-image-5.10.0-10-amd64) which also works fine using the boot parameter "intel_iommu=off". Although I did not try this version in the default configuration without this boot parameter. It would help the Debian linux maintainers a lot if you could/want to try this with the latest version in bullseye. Just in case it got already fixed without going noticed inside Debian. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!
Hi, On Thu, 02 Dec 2021 13:44:15 +0100 Paul Gevers wrote: The last couple of days, two of the ci.debian.net arm64 workers became unresponsive. The systems were rebooted and I found the message in the journal pasted below. Please let me know if you need more info about these systems. As requested by carnil on IRC, let me try to add some things I checked. In contrast to the previous kernel bug I reported, this time the two machines that hang were testing different packages (syslog-ng being one of them) that succeed often on arm64. I noticed in the logs that *after* the reported kernel bug but before the actual hang, I see multiple instances of: watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [apt-get:2204621] and watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kcompactd0:40] on ci-worker-arm64-07. The other system (ci-worker-arm64-02) has watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [khugepaged:42] and watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [apt-get:4191233] I found a third system that had to be rebooted recently (ci-worker-arm64-08 on 18 November): watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [apt-get:3325970] and watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [python3:3275229] Although the journal is lost by now, we had more arm64 VM's hang; ci-worker-arm64-03 on 6 November 2021 Probably worth to mention, albeit hopefully unrelated, we had issues in the recent past (ci-worker-arm64-06 on 29 October 2021) with virtio_gpu so we blocked that module on all our workers from loading as we believe we don't need it. [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1202 (command 0x103) Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#995932: upgrade-reports: 3.0 USB ports unusable after upgrade
Control: reassign -1 src:linux Hi, On 08-10-2021 13:06, Lorenzo Iannuzzi wrote: > - Were there any problems with the system after upgrading? > USB 3.0 ports stop working at boot or as soon as I plug more than one device. > Devices attached to them are not recognized and not listed with lsusb. I had > no > problems before the upgrade. > On logs I found: > kernel: DMAR: DRHD: handling fault status reg 2 > kernel: DMAR: [DMA Read] Request device [04:00.0] PASID fault add > r fff7e000 [fault reason 06] PTE Read access is not set > kernel: xhci_hcd :04:00.0: WARNING: Host System Error > > I can avoid this issue adding "iommu=soft" to kernel parameters at boot. The signs of this issue hint towards the kernel, hence reassigning there. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#993978: thanks. Re: Bug#993978: fixed in linux 5.10.46-5
Hi, On Sat, 25 Sep 2021 22:02:07 + Debian FTP Masters wrote: > linux (5.10.46-5) bullseye-security; urgency=high [...] > * netfilter: nf_tables: initialize set before expression setup > (Closes: #993978) Just to confirm, this seems to have fixed the issue we saw on ci.debian.net as I haven't seen the hangs after updating the kernel and enabling the nftables autopkgtests again. Thanks. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#995014: linux/linux-signe-* break zfs-linux autopkgtest: None of the expected "capability" interfaces were detected
Source: linux, zfs-linux Control: found -1 linux/5.14.6-2 Control: found -1 zfs-linux/2.0.3-9 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of linux ans linux-signed-* the autopkgtest of zfs-linux fails in testing when that autopkgtest is run with the binary packages of linux or the singed variants from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing5.14.6-2 zfs-linux from testing2.0.3-9 all others from testingfrom testing I copied some of the output at the bottom of this report. I'm *suspecting* that the zfs-linux autopkgtest fails because the linux header are not in sync with the running kernel, but I'm by far not sure. Currently this regression is blocking the migration of linux and it's signed versions to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/z/zfs-linux/15487822/log.gz checking whether inode_owner_or_capable() exists... configure: error: *** None of the expected "capability" interfaces were detected. *** This may be because your kernel version is newer than what is *** supported, or you are using a patched custom kernel with *** incompatible modifications. *** *** ZFS Version: zfs-2.0.3-9 *** Compatible Kernels: 3.10 - 5.10 make: *** [debian/rules:230: override_dh_configure_modules_udeb_stamp] Error 1 OpenPGP_signature Description: OpenPGP digital signature
Bug#993978: linux-image-5.10.0-8-arm64: host hangs after some time of use
Hi, On 09-09-2021 09:37, Paul Gevers wrote: > All the architectures (amd64, arm64, ppc64el and s390x) that we have > experience these hangs. I'm absolutely not claiming that the root cause > is the same, but on buster we didn't experience this (our s390x host > never workerd on buster so I don't claim regression there), so there is > a pattern. However, the symptoms don't look completely the same everywhere. I checked some hosts now and apart from the ppc64el hang (which I was told to have a corrupted disk) the hosts that I checked had the autopkgtest of nftables started around the time of the last contact, but not finished suggesting the same root cause and related to the issue that carnil pointed out. Sep 04 00:19:05 ci-worker-s390x-01 debci[1007526]: nftables unstable/s390x started Sep 07 16:20:17 ci-worker-arm64-05 debci[3002806]: nftables unstable/arm64 started Sep 07 01:33:06 ci-worker-armel-01 debci[3140657]: nftables testing/armhf started Sep 06 20:21:53 ci-worker13 debci[4071985]: nftables testing/amd64 started For now, I've put nftables on our reject_list [1] (but there are still several tests pending). Paul [1] https://ci.debian.net/status/reject_list/ OpenPGP_signature Description: OpenPGP digital signature
Bug#993978: linux-image-5.10.0-8-arm64: host hangs after some time of use
Package: src:linux Version: 5.10.46-4 X-Debbugs-CC: debian...@lists.debian.org, a...@debian.org Severity: serious Justification: data loss Hi, As discussed over IRC, here is the bug report for one of the hanging arm64 hosts we have for ci.debian.net. Since the upgrade of our hosts to bullseye (days before the bullseye release) we have been experiencing random loss of access to our hosts. For the hosts that have some form of out-of-bound access, I tried to use that to see what's going on, but at AWS our account doesn't have the right permissions to use the serial port out-of-bound access and all other forms that I tried on all hosts that I have access to some for of out-of-bound access that didn't work. Since the bullseye release I've rebooted (externally triggered) already dozens of times and for those host that don't allow rebooting (AWS again) I had to reprovision the hosts. All the architectures (amd64, arm64, ppc64el and s390x) that we have experience these hangs. I'm absolutely not claiming that the root cause is the same, but on buster we didn't experience this (our s390x host never workerd on buster so I don't claim regression there), so there is a pattern. However, the symptoms don't look completely the same everywhere. On one of our arm64 hosts (we call ci-worker-armel-01) I found the attached logging as the final logs in the journal. Paul -- Package-specific info: ** Version: Linux version 5.10.0-8-arm64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-arm64 root=UUID=05ed5059-7820-4ab3-a3b7-37cc7dede2cf ro console=tty0 console=ttyS1,115200n8 quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information ** Loaded modules: cfg80211 rdma_ucm streebog_generic sha3_generic rmd320 rmd256 rmd160 rmd128 poly1305_generic poly1305_neon nhpoly1305_neon nhpoly1305 libpoly1305 michael_mic crc32_generic blake2b_generic twofish_generic twofish_common serpent_generic fcrypt cast6_generic cast5_generic cast_common camellia_generic blowfish_generic blowfish_common aes_arm64 ghash_generic gcm aegis128 aes_generic nf_log_ipv6 nf_conntrack_ftp nf_log_ipv4 nf_log_common nft_log nft_synproxy nf_synproxy_core nft_limit nft_objref nft_osf nfnetlink_osf nft_numgen nft_nat nf_conntrack_sip nft_quota nft_meta_bridge nf_flow_table_ipv4 nft_flow_offload nf_flow_table_inet nf_flow_table aes_ce_ccm cbc des_generic libdes ecb sha512_generic sha512_arm64 md4 af_packet_diag netlink_diag nft_masq nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv6 nft_reject nft_ct sctp_diag udp_diag raw_diag unix_diag iptable_mangle iptable_filter tcp_diag inet_diag 8021q garp mrp nfsd auth_rpcgss nfs_acl lockd grace sunrpc nf_conntrack_netlink xfrm_user xfrm_algo overlay algif_rng algif_skcipher algif_aead can_bcm sctp bluetooth jitterentropy_rng drbg ansi_cprng ecdh_generic rfkill ecc qrtr ns can_j1939 can_isotp can_raw can algif_hash af_alg xt_nat xt_addrtype iptable_nat dummy xt_multiport vhost_net vhost vhost_iotlb tap tun veth xt_conntrack ipt_REJECT nf_reject_ipv4 xt_CHECKSUM nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_counter xt_tcpudp nft_compat bridge stp llc nf_tables nfnetlink binfmt_misc nls_ascii nls_cp437 vfat fat dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce efi_pstore gf128mul libaes sha2_ce sha256_arm64 sha1_ce sbsa_gwdt acpi_ipmi ipmi_ssif dm_mod evdev ipmi_devintf ipmi_msghandler arm_cmn xgene_hwmon cppc_cpufreq ib_iser rdma_cm iw_cm ib_cm iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod bonding drm fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq crc32c_generic libcrc32c raid1 raid0 multipath linear md_mod mlx5_ib ib_uverbs ib_core mlx5_core nvme nvme_core igb t10_pi crc_t10dif mlxfw crct10dif_generic i2c_algo_bit ptp crct10dif_ce pps_core crct10dif_common i2c_designware_platform i2c_designware_core ** Network interface configuration: *** /etc/network/interfaces: auto lo iface lo inet loopback auto bond0 iface bond0 inet static address 139.178.85.85 netmask 255.255.255.254 gateway 139.178.85.84 bond-downdelay 200 bond-miimon 100 bond-mode 4 bond-updelay 200 bond-xmit_hash_policy layer3+4 bond-slaves enP7p1s0f0 enP7p1s0f1 dns-nameservers 147.75.207.207 147.75.207.208 iface bond0 inet6 static address 2604:1380:4111:f200::1 netmask 127 gateway 2604:1380:4111:f200:: auto bond0:0 iface bond0:0 inet static address 10.32.131.1 netmask 255.255.255.254 post-up route add -net 10.0.0.0/8 gw 10.32.131.0 post-down route del -net 10.0.0.0/8 gw 10.32.131.0 **
Re: Bug#992855: upgrade-reports: buster to bullseye, nvme logs make ttys messy.
Control: reassign -1 kernel
Hi,
Although as you said, it may be something else, as it's the kernel
logging this, I reassign to the kernel package, in the hope they are
more able to pinpoint where the problem lies.
Paul
On 24-08-2021 10:53, hox...@noramail.jp wrote:
> Package: upgrade-reports
> Severity: normal
>
> Dear maintainers,
>
> I've upgraded one of my buster 10.10 into bullseye 11.
>
> * Upgrading was mostly successfull.
>
> * As "buster" GNOME desktop it had almost no problem,
> and upgraded "bullseye" GNOME session seems fine for now.
>
> However, after rebooting the issue below stared on ttys.
>
> The machine has one NVMe and one SATA SSD (separated /home).
> The Entire system installed into LUKS2 encrypted LVM volumes.
> Mostly "main" packages except Intel microcode ("non-free").
>
> NVMe continual syslog messsage on terminal
> ==
>
> 1. kernel reports nvme RxErr related messages.
> 2. on any tty (even in rescue.target).
> 3. almost always (I/O access on NVMe seems to be a trigger).
>
> AFAIK, the reported device (WD BLACK NVMe) works fine
> and "nvme smartlog" have not reported any error in years.
>
> After bullseye upgrading kernel started this reporting on ttys.
>
> At the same time, "smartd" seems to have a minor systemd unit problem,
> and it also seems to start tracking NVMe just like below syslog sample
> (at the smartd starting log section).
> "smartd" in buster only monitored SATA SSD.
>
> I can not tell what actual package and/or whether that device caused this,
> posting this bug report to "upgrade-reports".
>
> Actual syslog (partially modified; DATETIME/HOSTNAME/SERIAL_NUMBER)
> -
>
> 1. Cold booted.
> 2. systemctl shows no error.
> 3. target was shifted during this log sampling (graphical, rescue, multiuser,
> graphical).
>
> syslog and my comments follow:
>
> Aug 23 19:50:27 hostname kernel: [0.289634] pci :01:00.0: [15b7:5002]
> type 00 class 0x010802
> Aug 23 19:50:27 hostname kernel: [0.289657] pci :01:00.0: reg 0x10:
> [mem 0xdf00-0xdf003fff 64bit]
> Aug 23 19:50:27 hostname kernel: [0.289691] pci :01:00.0: reg 0x20:
> [mem 0xdf004000-0xdf0040ff 64bit]
> Aug 23 19:50:27 hostname kernel: [0.718254] pci :01:00.0: Adding to
> iommu group 11
> Aug 23 19:50:27 hostname kernel: [1.020213] nvme nvme0: pci function
> :01:00.0
> Aug 23 19:50:27 hostname kernel: [1.029047] nvme nvme0: 4/0/0
> default/read/poll queues
> Aug 23 19:50:27 hostname kernel: [1.031074] nvme0n1: p1 p2 p3
>
> This NVMe contains EFI, /boot, and LUKS root filesystem except /home (in SATA
> SSD).
>
> Aug 23 19:50:27 hostname kernel: [ 15.626412] input: HDA Intel PCH
> HDMI/DP,pcm=7 as /devices/pci:00/:00:1f.3/sound/card0/input18
> Aug 23 19:50:27 hostname kernel: [ 15.626483] input: HDA Intel PCH
> HDMI/DP,pcm=8 as /devices/pci:00/:00:1f.3/sound/card0/input19
> Aug 23 19:50:27 hostname kernel: [ 15.626548] input: HDA Intel PCH
> HDMI/DP,pcm=9 as /devices/pci:00/:00:1f.3/sound/card0/input20
>
> The first NVMe RxErr reporting starts after the kernel dmesg (after sound
> subsystem).
>
> Aug 23 19:50:27 hostname kernel: [ 17.365057] pcieport :00:1b.0: AER:
> Corrected error received: :01:00.0
> Aug 23 19:50:27 hostname kernel: [ 17.365089] nvme :01:00.0: PCIe Bus
> Error: severity=Corrected, type=Physical Layer, (Receiver ID)
> Aug 23 19:50:27 hostname kernel: [ 17.365117] nvme :01:00.0: device
> [15b7:5002] error status/mask=0001/e000
> Aug 23 19:50:27 hostname kernel: [ 17.365142] nvme :01:00.0:[ 0]
> RxErr
>
> Then, on any tty (regardless the login status),
> it keep showing that messages like this.
> DATETIME was modified but kernel timing is the real log.
>
> Aug 23 19:51:16 hostname kernel: [ 70.416916] pcieport :00:1b.0: AER:
> Corrected error received: :01:00.0
> Aug 23 19:51:16 hostname kernel: [ 70.417029] nvme :01:00.0: PCIe Bus
> Error: severity=Corrected, type=Physical Layer, (Receiver ID)
> Aug 23 19:51:16 hostname kernel: [ 70.417145] nvme :01:00.0: device
> [15b7:5002] error status/mask=0001/e000
> Aug 23 19:51:16 hostname kernel: [ 70.417268] nvme :01:00.0:[ 0]
> RxErr
> Aug 23 19:51:17 hostname kernel: [ 71.693968] pcieport :00:1b.0: AER:
> Corrected error received: :01:00.0
> Aug 23 19:51:17 hostname kernel: [ 71.699967] nvme :01:00.0: PCIe Bus
> Error: severity=Corrected, type=Physical Layer, (Receiver ID)
> Aug 23 19:51:17 hostname kernel: [ 71.701511] nvme :01:00.0: device
> [15b7:5002] error status/mask=0001/e000
> Aug 23 19:51:17 hostname kernel: [ 71.703040] nvme :01:00.0:[ 0]
> RxErr
> Aug 23 19:51:19 hostname kernel: [ 73.739331] pcieport :00:1b.0: AER:
> Corrected
Bug#992798: initramfs-tools: please drop shellcheck autopkgtest
Source: initramfs-tools
Version: 0.140
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, shellch...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:shellcheck
Dear maintainer(s),
With a recent upload of shellcheck the autopkgtest of initramfs-tools
fails in testing when that autopkgtest is run with the binary packages
of shellcheck from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
shellcheck from testing0.7.2-2
initramfs-toolsfrom testing0.140
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of shellcheck to
testing [1]. Of course, shellcheck shouldn't just break your autopkgtest
(or even worse, your package), but in this case shellcheck just evolved.
Static analysis tools are intended to run on source code, while
autopkgtest is intended to run against installed packages, where source
code is in principle not relevant; we want to know whether the binary
packages, as provided in the Debian archive, work correctly. In our
opinion running this type of tools as integration tests in autopkgtest,
or even as build-time tests is Wrong™, and should not be done. (Having
them run in salsaci or equivalent is of course totally great.)
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=shellcheck
https://ci.debian.net/data/autopkgtest/testing/amd64/i/initramfs-tools/14767451/log.gz
autopkgtest [02:16:57]: test shellcheck: [---
In /usr/bin/unmkinitramfs line 115:
if [ -n "$dir" ]; then
^--^ SC2030: Modification of dir is
local (to subshell caused by (..) group).
In /usr/bin/unmkinitramfs line 130:
xcpio "$subarchive" "${dir:+$dir/main}" -i "$@"
^---^ SC2031: dir was
modified in a subshell. That change might be lost.
^--^ SC2031: dir was
modified in a subshell. That change might be lost.
In /usr/bin/unmkinitramfs line 133:
xcpio "$initramfs" "$dir" -i "$@"
^--^ SC2031: dir was modified in a
subshell. That change might be lost.
In /usr/share/initramfs-tools/init line 170:
[ "x$debug" = "xy" ] && log_output=/dev/kmsg
^---^ SC2268: Avoid x-prefix in comparisons as it
no longer serves a purpose.
Did you mean:
[ "$debug" = "y" ] && log_output=/dev/kmsg
In /usr/sbin/update-initramfs line 14:
if [ -n "$DPKG_MAINTSCRIPT_PACKAGE" ] && [ $# = 1 ] && [ x"$1" = x-u ]; then
^---^ SC2268:
Avoid x-prefix in comparisons as it no longer serves a purpose.
Did you mean:
if [ -n "$DPKG_MAINTSCRIPT_PACKAGE" ] && [ $# = 1 ] && [ "$1" = -u ]; then
In /usr/share/initramfs-tools/scripts/nfs line 42:
if [ "x${NFSROOT}" = "xauto" ]; then
^---^ SC2268: Avoid x-prefix in comparisons as it
no longer serves a purpose.
Did you mean:
if [ "${NFSROOT}" = "auto" ]; then
For more information:
https://www.shellcheck.net/wiki/SC2030 -- Modification of dir is local
(to ...
https://www.shellcheck.net/wiki/SC2031 -- dir was modified in a
subshell. T...
https://www.shellcheck.net/wiki/SC2268 -- Avoid x-prefix in
comparisons as ...
autopkgtest [02:17:03]: test shellcheck: ---]
OpenPGP_signature
Description: OpenPGP digital signature
Re: Bug#990140: upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10
Hi Bernd, Thanks for your report. On 21-06-2021 18:04, Bernd Breuer wrote: > after the recent upgrade to Buster 10.10 (including a kernel upgrade) the > command 'lxc-attach' (out of the Linux Container (lxc) set of commands), > typed in like > > "sudo lxc-attach " > > stopped working with the error message > > "lxc-attach: : lsm/lsm.c: lsm_process_label_set_at: 174 > Operation not permitted - Failed to set AppArmor label "unconfined" > > The conainer itself is starting, but apparmor related config lines like > > "lxc.apparmor.profile = unconfined" > > produce the above mentioned error, also on another machine after the > same packages upgrade. > > I expect lxc-attach to provide me a root shell in the running lxc-container > like it was the case before the recent upgrade. As we didn't upgrade lxc during the point release, this *may* be caused by the updated Linux kernel. What happens if you reboot using the previous kernel? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: release notes mentioning dropped support?
Hi all, Proposed text for the release notes attached. On 11-06-2021 21:47, Ben Hutchings wrote: > On Sat, 2021-06-12 at 03:01 +0900, Roger Shimizu wrote: >> On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso >> wrote: >>> On Thu, Jun 10, 2021 at 11:32:23AM +0200, Paul Gevers wrote: >>>> On 24-05-2021 06:55, Paul Gevers wrote: >>>>> I happen to own a QNAP (armel) and I spotted in the changelog that it's >>>>> not going to be supported in bullseye. I was wondering, is that >>>>> something that should be mentioned in the release notes? Obviously I >>>>> don't mean because I own it, but I'm betting that support for particular >>>>> hardware pieces has been dropped in the past too. I don't recall >>>>> something like that in the buster release notes, but even if we didn't >>>>> do it in the past, now could be a good moment to start if we think we >>>>> should add it. >> >> for armel, the limitation is by: >> https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35 >> >> And from the list in that file, below devices are not supported now. >> # QNAP TS-119/TS-219: 2097152 - 64 = 2097088 >> # D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported) >> # HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080 >> # QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080 >> >> I guess support for D-Link DNS-323 was dropped since buster, or earlier. > > Yes, since stretch. > >> >>>>> Either way, I was wondering what would happen if I try to upgrade such a >>>>> device. I'm *assuming* that the linux package would detect that the >>>>> image is too big, but what would that leave me? A fully upgraded system >>>>> with an old kernel, or is there any detection before any upgrade >>>>> happens? For owners of such devices, is their only option to stay at >>>>> buster? E.g. is there any chance in building a smaller custom kernel >>>>> with less options enabled or is that impossible because nearly >>>>> everything is build as module? >> >> The upgrade of kernel may succeed if /boot still have enough space, >> but reboot will fail because of the uboot configuration hard coded in >> those hardware. > [...] > > My understanding is that these devices load the kernel and initramfs > from fixed partitions on the on-board flash, not from the filesystem. > That's why the limits vary. flash-kernel is responsible for copying > the kernel and initramfs to these partitions. When the kernel is too> > Ben. > > large, it will report an error, which should abort the package > installation. > > To avoid this, users should keep the buster sources enabled and, before > upgrading, add an APT preferences file containing something like: > > Package: linux-image-marvell > Pin: release a=buster > Pin-Priority: 900 > > (not tested). Obviously this will only work as long as buster is > supported. As I own one of the unsupported devices, I intend to check if this works as intended and I'll not push the change until confirmed. If I'm really brave, I'll even check that flash-kernel errors out in the right way. Paul From a58174c17ad3b6cdb19f4e908428f0b0e8bf53c3 Mon Sep 17 00:00:00 2001 From: Paul Gevers Date: Sun, 13 Jun 2021 21:30:33 +0200 Subject: [PATCH] issues.dbk: unsupported armel hardware --- en/issues.dbk | 34 ++ 1 file changed, 34 insertions(+) diff --git a/en/issues.dbk b/en/issues.dbk index 805a15be..01184f9a 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -775,5 +775,39 @@ Environment=SYSTEMD_SULOGIN_FORCE=1 + + Hardware that's no longer supported + + Due to hardware limitations, it's no longer viable for Debian + to build the Linux kernel supporting a + number of armel based devices that were supported in + buster. The unsupported devices are: + + + + + QNAP TS-109/TS-209, TS-119/TS-219 and TS-409 + + + + + HP Media Vault mv2120 + + + + + Users of those platforms that wish to upgrade to bullseye + nevertheless should keep the buster APT sources enabled and, + before upgrading, add an APT preferences file containing + something like: + +Package: linux-image-marvell +Pin: release a=buster +Pin-Priority: 900 + + Obviously, the security support for this configuration will + end with the End Of Life of buster. + + -- 2.30.2 OpenPGP_signature Description: OpenPGP digital signature
Re: release notes mentioning dropped support?
Hi Roger, Thanks for the reply, On 11-06-2021 20:01, Roger Shimizu wrote: > On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso > wrote: >>> On 24-05-2021 06:55, Paul Gevers wrote: >>>> I happen to own a QNAP (armel) and I spotted in the changelog that it's >>>> not going to be supported in bullseye. I was wondering, is that >>>> something that should be mentioned in the release notes? Obviously I >>>> don't mean because I own it, but I'm betting that support for particular >>>> hardware pieces has been dropped in the past too. I don't recall >>>> something like that in the buster release notes, but even if we didn't >>>> do it in the past, now could be a good moment to start if we think we >>>> should add it. > > for armel, the limitation is by: > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35 > > And from the list in that file, below devices are not supported now. > # QNAP TS-119/TS-219: 2097152 - 64 = 2097088 > # D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported) > # HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080 > # QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080 > > I guess support for D-Link DNS-323 was dropped since buster, or earlier. I found this part earlier indeed. I was mostly wondering what we did in the past (maybe nothing) and if we should mention it. Reading below, I think we should. Do the other architectures have similar devices where support is dropped, or is this specific for armel? >>>> Either way, I was wondering what would happen if I try to upgrade such a >>>> device. I'm *assuming* that the linux package would detect that the >>>> image is too big, but what would that leave me? A fully upgraded system >>>> with an old kernel, or is there any detection before any upgrade >>>> happens? For owners of such devices, is their only option to stay at >>>> buster? E.g. is there any chance in building a smaller custom kernel >>>> with less options enabled or is that impossible because nearly >>>> everything is build as module? > > The upgrade of kernel may succeed if /boot still have enough space, > but reboot will fail because of the uboot configuration hard coded in > those hardware. > It's possible to update the uboot configuration, but if something is > wrong, it may brick the device, and no easy way to recover, except you > the device support serial or JTAG, and you have serial or JTAG cable. Ouch. This sounds bad. And nothing is protecting the user against this? Wouldn't it be possible/wise to have a check in preinst and abort the upgrade in such cases? To protect the user from ending in such a state? > Of course, remove some unused built-in module and rebuild own kernel > is always an option. Good to know. I wasn't sure if the Debian Linux kernel was built lean with everything available as modules. > But it need continuous effort, for stable / security kernel updates. Sure. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: release notes mentioning dropped support?
Hi Kernel team, I know everybody is busy, but friendly ping. On 24-05-2021 06:55, Paul Gevers wrote: > I happen to own a QNAP (armel) and I spotted in the changelog that it's > not going to be supported in bullseye. I was wondering, is that > something that should be mentioned in the release notes? Obviously I > don't mean because I own it, but I'm betting that support for particular > hardware pieces has been dropped in the past too. I don't recall > something like that in the buster release notes, but even if we didn't > do it in the past, now could be a good moment to start if we think we > should add it. > > Either way, I was wondering what would happen if I try to upgrade such a > device. I'm *assuming* that the linux package would detect that the > image is too big, but what would that leave me? A fully upgraded system > with an old kernel, or is there any detection before any upgrade > happens? For owners of such devices, is their only option to stay at > buster? E.g. is there any chance in building a smaller custom kernel > with less options enabled or is that impossible because nearly > everything is build as module? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988442: unblock: linux/5.10.40-1
Hi, On 01-06-2021 08:06, Salvatore Bonaccorso wrote: > The version is not 4 days in unstable, looks good to me to let it > migrate to testing (unless Cyril spotted issues in recent d-i tests). I'm still good to go. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#986728: upgrade-reports: boot fail until kernel 4.19.0.14
Control: reassign -1 linux Hi Lamome, Sorry it took so long to respond, but normally upgrade-reports as pseudo package in the bts is used for upgrade reports from the current (or just replaced) stable to the future (or just released) stable. I was confused by your "version numbers" of linux as I didn't recognize them from anywhere. However, I realized today that the linux version is different than the version of the linux package. I already pointed Salvatore at this bug over IRC long time ago, but I guess that got lost. It's a bit late, but let's reassign this bug to the package it probably belongs to. On 10-04-2021 14:56, Lamome Julien wrote: > Package: upgrade-reports > Severity: critical > Justification: breaks the whole system > > Dear Maintainer, > > >* What led up to the situation? > try to boot on kernel 4.19.0-14 or 4.19.0-16 >* What exactly did you do (or not do) that was effective (or > ineffective)? > update kernel via aptitude >* What was the outcome of this action? >* What outcome did you expect instead? > boot... > > The boot fail (freeze, block) just after "initrd" print on screen. > I notice that initrd of kernel ..14 and ..16 are bigger than other. > > Thank > > -- System Information: > Debian Release: 10.9 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > OpenPGP_signature Description: OpenPGP digital signature
release notes mentioning dropped support?
Hi Kernel team, I happen to own a QNAP (armel) and I spotted in the changelog that it's not going to be supported in bullseye. I was wondering, is that something that should be mentioned in the release notes? Obviously I don't mean because I own it, but I'm betting that support for particular hardware pieces has been dropped in the past too. I don't recall something like that in the buster release notes, but even if we didn't do it in the past, now could be a good moment to start if we think we should add it. Either way, I was wondering what would happen if I try to upgrade such a device. I'm *assuming* that the linux package would detect that the image is too big, but what would that leave me? A fully upgraded system with an old kernel, or is there any detection before any upgrade happens? For owners of such devices, is their only option to stay at buster? E.g. is there any chance in building a smaller custom kernel with less options enabled or is that impossible because nearly everything is build as module? Paul OpenPGP_signature Description: OpenPGP digital signature
inquiring for input to the release notes
Hi kernel team, As is custom in the final phases of the release, I'm asking you to think about issues that are worth mentioning in the release notes for bullseye from the perspective of the kernel. Feel free to reply to this e-mail, or, even better, to bts against the release-notes package if there's anything that comes to your mind. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: firmware-nonfree 20210208-1 upload
Hi On 08-03-2021 20:50, maximilian attems wrote: > so please unblock firmware-nonfree 20210208-3 Please file a bug, as this message has a high chance to get lost (the volume of traffic is rising) as it's not actionable right now. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: firmware-nonfree 20210208-1 upload
Hi maks, On 08-03-2021 19:46, maximilian attems wrote: > non-free packages were never considered key by Debian afair. https://udd.debian.org/cgi-bin/key_packages.yaml.cgi disagrees. The release team uses this list as the canonical source for the implementation for the automatic blocks. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: firmware-nonfree 20210208-1 upload
Hi, On 08-03-2021 10:39, maximilian attems wrote: > Tomorrow once firmware-nonfree has migrated 20210208-4 will be uploaded > with important small fixes to Raspberry Pi 4B and BananaPi M2 ultra and > BananaPi M3 supports. As all changes are quite small and current window > allows important fixes, I do not expect to need an unblock. Ehm, firmware-nonfree is a key package. If the upload didn't happen somewhere before 2-3-2021 it will require an unblock. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#970184: autopkgtest should gain arch support
Package: autopkgtest On Sun, 13 Sep 2020 19:21:11 +0100 Ben Hutchings wrote: > On Sat, 2020-09-12 at 15:59 +0100, Simon McVittie wrote: > > Please add "Restrictions: skip-not-installable" to the amd64-* tests, so > > that they will be skipped if the test-dependencies are uninstallable. > [...] > > I will do that, though what I really would like is for autopkgtests to > support an Architecture field for tests. I agree, so lets file a bug against the autopkgtest package to ask for such a feature. Paul signature.asc Description: OpenPGP digital signature
Arch qualification for buster: call for DSA, Security, toolchain concerns
Hi, [Note, this e-mail may look familiar as it is mostly copied over from the buster call, not much has changed, AFAICT]. As part of the interim architecture qualification for bullseye, we request that DSA, the security team, Wanna build, and the toolchain maintainers review and update their list of known concerns for bullseye release architectures. Summary of the current concerns and issues: * DSA have announced a blocking issue for armel and armhf (see below) * Concerns from DSA about ppc64el and s390x have been carried over from (stretch and) buster. * Concerns from the GCC maintainers about i386, armel, armhf, mips64el and mipsel have been carried over from (stretch and) buster. If the issues and concerns from you or your team are not up to date, then please follow up to this email (keeping debian-release@l.d.o in CC to ensure we are notified). Whilst porters remain ultimately responsible for ensuring the architectures are ready for release, we do expect that you / your team are willing to assist with clarifications of the concerns and to apply patches/changes in a timely manner to resolve the concerns. List of blocking issues by architecture === The following is a summary from the current architecture qualification table. armel/armhf: * Undesirable to keep the hardware running beyond 2020. armhf VM support uncertain. (DSA) - Source: [DSA Sprint report] - I was under the impression that this issue has been resolved (at least for armhf) by now, but we like a fresh statement on this. [DSA Sprint report]: https://lists.debian.org/debian-project/2018/02/msg4.html List of concerns for architectures == The following is a summary from the current architecture qualification table. * Concern for ppc64el and s390x: we are dependent on sponsors for hardware. (Raised by DSA; carried over from stretch and buster) * Concern for armel and armhf: only secondary upstream support in GCC (Raised by the GCC maintainer; carried over from stretch and buster) * Concern for mips, mips64el, mipsel and ppc64el: no upstream support in GCC; Debian carries patches in binutils and GCC that haven't been integrated upstream even after a long time. (Raised by the GCC maintainer; carried over from stretch and buster) Architecture status === These are the architectures currently being built for bullseye: * Intel/AMD-based: amd64, i386 * ARM-based: arm64, armel, armhf * MIPS-based: mipsel, mips64el * Other: ppc64el, s390x If the blocking issues cannot be resolved, affected architectures are at risk of removal from testing before bullseye is frozen. We are currently unaware of any new architectures likely to be ready in time for inclusion in bullseye. On behalf of the release team, Paul Gevers signature.asc Description: OpenPGP digital signature
Bug#958851: initramfs-tools: autopkgtest needs update for new version of shellcheck: SC2086: Double quote to prevent globbing and word splitting.
Source: initramfs-tools
Version: 0.136
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, shellch...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:shellcheck
Dear maintainer(s),
With a recent upload of shellcheck the autopkgtest of initramfs-tools
fails in testing when that autopkgtest is run with the binary packages
of shellcheck from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
shellcheck from testing0.7.1-1
initramfs-toolsfrom testing0.136
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of shellcheck to
testing [1]. Of course, shellcheck shouldn't just break your autopkgtest
(or even worse, your package), but it seems to me that the change in
shellcheck was intended and your package needs to update to the new
situation.
If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from shellcheck should really
add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=shellcheck
https://ci.debian.net/data/autopkgtest/testing/amd64/i/initramfs-tools/5145819/log.gz
autopkgtest [21:50:34]: test shellcheck: [---
In /usr/share/initramfs-tools/init line 227:
sleep $ROOTDELAY
^^ SC2086: Double quote to prevent globbing and
word splitting.
Did you mean:
sleep "$ROOTDELAY"
In /usr/sbin/update-initramfs line 176:
run-parts --arg=${version} --arg=${initramfs} \
^^ SC2086: Double quote to
prevent globbing and word splitting.
Did you mean:
run-parts --arg="${version}" --arg=${initramfs} \
In /usr/share/initramfs-tools/scripts/functions line 393:
logsave -a -s $FSCK_LOGFILE fsck $spinner $force $fix -V -t
"$TYPE" "$DEV"
^^ SC2086:
Double quote to prevent globbing and word splitting.
Did you mean:
logsave -a -s $FSCK_LOGFILE fsck $spinner "$force" $fix -V -t
"$TYPE"
"$DEV"
In /usr/share/initramfs-tools/scripts/functions line 398:
logsave -a -s $FSCK_LOGFILE fsck $spinner $force $fix -T -t
"$TYPE" "$DEV"
^^ SC2086:
Double quote to prevent globbing and word splitting.
Did you mean:
logsave -a -s $FSCK_LOGFILE fsck $spinner "$force" $fix -T -t
"$TYPE"
"$DEV"
For more information:
https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent
globbing ...
autopkgtest [21:50:38]: test shellcheck: ---]
signature.asc
Description: OpenPGP digital signature
Re: Bug#950551: libgcc1: after libgcc1 upgrade, can't unlock luks partition at boot
Control: retitle -1 libgcc1 should add a Breaks on cryptsetup-initramfs Hi Matthias, initramfs-tools maintainers, > Am Montag, den 03.02.2020, 18:59 +0100 schrieb Matthias Klose: > > I'm fine to add some breaks if required. cryptsetup-initramfs version 2:2.2.2-3 already worked around the issue and has migrated to testing. Adding a Breaks on cryptsetup-initramfs << 2:2.2.2-3~ (IIAC) will prevent this specific issue. > This gets now fixed directly in initramfs-tools: > > https://salsa.debian.org/kernel-team/initramfs-tools/commit/f2ac13e8881f975b062a56050ceda85ef9ccc015 > > See also #950254 > > So I guess as soon as that is uploaded, libgcc1 should then Breaks: the > older versions. I think it makes sense to add that Breaks for safety as well, once that fix gets uploaded, but do we need to block the migration of gcc-10 until that happens? If so, can that upload happen soon? Paul signature.asc Description: OpenPGP digital signature
Bug#943876: linux breaks systemtap autopkgtest: error: this statement may fall through [-Werror=implicit-fallthrough=]
Source: linux, systemtap Control: found -1 linux/5.3.7-1 Control: found -1 systemtap/4.1-10 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainers, With a recent upload of linux the autopkgtest of systemtap fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing5.3.7-1 systemtap from testing4.1-10 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of linux to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from linux/5.3.7-1. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/s/systemtap/3297749/log.gz autopkgtest [17:24:37]: test build-hello: [--- WARNING: Kernel function symbol table missing [man warning::symbols] Pass 1: parsed user script and 476 library scripts using 95952virt/82936res/7544shr/75500data kb, in 230usr/50sys/280real ms. Pass 2: analyzed script: 1 probe, 1 function, 0 embeds, 0 globals using 97536virt/84640res/7672shr/77084data kb, in 10usr/0sys/9real ms. Pass 3: translated to C into "/tmp/stapKkW4rr/hello_src.c" using 97536virt/84640res/7672shr/77084data kb, in 0usr/0sys/0real ms. In file included from /usr/share/systemtap/runtime/linux/print.c:18, from /usr/share/systemtap/runtime/print.c:17, from /usr/share/systemtap/runtime/runtime_context.h:22, from /tmp/stapKkW4rr/hello_src.c:56: /usr/share/systemtap/runtime/vsprintf.c: In function ‘_stp_vsnprintf’: /usr/share/systemtap/runtime/vsprintf.c:641:35: error: this statement may fall through [-Werror=implicit-fallthrough=] 641 | flags |= STP_LARGE; | ~~^~~~ /usr/share/systemtap/runtime/vsprintf.c:642:21: note: here 642 | case 'x': | ^~~~ /usr/share/systemtap/runtime/vsprintf.c:828:10: error: this statement may fall through [-Werror=implicit-fallthrough=] 828 |flags |= STP_LARGE; |~~^~~~ /usr/share/systemtap/runtime/vsprintf.c:829:3: note: here 829 | case 'x': | ^~~~ cc1: all warnings being treated as errors make[2]: *** [/usr/src/linux-headers-5.3.0-1-common/scripts/Makefile.build:285: /tmp/stapKkW4rr/hello_src.o] Error 1 make[1]: *** [/usr/src/linux-headers-5.3.0-1-common/Makefile:1639: _module_/tmp/stapKkW4rr] Error 2 make: *** [/usr/src/linux-headers-5.3.0-1-common/Makefile:179: sub-make] Error 2 WARNING: kbuild exited with status: 2 Pass 4: compiled C into "hello.ko" in 11380usr/1860sys/13245real ms. Pass 4: compilation failed. [man error::pass4] Tip: /usr/share/doc/systemtap/README.Debian should help you get started. autopkgtest [17:24:51]: test build-hello: ---] signature.asc Description: OpenPGP digital signature
bug 864320: multiple critical problems booting
clone 864320 -1 reassign -1 initramfs-tools retitle -1 update-initramfs silently failed to change \ initrd/conf/conf.d/cryptroot > 4. > > one of my goals is to set up a new drive as a backup -- with > accessibility fixed as much as possible -- in case there are > problems booting to my main drive. however, this is > problematic. > > with or without this: > > i have had many, many, runins with update-initramfs. i > finally settled on something that seemed to work: > > # of course i looked for error messages > update-initramfs -u -k all && > echo update-initramfs returned normal exit code. like i believe that. > # fixme update-grub should, but does not, create /boot/grub/grub.cfg > update-grub > # we do either grub-install or dpkg-reconfigure > # dpkg-reconfigure says what future upgrades should install to > echo enter argument to grub-install like /dev/sdb and sacrifice a goat: > grub-install `line` > > maybe this is totally wrong. i am an ordinary person just > trying to get my computer to work. i tried dpkg-reconfigure > grub-pc also. > > in order to put in the brittle, hardcoded partition syntax, > i did the above. > > but guess what? update-initramfs silently failed to change > initrd/conf/conf.d/cryptroot! > > in the past it silently failed to create it at all, so this > is progress! > > bug fix: don't silently fail > bug fix: don't fail to write a file > bug fix: don't fail to update a file > bug fix: don't make user edit his or her initrd > bug fix: don't make user have to debug @initramfs-tools maintainers: The above report has been lingering in a long multibug report against the base package. It may be worth investigating. Paul signature.asc Description: OpenPGP digital signature
Bug#928618: linux: autopkgtest regression
Source: linux Version: 4.19.37-1 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of linux the autopkgtest of linux fails in testing when that autopkgtest is run with the binary packages of linux from unstable. It passes when run with only packages from testing. In tabular form: passfail linux from testing4.19.37-1 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is a reason for blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from linux/4.19.37-1. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=linux https://ci.debian.net/data/autopkgtest/testing/amd64/l/linux/2340029/log.gz autopkgtest [03:11:55]: test python: [--- I: Running pycodestyle... debian/bin/gencontrol_signed.py:303:30: E131 continuation line unaligned for hanging indent debian/bin/gencontrol_signed.py:308:36: E202 whitespace before '}' E: pycodestyle detected problems I: Running pyflakes... debian/bin/abiupdate.py:139: local variable 'e' is assigned to but never used E: pyflakes detected problems I: Running debian_linux.debian unit tests... . -- Ran 21 tests in 0.002s OK autopkgtest [03:11:57]: test python: ---] signature.asc Description: OpenPGP digital signature
Re: release-notes for buster and the kernel
Dear kernel team, I hope I didn't miss your response, but AFAICT the request below is still open. A reply like "no, there is no need for any specifics" is also very welcome. On 06-04-2019 21:50, Paul Gevers wrote: > Dear kernel team, > > I am reaching out to you as I help to coordinate this release's > release-notes. In most release-notes in the past, there have been words > about the kernel. For buster, is there anything that is worth mentioning > in the notes? > > We already mention that AppArmor is pulled in via Recommends. In case > you want to check what's there, you can find the current draft here: > https://www.debian.org/releases/buster/releasenotes > and the source of it here (merge requests welcome): > https://salsa.debian.org/ddp-team/release-notes/ Paul signature.asc Description: OpenPGP digital signature
release-notes for buster and the kernel
Dear kernel team, I am reaching out to you as I help to coordinate this release's release-notes. In most release-notes in the past, there have been words about the kernel. For buster, is there anything that is worth mentioning in the notes? We already mention that AppArmor is pulled in via Recommends. In case you want to check what's there, you can find the current draft here: https://www.debian.org/releases/buster/releasenotes and the source of it here (merge requests welcome): https://salsa.debian.org/ddp-team/release-notes/ Paul signature.asc Description: OpenPGP digital signature
Bug#697029: [ilk] using GNOME 3 makes computer sluggish after a few minutes
Hi, On Sun, 24 Feb 2013 07:08:14 + Ben Hutchings wrote: > "Graphics rendering may be very slow on Intel 'Ironlake M' GPUs (PCI > ID 8086:0046) when an IOMMU (VT-d) is enabled. The IOMMU > functionality can be disabled for the GPU by adding the kernel > parameter 'intel_iommu=igfx_off'." This bug is marked as affecting the release-notes. I don't think this is still relevant for stretch or buster? If not, I'll like to remove the "affects", to not clutter the release-notes bug list. Paul PS: please CC me, I am not subscribed to this bug. signature.asc Description: OpenPGP digital signature
Bug#658759: [kirkwood] squeeze-backports kernel fails to boot on SheevaPlug
Hi all, On Fri, 24 Aug 2012 09:44:47 +0100 Ian Campbell wrote: > On Fri, 2012-08-24 at 00:31 -0700, Jonathan Nieder wrote: > > Any ideas for how to word a hint about this for > > the wheezy release-notes? > > Hrm, how about: > > The version of u-boot shipped from the factory on many > kirkwood(???) devices, as well as u-boot shipped in versions of > Debian prior to Wheezy, contain a bug (#658759) which renders > them unable to boot kernel versions 3.2(???) or newer. This > includes the kernel in Wheezy. > > Users are advised to upgrade u-boot before upgrading their > kernel. XXX link to suitable documentation? > http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html > and similar? > > (??? fact needs checking). This bug is marked as affecting the release-notes. I don't think this is relevant for stretch or buster anymore? If not, I'll like to remove the "affects", to not clutter the release-notes bug list. Paul PS: please CC me, I am not subscribed to this bug. signature.asc Description: OpenPGP digital signature
Bug#827309: linux-image-3.16.0-4-kirkwood: latest upgrade made WiFi unstable
Hi On 06/24/16 22:18, Paul Gevers wrote: >> But just to be honest and complete, also not all traffic for this NAS is >> going via the dongle anymore, as it is now also connect via UTP wire. >> Furthermore, due to its location, it is also missing the audio USB. > > Do you think it is worth while and/or needed to check with the old setup > and the old kernel? Yesterday, I finally moved my NAS back to the old situation, with both the WiFi and audio dongle attached, and even with the older kernel image, the issue is there. So the issue doesn't seem to be caused by the specific upgrade anymore. No clue how to proceed, but if this bug report is in-actionable for you, I suggest you close it. Paul signature.asc Description: OpenPGP digital signature
Bug#827309: linux-image-3.16.0-4-kirkwood: latest upgrade made WiFi unstable
Hi, On 19-06-16 19:08, Paul Gevers wrote: > I reverted to version 3.16.7-ckt25-1 on Thursday, and haven't seen the > issue since. Still true, no issues so far. > But just to be honest and complete, also not all traffic for this NAS is > going via the dongle anymore, as it is now also connect via UTP wire. > Furthermore, due to its location, it is also missing the audio USB. Do you think it is worth while and/or needed to check with the old setup and the old kernel? Paul signature.asc Description: OpenPGP digital signature
Bug#827309: linux-image-3.16.0-4-kirkwood: latest upgrade made WiFi unstable
Hi, On 16-06-16 20:06, Paul Gevers wrote: > I am going to try if installing the previous kernel actually helps and > report back in one or two days. I reverted to version 3.16.7-ckt25-1 on Thursday, and haven't seen the issue since. Jun 16 20:27:44 fuji sudo: paul : TTY=pts/0 ; PWD=/home/paul ; USER=root ; COMMAND=/usr/bin/dpkg -i /var/cache/apt/archives/linux-image-3.16.0-4-kirkwood_3.16.7-ckt25-1_armel.deb But just to be honest and complete, also not all traffic for this NAS is going via the dongle anymore, as it is now also connect via UTP wire. Furthermore, due to its location, it is also missing the audio USB. Paul signature.asc Description: OpenPGP digital signature
Bug#827309: linux-image-3.16.0-4-kirkwood: latest upgrade made WiFi unstable
Hi, Maybe some more useful information: After my latest reboot, just before the already reported error log line occurs, the following can be found in the syslog: Jun 16 00:01:30 fuji wpa_supplicant[386]: wlan0: CTRL-EVENT-DISCONNECTED bssid=4c:09:d4:98:fb:c1 reason=4 locally_generated=1 Jun 16 00:01:30 fuji kernel: [10386.670721] cfg80211: Calling CRDA for country: NL Jun 16 00:01:38 fuji dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10 Jun 16 00:01:48 fuji dhclient: No DHCPOFFERS received. Jun 16 00:01:48 fuji dhclient: No working leases in persistent database - sleeping. Jun 16 00:02:01 fuji kernel: [10417.449181] ieee80211 phy0: rt2800usb_fill_rxdone: Error - Bad frame size 12349, forcing to 0 Jun 16 00:02:01 fuji kernel: [10417.457797] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840 Jun 16 00:02:40 fuji kernel: [10457.218806] ieee80211 phy0: rt2800usb_fill_rxdone: Error - Bad frame size 12349, forcing to 0 Jun 16 00:02:40 fuji kernel: [10457.227412] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840 Jun 16 00:04:30 fuji kernel: [10567.348166] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x1004 with error -110 I am going to try if installing the previous kernel actually helps and report back in one or two days. Paul signature.asc Description: OpenPGP digital signature
Bug#827309: linux-image-3.16.0-4-kirkwood: latest upgrade made WiFi unstable
Control: tag -1 -moreinfo On 14-06-16 23:16, Ben Hutchings wrote: > What was the previous installed version? (/var/log/dpkg.log should > show this.) 2016-06-05 10:31:50 upgrade linux-image-3.16.0-4-kirkwood:armel 3.16.7-ckt25-1 3.16.7-ckt25-2 Paul signature.asc Description: OpenPGP digital signature
Bug#827309: linux-image-3.16.0-4-kirkwood: latest upgrade made WiFi unstable
Package: linux-image-3.16.0-4-kirkwood Version: 3.16.7-ckt25-2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Since a couple of days, my QNAP NAS TS-219 is dropping its WiFi connection, after which I can only reboot the system to get it back (as far as I know). Although I am not sure at all, this seems to coincide with my update of the linux-image* package, and hence the report here. Please reassign if you know where this belongs or feel free to close it if it really doesn't make sense. I updated the image on 2016-06-05 around 10:27:07 and am running that now (although I don't really remember if I rebooted immediately): paul@fuji ~ $ uname -a Linux fuji 3.16.0-4-kirkwood #1 Debian 3.16.7-ckt25-2 (2016-04-08) armv5tel GNU/Linux My WiFi dongle is connected via USB (the first device): paul@fuji ~ $ lsusb Bus 001 Device 004: ID 1737:0079 Linksys WUSB600N v2 Dual-Band Wireless-N Network Adapter [Ralink RT3572] Bus 001 Device 003: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub In the syslog I see the following error messages about every 50 seconds, which doesn't seem to appear when I still have a connection: Jun 14 21:15:04 fuji kernel: [177628.821851] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x101c with error -110 Which for the very first time after reboot that this appears may be right after the following items: Jun 13 00:36:05 fuji kernel: [16895.965179] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -75 The first time I can now spot this in my syslog is on 2016-06-08 00:04:35, unfortunately, my syslog before 2016-06-06 06:25:11 is lost. Until last week I never had any issues with the WiFi since I installed Debian on this NAS, which was somewhere in May 2014. At first, I thought the issue was cause by OOM of my device (no idea yet where that is caused by) but since my last reboot, there were no OOM issues and still the WiFi was dropped after it worked correctly initially after the reboot. Please let me know if I can help with more information. Paul paul@fuji ~ $ lsmod Module Size Used by ctr 3445 0 ccm 7495 0 nfsd 268736 13 auth_rpcgss49634 1 nfsd oid_registry2097 1 auth_rpcgss nfs_acl 2313 1 nfsd nfs 173062 0 lockd 75585 2 nfs,nfsd fscache50659 1 nfs sunrpc228119 19 nfs,nfsd,auth_rpcgss,lockd,nfs_acl arc41597 2 snd_usb_audio 106714 2 snd_usbmidi_lib18589 1 snd_usb_audio snd_hwdep 5615 1 snd_usb_audio snd_rawmidi17852 1 snd_usbmidi_lib rt2800usb 16484 0 rt2x00usb 8132 1 rt2800usb rt2800lib 72043 1 rt2800usb rt2x00lib 34793 3 rt2x00usb,rt2800lib,rt2800usb mac80211 425587 3 rt2x00lib,rt2x00usb,rt2800lib hid_generic 775 0 snd_seq_device 5065 1 snd_rawmidi cfg80211 354796 2 mac80211,rt2x00lib crc_ccitt 1141 1 rt2800lib snd_pcm67511 1 snd_usb_audio rfkill 15860 2 cfg80211 usbhid 40190 0 snd_timer 16545 1 snd_pcm snd48924 11 snd_usb_audio,snd_hwdep,snd_timer,snd_pcm,snd_rawmidi,snd_usbmidi_lib,snd_seq_device hid81789 2 hid_generic,usbhid soundcore 4589 1 snd ehci_orion 3062 0 ehci_hcd 55579 1 ehci_orion marvell 6201 0 sg 19402 0 usbcore 167263 7 snd_usb_audio,rt2x00usb,rt2800usb,snd_usbmidi_lib,ehci_hcd,ehci_orion,usbhid mvmdio 2960 0 usb_common 1850 1 usbcore orion_wdt 6053 0 mv643xx_eth26377 0 ahci 14305 0 of_mdio 2356 2 mvmdio,mv643xx_eth libahci21216 1 ahci libphy 23208 4 marvell,mvmdio,of_mdio,mv643xx_eth mv_cesa11258 0 evdev 9200 1 loop 15208 0 gpio_keys 7786 0 ipv6 314732 70 autofs425934 2 ext4 452540 4 mbcache 5586 1 ext4 jbd2 80275 1 ext4 raid1 27848 3 md_mod103619 4 raid1 sd_mod 35718 11 crc_t10dif 984 1 sd_mod crct10dif_generic 1234 1 crct10dif_common1154 2 crct10dif_generic,crc_t10dif sata_mv26340 9 libata150715 3 ahci,sata_mv,libahci scsi_mod 165063 3 sg,libata,sd_mod -BEGIN PGP SIGNATURE- Version: GnuPG v1
Bug#735202: speakup freezes system when trying to paste
On 07-04-14 19:30, Jarek Czekalski wrote: If there was a place to get deb files for 3.12, the rest should be easy. http://snapshot.debian.org/ Paul signature.asc Description: OpenPGP digital signature
