Bug#1013249: virtio_ring: module verification failed: signature and/or required key missing - tainting kernel
Package: src:linux Version: 5.18.5-1 Severity: normal User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Dear Maintainer, I do not expect a kernel module in a genuine Debian kernel package taints a kernel. But I see the following message in dmesg on QEMU RISCV64 virt machine: [8.038025] virtio_ring: module verification failed: signature and/or required key missing - tainting kernel The QEMU is running on Debian/testing amd64 with the following version: $ dpkg-query -W | fgrep qemu-system-misc qemu-system-misc1:7.0+dfsg-7 The QEMU is started as follows: qemu-system-riscv64 -machine virt,aclint=on,aia=none -m 4G -smp 4 -bios /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_jump.elf -kernel /usr/lib/u-boot/qemu-riscv64_smode/uboot.elf -append "console=ttyS0 rw root=/dev/vda1" -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -drive if=virtio,file=debian-sid-riscv64.qcow2,index=0,format=qcow2,discard=unmap,detect-zeroes=unmap -- Package-specific info: ** Version: Linux version 5.18.0-2-riscv64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-20) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP Debian 5.18.5-1 (2022-06-16) ** Command line: root=UUID=031c42a9-74c5-4b38-8e78-87d5f1141c24 rw noquiet root=/dev/vda1 net.ifnames=0 consoleblank=0 rw ** Tainted: E (8192) * unsigned module was loaded ** Kernel log: [0.00] Linux version 5.18.0-2-riscv64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.2.0-20) 11.2.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP Debian 5.18.5-1 (2022-06-16) [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 [0.00] Machine model: riscv-virtio,qemu [0.00] efi: UEFI not found. [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a node at [mem 0x8020-0x00017fff] [0.00] NUMA: NODE_DATA [mem 0x17ffedbc0-0x17ffeefff] [0.00] Zone ranges: [0.00] DMA32[mem 0x8020-0x] [0.00] Normal [mem 0x0001-0x00017fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x8020-0x00017fff] [0.00] Initmem setup node 0 [mem 0x8020-0x00017fff] [0.00] On node 0, zone DMA32: 512 pages in unavailable ranges [0.00] SBI specification v0.3 detected [0.00] SBI implementation ID=0x1 Version=0x1 [0.00] SBI TIME extension detected [0.00] SBI IPI extension detected [0.00] SBI RFENCE extension detected [0.00] SBI SRST extension detected [0.00] SBI HSM extension detected [0.00] riscv: base ISA extensions acdfhim [0.00] riscv: ELF capabilities acdfim [0.00] percpu: cpu 0 has no node -1 or node-local memory [0.00] percpu: Embedded 27 pages/cpu s72744 r8192 d29656 u110592 [0.00] pcpu-alloc: s72744 r8192 d29656 u110592 alloc=27*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Fallback order for Node 0: 0 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 1031688 [0.00] Policy zone: Normal [0.00] Kernel command line: root=UUID=031c42a9-74c5-4b38-8e78-87d5f1141c24 rw noquiet root=/dev/vda1 net.ifnames=0 consoleblank=0 rw [0.00] Unknown kernel command line parameters "noquiet", will be passed to user space. [0.00] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) [0.00] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:on, heap free:off [0.00] software IO TLB: mapped [mem 0xfb73a000-0xff73a000] (64MB) [0.00] Memory: 2079280K/4192256K available (7539K kernel code, 5095K rwdata, 4096K rodata, 2456K init, 426K bss, 252764K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] ftrace: allocating 28720 entries in 113 pages [0.00] ftrace: allocated 113 pages with 4 groups [0.00] trace event string verifier disabled [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4. [0.00] Rude variant of Tasks RCU enabled. [0.00] Tracing variant of Tasks RCU enabled. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 [0.00] riscv-intc: 64 local interrupts mapped [0.00] plic: plic@c00: mapped 53 interrupts with 4 handlers for 8 contexts. [0.00] riscv_timer_init_dt: Registering clocksource cpuid
Bug#977647: 5.10.4 Debian kernel does not boot on amd64 with btrfs rootfs
Control: close -1 >> The severity seems now minor. >> It has still the mysterious dmesg error on tpm as follows. >> The full dmesg log is attached. > > Do you still have the issues? Otherwise let's close this bug. No. Let's close this. Ryutaroh
Bug#996752: clang-13: -static-pie AND -fuse-ld=lld produce unusable a.out
Control: clone -1 -2 Control: reassign -2 clang-12 1:12.0.1-12 Control: retitle -2 -static-pie AND -fuse-ld=lld-12 produce unusable a.out The same symptom appears with clang-12 -static-pie AND -fuse-ld=lld-12 Best regards, Ryutaroh
Bug#996752: clang-13: -static-pie AND -fuse-ld=lld produce unusable a.out
Control: tags -1 + upstream Control: forwarded -1 https://bugs.llvm.org/show_bug.cgi?id=52201 From: Sylvestre Ledru > It seems an upstream issue, not a packaging issue. > Could you please report this bug upstream? Thank you for your quick response. I brought this to the upstream as above. Ryutaroh
Bug#996752: clang-13: -static-pie AND -fuse-ld=lld produce unusable a.out
Package: clang-13 Version: 1:13.0.0-5 Severity: normal X-Debbugs-Cc: 996...@bugs.debian.org Dear Maintainer, The following transcript should be self-explanatory. gcc-11 also procudes unusable a.out with -static-pie as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996659 This issue could be a duplicate of #996659 but I am unsure. This could also be an issue of lld-13 instead of clang-13... $ clang-13 -g -static-pie -fPIE hello.c $ ./a.out hello world! $ clang-13 -g -fuse-ld=lld -static-pie -fPIE hello.c $ ./a.out Segmentation fault $ ldd a.out statically linked $ gdb a.out GNU gdb (Debian 10.1-2) 10.1.90.20210103-git Reading symbols from a.out... (gdb) run Starting program: /home/ryutaroh/clang-test/a.out Program received signal SIGSEGV, Segmentation fault. 0xf7fd8210 in _dl_relocate_static_pie () (gdb) info stack #0 0xf7fd8210 in _dl_relocate_static_pie () #1 0xf7f8663c in __libc_start_main () #2 0xf7f864b8 in _start () (gdb) info local No symbol table info available. (gdb) quit A debugging session is active. Inferior 1 [process 530049] will be killed. Quit anyway? (y or n) y Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.14.12-clang13 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clang-13 depends on: ii binutils2.37-7 ii libc6 2.32-4 ii libc6-dev 2.32-4 ii libclang-common-13-dev 1:13.0.0-5 ii libclang-cpp13 1:13.0.0-5 ii libclang1-131:13.0.0-5 ii libgcc-11-dev 11.2.0-9 ii libgcc-s1 11.2.0-9 ii libllvm13 1:13.0.0-5 ii libobjc-11-dev 11.2.0-9 ii libstdc++-11-dev11.2.0-9 ii libstdc++6 11.2.0-9 Versions of packages clang-13 recommends: ii llvm-13-dev 1:13.0.0-5 ii python3 3.9.2-3 Versions of packages clang-13 suggests: pn clang-13-doc -- no debconf information
Bug#996661: clang-13: -static -fsanitize=undefined causes seg fault of a.out
Package: clang-13 Version: 1:13.0.0-5 Severity: normal Dear Maintainer, -static -fsanitize=undefined causes unusable a.out as below: $ clang-13 -static -fsanitize=undefined hello.c $ ./a.out Segmentation fault On the other hand, gcc-11 produces a usable a.out: $ gcc-11 -static -fsanitize=undefined hello.c $ ./a.out hello world! Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.14.12-clang13 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clang-13 depends on: ii binutils2.37-7 ii libc6 2.32-4 ii libc6-dev 2.32-4 ii libclang-common-13-dev 1:13.0.0-5 ii libclang-cpp13 1:13.0.0-5 ii libclang1-131:13.0.0-5 ii libgcc-11-dev 11.2.0-9 ii libgcc-s1 11.2.0-9 ii libllvm13 1:13.0.0-5 ii libobjc-11-dev 11.2.0-9 ii libstdc++-11-dev11.2.0-9 ii libstdc++6 11.2.0-9 Versions of packages clang-13 recommends: ii llvm-13-dev 1:13.0.0-5 ii python3 3.9.2-3 Versions of packages clang-13 suggests: pn clang-13-doc -- no debconf information
Bug#996660: file: mistake statically linked PIE executables as dynamically linked
Package: file Version: 1:5.39-3 Severity: normal Dear Maintainer, Statically linked PIE executable are mistaken as dynamically linked as below: $ clang-13 -static -fPIE -static-pie hello.c $ ldd a.out statically linked $ file a.out a.out: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=8fb93260326c669fd2b80d0863ca0c536d425c19, for GNU/Linux 3.7.0, not stripped Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.14.12-clang13 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages file depends on: ii libc6 2.32-4 ii libmagic1 1:5.39-3 file recommends no packages. file suggests no packages. -- no debconf information
Bug#996659: gcc-11: static-pie cause link failure
Package: gcc-11 Version: 11.2.0-9 Severity: normal Dear Maintainer, gcc-11 -static -fPIE -static-pie hello.c causes the following link failure: /usr/bin/ld: /usr/lib/gcc/aarch64-linux-gnu/11/crtbeginT.o: warning: relocation against `__deregister_frame_info' in read-only section `.rodata.cst8' /usr/bin/ld: read-only segment has dynamic relocations collect2: error: ld returned 1 exit status On the other hand, clang-13 can handle the same situation better as below: $ clang-13 -static -fPIE -static-pie hello.c $ ./a.out hello world! Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.14.12-clang13 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-11 depends on: ii binutils 2.37-7 ii cpp-11 11.2.0-9 ii gcc-11-base11.2.0-9 ii libc6 2.32-4 ii libcc1-0 11.2.0-9 ii libgcc-11-dev 11.2.0-9 ii libgcc-s1 11.2.0-9 ii libgmp10 2:6.2.1+dfsg-2 ii libisl23 0.23-1 ii libmpc31.2.0-1 ii libmpfr6 4.1.0-3 ii libstdc++6 11.2.0-9 ii libzstd1 1.4.8+dfsg-3 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages gcc-11 recommends: ii libc6-dev 2.32-4 Versions of packages gcc-11 suggests: pn gcc-11-doc pn gcc-11-locales -- no debconf information
Bug#975023: vmdb2: qemu-debootstrap after virtual-filesystems fails,Re: vmdb2: qemu-debootstrap after virtual-filesystems fails
Hi, Diederik I redid vmdb run and again got errors as attached. qemu-user-static are from bullseye and sid. Both trial failed. Best regards, Ryutaroh From: Diederik de Haas Subject: Re: vmdb2: qemu-debootstrap after virtual-filesystems fails,Re: vmdb2: qemu-debootstrap after virtual-filesystems fails Date: Thu, 19 Aug 2021 15:58:26 +0200,Thu, 19 Aug 2021 15:58:26 +0200 > Hi Ryutaroh Matsumoto, > > On 18 Nov 2020 12:57:40 +0900 Ryutaroh Matsumoto > > wrote: >> Package: vmdb2 >> Version: 0.19-1 >> ... >> ii qemu-utils 1:5.1+dfsg-4+b1 > > Can you check whether this issue is still reproducible with version 0.22-1? > What qemu version are you using? > > If it's 5.1, I'd like to see whether the problem still occurs with qemu 6.x, > which has now been uploaded to unstable. > I'm wondering whether https://bugs.debian.org/988174 and this bug may have a > similar or even the same cause. > > Cheers, > Diederik test.log.xz Description: Binary data test6.log.xz Description: Binary data
Bug#989499: openssl: version 3 is slower than version 1.1.1k on arm64 with no crypto hardware
Package: openssl Version: 3.0.0~~alpha16-1 Severity: minor Tags: experimental X-Debbugs-Cc: debian-...@lists.debian.org Dear Maintainer, As a response to a recent discussion at the Debian ARM mailing list, I compared the speed of aes-128-cbc of openssl 1.1.1k in Bullseye and 3.0 in experimental on Raspberry Pi 4B. The results are as below. Version 3.0 is slower than version 1.1.1k. On the other hand, at https://lists.debian.org/debian-arm/2021/06/msg9.html Diederik reported that version 3.0 is faster on arm64 with crypto hardware. I am unsure if this is an upstream issue. My speed results are as below: # openssl speed aes-128-cbc ... OpenSSL 1.1.1k 25 Mar 2021 built on: Thu Mar 25 20:49:34 2021 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-YhzaKF/openssl-1.1.1k=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 73719.58k78001.25k79918.46k79520.45k78646.02k 79442.42k # openssl speed -evp aes-128-cbc ... OpenSSL 1.1.1k 25 Mar 2021 built on: Thu Mar 25 20:49:34 2021 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-YhzaKF/openssl-1.1.1k=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 37975.41k40705.82k41937.97k42066.56k42265.07k 42382.97k # openssl speed aes-128-cbc ... version: 3.0.0-alpha16 built on: built on: Thu May 6 19:54:38 2021 UTC options:bn(64,64) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-UqeSFN/openssl-3.0.0~~alpha16=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 CPUINFO: OPENSSL_armcap=0x83 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 37858.56k40995.79k41736.44k42339.69k41984.00k 42350.33k # openssl speed -evp aes-128-cbc ... version: 3.0.0-alpha16 built on: built on: Thu May 6 19:54:38 2021 UTC options:bn(64,64) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-UqeSFN/openssl-3.0.0~~alpha16=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 CPUINFO: OPENSSL_armcap=0x83 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes AES-128-CBC 38057.99k41038.28k41973.03k41930.50k42233.35k 42308.27k Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.41-rt42 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssl depends on: ii libc62.31-12 ii libssl3 3.0.0~~alpha16-1 openssl recommends no packages. Versions of packages openssl suggests: ii ca-certificates 20210119 -- no debconf information
Bug#987245: apache2: After=network.target should be After=network-online.target
Package: apache2 Version: 2.4.46-4 Severity: normal Tags: sid bullseye Dear Maintainer, When /etc/apache2/ports.conf listens specific IP addresses like below Listen 192.168.1.2:80 Listen 153.240.174.134:64193 Listen [2400:4050:2ba1:ac00:99:f0ae:8600:9595]:80 Listen [2400:4050:2ba1:ac00:99:f0ae:8600:beef]:80 apache httpd needs those IP addresses being already configured when it starts, otherwise the httpd fails to start. This ordering dependency is captured by After=network-online.target Wants=network-online.target The current apache2.service systemd file seems slightly incorrect. Best regards, Ryutaroh Matsumoto -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-6-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apache2 depends on: ii apache2-bin 2.4.46-4 ii apache2-data 2.4.46-4 ii apache2-utils2.4.46-4 ii dpkg 1.20.7.1 ii init-system-helpers 1.60 ii lsb-base 11.1.0 ii mime-support 3.66 ii perl 5.32.1-3 ii procps 2:3.3.17-5 Versions of packages apache2 recommends: ii ssl-cert 1.1.0 Versions of packages apache2 suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom pn www-browser Versions of packages apache2-bin depends on: ii libapr1 1.7.0-6 ii libaprutil1 1.6.1-5 ii libaprutil1-dbd-sqlite3 1.6.1-5 ii libaprutil1-ldap 1.6.1-5 ii libbrotli1 1.0.9-2+b2 ii libc62.31-11 ii libcrypt11:4.4.18-2 ii libcurl4 7.74.0-1.2 ii libjansson4 2.13.1-1.1 ii libldap-2.4-22.4.57+dfsg-2 ii liblua5.3-0 5.3.3-1.1+b1 ii libnghttp2-141.43.0-1 ii libpcre3 2:8.39-13 ii libssl1.11.1.1k-1 ii libxml2 2.9.10+dfsg-6.3+b1 ii perl 5.32.1-3 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages apache2-bin suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom pn www-browser Versions of packages apache2 is related to: ii apache2 2.4.46-4 ii apache2-bin 2.4.46-4 -- Configuration Files: /etc/apache2/conf-available/charset.conf changed: AddDefaultCharset UTF-8 /etc/apache2/ports.conf changed: Listen 192.168.1.2:80 Listen 153.240.174.134:64193 Listen [2400:4050:2ba1:ac00:99:f0ae:8600:9595]:80 Listen [2400:4050:2ba1:ac00:99:f0ae:8600:beef]:80 Listen 443 Listen 443 -- no debconf information
Bug#986905: IPAccounting=yes does not work for systemd-run --user,Re: Bug#986905: IPAccounting=yes does not work for systemd-run --user
Control: tags -1 + wontfix > Not sure what I should do with this bug report (besides closing it). You are welcome to close this. It seems a bit strange that IPAccounting=yes is also accepted by systemd user instance... Sorry for my initial report not being much pointed... Best regards, Ryutaroh
Bug#986905: IPAccounting=yes does not work for systemd-run --user
Control: retitle -1 IPAccounting=yes does not work for systemd-run --user A real inconvenience of 986905 is that IPAccounting does not work for any process under systemd --user by non-root. For example, ryutaroh@raspi4b8gb:~$ systemd-run --user --scope --unit=test -p "IPAccounting=yes" sh -c 'wget -O /dev/null http://www.debian.org/ ; sleep 100; exit 0' & [1] 1821 Running scope as unit: test.scope ryutaroh@raspi4b8gb:~$ systemctl --user status test.scope ● test.scope - /bin/sh -c wget -O /dev/null http://www.debian.org/ ; sleep 100; exit 0 Loaded: loaded (/run/user/1000/systemd/transient/test.scope; transient) Transient: yes Active: active (running) since Fri 2021-04-16 13:00:05 JST; 21s ago IP: 0B in, 0B out IO: 696.0K read, 0B written Tasks: 2 (limit: 9028) Memory: 1.2M CPU: 123ms CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/test.scope ├─1821 /bin/sh -c wget -O /dev/null http://www.debian.org/ ; sleep 100; exit 0 └─1831 sleep 100 IP Accounting information is clearly incorrect above. Is it expected to work??? Best regards, Ryutaroh
Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed
Control: retitle -1 systemd user instance: Attaching egress BPF program to cgroup failed with Invalid argument > Currently, to trigger this issue, I need task-xfce-desktop (on every arch.). > I believe that this can be reproduced without task-xfce-desktop, > and will try to find a reproduction procedure with CUI in a weekend... A minimal reproduction procedure of 986905 is as follows: 1. Install dbus-user-session, pulseaudio and libpam-systemd. 2. Add "DefaultIPAccounting=yes" to /etc/systemd/user.conf (reload systemd if necessary) 3. Login as a non-root user of UID >= 1000. 4. journalctl -b -g BPF as root. Best regards, Ryutaroh
Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed,Re: Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed
> So you enabled "DefaultIPAccounting=yes" for the systemd --user > instances (i.e. in user.conf) and only those systemd --user instances > trigger that error? Yes (on amd64, arm64 and armhf). I do not see the error in the systemd PID 1 except on an armhf kernel with CONFIG_BPF_JIT_ALWAYS_ON=y. But we do not need to consider the issue on the armhf kernel here. > If you remove "DefaultIPAccounting=yes" from user.conf, are the error > messages gone? Yes. This seems something like "Permission denied" or "Operation not permitted", but the error is "Invalid argument", which seems strange. Currently, to trigger this issue, I need task-xfce-desktop (on every arch.). I believe that this can be reproduced without task-xfce-desktop, and will try to find a reproduction procedure with CUI in a weekend... Best regards, Ryutaroh
Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed
Hi Michael, I failed to send my email to you: > This reported symptom (986905) is also observed with Debian amd64, > outside of a VM, with task-xfce-desktop installed and > DefaultIPAccounting=yes in /etc/systemd/user.conf. We do not need armhf to reproduce 986905. > The systemd system instance (PID==1) also gives > "Attaching egress BPF program to cgroup failed", > and its reason is "Cannot allocate memory". (What is it???) "Cannot allocate memory" was not observed with Debian linux-image-armmp-lpae, but CONFIG_BPF_JIT_ALWAYS_ON=y caused "Cannot allocate memory" on armhf. CONFIG_BPF_JIT_ALWAYS_ON=n in Debian kernel. "Cannot allocate memory" might be a bug in systemd upstream, but Debian does not suffer from it. Sorry for my misinformation. Best regards, Ryutaroh
Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed
My reports have been wrong. This reported symptom is also observed with Debian amd64, outside of a VM, with task-xfce-desktop installed and DefaultIPAccounting=yes in /etc/systemd/user.conf. In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986905#5 all the error messages are from systemd user instance (whose PID != 1), and the error is "Invalid argument". But on linux-image-armmp-lpae running a barebone hardware (my RPi4B 8GB), the symptom has difference appearance: The systemd system instance (PID==1) also gives "Attaching egress BPF program to cgroup failed", and its reason is "Cannot allocate memory". (What is it???) A full output of "journalctl -b -g BPF" on barebone hardware is as below, which cannot be reproduced in a VM (afaik): -- Journal begins at Tue 2021-04-13 20:01:59 JST, ends at Wed 2021-04-14 12:58:58 JST. -- Apr 14 12:57:48 raspi4b-armhf systemd[1]: -.slice: Attaching egress BPF program to cgroup /sys/fs/cgroup failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: system.slice: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: system-getty.slice: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/system-getty.slice failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: system-modprobe.slice: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/system-modprobe.slice failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: system-postfix.slice: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/system-postfix.slice failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: system-serial\x2dgetty.slice: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/system-serial\x2dgetty.slice failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: system-systemd\x2dfsck.slice: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/system-systemd\x2dfsck.slice failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: system-wpa_supplicant.slice: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/system-wpa_supplicant.slice failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: user.slice: Attaching egress BPF program to cgroup /sys/fs/cgroup/user.slice failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: dev-hugepages.mount: Attaching egress BPF program to cgroup /sys/fs/cgroup/dev-hugepages.mount failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: dev-mqueue.mount: Attaching egress BPF program to cgroup /sys/fs/cgroup/dev-mqueue.mount failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: sys-kernel-debug.mount: Attaching egress BPF program to cgroup /sys/fs/cgroup/sys-kernel-debug.mount failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: sys-kernel-tracing.mount: Attaching egress BPF program to cgroup /sys/fs/cgroup/sys-kernel-tracing.mount failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: fake-hwclock.service: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/fake-hwclock.service failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: keyboard-setup.service: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/keyboard-setup.service failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: kmod-static-nodes.service: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/kmod-static-nodes.service failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: modprobe@configfs.service: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/system-modprobe.slice/modprobe@configfs.service failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: modprobe@drm.service: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/system-modprobe.slice/modprobe@drm.service failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: modprobe@fuse.service: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/system-modprobe.slice/modprobe@fuse.service failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: systemd-modules-load.service: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/systemd-modules-load.service failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: systemd-remount-fs.service: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/systemd-remount-fs.service failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: systemd-udev-trigger.service: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/systemd-udev-trigger.service failed: Cannot allocate memory Apr 14 12:57:48 raspi4b-armhf systemd[1]: system.slice:
Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed
Hi, a minimal procedure to reproduce this in armhf VM is as follows: > Download d-i Alpha 3 for armhf. > (The latest weekly build of d-i did not boot...) * Start installer in VM with non-expert CUI mode. * Install as you like with "standard packages" with Xfce desktop (Instllation is painfully slow on VM...) * In the VM as root echo "DefaultIPAccounting=yes" >>/etc/systemd/user.conf * Reboot the VM * Make sure lightdm.service is running normally. A video card must be with the VM. * journalctl -b -g BPF I guess that task-gnome-desktop also produces this symptom, but Gnome is less likely for armhf installations than Xfce. Best regards, Ryutaroh
Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed
Control: tags -1 - moreinfo > Do you have instructions how I can reproduce this (on a amd64 box)? I removed "moreinfo" tag. If the following is not enough, please attach the tag again. (Assuming "virt-manager" is acceptable) In the following, lighdm display manager is somehow needed to reproduce the reported symptom. "systemctl set-target multi-user.target" prevents the symptom from appearing... >> Is it related with CONFIG_BPF_JIT_DEFAULT_ON??? > Hm, I don't think so. The above looks ok. > Can you raise this upstream please (maybe with a reference to #7054). > I don't have an armhf setup to easily reproduce this myself. > I'd attach an strace log to the upstream bug report as well. I am weakly doubting if this is an upstream issue, could you confirm again that this should be reported upstream...? This seems caused by subtle interactions among Debian packages... *** start of reproduction steps *** (Verified on Ubuntu 20.04 amd64 notebook) # apt-get --install-recommends install virt-manager qemu-system-arm qemu-system-aarch64 qemu-efi-arm qemu-efi-aarch64 ipxe-qemu A qemu hard disk image of size 5GB with no password for root is placed at http://153.240.174.134:64193/debian11-armhf.qcow2 (alternative instructions to produce an equivalent image is given below). Start the virt-manager. In the virt-manager: * Create a new VM. * Select "arm" as "Architecture", with "virt" machine type, 2 CPUs and memory = 5120 MB (smaller maybe OK). * Check "customize configuration before install" * By pushing "Add Hardware", add (they are needed for lightdm to start) - "virtio video" in the subcategory video. - "virtio keyboard" and "virtio tablet" in the subcategory input * Boot into the installed disk image. * Log in as root with no password, verify lightdm.service has started and "journalctl -b -g BPF". *** steps to produce debian11-armhf.qcow2 *** Download d-i Alpha 3 for armhf. (The latest weekly build of d-i did not boot...) * Install as you like with "standard packages" with NO desktop. * linux-image-armmp-lpae should be chosen as the kernel. * In the VM as root run https://github.com/emojifreak/debian-rpi-image-script/blob/main/root-setup.sh I am unsure if just installing task-xfce-desktop reproduces the reported symptom... Best regards, Ryutaroh
Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed,Re: Bug#986905: systemd armhf: Attaching egress BPF program to cgroup failed
> Can you attach the output of > grep BPF /boot/config-$(uname -r) root@qemu-bullseye-armhf:~# uname -a Linux qemu-bullseye-armhf 5.10.0-5-armmp-lpae #1 SMP Debian 5.10.26-1 (2021-03-27) armv7l GNU/Linux root@qemu-bullseye-armhf:~# fgrep -nH BPF /boot/config-5.10.0-5-armmp-lpae /boot/config-5.10.0-5-armmp-lpae:161:CONFIG_CGROUP_BPF=y /boot/config-5.10.0-5-armmp-lpae:189:CONFIG_BPF=y /boot/config-5.10.0-5-armmp-lpae:216:CONFIG_BPF_LSM=y /boot/config-5.10.0-5-armmp-lpae:217:CONFIG_BPF_SYSCALL=y /boot/config-5.10.0-5-armmp-lpae:218:# CONFIG_BPF_JIT_ALWAYS_ON is not set /boot/config-5.10.0-5-armmp-lpae:219:# CONFIG_BPF_PRELOAD is not set /boot/config-5.10.0-5-armmp-lpae:1195:CONFIG_IPV6_SEG6_BPF=y /boot/config-5.10.0-5-armmp-lpae:1335:CONFIG_NETFILTER_XT_MATCH_BPF=m /boot/config-5.10.0-5-armmp-lpae:1554:# CONFIG_BPFILTER is not set /boot/config-5.10.0-5-armmp-lpae:1714:CONFIG_NET_CLS_BPF=m /boot/config-5.10.0-5-armmp-lpae:1741:CONFIG_NET_ACT_BPF=m /boot/config-5.10.0-5-armmp-lpae:1796:CONFIG_BPF_JIT=y /boot/config-5.10.0-5-armmp-lpae:1797:CONFIG_BPF_STREAM_PARSER=y /boot/config-5.10.0-5-armmp-lpae:2013:CONFIG_LWTUNNEL_BPF=y /boot/config-5.10.0-5-armmp-lpae:2021:CONFIG_HAVE_EBPF_JIT=y /boot/config-5.10.0-5-armmp-lpae:7784:# CONFIG_NBPFAXI_DMA is not set /boot/config-5.10.0-5-armmp-lpae:10100:CONFIG_BPF_EVENTS=y /boot/config-5.10.0-5-armmp-lpae:10173:CONFIG_TEST_BPF=m root@qemu-bullseye-armhf:~# In addition, there is little difference between arm64 and armhf in linux kernel config as follows. Is it related with CONFIG_BPF_JIT_DEFAULT_ON??? I have not seen the reported issue on arm64 (nor amd64). ryutaroh@ryutaroh-CFSZ6-1L:/var/tmp/linux-config$ fgrep BPF usr/src/linux-config-5.10/config.armhf_none_armmp-lpae >bpf-armhf.txt ryutaroh@ryutaroh-CFSZ6-1L:/var/tmp/linux-config$ fgrep BPF usr/src/linux-config-5.10/config.arm64_none_arm64 >bpf-arm64.txt ryutaroh@ryutaroh-CFSZ6-1L:/var/tmp/linux-config$ diff -u bpf-arm64.txt bpf-armhf.txt --- bpf-arm64.txt 2021-04-15 09:24:59.596968170 +0900 +++ bpf-armhf.txt 2021-04-15 09:24:40.961010643 +0900 @@ -2,9 +2,7 @@ CONFIG_BPF=y CONFIG_BPF_LSM=y CONFIG_BPF_SYSCALL=y -CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y # CONFIG_BPF_JIT_ALWAYS_ON is not set -CONFIG_BPF_JIT_DEFAULT_ON=y # CONFIG_BPF_PRELOAD is not set CONFIG_IPV6_SEG6_BPF=y CONFIG_NETFILTER_XT_MATCH_BPF=m @@ -15,6 +13,6 @@ CONFIG_BPF_STREAM_PARSER=y CONFIG_LWTUNNEL_BPF=y CONFIG_HAVE_EBPF_JIT=y +# CONFIG_NBPFAXI_DMA is not set CONFIG_BPF_EVENTS=y -# CONFIG_BPF_KPROBE_OVERRIDE is not set CONFIG_TEST_BPF=m Best regards, Ryutaroh
Bug#986882: firefox-esr armhf: always fails to start with Error: eval: #() is not a valid R5RS form. use '#() instead
Control: reassign -1 uim 1:1.8.8-9 Control: severity -1 normal I found that GTK_IM_MODULE=uim firefox-esr causes the reported start-up failure, while GTK_IM_MODULE=xim firefox-esr allows the normal start-up of firefox-esr. So I reassign this to uim. The same symptom is also observed with firefox/sid. See also https://wiki.matoken.org/linux/issue http://hidenosuke.org/diary/?date=20080213 Best regards, Ryutaroh Matsumoto
Bug#986882: firefox-esr armhf: always fails to start with Error: eval: #() is not a valid R5RS form. use '#() instead
Firefox-ESR always fails to start also in a QEMU armhf VM with linux-image-armmp-lpae/bullseye. It seems that firefox-esr is completely unavailable on Debian Bullseye armhf, while few people would use firefox on 32-bit architectures... Best regards, Ryutaroh Matsumoto
Bug#986882: firefox-esr armhf: always fails to start with Error: eval: #() is not a valid R5RS form. use '#() instead
Package: firefox-esr Version: 78.9.0esr-1 Severity: important Tags: sid bullseye X-Debbugs-Cc: debian-...@lists.debian.org Dear Maintainer, On freshly installed Debian bullseye armhf, firefox-esr does not start at all with the following error: rm -rf .mozilla MOZILLA_DISABLE_PLUGINS=1 firefox-esr Error: eval: #() is not a valid R5RS form. use '#() instead Best regards, Ryutaroh Matsumoto -- Package-specific info: -- Extensions information Name: DoH Roll-Out Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: Firefox Screenshots Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: Form Autofill Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: Japanese Language Pack locale Location: /usr/lib/firefox-esr/browser/extensions/langpack...@firefox-esr.mozilla.org.xpi Package: firefox-esr-l10n-ja Status: enabled Name: Web Compat Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: WebCompat Reporter Location: /usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi Package: firefox-esr Status: user-disabled -- Plugins information -- Addons package information ii firefox-esr 78.9.0esr-1 armhfMozilla Firefox web browser - Extended Support Release (ESR) ii firefox-esr-l10n-ja 78.9.0esr-1 all Japanese language package for Firefox ESR -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 5.10.29-preempt (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libatk1.0-0 2.36.0-2 ii libc62.31-11 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.20-2 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-3 ii libnspr4 2:4.29-1 ii libnss3 2:3.61-1 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libvpx6 1.9.0-1 ii libx11-6 2:1.7.0-2 ii libx11-xcb1 2:1.7.0-2 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxrender1 1:0.9.10-1 ii procps 2:3.3.17-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages firefox-esr recommends: ii libavcodec-extra58 [libavcodec58] 7:4.3.2-0+deb11u1 Versions of packages firefox-esr suggests: pn fonts-lmodern pn fonts-stix | otf-stix ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.18.3-4 ii libgtk2.0-02.24.33-1 ii pulseaudio 14.2-2 -- no debconf information
Bug#981586: Bullseye armhf kernel for Raspberry Pi 4b does not boot
Control: tags -1 + wontfix patch
From: Der_Martin
Date: Fri, 9 Apr 2021 10:45:13 +0200
> On 16 Mar 2021 someone published a solution to that bug. Obviously nobody
> cares?
Bug #981586 is a duplicate of #971059.
#981586 is unlikely to get fixed because
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971059#12
So I add "wontfix".
Only
CONFIG_PCIE_BRCMSTB=m
is sufficient for linux-image-armmp-lpae to boot on RPi4B 8GB.
The following script on Debian Bullseye armhf (in a container or a VM)
builds a kernel bootable from USB MSD on RPi4B 8GB.
#!/bin/sh
set -ex
KVAR=5.10.29
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-${KVAR}.tar.xz
tar Jxf linux-${KVAR}.tar.xz
apt-get -q -y install linux-config-5.10 build-essential libncurses-dev fakeroot
dpkg-dev
apt-get -q -y build-dep linux
cd linux-${KVAR}
xzcat /usr/src/linux-config-5.10/config.armhf_none_armmp-lpae.xz >.config
ARCH=arm
export ARCH
echo 'CONFIG_PCIE_BRCMSTB=m' >>.config
make oldconfig
nice -19 make -j 12 bindeb-pkg
Best regards, Ryutaroh Matsumoto
Bug#960329: change severity of 960329 to minor.
Control: severity -1 minor Startup failure of lightdm was caused by GDM_BACKEND=wayland environment variable... Installing accountsservice removes the error message reported in #960329. accountsservice is suggested by lightdm. Upgrading "suggest" to "recommend" might be a good idea... Sorry for disturbing... Ryutaroh
Bug#960329: change severity of 960329 to normal.
Control: severity -1 normal I now think that failure of the startup of lightdm is caused by something other than lightdm. I keep investigating and lower the severity until I get a clear picture of the symptom. Best regards, Ryutaroh
Bug#960329: lightdm: Error getting user list from org.freedesktop.Accounts
Package: lightdm Version: 1.26.0-7 Followup-For: Bug #960329 Control: tags -1 + bullseye sid Control: severity -1 grave Dear Maintainer, After insatlling lightdm by apt-get --install-recommends install task-xfce-desktop/sid task-desktop/sid, the bug #960329 still persists. Installing the package accountsservice, and systemctl restart lightdm does not fix this symptom. Because of this bug, lightdm keeps failing to start, and I can make no interaction with keyboard and display (ssh is OK), so I increase the severity to grave. The system is Debian bullseye arm64 running on the Raspberry Pi 4B. All packages are pure Debian. I hope this issue is fixed before the official Bullseye release. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-5-rt-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lightdm depends on: ii adduser3.118 ii dbus 1.12.20-2 ii debconf [debconf-2.0] 1.5.75 ii libaudit1 1:3.0-2 ii libc6 2.31-10 ii libgcrypt201.8.7-3 ii libglib2.0-0 2.66.7-2 ii libpam-systemd [logind]247.3-3 ii libpam0g 1.4.0-7 ii libxcb11.14-3 ii libxdmcp6 1:1.1.2-3 ii lightdm-gtk-greeter [lightdm-greeter] 2.0.8-2 ii lsb-base 11.1.0 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+22 Versions of packages lightdm suggests: ii accountsservice 0.6.55-3 ii upower 0.99.11-2 pn xserver-xephyr -- debconf information: * shared/default-x-display-manager: lightdm lightdm/daemon_name: /usr/sbin/lightdm
Bug#981616: RPi4B 5GHz WiFi problems #985632 & #981616 completely went away by replacing brcmfmac43455-sdio.bin and brcmfmac43455-sdio.clm_blob
Control: reassign 981616 firmware-brcm80211 20201218-3 Hi, two RPi4B 5GHz WiFi problems #985632 firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine and #981616 5GHz WiFi does not work with vc4.ko on RPi4 and 4K display completely went away by replacing /lib/firmware/brcm/brcmfmac43455-sdio.bin and /lib/firmware/brcm/brcmfmac43455-sdio.clm_blob by the files at https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm Commit messages at https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm are interesting: Use BCM43456 clm_blob on CYW43455 The previous CYW43455 clm_blob provides limited access to the higher 5GHz channels (100+) - the BCM43456 (surprisingly) seems to work and doesn't have this problem. Huh Update CYW43455 firmware This release fixes the error: Firmware trap: type 0x4 @ epc 0x0007a094 The full version string is: Version 7.45.229 (617f1f5 CY) CRC: 253bd863 Date: Mon 2021-01-04 19:58:58 PST Ucode Ver: 1043.2160 FWID 01-2dbd9d2e See: raspberrypi/linux#3849 Best regards, Ryutaroh Matsumoto
Bug#978025: Sound issues with the 5.10.x kernel (alsa)
>> i assume you set this option in the config.txt? This shouldn't have any >> affect for the mainline kernel / DT. > I am aware of that... I include my config.txt on RPi4B for reference... arm_64bit=1 enable_uart=1 upstream_kernel=1 kernel=vmlinuz-5.10.0-5-rt-arm64 initramfs initrd.img-5.10.0-5-rt-arm64 disable_fw_kms_setup=1 disable_overscan=1 hdmi_enable_4kp60=1 Best regards, Ryutaroh Matsumoto
Bug#985928: Sound issues with the 5.10.x kernel (alsa)
Hi Stefan, thank you for your response. > i assume you set this option in the config.txt? This shouldn't have any > affect for the mainline kernel / DT. I am aware of that... I did "snd_bcm2835 enable_hdmi=0" in /etc/modules. "modinfo snd_bcm2835" shows as below. Doesn't it indicate snd_bcm2835 having an option enable_hdmi??? It seems that the contention of grabbing HDMI audio output between vc4.ko and snd_bcm2835.ko can be addressed if snd_bcm2835.ko honors the option enable_hdmi with its default =0, but currently enable_hdmi seems having no effect in behavior of snd_bcm2835... # modinfo snd_bcm2835 filename: /lib/modules/5.10.0-5-rt-arm64/kernel/drivers/staging/vc04_services/bcm2835-audio/snd-bcm2835.ko alias: platform:bcm2835_audio license:GPL description:Alsa driver for BCM2835 chip author: Dom Cobley depends:snd-pcm,vchiq,snd staging:Y intree: Y name: snd_bcm2835 vermagic: 5.10.0-5-rt-arm64 SMP preempt_rt mod_unload modversions aarch64 sig_id: PKCS#7 signer: Debian Secure Boot CA sig_key:4B:6E:F5:AB:CA:66:98:25:17:8E:05:2C:84:66:7C:CB:C0:53:1F:8C sig_hashalgo: sha256 signature: omitted, too long. parm: force_bulk:Force use of vchiq bulk for audio (bool) parm: enable_hdmi:Enables HDMI virtual audio device (bool) parm: enable_headphones:Enables Headphones virtual audio device (bool) parm: enable_compat_alsa:Enables ALSA compatibility virtual audio device (bool) parm: num_channels:Number of audio channels (default: 8) (int) Best regards, Ryutaroh
Bug#978025: Sound issues with the 5.10.x kernel (alsa)
> I think the root cause of this issue is that both vc4.ko and snd_bcm2835.ko > try to provide ALSA sinks to HDMI audio outputs from RPi. > Why do the two drivers provide the same functionality for the same device? > It seems nonsense. > There must be some coordination between vc4.ko and snd_bcm2835.ko > on who provides ALSA sinks of RPi HDMI output. Giving "enable_hdmi=0" to snd_bcm2835.ko does not improve the situation, while module_blacklisting snd_bcm2835 suppresses all the symptoms reported. snd_bcm2835.ko in 5.10.24 seems having a bug ignoring "enable_hdmi=0". Best regards, Ryutaroh
Bug#978025: Sound issues with the 5.10.x kernel (alsa)
Hi all, From: Stefan Wahren Subject: Re: Sound issues with the 5.10.x kernel (alsa) Date: Mon, 8 Feb 2021 13:22:56 +0100 >> This is basically me forwarding the bug I reported on Debian's BTS: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978025 >> TL;DR: I have a RPi 3B+ running pure Debian Bullseye arm64 (~from >> raspi.debian.net), named rpi-mpd, connected via HDMI cable to my AV Receiver. > can you please confirm that the bcm2835-audio driver causing the issues? I think the root cause of this issue is that both vc4.ko and snd_bcm2835.ko try to provide ALSA sinks to HDMI audio outputs from RPi. Why do the two drivers provide the same functionality for the same device? It seems nonsense. There must be some coordination between vc4.ko and snd_bcm2835.ko on who provides ALSA sinks of RPi HDMI output. The non-coordination that both drivers provide different ALSA sinks of the same device already causes another symptom as http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-March/008077.html Best regards, Ryutaroh Matsumoto
Bug#985928: vc4.ko brings unusable ALSA sinks
From: Ryutaroh Matsumoto Subject: vc4.ko brings unusable ALSA sinks Date: Fri, 26 Mar 2021 17:15:40 +0900 (JST) > Touching vc4-hdmi-[01] too many times makes the kernel unstable, > and shutting down often needs several minutes. > /usr/bin/pulseaudio in its default setting touches all available ALSA sinks > and causes the above inconvenience. > I mainly use HDMI audio output, and In my last email, a pointed reproducing procedure should have been given: 0. Assume an RPi4B and a high resolution HDMI display. 1. Install pulseaudio on a sensible distro with the upstream kernel and systemd, e.g. https://raspi.debian.net 2. Make a non-root user and login as that user. 3. Run the following script by the non-root user: #!/bin/sh set -x while true; do systemctl --user status pulseaudio pacmd list-sinks pacmd exit systemctl --user restart pulseaudio done Then every command in the above script gets stuck or fails. I also prepared an SD card image that can reproduce the reported symptom on RPi4B 8GB at http://153.240.174.134:64193/tmp/sdimage8GB.img.xz (268,112,012 bytes). Best regards, Ryutaroh
Bug#984844: 984844 was fixed by upgrading firmware-brcm80211
Control: notfound -1 20210208-4 #984844 is not observed in 20210208-4 in testing/Bullseye. Ryutaroh
Bug#984844: 984844 was fixed by upgrading firmware-brcm80211
Control: reassign -1 firmware-brcm80211 20201218-3 Control: close -1 20210315-1 The symptom #984844 disappeared by upgrading firmware-brcm80211 from 20201218-3 to 20210315-1. Ryutaroh
Bug#981616: 981616 remains in 5.10.24-1
Control: reopen -1 Control: forwarded -1 http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-March/008065.html Control: found -1 5.10.24-1 Control: tags -1 + upstream Sorry, #981616 still persists in 5.10.24-1. For detail, please refer to http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-March/008065.html Best regards, Ryutaroh
Bug#985863: firefox: VideoCore GPU seems unrecognized by Firefox 87 Wayland
Package: firefox Version: 87.0-1 Severity: normal Tags: sid X-Debbugs-Cc: debian-...@lists.debian.org Dear Maintainer, I wonder if the reported issue is https://bugzilla.mozilla.org/show_bug.cgi?id=1689207 but I am unsure of it. I am running linux-image-arm64 with VideoCore GPU as follows: $ ls -l /dev/dri total 0 drwxr-xr-x 2 root root 60 Mar 24 16:34 by-path crw-rw+ 1 root video 226, 0 Mar 24 16:35 card0 $ ls -l /dev/dri/by-path total 0 lrwxrwxrwx 1 root root 8 Mar 24 16:35 platform-gpu-card -> ../card0 # dmesg | fgrep -i gpu [ 23.523232] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4]) [ 23.610693] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4]) [ 23.611152] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4]) [ 23.611474] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4]) [ 23.611805] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 23.612075] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 23.612523] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 23.612848] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 23.821879] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 [ 24.141019] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device # dpkg-query -W | fgrep linux-image linux-image-5.10.0-5-rt-arm64 5.10.24-1 linux-image-rt-arm645.10.24-1 The reported issue is observed on the Debian kernel as well as the Raspberry Pi OS kernel. Firefox 87 Wayland seems not recognizing the GPU and shows the following error messages, while firefox-esr in Bullseye does not show it. Under MOZ_ENABLE_WAYLAND=1 firefox on amd64 host with I915 GPU shows no error messages. Script started on 2021-03-25 14:22:01+09:00 [TERM="xterm-256color" TTY="/dev/pts/0" COLUMNS="80" LINES="24"] $ export MOZ_ENABLE_WAYLAND=1 $ firefox --version Mozilla Firefox 87.0 $ firefox Crash Annotation GraphicsCriticalError: |[0][GFX1-]: No GPUs detected via PCI (t=2.27638) [GFX1-]: No GPUs detected via PCI (firefox:2753): Gdk-CRITICAL **: 14:23:35.084: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox:2753): Gdk-CRITICAL **: 14:23:36.057: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox:2753): Gdk-CRITICAL **: 14:23:36.059: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox:2753): Gdk-CRITICAL **: 14:23:36.709: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox:2753): Gdk-CRITICAL **: 14:23:37.510: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox:2753): Gdk-WARNING **: 14:23:47.899: Tried to unmap the parent of a popup $ firefox-esr --version Mozilla Firefox 78.9.0esr $ firefox-esr (firefox-esr:2556): Gdk-CRITICAL **: 14:22:52.143: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-CRITICAL **: 14:22:53.322: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-CRITICAL **: 14:22:53.324: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-CRITICAL **: 14:22:53.914: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-CRITICAL **: 14:22:53.916: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-CRITICAL **: 14:22:54.618: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-WARNING **: 14:23:08.679: Tried to unmap the parent of a popup $ exit exit Script done on 2021-03-25 14:23:55+09:00 [COMMAND_EXIT_CODE="0"] Best regards, Ryutaroh Matsumoto -- Package-specific info: -- Addons package information -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-5-rt-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libatk1.0-0 2.36.0-2 ii libc62.31-10 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.20-2 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stabl
Bug#985847: #985847 is fixed-upstream
Control: tags -1 + fixed-upstream #985847 is fixed in upstream by https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1798 Ryutaroh
Bug#985847: libmutter-7-0: gnome-shell with wayland shows deformed output with v3d.ko
Package: libmutter-7-0 Version: 3.38.4-1 Severity: important Tags: upstream sid bullseye Control: forwarded -1 https://gitlab.gnome.org/GNOME/mutter/-/issues/1520 Dear Maintainer, Gnome shell with wayland shows deformed output as shown in https://gitlab.gnome.org/GNOME/mutter/-/issues/1520 I confirmed that the symptom also appears with Firefox in Debian Bullseye. This symptom does not happen with weston with Xwayland. Related Ubuntu bug report at https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1896171 I wish some fix will be included in Bullseye Updates... Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.10.17-v8+ (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libmutter-7-0 depends on: ii adwaita-icon-theme 3.38.0-1 ii gsettings-desktop-schemas 3.38.0-2 ii libatk1.0-02.36.0-2 ii libc6 2.31-10 ii libcairo-gobject2 1.16.0-5 ii libcairo2 1.16.0-5 ii libcanberra0 0.30-7 ii libdrm22.4.104-1 ii libegl11.3.2-1 ii libfontconfig1 2.13.1-4.2 ii libfribidi01.0.8-2 ii libgbm120.3.4-1 ii libgdk-pixbuf-2.0-02.42.2+dfsg-1 ii libgl1 1.3.2-1 ii libglib2.0-0 2.66.8-1 ii libgnome-desktop-3-19 3.38.5-1 ii libgraphene-1.0-0 1.10.4+dfsg1-1 ii libgtk-3-0 3.24.24-3 ii libgudev-1.0-0 234-1 ii libice62:1.0.10-1 ii libinput10 1.16.4-3 ii libjson-glib-1.0-0 1.6.2-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-01.46.2-3 ii libpangoft2-1.0-0 1.46.2-3 ii libpipewire-0.3-0 0.3.19-4 ii libsm6 2:1.2.3-1 ii libstartup-notification0 0.12-6+b1 ii libsystemd0247.3-3 ii libudev1 247.3-3 ii libwacom2 1.8-2 ii libwayland-server0 1.19.0-2 ii libx11-6 2:1.7.0-2 ii libx11-xcb12:1.7.0-2 ii libxau61:1.0.9-1 ii libxcb-randr0 1.14-3 ii libxcb-res01.14-3 ii libxcb11.14-3 ii libxcomposite1 1:0.4.5-1 ii libxcursor11:1.2.0-2 ii libxdamage11:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxi6 2:1.7.10-1 ii libxinerama1 2:1.1.4-2 ii libxkbcommon-x11-0 1.0.3-2 ii libxkbcommon0 1.0.3-2 ii libxkbfile11:1.1.0-1 ii libxrandr2 2:1.5.1-1 ii libxtst6 2:1.2.3-1 ii mutter-common 3.38.4-1 libmutter-7-0 recommends no packages. libmutter-7-0 suggests no packages. Versions of packages libmutter-7-0 is related to: ii libegl-mesa0 [libegl-vendor] 20.3.4-1 ii libgl1-mesa-dri 20.3.4-1 ii libglx-mesa0 [libglx-vendor] 20.3.4-1 -- no debconf information
Bug#981616: 981616 is fixed in 5.10.24-1
Control: close -1 5.10.24-1 I recheck the situation with Debian kernel 5.10.24 and Debian firmware-brcm80211 20201218-3. 5GHz WiFi works fine with vc4 and without vc4. Debian package of firmware-brcm80211 newer than 20201218-3 has a severe issue with 5GHz WiFi as reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984489 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985632 But it is a separate topic. Best regards, Ryutaroh
Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine
Control: found -1 20210315-1 > I will re-check 20210315-1. The system boots with 20210315-1 and the reported symtom remains in the same way. Ryutaroh
Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine
Hi Maximilian, thank you again for your response. > but are you sure that these > bootflags are still adequate for the latest cypress firmware? What did you mean by "bootflags"?? Did you mean /proc/cmdline (i.e. cmdline.txt in Raspberry Pi)? > concerning bluetooth unfortunately this seems missing firmware > in latest upstream firmware git (see #962038 ) or possible wget info > https://wiki.debian.org/RaspberryPi4#Bluetooth I know that bluetooth interferes with 2.4GHz WiFi with pure Debian packages as reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984844 I do not see any intererence between bluetooth and 5GHz WiFi. I doubt the intererence as bluetooth frequency does not overlap with 5GHz WiFi at all. With the firmware 20210208-4, 2.4GHz WiFi works fine provided that bluetooth is turned off by rfkill etc. I am running a combination of pure Debian packages and encountered the reported symptom. What is a Debian way to use 5GHz WiFi? Do you need additional information? > this should not be reproducible as 20210315-1 and 20210315-1~exp1 are > unchanged (just uploaded into experimental before unstable). I will re-check 20210315-1. Best regards, Ryutaroh
Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine
Control: tags -1 - moreinfo Hi Maximilian, thank you for your attention! > please provide info on the affected hardware, It is Raspberry Pi 4B 8GB model. > please show affected dmesg output working and non working, > the difference between 20210208-3 20210208-4 is minimal, > hence it should be easy to find out what broke? Not at all, unfortunately. 20210208-3 was completely broken on RPi4B as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984489 20210208-1 to 20210208-3 were broken... The last working version was 20201218-3, and I apt-mark-holded firmware-brcm80211. I unhold it in the weekend and found this issue. I attach dmesg of 20201218-3, 20210208-4, and 20210315-1. It was also interesting that installation of 20210315-1 causes boot failure and showed "Give root password for maintainance"... Should I file a separete report against 20210315-1? 20210315-1~exp1 was booted fine... Best regards, Ryutaroh dmesg.tar.xz Description: Binary data
Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine
Package: firmware-brcm80211 Version: 20210315-1~exp1 Followup-For: Bug #985632 Dear Maintainer, This reported symptom also exists in 20210315-1~exp1. Best regards, Ryutaroh -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-4-rt-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-brcm80211 depends on no packages. firmware-brcm80211 recommends no packages. Versions of packages firmware-brcm80211 suggests: ii initramfs-tools 0.140 -- no debconf information
Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine
Package: firmware-brcm80211 Version: 20210208-4 Severity: grave Tags: sid bullseye Justification: renders package unusable X-Debbugs-Cc: debian-...@lists.debian.org Dear Maintainer, 5GHz WiFi stopped working with 20210208-4. iw wlan0 scan does not show SSID of 5GHz WiFi. With 20201218-3, 5GHz worked fine, provided that vc4.ko is blacklisted (see #981616). I will see if the newer package in the experimental behaves differently. Best regards, Ryutaroh Matsumoto5GHz WiFi stopped working with 20210208-4. iw wlan0 scan does not show SSID of 5GHz WiFi. With 20201218-3, 5GHz worked fine, provided that vc4.ko is blacklisted (see #981616). I will see if the newer package in the experimental behaves differently. Best regards, Ryutaroh Matsumoto5GHz WiFi stopped working with 20210208-4. iw wlan0 scan does not show SSID of 5GHz WiFi. With 20201218-3, 5GHz worked fine, provided that vc4.ko is blacklisted (see #981616). I will see if the newer package in the experimental behaves differently. Best regards, Ryutaroh Matsumoto5GHz WiFi stopped working with 20210208-4. iw wlan0 scan does not show SSID of 5GHz WiFi. With 20201218-3, 5GHz worked fine, provided that vc4.ko is blacklisted (see #981616). I will see if the newer package in the experimental behaves differently. Best regards, Ryutaroh Matsumoto5GHz WiFi stopped working with 20210208-4. iw wlan0 scan does not show SSID of 5GHz WiFi. With 20201218-3, 5GHz worked fine, provided that vc4.ko is blacklisted (see #981616). I will see if the newer package in the experimental behaves differently. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-4-rt-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-brcm80211 depends on no packages. firmware-brcm80211 recommends no packages. Versions of packages firmware-brcm80211 suggests: ii initramfs-tools 0.139 -- no debconf information
Bug#985630: linux-image-5.10.0-4-rt-arm64: vc4.ko gives a false error messages with empty SD card slot
Package: src:linux Version: 5.10.19-1 Severity: minor Tags: upstream sid bullseye Control: forwarded -1 http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-March/008058.html Dear Maintainer, I found another mysterious error caused by vc4.ko. Only when vc4.ko is loaded AND the SD card slot is empty in my RPi4B 8GB, I observe the following harmless error message at every 10 seconds: [ 255.457584] mmc1: Timeout waiting for hardware cmd interrupt. [ 255.460735] mmc1: sdhci: SDHCI REGISTER DUMP === [ 255.464244] mmc1: sdhci: Sys addr: 0x | Version: 0x1002 [ 255.467752] mmc1: sdhci: Blk size: 0x | Blk cnt: 0x [ 255.471259] mmc1: sdhci: Argument: 0x | Trn mode: 0x [ 255.474765] mmc1: sdhci: Present: 0x1fff0001 | Host ctl: 0x0001 [ 255.478271] mmc1: sdhci: Power: 0x000f | Blk gap: 0x0080 [ 255.481777] mmc1: sdhci: Wake-up: 0x | Clock:0xf447 [ 255.485282] mmc1: sdhci: Timeout: 0x | Int stat: 0x [ 255.488787] mmc1: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 [ 255.492293] mmc1: sdhci: ACmd stat: 0x | Slot int: 0x [ 255.495799] mmc1: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525 [ 255.499305] mmc1: sdhci: Cmd: 0x0502 | Max curr: 0x00080008 [ 255.502809] mmc1: sdhci: Resp[0]: 0x | Resp[1]: 0x [ 255.506314] mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x [ 255.509819] mmc1: sdhci: Host ctl2: 0x [ 255.512239] mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0x [ 255.515743] mmc1: sdhci: [ 265.697585] mmc1: Timeout waiting for hardware cmd interrupt. [ 265.700734] mmc1: sdhci: SDHCI REGISTER DUMP === [ 265.704244] mmc1: sdhci: Sys addr: 0x | Version: 0x1002 [ 265.707752] mmc1: sdhci: Blk size: 0x | Blk cnt: 0x [ 265.711258] mmc1: sdhci: Argument: 0x | Trn mode: 0x [ 265.714764] mmc1: sdhci: Present: 0x1fff0001 | Host ctl: 0x0001 [ 265.718270] mmc1: sdhci: Power: 0x000f | Blk gap: 0x0080 [ 265.721775] mmc1: sdhci: Wake-up: 0x | Clock:0xf447 [ 265.725279] mmc1: sdhci: Timeout: 0x | Int stat: 0x [ 265.728785] mmc1: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 [ 265.732290] mmc1: sdhci: ACmd stat: 0x | Slot int: 0x [ 265.735795] mmc1: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525 [ 265.739300] mmc1: sdhci: Cmd: 0x0502 | Max curr: 0x00080008 [ 265.742806] mmc1: sdhci: Resp[0]: 0x | Resp[1]: 0x [ 265.746311] mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x [ 265.749815] mmc1: sdhci: Host ctl2: 0x [ 265.752234] mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0x [ 265.755739] mmc1: sdhci: Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.10.0-4-rt-arm64 (debian-ker...@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 PREEMPT_RT Debian 5.10.19-1 (2021-03-02) ** Command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 vc_mem.mem_size=0x3ff0 console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=256M@256M rootwait rootfstype=ext4 module_blacklist=btrfs ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [0.00] Booting Linux on physical CPU 0x00 [0x410fd083] [0.00] Linux version 5.10.0-4-rt-arm64 (debian-ker...@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 PREEMPT_RT Debian 5.10.19-1 (2021-03-02) [0.00] Machine model: Raspberry Pi 4 Model B Rev 1.4 [0.00] efi: UEFI not found. [0.00] Reserved memory: bypass linux,cma node, using cmdline CMA params instead [0.00] OF: reserved mem: node linux,cma compatible matching fail [0.00] cma: Reserved 256 MiB at 0x1000 [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a node at [mem 0x-0x0001] [0.00] NUMA: NODE_DATA [mem 0x1ff018940-0x1ff01afff] [0.00] Zone ranges: [0.00] DMA [mem 0x-0x3fff] [0.00] DMA32[mem 0x4000-0x] [0.00] Normal [mem 0x0001-0x0001] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x3b2f] [0.00] node 0: [mem 0x4000-0xfbff] [0.00
Bug#982929: systemd: upstream testsuite failures on armhf
Control: forwarded -1 https://github.com/systemd/systemd/issues/19060 I brought #982929 to the upstream as above. Best regards, Ryutaroh
Bug#982929: systemd: upstream testsuite failures on armhf
Hi Michael, Thanks again for your attention. >> Architecture: arm64 (aarch64) > Might be an issue of trying to execute armhf on a arm64 kernel. It was an error in testsuites running on linux-image-armmp-lpae on qemu-system-arm, so the above should not be the case. > But I'm no expert on this and I don't have the necessary hardware to > try this, Since it happens on qemu-system-arm, in an ideal world, any Debian amd64 host should be able to reproduce this symptom... (we are not living in an ideal world) so could you please raise this upstream yourself and report > back with the issue number? I will do it after I return from my travel. > It's likely that upstream has follow-up questions. Best regards, Ryutaroh
Bug#977694: #977694 is fixed by initramfs-tools 0.140
Control: reassign -1 initramfs-tools 0.139 Control: tags -1 + pending #977694 is going to be fixed by the commit https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/a930e9a448d807cd23632c095a45d48842ff2f24 Ryutaroh
Bug#985121: linux-image-5.10.0-4-rt-arm64: KMS seems broken in vc4.ko
Hi Lucas, > According to strace, it fails because /dev/dri does not exist. When vc4.ko is not loaded, /dev/dri does not exist. If vc4.ko is loaded, /dev/dri exists. Could you make sure that vc4.ko is loaded by "lsmod | fgrep vc4"? vc4.ko was disabled at Debian kernel 5.10.9. Other Debian 5.10.? kernel packages have vc4.ko. When vc4.ko is not loaded, kmscube fails as: Script started on 2021-03-15 09:02:32+09:00 [TERM="linux" TTY="/dev/tty3" COLUMNS="480" LINES="135"] root@raspi4b8gb:/tmp# kmscube drmGetDevices2 failed: No such file or directory could not open drm device failed to initialize legacy DRM root@raspi4b8gb:/tmp# exit Script done on 2021-03-15 09:02:40+09:00 [COMMAND_EXIT_CODE="255"] When vc4.ko is loaded, kmscube fails as: $ kmscube Using display 0xe087a150 with EGL version 1.4 === EGL information: version: "1.4" vendor: "Mesa Project" client extensions: "EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless" display extensions: "EGL_ANDROID_blob_cache EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_image_dma_buf_export EGL_MESA_query_driver " === OpenGL ES 2.x information: version: "OpenGL ES 3.2 Mesa 20.3.4" shading language version: "OpenGL ES GLSL ES 3.20" vendor: "Mesa/X.org" renderer: "llvmpipe (LLVM 11.0.1, 128 bits)" extensions: "GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_format_BGRA GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_half_float GL_EXT_draw_instanced GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_NV_conditional_render GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_EXT_frag_depth GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_OES_viewport_array GL_ANGLE_pack_reverse_row_order GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_occlusion_query_boolean GL_EXT_robustness GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_robustness GL_KHR_texture_compression_astc_ldr GL_NV_pixel_buffer_object GL_OES_depth_texture_cube_map GL_OES_required_internalformat GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_sRGB_write_control GL_EXT_separate_shader_objects GL_EXT_shader_group_vote GL_EXT_shader_implicit_conversions GL_EXT_shader_integer_mix GL_EXT_tessellation_point_size GL_EXT_tessellation_shader GL_ANDROID_extension_pack_es31a GL_EXT_base_instance GL_EXT_compressed_ETC1_RGB8_sub_texture GL_EXT_copy_image GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_gpu_shader5 GL_EXT_polygon_offset_clamp GL_EXT_primitive_bounding_box GL_EXT_render_snorm GL_EXT_shader_io_blocks GL_EXT_texture_border_clamp GL_EXT_texture_buffer GL_EXT_texture_cube_map_array GL_EXT_texture_norm16 GL_EXT_texture_view GL_KHR_blend_equation_advanced GL_KHR_context_flush_control GL_KHR_robust_buffer_access_behavior GL_NV_image_formats GL_OES_copy_image GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_gpu_shader5 GL_OES_primitive_bounding_box GL_OES_sample_shading GL_OES_sample_variables GL_OES_shader_io_blocks GL_OES_shader_multisample_interpolation GL_OES_tessellation_point_size GL_OES_tessellation_shader GL_OES_texture_border_clamp GL_OES_texture_buffer GL_OES_texture_cube_map_array GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array GL_OES_texture_view GL_EXT_blend_func_extended GL_EXT_buffer_storage
Bug#985121: linux-image-5.10.0-4-rt-arm64: KMS seems broken in vc4.ko
Package: src:linux Version: 5.10.19-1 Severity: normal Tags: upstream sid bullseye X-Debbugs-Cc: debian-...@lists.debian.org Control: forwarded -1 http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-March/008049.html Dear Maintainer, kmscube 0.0.0~git20210103-1 fails to start with the error message on Raspberry Pi 4B: failed to set mode: Invalid argument kmscube works fine on linux-image-amd64 and Raspberry Pi OS kernel with vc4.ko and v3d.ko loaded. Debian kernel without vc4.ko does not have KMS support on RPi4B. If this is an issue in kmscube, please feel free to reassign. This has been reported to the upstream maintainer. Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.10.0-4-rt-arm64 (debian-ker...@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 PREEMPT_RT Debian 5.10.19-1 (2021-03-02) ** Command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 vc_mem.mem_size=0x3ff0 console=tty0 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=256M@256M rootwait rootfstype=ext4 module_blacklist=vc4,btrfs ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [ 15.434159] systemd[1]: Listening on udev Kernel Socket. [ 15.469512] systemd[1]: Mounting Huge Pages File System... [ 15.586142] systemd[1]: Mounting POSIX Message Queue File System... [ 15.693933] systemd[1]: Mounting Kernel Debug File System... [ 15.760955] systemd[1]: Mounting Kernel Trace File System... [ 15.824464] systemd[1]: Starting Restore / save the current clock... [ 15.887927] systemd[1]: Starting Set the console keyboard layout... [ 15.948674] systemd[1]: Starting Create list of static device nodes for the current kernel... [ 16.009118] systemd[1]: Starting Load Kernel Module configfs... [ 16.072408] systemd[1]: Starting Load Kernel Module drm... [ 16.136954] systemd[1]: Starting Load Kernel Module fuse... [ 16.186350] fuse: init (API version 7.32) [ 16.593944] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [ 16.594243] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [ 16.606377] systemd[1]: Starting Journal Service... [ 16.697713] systemd[1]: Starting Load Kernel Modules... [ 16.772886] systemd[1]: Starting Remount Root and Kernel File Systems... [ 16.826411] EXT4-fs (sda2): re-mounted. Opts: journal_async_commit,nobarrier,data=writeback,commit=3600 [ 16.839276] systemd[1]: Starting Coldplug All udev Devices... [ 16.936206] systemd[1]: Mounted Huge Pages File System. [ 16.963282] systemd[1]: Mounted POSIX Message Queue File System. [ 16.991278] systemd[1]: Mounted Kernel Debug File System. [ 17.088051] systemd[1]: Started Journal Service. [ 17.499035] systemd-journald[259]: Received client request to flush runtime journal. [ 29.663856] vchiq: module is from the staging directory, the quality is unknown, you have been warned. [ 29.838127] iproc-rng200 fe104000.rng: hwrng registered [ 30.005996] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer [ 30.152450] Module vc4 is blacklisted [ 30.528213] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [ 30.841068] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned. [ 30.893324] cryptd: max_cpu_qlen set to 1000 [ 30.905644] mc: Linux media interface: v0.10 [ 30.931090] bcm2835_audio bcm2835_audio: card created with 8 channels [ 30.965046] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 30.965729] cfg80211: Loaded X.509 cert 'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf' [ 30.966251] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328' [ 30.966940] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 30.988506] platform regulatory.0: firmware: direct-loading firmware regulatory.db [ 30.993828] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s [ 31.010109] videodev: Linux video capture interface: v2.00 [ 31.089165] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 31.099490] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.bin [ 31.100616] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt [ 31.106479] usbcore: registered new interface driver brcmfmac [ 31.197366] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned. [ 31.222017] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned. [ 31.241095] brcmfmac
Bug#984844: bluez-firmware: 2.4 GHz WiFi is interfered by bluetooth on RPi4B
Package: bluez-firmware Version: 1.2-4 Severity: important Tags: upstream fixed-upstream sid bullseye X-Debbugs-Cc: debian-...@lists.debian.org Control: forwarded -1 https://github.com/RPi-Distro/firmware-nonfree/issues/8 Dear Maintainer, I have installed bluetooth 5.55-3 bluez 5.55-3 bluez-firmware 1.2-4 When I block bluetooth by /usr/sbin/rfkill, 2.4 GHz WiFi on Raspberry Pi 4 seems to work, at least ping packets can reach to machines on the same LAN. On the other hand, when I unblock bluetooth by /usr/sbin/rfkill, 2.4GHz WiFi does not work well. Connection by SSID is established, but no ping packet reach to machines on the same LAN. This seems fixed at https://github.com/RPi-Distro/firmware-nonfree/issues/8 Linux kernel is Debian linux-image-5.10.0-4-rt-arm64 5.10.19-1 Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-4-rt-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#983662: openvpn: autopkgtest always fails on qemu testbed
Hi again, >> The stderr is recoreded to "test name"-stderr by autopkgtest. >> But that file is empty... > > Yes, that only lists non-redirected stderr. Since output on stderr > causes the autopkgtest to fail by default the output of most commands is > already redirected to /dev/null Sorry, I misunderstood what you wrote yesterday. I added "allow-stderr" to debian/tests/control. Then server-setup-with-ca-stderr looked like Generating RSA private key, 2048 bit long modulus (2 primes) + ..+ e is 65537 (0x010001) You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Common Name (eg: your user, host, or server name) [Easy-RSA CA]:problems making Certificate Request Easy-RSA error: Failed to build the CA The above seems suggesting "easyrsa" waits some input from stdin. So I changed the test script as follows: --- server-setup-with-ca-orig 2021-03-08 17:12:26.215151712 +0900 +++ server-setup-with-ca2021-03-08 17:14:37.367548813 +0900 @@ -39,9 +39,9 @@ info "Setup the CA and the server keys" ./easyrsa init-pki -./easyrsa build-ca nopass -./easyrsa build-server-full server nopass -./easyrsa gen-dh +echo . | ./easyrsa build-ca nopass +echo . | ./easyrsa build-server-full server nopass +echo . | ./easyrsa gen-dh info "Create the OpenVPN server config file" cat << EOF > /etc/openvpn/server.conf Then the output to stderr "improved" as follows: Generating RSA private key, 2048 bit long modulus (2 primes) ...+ ..+ e is 65537 (0x010001) You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Common Name (eg: your user, host, or server name) [Easy-RSA CA]:error, no objects specified in config file problems making Certificate Request Easy-RSA error: Failed to build the CA Best regards, Ryutaroh
Bug#983662: openvpn: autopkgtest always fails on qemu testbed
Hi Bernhard, >one of the easyrsa commands fails, and since we redirect stderr to >/dev/null we are not seeing any error message. Could you drop the >redirects and check the output? The stderr is recoreded to "test name"-stderr by autopkgtest. But that file is empty... Best regards, Ryutaroh
Bug#983737: open-iscsi: configuration does not finish with sysvinit-core
Hi Ritesh, CC: Debian init-system-helpers maintainers, Thank you very much for spending your time on investigating this issue. I wonder if this issue should also be assigned to init-system-helpers package including deb-systemd-helper, for example, by the following commands clone 983737 -1 reassign -1 init-system-helpers 1.60 Your analysis of this issue seems indicating this is also an issue in init-system-helpers, though I am unsure. As init-system-helpers is one of very few "essential" packages, its bug must be identified and fixed before the release of Bullseye, if any. > @Ryutaroh: Thank you for finding and reporting the bug and having the > patience with me. Working on this bug, with you, made me learn a couple of > new things. :-) You are most welcome! Best regards, Ryutaroh
Bug#977647: 5.10.4 Debian kernel does not boot on amd64 with btrfs rootfs
7.198838] RBP: 0002 R08: R09: 55ee81373ff0 [7.198838] R10: 0011 R11: 0246 R12: 7ff6723a6e2d [7.198839] R13: R14: 55ee813330b0 R15: 55ee81379020 [7.198841] ---[ end trace 763ec261f802618a ]--- Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.10.0-4-amd64 (debian-ker...@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.19-1 (2021-03-02) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-4-amd64 root=UUID=676134ca-7200-4cf0-b363-ef93702a7a1c ro i8042.reset=1 intel_iommu=on i8042.nopnp ** Tainted: W (512) * kernel issued warning ** Kernel log: [7.697570] usbcore: registered new interface driver uvcvideo [7.700175] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware [7.706044] USB Video Class driver (1.1.1) [7.709730] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters, 655360 ms ovfl timer [7.713280] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules [7.713281] RAPL PMU: hw unit of domain package 2^-14 Joules [7.713282] RAPL PMU: hw unit of domain dram 2^-14 Joules [7.713282] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules [7.713283] RAPL PMU: hw unit of domain psys 2^-14 Joules [7.799578] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [7.813519] audit: type=1400 audit(1614821632.324:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=525 comm="apparmor_parser" [7.813753] audit: type=1400 audit(1614821632.324:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/lxc-start" pid=535 comm="apparmor_parser" [7.814648] audit: type=1400 audit(1614821632.324:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=527 comm="apparmor_parser" [7.818048] audit: type=1400 audit(1614821632.328:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=532 comm="apparmor_parser" [7.844320] audit: type=1400 audit(1614821632.328:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=532 comm="apparmor_parser" [7.844326] audit: type=1400 audit(1614821632.328:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" pid=530 comm="apparmor_parser" [7.844331] audit: type=1400 audit(1614821632.328:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=526 comm="apparmor_parser" [7.844335] audit: type=1400 audit(1614821632.328:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=526 comm="apparmor_parser" [7.844340] audit: type=1400 audit(1614821632.328:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=526 comm="apparmor_parser" [7.844345] audit: type=1400 audit(1614821632.328:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=528 comm="apparmor_parser" [8.104937] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x354 [8.215971] Bluetooth: Core ver 2.22 [8.216006] NET: Registered protocol family 31 [8.216008] Bluetooth: HCI device and connection manager initialized [8.216014] Bluetooth: HCI socket layer initialized [8.216019] Bluetooth: L2CAP socket layer initialized [8.216026] Bluetooth: SCO socket layer initialized [8.293461] iwlwifi :00:14.3: base HW address: bc:54:2f:bc:8f:9a [8.306026] thermal thermal_zone10: failed to read out thermal zone (-61) [8.360383] intel_rapl_common: Found RAPL domain package [8.360386] intel_rapl_common: Found RAPL domain core [8.360388] intel_rapl_common: Found RAPL domain uncore [8.360391] intel_rapl_common: Found RAPL domain dram [8.360393] intel_rapl_common: Found RAPL domain psys [8.360399] intel_rapl_common: RAPL package-0 domain package locked by BIOS [8.360414] intel_rapl_common: RAPL package-0 domain dram locked by BIOS [8.384742] snd_hda_intel :00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [8.385172] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0 [8.395871] snd_hda_intel :00:1f.3: Digital mics found on Skylake+ platform,
Bug#983360: multipath-tools: autopkgtest failure on the qemu testbed
> rrs@lenovo:~$ autopkgtest -B -U -u debci -o /tmp/multipath-tools-qemu > multipath-tools -- qemu -d --show-boot -c 1 --ram-size=3072 > /var/lib/debci/qemu/sid-amd64.img This should work... You could try the same command by root, but it should work under an ordinary user. > Booting from Hard Disk... > autopkgtest-virt-qemu: DBG: cleanup... > : failure: timed out waiting for "login prompt on ttyS0" > autopkgtest [20:12:41]: ERROR: testbed failure: cannot send to testbed: > [Errno 32] Broken pipe Have you seen "Grub" or "Linux"? If not, the installation of grub and/or linux-image-amd64 is broken in the VM image /var/lib/debci/qemu/sid-amd64.img. I wonder if /var/lib/debci/qemu/sid-amd64.img can be booted under virt-manager. I also see a problem in grub-pc/sid. Could you try # debci setup -f -s bullseye -a amd64 -b qemu Then > rrs@lenovo:~$ autopkgtest -B -U -u debci -o /tmp/multipath-tools-qemu > multipath-tools -- qemu -d --show-boot -c 1 --ram-size=3072 > /var/lib/debci/qemu/bullseye-amd64.img (sid replaced by bullseye). Best regards, Ryutaroh
Bug#983737: open-iscsi: configuration does not finish with sysvinit-core
> What should be the steps to reproduce this bug on my machine using > debci/autopkgtest ? (Assuming you are using Debian Bullseye amd64.) # debci setup -f -b qemu -a amd64 -s sid The above will create /var/lib/debci/qemu/sid-amd64.img "debci setup" sometimes fails, in such a case please retry... The above image has /sbin/init==systemd-sysv, of course. As open-iscsi has no problem with /sbin/init==systemd-sysv, We need to replace it with sysvinit-core in the VM image. # apt-get --install-recommends install virt-manager # cp /var/lib/debci/qemu/sid-amd64.img /var/lib/libvirt/images # virt-manager (this can be run by an ordinary user belonging to libvirt group) Start VM on /var/lib/libvirt/images/sid-amd64.img Login as root (no password) into the Linux running on VM. on-VM# apt-get install sysvinit-core on-VM# echo "S0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100" >>/etc/inittab on-VM# shutdown -h -P now /var/lib/libvirt/images/sid-amd64.img should have /sbin/init==sysvinit-core now. autopkgtest -B -u debci -o some-dir-for-logging open-iscsi -- qemu --debug --show-boot /var/lib/libvirt/images/sid-amd64.img The test should get stuck at apt-get install open-iscsi... Best regards, Ryutaroh
Bug#983737: open-iscsi: configuration does not finish with sysvinit-core
>> while "apt-get install open-iscsi" never finishes when >> /sbin/init==systemd-sysv. > I guess you meant sysvinit in the latter case. I was wrong... The latter should have been sysvinit-core... > So can you please point me to what the actual problem with the package > is, when run on a system with sysvinit-core being active ? apt-get install open-iscsi never finishes and, I have to kill -TERM the post installation script from another tty. Since I only run open-iscsi on a VM, I am unsure if the open-iscsi with terminated installation works without any problem, but at least apt/dpkg does not recognized open-iscsi as "fully installed". If you don't reproduce the reported symptom on your Debian host, I will upload the VM image file (300 MB qcow2) somewhere. Best regards, Ryutaroh
Bug#983737: open-iscsi: configuration does not finish with sysvinit-core
Hi Ritesh, Thanks again for paying attention to my report. > I see nothing wrong here. What is the output you expect ? On the qemu default configuration by virt-manager in Bullseye, "apt-get install open-iscsi" finishes with no problem when /sbin/init==systemd-sysv, while "apt-get install open-iscsi" never finishes when /sbin/init==systemd-sysv. Is it expected? If this is an expected behavior, I am happy to attach "wontfix" tag and/or close this issue. The reason behind reporting this different behavior of "apt-get install open-iscsi" is that it let autopkgtest of src:tgt always fail on the qemu testbed when /sbin/init==systemd-sysv. Best regards, Ryutaroh
Bug#983737: open-iscsi: configuration does not finish with sysvinit-core
Package: open-iscsi Version: 2.1.3-2 Severity: normal Tags: sid bullseye Dear Maintainer, When /sbin/init is sysvinit-core, apt-get install open-iscsi does not finish as follows. The postinst script is terminated from another tty. Script started on 2021-03-01 08:42:11+09:00 [TERM="linux" TTY="/dev/tty1" COLUMNS="128" LINES="48"] root@host:~# apt-get install open-iscsi The following additional packages will be installed: libisns0 libopeniscsiusr netbase The following NEW packages will be installed: libisns0 libopeniscsiusr netbase open-iscsi 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. Need to get 504 kB of archives. After this operation, 2,211 kB of additional disk space will be used. Preparing to unpack .../libisns0_0.100-3_amd64.deb ... Unpacking libisns0:amd64 (0.100-3) ... Selecting previously unselected package libopeniscsiusr. Preparing to unpack .../libopeniscsiusr_2.1.3-2_amd64.deb ... Unpacking libopeniscsiusr (2.1.3-2) ... Selecting previously unselected package open-iscsi. Preparing to unpack .../open-iscsi_2.1.3-2_amd64.deb ... Unpacking open-iscsi (2.1.3-2) ... Selecting previously unselected package netbase. Preparing to unpack .../archives/netbase_6.2_all.deb ... Unpacking netbase (6.2) ... Setting up libopeniscsiusr (2.1.3-2) ... Setting up libisns0:amd64 (0.100-3) ... Setting up netbase (6.2) ... Setting up open-iscsi (2.1.3-2) ... Starting iSCSI initiator daemon: iscsidSetting up iSCSI targets: iscsiadm: No records found . Starting iSCSI initiator daemon: iscsidSetting up iSCSI targets: iscsiadm: No records found . dpkg: error processing package open-iscsi (--configure): installed open-iscsi package post-installation script subprocess was killed by signal (Terminated) Processing triggers for libc-bin (2.31-9) ... Processing triggers for initramfs-tools (0.139) ... update-initramfs: Generating /boot/initrd.img-5.10.0-3-amd64 Errors were encountered while processing: open-iscsi E: Sub-process /usr/bin/dpkg returned an error code (1) W: Operation was interrupted before it could finish root@host:~# exit Script done on 2021-03-01 08:43:48+09:00 [COMMAND_EXIT_CODE="100"] Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages open-iscsi depends on: ii debconf [debconf-2.0] 1.5.75 ii libc6 2.31-9 ii libelogind0 [libsystemd0] 246.9.1-1+debian1 ii libisns0 0.100-3 ii libkmod2 28-1 ii libmount1 2.36.1-7 ii libopeniscsiusr2.1.3-2 ii libssl1.1 1.1.1j-1 ii udev 247.3-1 open-iscsi recommends no packages. open-iscsi suggests no packages. -- debconf information: open-iscsi/downgrade_and_break_system: open-iscsi/upgrade_even_with_failed_sessions: open-iscsi/upgrade_recovery_error: open-iscsi/remove_even_with_active_sessions:
Bug#983674: libvirt: autopkgtest always fails on qemu testbed with -u debci
Source: libvirt Version: 7.0.0-3 Severity: important Tags: sid bullseye Dear Maintainer, I made an autopkgtest qemu testbed by debci setup -f -s sid -a amd64 -b qemu. Then I run autopkgtest -U -B -u debci libvirt -- qemu. "smoke-qemu-session" always fails. Its stdout shows echo Running as debci QEMU: Checking for hardware virtualization : PASS QEMU: Checking if device /dev/kvm exists : PASS QEMU: Checking if device /dev/kvm is accessible: FAIL (Check /dev/kvm is world writable or you are in a group that is allowed to access it) QEMU: Checking if device /dev/vhost-net exists : PASS QEMU: Checking if device /dev/net/tun exists : PASS QEMU: Checking for cgroup 'cpu' controller support : PASS QEMU: Checking for cgroup 'cpuacct' controller support : PASS QEMU: Checking for cgroup 'cpuset' controller support : PASS QEMU: Checking for cgroup 'memory' controller support : PASS QEMU: Checking for cgroup 'devices' controller support : WARN (Enable 'devices' in kernel Kconfig file or mount/enable cgroup controller in your system) QEMU: Checking for cgroup 'blkio' controller support : PASS QEMU: Checking for device assignment IOMMU support : WARN (No ACPI DMAR table found, IOMMU either disabled in BIOS or not supported by this hardware platform) QEMU: Checking for secure guest support: WARN (Unknown if this platform has Secure Guest support) Its stderr shows + virt-host-validate qemu + true + virsh capabilities + virsh capabilities + grep -qs arch name='x86_64' + virsh capabilities + grep -qs os_type>hvm + virt-xml-validate debian/tests/smoke-qemu-session.xml debian/tests/smoke-qemu-session.xml validates + virsh define debian/tests/smoke-qemu-session.xml error: Failed to define domain from debian/tests/smoke-qemu-session.xml error: unsupported configuration: Emulator '/usr/bin/kvm' does not support virt type 'kvm' + cleanup + [ -z ] + virsh destroy sqs error: failed to get domain 'sqs' + true + virsh undefine sqs error: failed to get domain 'sqs' + true + CLEANED_UP=1 I suspect that "Rectrictions: needs-root" is forgotten in the test specification. The full log of autopkgtest is attached. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled libvirt-log.tar.xz Description: application/xz
Bug#983662: openvpn: autopkgtest always fails on qemu testbed
Source: openvpn Version: 2.5.1-1 Severity: normal Tags: sid bullseye Dear Maintainer, I made an autopkgtest qemu testbed by debci setup -f -s sid -a amd64 -b qemu. Then I run autopkgtest -U -B -u debci openvpn -- qemu. The test scripts in openvpn always fail. "summary" shows: server-setup-with-ca FAIL non-zero exit status 1 server-setup-with-static-key FAIL non-zero exit status 1 Inspection to log files does not give any useful cues to identify the cuase of the test failure. Full log of autopkgtest is attached. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled openvpn-log.tar.xz Description: application/xz
Bug#983661: zfs-linux: autopkgtest always fails on qemu testbed
Source: zfs-linux Version: 2.0.3-1 Severity: important Tags: sid bullseye Dear Maintainer, I made an autopkgtest qemu testbed by debci setup -f -s sid -a amd64 -b qemu. Then I run autopkgtest -U -B -u debci zfs-linux -- qemu. The test scripts in zfs-linux always fail. "summary" shows: kernel-smoke-testFAIL non-zero exit status 1 kernel-ztest FAIL stderr: zfs-test-suite FAIL non-zero exit status 1 dkms-zfs-testPASS binary-debs-modules PASS binary-debs-modules-udeb PASS The reason behind kernel-smoke-test and zfs-test-suite is modprobe: FATAL: Module zfs not found in directory /lib/modules/5.10.0-3-amd64 The full log of autopkgtest is also attached. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled zfs-log.tar.xz Description: application/xz
Bug#979434: zfsutils-linux: fails to install if zfs module is not loaded
Package: zfsutils-linux Version: 2.0.3-1 Followup-For: Bug #979434 Control: tags -1 + bullseye sid Control: found -1 2.0.3-1 Dear Maintainer, The bug #979434 remains in Debian Bullseye/Sid with a different error messages as follows. Note that linux-image-amd64 in Bullseye/Sid does not have zfs.ko. # apt-get install zfsutils-linux The following additional packages will be installed: libnvpair3linux libuutil3linux libzfs4linux libzpool4linux Suggested packages: nfs-kernel-server samba-common-bin zfs-initramfs | zfs-dracut Recommended packages: zfs-modules | zfs-dkms zfs-zed The following NEW packages will be installed: libnvpair3linux libuutil3linux libzfs4linux libzpool4linux zfsutils-linux 0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded. Selecting previously unselected package libnvpair3linux. Preparing to unpack .../libnvpair3linux_2.0.3-1_amd64.deb ... Unpacking libnvpair3linux (2.0.3-1) ... Selecting previously unselected package libuutil3linux. Preparing to unpack .../libuutil3linux_2.0.3-1_amd64.deb ... Unpacking libuutil3linux (2.0.3-1) ... Selecting previously unselected package libzfs4linux. Preparing to unpack .../libzfs4linux_2.0.3-1_amd64.deb ... Unpacking libzfs4linux (2.0.3-1) ... Selecting previously unselected package libzpool4linux. Preparing to unpack .../libzpool4linux_2.0.3-1_amd64.deb ... Unpacking libzpool4linux (2.0.3-1) ... Selecting previously unselected package zfsutils-linux. Preparing to unpack .../zfsutils-linux_2.0.3-1_amd64.deb ... Unpacking zfsutils-linux (2.0.3-1) ... Setting up libnvpair3linux (2.0.3-1) ... Setting up libuutil3linux (2.0.3-1) ... Setting up libzfs4linux (2.0.3-1) ... Setting up libzpool4linux (2.0.3-1) ... Setting up zfsutils-linux (2.0.3-1) ... modprobe: FATAL: Module zfs not found in directory /lib/modules/5.9.16-preempt Created symlink /etc/systemd/system/zfs-import.target.wants/zfs-import-cache.service → /lib/systemd/system/zfs-import-cache.service. Created symlink /etc/systemd/system/zfs.target.wants/zfs-import.target → /lib/systemd/system/zfs-import.target. Created symlink /etc/systemd/system/zfs-mount.service.wants/zfs-load-module.service → /lib/systemd/system/zfs-load-module.service. Created symlink /etc/systemd/system/zfs.target.wants/zfs-load-module.service → /lib/systemd/system/zfs-load-module.service. Created symlink /etc/systemd/system/zfs.target.wants/zfs-mount.service → /lib/systemd/system/zfs-mount.service. Created symlink /etc/systemd/system/zfs.target.wants/zfs-share.service → /lib/systemd/system/zfs-share.service. Created symlink /etc/systemd/system/zfs-volumes.target.wants/zfs-volume-wait.service → /lib/systemd/system/zfs-volume-wait.service. Created symlink /etc/systemd/system/zfs.target.wants/zfs-volumes.target → /lib/systemd/system/zfs-volumes.target. Created symlink /etc/systemd/system/multi-user.target.wants/zfs.target → /lib/systemd/system/zfs.target. zfs-import-scan.service is a disabled or a static unit, not starting it. Job for zfs-load-module.service failed because the control process exited with error code. See "systemctl status zfs-load-module.service" and "journalctl -xe" for details. A dependency job for zfs-import-cache.service failed. See 'journalctl -xe' for details. Processing triggers for man-db (2.9.4-1) ... Processing triggers for libc-bin (2.31-9) ... root@bullseye-gnome:/var/tmp/zfs# exit Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zfsutils-linux depends on: ii init-system-helpers 1.60 ii libblkid12.36.1-7 ii libc62.31-9 ii libnvpair3linux 2.0.3-1 ii libuuid1 2.36.1-7 ii libuutil3linux 2.0.3-1 ii libzfs4linux 2.0.3-1 ii libzpool4linux 2.0.3-1 ii python3 3.9.1-1 Versions of packages zfsutils-linux recommends: ii lsb-base11.1.0 pn zfs-modules | zfs-dkms pn zfs-zed Versions of packages zfsutils-linux suggests: pn nfs-kernel-server pn samba-common-bin pn zfs-initramfs | zfs-dracut -- no debconf information
Bug#706676: bug 706676 remains in the newest sysvinit-core sid
> Sorry I meant > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695568#15 Sorry again, the above is obsolete for the newest sysvinit-core. A correct patch is as follows: --- usr/share/sysvinit/inittab 2021-02-21 22:53:09.0 +0900 +++ /tmp/inittab.lxc2021-02-26 15:47:39.711010978 +0900 @@ -36,9 +36,9 @@ #kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work." # What to do when the power fails/returns. -pf::powerwait:/etc/init.d/powerfail start -pn::powerfailnow:/etc/init.d/powerfail now -po::powerokwait:/etc/init.d/powerfail stop +pf::powerwait:/sbin/shutdown -P +1 +pn::powerfailnow:/sbin/shutdown -P now +po::powerokwait:/sbin/shutdown -c "Power supply recovered." # /sbin/getty invocations for the runlevels. # Best regards, Ryutaroh
Bug#706676: bug 706676 remains in the newest sysvinit-core sid
> Could you consider to apply the known patch at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706676 Sorry I meant http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695568#15 Best regards, Ryutaroh Matsumoto
Bug#706676: bug 706676 remains in the newest sysvinit-core sid
Control: reassign -1 sysvinit-core 2.96-6 Control: tags -1 + patch bullseye sid The bug 706676 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706676 still remains in the newest sysvinit-core in Sid. Could you consider to apply the known patch at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706676 Best regards, Ryutaroh Matsumoto
Bug#983367: gvfs: autopkg test always fails on qemu testbed
I was told that autopkg test scripts should not assume that an ordinary user can sudo at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983432#10
Bug#983432: debci: sudo is prohibited by user debci
Package: debci Version: 2.15 Severity: normal Dear Maintainer, Autopkg test scripts in some packages assume that an ordinary user (e.g. debci) in the testbed can do "sudo" in qemu testbeds, see, for example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983367#10 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983367#15 for src:gvfs and src:libnfs. If /usr/share/debci/backends/qemu/customize.sh adds the user debci to the group sudo, the above test failures should be worked around. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.9.16-raspi4b (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debci depends on: ii adduser 3.118 ii amqp-tools 0.10.0-1 ii curl7.74.0-1.1 ii dctrl-tools 2.24-3 ii debian-archive-keyring 2019.1 ii debootstrap 1.0.123 ii devscripts 2.20.5 ii distro-info 1.0 ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4 ii jq 1.6-2.1 ii libjs-bootstrap 3.4.1+dfsg-2 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-flot 4.2.1+dfsg-5 ii moreutils 0.65-1 ii netcat-traditional 1.10-46 ii parallel20161222-1.1 ii patchutils 0.4.2-1 ii retry 1.0.4-2 ii rsync 3.2.3-4 ii ruby1:2.7+2 ii ruby-activerecord 2:6.0.3.5+dfsg-1 ii ruby-bunny 2.14.4-4 ii ruby-erubi 1.9.0-1 ii ruby-kaminari-activerecord 1.2.1-1 ii ruby-pg 1.2.3-1+b1 ii ruby-sinatra2.0.8.1-2 ii ruby-sinatra-contrib2.0.8.1-2 ii ruby-sqlite31.4.2-3 ii ruby-thor 1.0.1-1 ii sudo1.9.5p2-2 Versions of packages debci recommends: ii systemd-timesyncd [time-daemon] 247.3-1 Versions of packages debci suggests: pn apt-cacher-ng -- no debconf information
Bug#983360: multipath-tools: autopkgtest failure on the qemu testbed
> Other than the tests, does multipath-tools work proper for you ? > From the logs you've shared, multipath does report to see the iSCSI > LUNs. Now whether a proper map was created or not, is not clear from > the logs. I have seen no problems in bin. packages from src:multipath-tools. I run autopkgtest qemu on all packages with standard priority and in task-gnome-desktop, and reported all the errors I observed (as tests finished) except the packages already erred on ci.debian.net. Some of them turned out to be real errors... Best regards, Ryutaroh
Bug#983422: lxc: autopkg tests always fail on qemu testbed
Source: lxc Version: 4.0.6-1 Severity: normal Tags: sid bullseye User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Control: block -1 by 961578 Dear Maintainer, I believe the following issue is a bug in the testsuit and not a bug in the lxc itself. I made my qemu testbed by debci setup -f -s sid -a amd64 -b qemu. Then I run autopkgtest -B -U -u debci lxc -- qemu The four tests always fail. The relevant part of the full log is as follows. The full log is also attached. from summary: exercise FAIL timed out unprivileged-containers FAIL non-zero exit status 1 from exercise-stdout: FAIL: lxc-tests: /usr/bin/lxc-test-cgpath --- cgpath.c:73 lxc_cmd_get_cgroup_path returned NULL --- FAIL: lxc-tests: /usr/bin/lxc-test-no-new-privs --- + DONE=0 + trap cleanup EXIT SIGHUP SIGINT SIGTERM + '[' '!' -d /etc/lxc ']' + ARCH=i386 + type dpkg ++ dpkg --print-architecture + ARCH=amd64 + lxc-create -t download -n c1 -- -d ubuntu -r xenial -a amd64 Setting up the GPG keyring Downloading the image index WARNING: Failed to download the file over HTTPs The file was instead download over HTTP A server replay attack may be possible! Downloading the rootfs Downloading the metadata The image cache is now ready Unpacking the rootfs --- You just created an Ubuntu xenial amd64 (20210223_07:42) container. To enable SSH, run: apt install openssh-server No default root or user password are set by LXC. + echo 'lxc.no_new_privs = 1' + lxc-start -n c1 ++ lxc-info -n c1 -p -H + p1=14124 + '[' 14124 '!=' -1 ']' + sleep 5s + lxc-attach -n c1 --clear-env -- apt update -y WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Err:1 http://security.ubuntu.com/ubuntu xenial-security InRelease Temporary failure resolving 'security.ubuntu.com' Err:2 http://archive.ubuntu.com/ubuntu xenial InRelease Temporary failure resolving 'archive.ubuntu.com' Err:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease Temporary failure resolving 'archive.ubuntu.com' FAIL: lxc-tests: /usr/bin/lxc-test-usernsexec --- as test-userns executing /usr/bin/lxc-test-usernsexec /usr/bin/lxc-test-usernsexec: line 295: sudo: command not found --- SUMMARY: pass=38, fail=3, ignored=0 from unprivileged-containers-stderr: + mkdir -p /home/debci/.config/lxc + tee /home/debci/.config/lxc/default.conf + lxc-create -t download -n mycontainer -- -d debian -r buster -a amd64 lxc-create: mycontainer: confile.c: set_config_idmaps: 1940 Invalid argument - Failed to parse id mappings lxc-create: mycontainer: parse.c: lxc_file_for_each_line_mmap: 131 Failed to parse config file "/home/debci/.config/lxc/default.conf" at line "lxc.idmap = u 0 " lxc-create: mycontainer: conf.c: userns_exec_mapped_root: 4489 No uid mapping for container root lxc-create: mycontainer: lxccontainer.c: do_storage_create: 1292 Error chowning "/home/debci/.local/share/lxc/mycontainer/rootfs" to container root lxc-create: mycontainer: conf.c: suggest_default_idmap: 4806 You do not have subuids or subgids allocated lxc-create: mycontainer: conf.c: suggest_default_idmap: 4807 Unprivileged containers require subuids and subgids lxc-create: mycontainer: lxccontainer.c: do_lxcapi_create: 1871 Failed to create (none) storage for mycontainer lxc-create: mycontainer: tools/lxc_create.c: main: 319 Failed to create container mycontainer Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled lxc-log.tar.xz Description: application/xz
Bug#983362: Bug#983367: gvfs: autopkg test always fails on qemu testbed
Hi Simon, Thank you very much for the explanation. Previously reported another issue to src:libnfs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983362 seems to be caused by the same machanism. Should #983362 and #983367 be merged and reassigned to autopkgtest? Bes regards, Ryutaroh From: Simon McVittie Subject: Re: Bug#983367: gvfs: autopkg test always fails on qemu testbed Date: Tue, 23 Feb 2021 08:39:16 + > On Tue, 23 Feb 2021 at 11:20:49 +0900, Ryutaroh Matsumoto wrote: >> I made an autopkg qemu testbed by debci setup -f -s sid -a amd64 -b qemu. >> Then I run autopkgtest -B -U -u debci gvfs -- qemu >> It always fails with > ... >> sudo: a terminal is required to read the password; either use the -S option >> to read from standard input or configure an askpass helper >> sudo: a password is required > > This test needs to run as an ordinary user who can sudo, and autopkgtest > doesn't support that. Just running as root doesn't work: the gvfs tests > expect to run in an ordinary user's login session, so that the gvfs > daemons themselves run as that user, but the test escalates privileges to > root to set up things like Samba to test against. > > I'm told this works in Ubuntu, because Ubuntu runs tests in cloud images > with passwordless sudo available for the 'ubuntu' user by default. > > We probably need a new needs-sudo restriction that will make autopkgtest > set up the ordinary user to have passwordless sudo. > > smcv
Bug#983360: multipath-tools: autopkgtest failure on the qemu testbed
Hi Ritesh Raj Sarraf, Thank you for paying your attention to this. > I skimmed into the logs but I'm not sure what failure is being referred > to here. I meant the below part in "log" file. Feel free to downgrade the severity if you consider this as a false positive. In the following, the actual test results seem different from what are expected by the test script in multipath-tools. NVMe module may not be loaded = paths list = uuid hcildev dev_t pri dm_st chk_st vend/prod/revdev_st 2:0:0:1 sda 8:0 -1 undef undef IET,VIRTUAL-DISK unknown 3:0:0:1 sdb 8:16 -1 undef undef IET,VIRTUAL-DISK unknown 4:0:0:1 sdc 8:32 -1 undef undef IET,VIRTUAL-DISK unknown 5:0:0:1 sdd 8:48 -1 undef undef IET,VIRTUAL-DISK unknown No devices found Test WWN should now point to DM + lsscsi -liv list_ndevices: scandir: /sys/class/nvme/: No such file or directory + multipath -v3 -ll Feb 23 00:09:07 | set open fds limit to 1048576/1048576 Feb 23 00:09:07 | loading //lib/multipath/libchecktur.so checker Feb 23 00:09:07 | checker tur: message table size = 3 Feb 23 00:09:07 | loading //lib/multipath/libprioconst.so prioritizer Feb 23 00:09:07 | _init_foreign: foreign library "nvme" is not enabled Feb 23 00:09:07 | sr0: device node name blacklisted Feb 23 00:09:07 | vda: device node name blacklisted Feb 23 00:09:07 | fd0: device node name blacklisted Feb 23 00:09:07 | sda: size = 204800 Feb 23 00:09:07 | sda: vendor = IET Feb 23 00:09:07 | sda: product = VIRTUAL-DISK Feb 23 00:09:07 | sda: rev = 0001 Feb 23 00:09:07 | sda: h:b:t:l = 2:0:0:1 Feb 23 00:09:07 | sda: tgt_node_name = iqn.2016-11.foo.com:target.iscsi Feb 23 00:09:07 | sda: 1024 cyl, 4 heads, 50 sectors/track, start at 0 Feb 23 00:09:07 | sda: vpd_vendor_id = 0 "undef" (setting: multipath internal) Feb 23 00:09:07 | sda: serial = beaf11 Feb 23 00:09:07 | sda: detect_checker = yes (setting: multipath internal) Feb 23 00:09:07 | sda: path_checker = tur (setting: multipath internal) Feb 23 00:09:07 | sda: checker timeout = 30 s (setting: kernel sysfs) Feb 23 00:09:07 | sda: tur state = up Feb 23 00:09:07 | sdb: size = 204800 Feb 23 00:09:07 | sdb: vendor = IET Feb 23 00:09:07 | sdb: product = VIRTUAL-DISK Feb 23 00:09:07 | sdb: rev = 0001 Feb 23 00:09:07 | sdb: h:b:t:l = 3:0:0:1 Feb 23 00:09:07 | sdb: tgt_node_name = iqn.2016-11.foo.com:target.iscsi Feb 23 00:09:07 | sdb: 1024 cyl, 4 heads, 50 sectors/track, start at 0 Feb 23 00:09:07 | sdb: vpd_vendor_id = 0 "undef" (setting: multipath internal) Feb 23 00:09:07 | sdb: serial = beaf11 Feb 23 00:09:07 | sdb: detect_checker = yes (setting: multipath internal) Feb 23 00:09:07 | sdb: path_checker = tur (setting: multipath internal) Feb 23 00:09:07 | sdb: checker timeout = 30 s (setting: kernel sysfs) Feb 23 00:09:07 | sdb: tur state = up Feb 23 00:09:07 | sdc: size = 204800 Feb 23 00:09:07 | sdc: vendor = IET Feb 23 00:09:07 | sdc: product = VIRTUAL-DISK Feb 23 00:09:07 | sdc: rev = 0001 Feb 23 00:09:07 | sdc: h:b:t:l = 4:0:0:1 Feb 23 00:09:07 | sdc: tgt_node_name = iqn.2016-11.foo.com:target.iscsi Feb 23 00:09:07 | sdc: 1024 cyl, 4 heads, 50 sectors/track, start at 0 Feb 23 00:09:07 | sdc: vpd_vendor_id = 0 "undef" (setting: multipath internal) Feb 23 00:09:07 | sdc: serial = beaf11 Feb 23 00:09:07 | sdc: detect_checker = yes (setting: multipath internal) Feb 23 00:09:07 | sdc: path_checker = tur (setting: multipath internal) Feb 23 00:09:07 | sdc: checker timeout = 30 s (setting: kernel sysfs) Feb 23 00:09:07 | sdc: tur state = up Feb 23 00:09:07 | sdd: size = 204800 Feb 23 00:09:07 | sdd: vendor = IET Feb 23 00:09:07 | sdd: product = VIRTUAL-DISK Feb 23 00:09:07 | sdd: rev = 0001 Feb 23 00:09:07 | sdd: h:b:t:l = 5:0:0:1 Feb 23 00:09:07 | sdd: tgt_node_name = iqn.2016-11.foo.com:target.iscsi Feb 23 00:09:07 | sdd: 1024 cyl, 4 heads, 50 sectors/track, start at 0 Feb 23 00:09:07 | sdd: vpd_vendor_id = 0 "undef" (setting: multipath internal) Feb 23 00:09:07 | sdd: serial = beaf11 Feb 23 00:09:07 | sdd: detect_checker = yes (setting: multipath internal) Feb 23 00:09:07 | sdd: path_checker = tur (setting: multipath internal) Feb 23 00:09:07 | sdd: checker timeout = 30 s (setting: kernel sysfs) Feb 23 00:09:07 | sdd: tur state = up Feb 23 00:09:07 | libdevmapper version 1.02.175 (2021-01-08) Feb 23 00:09:07 | DM multipath kernel driver v1.14.0 Feb 23 00:09:07 | unloading const prioritizer Feb 23 00:09:07 | unloading tur checker + dmsetup table + echo Test WWN should now point to DM + grep dm + readlink /dev/disk/by-id/scsi-36e010001 Best regards, Ryutaroh
Bug#983377: libssh: autopkg test fails with valgrind error on armhf qemu testbed
autopkgtest [21:30:15]: summary libssh-serverFAIL non-zero exit status 253 qemu-system-aarch64: terminating on signal 15 from pid 166611 (/usr/bin/python3) Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.9.16-raspi4b (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled libssh-log.tar.xz Description: application/xz
Bug#983367: gvfs: autopkg test always fails on qemu testbed
Source: gvfs Version: 1.46.2-1 Severity: normal Tags: sid bullseye Dear Maintainer, I made an autopkg qemu testbed by debci setup -f -s sid -a amd64 -b qemu. Then I run autopkgtest -B -U -u debci gvfs -- qemu It always fails with autopkgtest [11:13:45]: test integration: [--- We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper sudo: a password is required autopkgtest [11:13:46]: test integration: ---] autopkgtest [11:13:46]: test integration: - - - - - - - - - - results - - - - - - - - - - integration FAIL non-zero exit status 1 This seems a bug in testsuite. The log is attached. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled gvfs-log.tar.xz Description: application/xz
Bug#983364: postfix: autopkg test failure only on the qemu testbed
Source: postfix Version: 3.5.6-1 Severity: important Tags: sid bullseye Dear Maintainer, I made a qemu autopkg testbed by debci setup -f -s sid -a amd64 -b qemu. Then autopkgtest -U -B -u debci postfix -- qemu always fails with ...F... == FAIL: test_10_sending_mail_direct_auth (__main__.PostfixTest) Mail authentication -- Traceback (most recent call last): File "/tmp/autopkgtest.4Xod7n/build.X4K/src/debian/tests/test-postfix.py", line 328, in test_10_sending_mail_direct_auth self.assertRaises(smtplib.SMTPAuthenticationError, self.s.login, 'root', 'crapcrapcrap') AssertionError: SMTPAuthenticationError not raised by login -- It seems a real error in postfix. On the other hand, the testsuite always passes on the lxc testbed and ci.debian.net. If the maintainer considers this as a bug in autopkgtest, please reassign this. The log is attached. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled postfix-log.tar.xz Description: application/xz
Bug#983363: unattended-upgrades: autopkg test failure only on qemu testbed
Source: unattended-upgrades
Version: 2.8
Severity: important
Tags: sid bullseye
Dear Maintainer,
I made a qemu autopkg testbed by debci setup -f -s sid -a amd64 -b qemu.
Then the test suite in unattended-upgrades 2.8 always fails with
autopkgtest [09:56:54]: test kernel-patterns: [---
DEBUG:root:Package linux-image-5.10.0-3-amd64-dbg matched linux.*-5\.10\.0\-3
and .*5\.10\.0\-3\-amd64, but did not match
re.compile('(^linux-.*-5\\.10\\.0\\-3\\-amd64$|^linux-.*-5\\.10\\.0\\-3$|^kfreebsd-.*-5\\.10\\.0\\-3\\-amd64$|^kfreebsd-.*-5\\.10\\.0\\-3$|^gnumach-.*-5\\.10\\.0\\-3\\-amd64$|^gnumach-.*-5\\.10\\.0\\-3$|^.*-modu)
DEBUG:root:Package linux-image-5.10.0-3-amd64-unsigned matched
linux.*-5\.10\.0\-3 and .*5\.10\.0\-3\-amd64, but did not match
re.compile('(^linux-.*-5\\.10\\.0\\-3\\-amd64$|^linux-.*-5\\.10\\.0\\-3$|^kfreebsd-.*-5\\.10\\.0\\-3\\-amd64$|^kfreebsd-.*-5\\.10\\.0\\-3$|^gnumach-.*-5\\.10\\.0\\-3\\-amd64$|^gnumach-.*-5\\.10\\.0\\-3$|^.*-modu)
F
==
FAIL: test_versioned (__main__.TestKernelPatterns)
kernel package patterns should cover versioned packages
--
Traceback (most recent call last):
File
"/tmp/autopkgtest.ODZ97z/build.j9G/src/test/autopkgtest_kernel_patterns.py",
line 51, in test_versioned
self.assertTrue(not not_matched,
AssertionError: False is not true : kernel packages not matched:
linux-image-5.10.0-3-amd64-unsigned linux-image-5.10.0-3-amd64-dbg
--
Ran 1 test in 0.543s
FAILED (failures=1)
This seems a real error.
The log is attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
unattended-upgrades-log.tar.xz
Description: application/xz
Bug#983362: libnfs: autopkg testsuite always fails
Source: libnfs Version: 4.0.0-1 Severity: normal Tags: sid bullseye Dear Maintainer, I made a qemu testbed by debci setup -f -s sid -a amd64 -b qemu. Then I run autopkgtest -B -U -u debci libnfs -- qemu The testsuite always fails with the following message We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper sudo: a password is required The log is attached. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled libnfs.tar.xz Description: application/xz
Bug#983360: multipath-tools: autopkgtest failure on the qemu testbed
Source: multipath-tools Version: 0.8.5-1 Severity: important Tags: bullseye sid Dear Maintainer, I run autopkgtest -U -B -u debci mutipath-tools -- qemu with a testbed made by debci setup -f -s sid -a amd64 -b qemu. The testsuite gives kpartx-file-loopback FAIL stderr: Warning: Partition table header claims that the size of partition table tgtbasedmpaths FAIL non-zero exit status 1 Looking at the log, failure of tgtbasedmpaths seems a real error. The log is attached. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled multipath-tools-autopkgtest.tar.xz Description: application/xz
Bug#983293: autopkgtest: testbed difference between lxc and qemu affecting mmdebstrap
Package: autopkgtest Version: 5.16 Severity: important Tags: bullseye sid Dear Maintainer, I report yet another testbed difference between lxc and qemu, affecting mmdebstrap 0.7.5-1 testsuite. My testbeds were prepared by debci setup -f -a amd64 -s bullseye -b ... On lxc testbed, the testsuite always return testsuiteSKIP exit status 77 and marked as skippable while on qemu it always return testsuiteFAIL non-zero exit status 1 testsuite-stderr on qemu ends as: + capsh --drop=cap_sys_admin -- -c exec "$@" exec mmdebstrap --mode=root --variant=apt testing /tmp/debian-chroot http://127.0.0.1/debian E: root mode requires mount which requires CAP_SYS_ADMIN + ret=25 + [ 25 = 0 ] + rm -r /tmp/debian-chroot rm: cannot remove '/tmp/debian-chroot': No such file or directory test.sh failed In addition to the above, the newest test result of mmdebstrap 0.7.5-1 on ci.debian.net is "PASS", which is different from both of the above. I am unsure if this is a duplicate of #983197 or #983186. Test logs are attached. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autopkgtest depends on: ii apt-utils 2.1.20 ii libdpkg-perl1.20.7.1 ii procps 2:3.3.16-5 ii python3 3.9.1-1 ii python3-debian 0.1.39 Versions of packages autopkgtest recommends: ii autodep8 0.24 Versions of packages autopkgtest suggests: ii lxc 1:4.0.6-1 pn lxd ii ovmf 2020.11-2 ii qemu-efi-aarch64 2020.11-2 ii qemu-efi-arm 2020.11-2 ii qemu-system 1:5.2+dfsg-3 ii qemu-utils1:5.2+dfsg-3 pn schroot ii vmdb2 0.22-1 -- no debconf information mmdebstrap-autopkgtest-log.tar.xz Description: application/xz
Bug#983197: autopkgtest: another difference between qemu and lxc testbeds
are attached. I also ovserve a difference of lxc and qemu testbeds on postfix test, but I cannot figure out whether the difference with postfix is the same as already reported bugs or a different one... I am running autopkgtest-virt-qemu on almost all packages in task-gnome-desktop or with standard priority. I plan to submit a report as I see yet another difference. If I do not need to do so, please let me know. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autopkgtest depends on: ii apt-utils 2.1.20 ii libdpkg-perl1.20.7.1 ii procps 2:3.3.16-5 ii python3 3.9.1-1 ii python3-debian 0.1.39 Versions of packages autopkgtest recommends: ii autodep8 0.24 Versions of packages autopkgtest suggests: ii lxc 1:4.0.6-1 pn lxd ii ovmf 2020.11-2 ii qemu-efi-aarch64 2020.11-2 ii qemu-efi-arm 2020.11-2 ii qemu-system 1:5.2+dfsg-3 ii qemu-utils1:5.2+dfsg-3 pn schroot ii vmdb2 0.22-1 -- no debconf information debootstrap-test-results.tar.xz Description: application/xz
Bug#983186: autopkgtest: difference between qemu and lxc testbeds
Package: autopkgtest Version: 5.16 Severity: important Tags: bullseye sid Dear Maintainer, I set up testbeds by debci setup -f -a amd64 -s sid -b qemu debci setup -f -a amd64 -s sid -b lxc "autopkgtest -u debci -B -U python3.9" behaves differently on QEMU and LXC testbeds. On QEMU testbed, it fails with [error] character map file `ISO-8859-1' not found: No such file or directory [error] cannot read character map directory `/usr/share/i18n/charmaps': No such file or directory [error] character map file `UTF-8' not found: No such file or directory [error] cannot read character map directory `/usr/share/i18n/charmaps': No such file or directory On the other hand, all tests pass on LXC testbed, as seen on ci.debian.net. I have not understood how this difference appear... Log of autopkgtest is attached. Any difference betwen LXC and QEMU testbeds seems important, so I chose "important" severity. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autopkgtest depends on: ii apt-utils 2.1.20 ii libdpkg-perl1.20.7.1 ii procps 2:3.3.16-5 ii python3 3.9.1-1 ii python3-debian 0.1.39 Versions of packages autopkgtest recommends: ii autodep8 0.24 Versions of packages autopkgtest suggests: ii lxc 1:4.0.6-1 pn lxd ii ovmf 2020.11-2 ii qemu-efi-aarch64 2020.11-2 ii qemu-efi-arm 2020.11-2 ii qemu-system 1:5.2+dfsg-3 ii qemu-utils1:5.2+dfsg-3 pn schroot ii vmdb2 0.22-1 -- no debconf information python3.9.tar.xz Description: application/xz
Bug#983156: debci: user debci in qemu testbed is a system user while it is not in lxc testbed
Package: debci Version: 2.15 Severity: important Tags: bullseye sid Dear Maintainer, I built a qemu testbed with debci setup -f -b qemu -s sid -a amd64 with debci and autopkgtest in Sid. Then I run test of reportbug as /usr/bin/autopkgtest --timeout-factor=10 -U -B -u debci -o /var/tmp/log15/reportbug-amd64-1613798173 reportbug -- qemu -d --timeout-reboot=600 --ram-size=3072 -c 2 /var/lib/debci/qemu/sid-amd64.img The above command runs test scripts under user "debci". But "runner" test in reportbug failed with runner-stderr as Running 'reportbug' as an administrative user is probably not a good idea! Continue [y|N|q|?]? /usr/share/debci/backends/qemu/customize.sh creates user "debci" with --system, while /usr/share/debci/backends/lxc/create-testbed creates it without --system. The above difference causes reportbug test passes on lxc testbed, while it fails on qemu testbed. I believe they should produce the same result, and this seems an important bug. Log is attached. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debci depends on: ii adduser 3.118 ii amqp-tools 0.10.0-1 ii curl7.74.0-1 ii dctrl-tools 2.24-3+b1 ii debian-archive-keyring 2019.1 ii debootstrap 1.0.123 ii devscripts 2.20.5 ii distro-info 1.0 ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4 ii jq 1.6-2.1 ii libjs-bootstrap 3.4.1+dfsg-2 ii libjs-jquery3.5.1+dfsg+~3.5.5-7 ii libjs-jquery-flot 4.2.1+dfsg-5 ii moreutils 0.65-1 ii netcat-traditional 1.10-46 ii parallel20161222-1.1 ii patchutils 0.4.2-1 ii retry 1.0.4-2 ii rsync 3.2.3-4 ii ruby1:2.7+2 ii ruby-activerecord 2:6.0.3.4+dfsg-3 ii ruby-bunny 2.14.4-4 ii ruby-erubi 1.9.0-1 ii ruby-kaminari-activerecord 1.2.1-1 ii ruby-pg 1.2.3-1+b1 ii ruby-sinatra2.0.8.1-2 ii ruby-sinatra-contrib2.0.8.1-2 ii ruby-sqlite31.4.2-2+b3 ii ruby-thor 1.0.1-1 ii sudo1.9.5p2-2 Versions of packages debci recommends: ii systemd-timesyncd [time-daemon] 247.3-1 Versions of packages debci suggests: pn apt-cacher-ng -- no debconf information reportbug-autopkgtest.tar.xz Description: application/xz
Bug#982928: systemd: boot-and-services testsuite failure on armhf
Source: systemd Version: 247.3-1 Severity: minor Dear Maintainer, Salsa latest version of autopkgtest adds armhf qemu testbed. autopkgtest-virt-qemu --dpkg-architecture=armhf on systemd fails on boot-and-service. Failure happens at boot-and-service. The relevant log is as follows. It seems that the error message is different from what is expected by testsuite script... 17:test_bash_crash (__main__.CoredumpTest) ... FAIL 41:FAIL: test_bash_crash (__main__.CoredumpTest) 44: File "/tmp/autopkgtest.XllwP8/build.pib/src/debian/tests/boot-and-services", line 457, in test_bash_crash 45:self.assertRegex(journal, b'#[0-9] .*bash') 46:AssertionError: Regex didn't match: b'#[0-9] .*bash' not found in b'-- Journal begins at Sun 2021-02-14 16:04:21 UTC, ends at Sun 2021-02-14 16:09:03 UTC. --\nFeb 14 16:09:03 host systemd-coredump[835]: Process 833 (bash) of user 0 dumped core.\n\n Stack trace of thread 833:\n #0 0xb6eba0e8 kill (libc.so.6 + 0x2a0e8)\n' Best regards, Ryutaroh Matsumoto -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-3-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.139 ii libnss-systemd 247.3-1 ii libpam-systemd 247.3-1 ii udev 247.3-1 -- no debconf information boot-and-services.tar.xz Description: application/xz
Bug#982840: linux-image-5.10.0-3-arm64: requesting scsi_debug.ko for arm64/armhf helping systemd autopkgtest
Control: retitle -1 requesting scsi_debug.ko for arm64 helping systemd autopkgtest Lack of scsi_debug.ko is also observed for ppc64el. Ryutaroh
Bug#982840: linux-image-5.10.0-3-arm64: requesting scsi_debug.ko for arm64/armhf helping systemd autopkgtest
The lack of scsci_debug.ko for arm64 also makes the autopkgtest-virt-qemu testsuite fail with udisks2. Ryutaroh
Bug#982840: linux-image-5.10.0-3-arm64: requesting scsi_debug.ko for arm64/armhf helping systemd autopkgtest
Package: src:linux Version: 5.10.13-1 Severity: wishlist Dear Maintainer, Latest autopkgtest Salsa supports arm64 QEMU testbeds. When we apply autopkgtest-virt-qemu --dpkg-architecture=arm64 or armhf on systemd, the "storage" test fails because of modprobe: FATAL: Module scsi_debug not found in directory /lib/modules/5.10.0-3-arm64 I talked with Michael Biebl on https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/113#note_227958 he wondered if it is possible to enable scsi_debug on arm64 Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.10.0-3-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.13-1 (2021-02-06) ** Command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 vc_mem.mem_size=0x3ff0 console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 rootwait rootfstype=ext4 module_blacklist=vc4 ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [ 20.631603] systemd[1]: Mounting Huge Pages File System... [ 20.683486] systemd[1]: Mounting POSIX Message Queue File System... [ 20.736492] systemd[1]: Mounting Kernel Debug File System... [ 20.787618] systemd[1]: Mounting Kernel Trace File System... [ 20.836925] systemd[1]: Starting Restore / save the current clock... [ 20.889264] systemd[1]: Starting Set the console keyboard layout... [ 20.940552] systemd[1]: Starting Create list of static device nodes for the current kernel... [ 20.992153] systemd[1]: Starting Load Kernel Module configfs... [ 21.044220] systemd[1]: Starting Load Kernel Module drm... [ 21.095387] systemd[1]: Starting Load Kernel Module fuse... [ 21.138735] fuse: init (API version 7.32) [ 21.163989] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [ 21.164255] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [ 21.227986] systemd[1]: Starting Journal Service... [ 21.464155] systemd[1]: Starting Load Kernel Modules... [ 21.513840] systemd[1]: Starting Remount Root and Kernel File Systems... [ 21.563344] EXT4-fs (sda2): re-mounted. Opts: journal_async_commit,nobarrier,data=writeback,commit=3600 [ 21.564141] systemd[1]: Starting Coldplug All udev Devices... [ 21.651478] systemd[1]: Mounted Huge Pages File System. [ 21.694010] systemd[1]: Started Journal Service. [ 22.064408] systemd-journald[243]: Received client request to flush runtime journal. [ 37.861091] vcc-sd: disabling [ 39.399477] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer [ 39.439887] vchiq: module is from the staging directory, the quality is unknown, you have been warned. [ 39.488816] iproc-rng200 fe104000.rng: hwrng registered [ 39.516318] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 39.610584] Module vc4 is blacklisted [ 39.638493] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 39.657619] cfg80211: Loaded X.509 cert 'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf' [ 39.678583] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328' [ 39.700179] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 39.706556] io scheduler kyber registered [ 39.719922] platform regulatory.0: firmware: direct-loading firmware regulatory.db [ 39.787993] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s [ 39.813752] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [ 39.844975] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 39.863636] usbcore: registered new interface driver brcmfmac [ 39.877152] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned. [ 39.905384] bcm2835_audio bcm2835_audio: card created with 8 channels [ 39.907090] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.bin [ 39.925440] mc: Linux media interface: v0.10 [ 39.956391] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt [ 40.102108] videodev: Linux video capture interface: v2.00 [ 40.107976] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 40.108103] brcmfmac mmc0:0001:1: firmware: failed to load brcm/brcmfmac43455-sdio.clm_blob (-2) [ 40.108107] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware [ 40.108113] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 40.109706] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 1 201
Bug#982167: linux-image-5.10.0-3-arm64: suspend and hibernation fail to work on raspi
Package: src:linux Version: 5.10.12-1 Severity: normal Dear Maintainer, I wonder if suspend or hibernation works on any single board computer (SBC) in a sensible way. I run the Gnome desktop environment on RPi4 with Debian. After some idle, it goes to suspend (so called "s2idle" as defined in https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html ) On usual x86 PC, touching a keyboard or a mouse make the computer to resume. But with RPi4, no method seems able to make RPi4 resume from s2idle. In addition, "systemctl hibernate" often causes kernel panic. Even with no panic, turning off and on the power supply to RPi4 does not restore pre-hibernation state, i.e., hibernation does not work. If a distro includes an SBC-specific build of kernel with CONFIG_SUSPEND=n and CONFIG_HIBERNATION=n, then the above problems probably cannot appear. But Debian only ships generic kernel build for aarch64 with CONFIG_SUSPEND=y and CONFIG_HIBERNATION=y. If this is considered responsible by another package, e.g. raspi-firmware, please feel free to reassign this. This symptom can be supressed by cat >/etc/systemd/sleep.conf.d/nosleep.conf <<'EOF' [Sleep] AllowSuspend=no AllowHibernation=no AllowSuspendThenHibernate=no AllowHybridSleep=no EOF Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.10.0-3-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.12-1 (2021-01-30) ** Command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 vc_mem.mem_size=0x3ff0 console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 rootwait rootfstype=btrfs module_blacklist=vc4 ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [0.00] Booting Linux on physical CPU 0x00 [0x410fd083] [0.00] Linux version 5.10.0-3-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.12-1 (2021-01-30) [0.00] Machine model: Raspberry Pi 4 Model B Rev 1.4 [0.00] efi: UEFI not found. [0.00] Reserved memory: created CMA memory pool at 0x3700, size 64 MiB [0.00] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a node at [mem 0x-0x0001] [0.00] NUMA: NODE_DATA [mem 0x1ff019b00-0x1ff01bfff] [0.00] Zone ranges: [0.00] DMA [mem 0x-0x3fff] [0.00] DMA32[mem 0x4000-0x] [0.00] Normal [mem 0x0001-0x0001] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x3b2f] [0.00] node 0: [mem 0x4000-0xfbff] [0.00] node 0: [mem 0x0001-0x0001] [0.00] Zeroed struct page in unavailable ranges: 256 pages [0.00] Initmem setup node 0 [mem 0x-0x0001] [0.00] On node 0 totalpages: 2061056 [0.00] DMA zone: 3788 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 242432 pages, LIFO batch:63 [0.00] DMA32 zone: 12288 pages used for memmap [0.00] DMA32 zone: 770048 pages, LIFO batch:63 [0.00] Normal zone: 16384 pages used for memmap [0.00] Normal zone: 1048576 pages, LIFO batch:63 [0.00] percpu: Embedded 33 pages/cpu s95192 r8192 d31784 u135168 [0.00] pcpu-alloc: s95192 r8192 d31784 u135168 alloc=33*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Detected PIPT I-cache on CPU0 [0.00] CPU features: detected: EL2 vector hardening [0.00] CPU features: kernel page table isolation forced ON by KASLR [0.00] CPU features: detected: Kernel page table isolation (KPTI) [0.00] CPU features: detected: Spectre-v2 [0.00] CPU features: detected: Spectre-v4 [0.00] CPU features: detected: ARM errata 1165522, 1319367, or 1530923 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 2028596 [0.00] Policy zone: Normal [0.00] Kernel command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 vc_mem.mem_size=0x3ff0 console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repai
Bug#980980: linux-image-5.10.0-3-arm64: flood of false udev messages make udisks2 eat CPU usage on usb-booted raspi4
Package: src:linux Version: 5.10.12-1 Followup-For: Bug #980980 Control: reopen -1 Control: found -1 5.10.12-1 Dear Maintainer, The bug #980980 reappears with genuin Debian kernel 5.10.12, when RPi4B 8GB model is booted from my USB MSD... A mojor difference between Debian kernel 5.10.9 on which I do not observe #980980, and 5.10.12 seems presence of vc4.ko... Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.10.0-3-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.12-1 (2021-01-30) ** Command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 vc_mem.mem_size=0x3ff0 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=256M@256M rootwait rootfstype=ext4 module_blacklist=vc4 ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [0.00] Booting Linux on physical CPU 0x00 [0x410fd083] [0.00] Linux version 5.10.0-3-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.12-1 (2021-01-30) [0.00] Machine model: Raspberry Pi 4 Model B Rev 1.4 [0.00] efi: UEFI not found. [0.00] Reserved memory: bypass linux,cma node, using cmdline CMA params instead [0.00] OF: reserved mem: node linux,cma compatible matching fail [0.00] cma: Reserved 256 MiB at 0x1000 [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a node at [mem 0x-0x0001] [0.00] NUMA: NODE_DATA [mem 0x1ff019b00-0x1ff01bfff] [0.00] Zone ranges: [0.00] DMA [mem 0x-0x3fff] [0.00] DMA32[mem 0x4000-0x] [0.00] Normal [mem 0x0001-0x0001] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x3b2f] [0.00] node 0: [mem 0x4000-0xfbff] [0.00] node 0: [mem 0x0001-0x0001] [0.00] Zeroed struct page in unavailable ranges: 256 pages [0.00] Initmem setup node 0 [mem 0x-0x0001] [0.00] On node 0 totalpages: 2061056 [0.00] DMA zone: 3788 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 242432 pages, LIFO batch:63 [0.00] DMA32 zone: 12288 pages used for memmap [0.00] DMA32 zone: 770048 pages, LIFO batch:63 [0.00] Normal zone: 16384 pages used for memmap [0.00] Normal zone: 1048576 pages, LIFO batch:63 [0.00] percpu: Embedded 33 pages/cpu s95192 r8192 d31784 u135168 [0.00] pcpu-alloc: s95192 r8192 d31784 u135168 alloc=33*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Detected PIPT I-cache on CPU0 [0.00] CPU features: detected: EL2 vector hardening [0.00] CPU features: kernel page table isolation forced ON by KASLR [0.00] CPU features: detected: Kernel page table isolation (KPTI) [0.00] CPU features: detected: Spectre-v2 [0.00] CPU features: detected: Spectre-v4 [0.00] CPU features: detected: ARM errata 1165522, 1319367, or 1530923 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 2028596 [0.00] Policy zone: Normal [0.00] Kernel command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 vc_mem.mem_size=0x3ff0 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=256M@256M rootwait rootfstype=ext4 module_blacklist=vc4 [0.00] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) [0.00] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:on, heap free:off [0.00] software IO TLB: mapped [mem 0x3730-0x3b30] (64MB) [0.00] Memory: 4714240K/8244224K available (11648K kernel code, 2420K rwdata, 6848K rodata, 5312K init, 588K bss, 282704K reserved, 262144K cma-reserved) [0.00] random: get_random_u64 called from __kmem_cache_create+0x3c/0x5c0 with crng_init=0 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] ftrace: allocating 37920 entries in 149 pages [0.00] ftrace: allocated 149 pages with 4 groups [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU
Bug#981616: Acknowledgement (linux-image-5.10.0-3-arm64-unsigned: WiFi does not work with vc4.ko on RPi4, module_blacklist=vc4 enables WiFi)
Control: retitle -1 5GHz WiFi does not work with vc4.ko on RPi4 and 4K display Control: tags -1 + upstream Control: severity -1 normal It turns out that the reported symptom happens with 5GHz Wifi and 4K display resolution at 30 Hz refreshing rate. Since the condition is rather limited, I lowered severity to normal. This is an upstream issue. It is being discussed at "linux-rpi-kernel" mailing list. Best regards, Ryutaroh Matsumoto
Bug#981616: linux-image-5.10.0-3-arm64-unsigned: WiFi does not work with vc4.ko on RPi4, module_blacklist=vc4 enables WiFi
Package: src:linux Version: 5.10.12-1 Severity: important Dear Maintainer, With Debian kernel 5.10.12-1, WiFi does not work on my RPi 4B 8GB model. Disabling vc4.ko by module_blacklist=vc4 in kernel command line restores WiFi connection... I have not yet verified if this is an upstream issue. The network is configured by systemd-networkd and wpa_supplicant, but I observe the same issue with ifupdown and NetworkManager. Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.10.0-3-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.12-1 (2021-01-30) ** Command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=tty0 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 rootwait rootfstype=ext4 module_blacklist=vc4 ** Tainted: CE (9216) * staging driver was loaded * unsigned module was loaded ** Kernel log: [0.00] Booting Linux on physical CPU 0x00 [0x410fd083] [0.00] Linux version 5.10.0-3-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.12-1 (2021-01-30) [0.00] Machine model: Raspberry Pi 4 Model B Rev 1.4 [0.00] efi: UEFI not found. [0.00] Reserved memory: created CMA memory pool at 0x3740, size 64 MiB [0.00] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a node at [mem 0x-0x0001] [0.00] NUMA: NODE_DATA [mem 0x1ff019b00-0x1ff01bfff] [0.00] Zone ranges: [0.00] DMA [mem 0x-0x3fff] [0.00] DMA32[mem 0x4000-0x] [0.00] Normal [mem 0x0001-0x0001] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x3b3f] [0.00] node 0: [mem 0x4000-0xfbff] [0.00] node 0: [mem 0x0001-0x0001] [0.00] Initmem setup node 0 [mem 0x-0x0001] [0.00] On node 0 totalpages: 2061312 [0.00] DMA zone: 3792 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 242688 pages, LIFO batch:63 [0.00] DMA32 zone: 12288 pages used for memmap [0.00] DMA32 zone: 770048 pages, LIFO batch:63 [0.00] Normal zone: 16384 pages used for memmap [0.00] Normal zone: 1048576 pages, LIFO batch:63 [0.00] percpu: Embedded 33 pages/cpu s95192 r8192 d31784 u135168 [0.00] pcpu-alloc: s95192 r8192 d31784 u135168 alloc=33*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Detected PIPT I-cache on CPU0 [0.00] CPU features: detected: EL2 vector hardening [0.00] CPU features: kernel page table isolation forced ON by KASLR [0.00] CPU features: detected: Kernel page table isolation (KPTI) [0.00] CPU features: detected: Spectre-v2 [0.00] CPU features: detected: Spectre-v4 [0.00] CPU features: detected: ARM errata 1165522, 1319367, or 1530923 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 2028848 [0.00] Policy zone: Normal [0.00] Kernel command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=tty0 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 rootwait rootfstype=ext4 module_blacklist=vc4 [0.00] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) [0.00] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:on, heap free:off [0.00] software IO TLB: mapped [mem 0x3340-0x3740] (64MB) [0.00] Memory: 4913088K/8245248K available (11648K kernel code, 2420K rwdata, 6848K rodata, 5312K init, 588K bss, 281488K reserved, 65536K cma-reserved) [0.00] random: get_random_u64 called from __kmem_cache_create+0x3c/0x5c0 with crng_init=0 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] ftrace: allocating 37920 entries in 149 pages [0.00] ftrace: allocated 149 pages with 4 groups [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU restricting CPUs
Bug#980785: linux-image-5.10.0-1-arm64: vc4.ko garbles screen ouput on raspi 4B
Patches are incorporated into the 5.10-stable branch as https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/queue-5.10/drm-vc4-correct-lbm-size-and-calculation.patch?id=138ad5c64ba368c5e077b8c178c47f12b29b8701 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/queue-5.10/drm-vc4-correct-pos1_scl-for-hvs5.patch?id=138ad5c64ba368c5e077b8c178c47f12b29b8701 Best regards, Ryutaroh
Bug#979187: 5.9.15 Debian kernel stopped booting on raspi 4 with Elecom USB MSD 056e:6a13
Control: close -1 5.10.9-1 When "reset-raspberrypi.ko" and "raspberrypi-cpufreq.ko" are loaded by initramfs, linux-image-arm64/sid can be booted from my buggy USB MSD 056e:6a13. It seems mysterious, but anyway I'd like to close #979187. Best regards, Ryutaroh Matsumoto
Bug#975392: autopkgtest-virt-qemu assumes child qemu-system-* is quiet to stdout
Control: close -1 5.16 975392 is fixed in 5.16. Best regards, Ryutaroh Matsumoto
Bug#977694: 5.10.4 Debian kernel does not boot on raspi 4 with ext4 rootfs and usb-msd
Control: reassign -1 raspi-firmware 1.20210111+ds-2 Booting linux kernel 5.10.x from USB MSD needs either * loading reset-raspberrypi.ko in initramfs, * or rebuild kernel with CONFIG_RESET_RASPBERRYPI=y in .config Anyway, the combination of linux-image-arm64/sid and raspi-firmware/sid does not allow booting RPi4 from USB-MSD. Boot from USB-MSD was possible in Debian kernel 5.9 series. I think this boot failure should be fixed by echo reset-raspberrypi >/usr/share/initramfs-tools/modules.d/raspi-firmware.conf instead of CONFIG_RESET_RASPBERRYPI=y. If this is considered an issue in src:linux, please reassign this back. Best regards, Ryutaroh Matsumoto
Bug#980980: linux-image-5.10.0-2-arm64-unsigned: flood of false udev messages make udisks2 eat CPU usage on usb-booted raspi4
Control: forwarded -1 http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-January/007985.html Forwarded to the linux-rpi-kernel list. Ryutaroh
Bug#979187: 977694 & 979187 fixed-upstream but remain in Debian :-
I found that CONFIG_RESET_RASPBERRYPI=y is enough to fix #979187, while CONFIG_RESET_RASPBERRYPI=m is not. I will submit an MR to salsa. Ryutaroh
Bug#980785: patch applied upstream
Control: tags -1 + fixed-upstream The patch attached to this report was merged upstream (drm-misc-fixes branch) as https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/vc4?h=drm-misc-fixes=f6b57101a6b31277a4bde1d8028c46e898bd2ff2 https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/vc4?h=drm-misc-fixes=78e5330329ee206d6aa4593a90320fd837f7966e This seems to satisfy the condition for Debian kernel patch at https://kernel-team.pages.debian.net/kernel-handbook/ch-bugs.html#s9.1.7 > 9.1.7. Applying patches > Patches should normally be reviewed and accepted by the relevant upstream > maintainer > (aside from necessary adjustments for an older kernel version) before being > applied. Best regards, Ryutaroh Matsumoto
Bug#980995: weston-info recommends wayland-info that does not exist in Debian
Package: weston Version: 9.0.0-2 Severity: minor Dear Maintainer, When weston-info is started, it says: $ weston-info *** Please use wayland-info instead *** weston-info is deprecated and will be removed in a future version But "weston-info" does not exist in the Debian packages. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.10raspi4usb (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages weston depends on: ii adduser 3.118 ii libc62.31-9 ii libcairo21.16.0-5 ii libcolord2 1.4.5-3 ii libdrm2 2.4.103-2 ii libegl1 1.3.2-1 ii libegl1-mesa 20.3.3-1 ii libevdev21.10.1+dfsg-1 ii libgbm1 20.3.3-1 ii libgles2 1.3.2-1 ii libglib2.0-0 2.66.4-1 ii libinput10 1.16.4-3 ii libjpeg62-turbo 1:2.0.5-2 ii liblcms2-2 2.12~rc1-2 ii libpam0g 1.4.0-2 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpixman-1-00.40.0-1 ii libpng16-16 1.6.37-3 ii libsystemd0 247.2-5 ii libwayland-client0 1.18.0-2~exp1.1 ii libwayland-cursor0 1.18.0-2~exp1.1 ii libwayland-egl1 1.18.0-2~exp1.1 ii libwayland-server0 1.18.0-2~exp1.1 ii libwebp6 0.6.1-2+b1 ii libweston-9-09.0.0-2 ii libxkbcommon01.0.3-2 Versions of packages weston recommends: ii libgl1-mesa-dri 20.3.3-1 weston suggests no packages. -- no debconf information
