Bug#903011: please consider non-disruptive workaround
Dear Debian systemd maintainers, CC: Michael, This debian bug #903011 seems rather severe to me as this makes all the per-user resource control unusable as reported to the upstream at https://github.com/systemd/systemd/issues/9502 https://github.com/systemd/systemd/issues/9512 https://github.com/systemd/systemd/issues/9578 and the upstream maintainers do not seem eager to address this bug, though the upstream report 9512 received "bug" and "v240 milestone" tags, while 9502 and 9578 keep "needs-reporter-feedback" tag despite sufficient feedbacks. There is a non-disruptive workaround for this bug, and it prevents all of the upstream bugs 9502, 9512 and 9578 above: (1) Make the following file as /lib/systemd/system/user-nonexistent.slice [Unit] Description=Dummy Slice for working around the bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903011 Documentation=https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903011 Before=systemd-user-sessions.service systemd-logind.service [Slice] Slice=user.slice [Install] WantedBy=multi-user.target (2) Run systemctl enable user-nonexistent.slice If the debian systemd maintainers (A) regard this group of three upstream bugs as severe, and (B) confirm that the above workaround works as expected and is non-disruptive, I would appreciate it if you consider incorporating the above workaround until the real cause is fixed in the upstream. Best regards, Ryutaroh Matsumoto
Bug#903011: please consider non-disruptive workaround,Re: Bug#903011: please consider non-disruptive workaround
Dear Michael, > Let's give upstream a bit more time to address this. They have lots of > bug reports to deal with and I'm a bit wary to apply a workaround I see. Thank you for your consideration. Best regards, Ryutaroh
Bug#905001: ibus-wayland always fails on weston with "No input_method global"
Package: ibus-wayland Version: 1.5.18-1 Severity: grave Tags: upstream Justification: renders package unusable Control: forwarded -1 https://github.com/ibus/ibus/issues/2030 Dear Maintainer, ibus-wayland always 100% fails with the error message "No input_method global" when used with the weston Debian package. As such, the ibus-wayland Debian package is COMPLETELY USELESS. I suggest removal of ibus-wayland package, unless the upstream fixes this. This is a bug in upstream. I already reported this to https://github.com/ibus/ibus/issues/2030 See the upstream bug report for the root cause of this. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ibus-wayland depends on: ii libc6 2.27-5 ii libglib2.0-02.56.1-2 ii libibus-1.0-5 1.5.18-1 ii libwayland-client0 1.15.0-2 ii libxkbcommon0 0.8.0-2 ibus-wayland recommends no packages. ibus-wayland suggests no packages. -- no debconf information
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.50k 42233.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#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#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#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#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#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#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#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#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#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
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&armhf 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&armhf. 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_
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&armhf 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
Control: retitle -1 requesting scsi_debug.ko for arm64&armhf&ppc64el helping systemd&udisks2 autopkgtest Lack of scsi_debug.ko is also observed for ppc64el. Ryutaroh
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#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#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#983197: autopkgtest: another difference between qemu and lxc testbeds
w- 1 root root 5, 2 Feb 20 23:12 /tmp/autopkgtest.PYPTQP/autopkgtest_tmp/from-nspawn.d/dev/pts/ptmx Full log of autopkgtests 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#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#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#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#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#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#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#983377: libssh: autopkg test fails with valgrind error on armhf qemu testbed
LEAK SUMMARY: ==1364==definitely lost: 0 bytes in 0 blocks ==1364==indirectly lost: 0 bytes in 0 blocks ==1364== possibly lost: 0 bytes in 0 blocks ==1364==still reachable: 39,300 bytes in 243 blocks ==1364== suppressed: 0 bytes in 0 blocks ==1364== Rerun with --leak-check=full to see details of leaked memory ==1364== ==1364== For lists of detected and suppressed errors, rerun with: -s ==1364== ERROR SUMMARY: 839 errors from 132 contexts (suppressed: 0 from 0) Connection closed by 127.0.0.1 port 1234 autopkgtest [21:30:12]: test libssh-server: ---] autopkgtest [21:30:14]: test libssh-server: - - - - - - - - - - results - - - - - - - - - - libssh-serverFAIL non-zero exit status 253 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#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#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#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#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#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#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#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#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
> 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#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#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#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#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#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#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
>> 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
> 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#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#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#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#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#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#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#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 w
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 GL_EXT_float_ble
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#982929: systemd: upstream&root-unit-test 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#982929: systemd: upstream&root-unit-test 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#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#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#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
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
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: 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#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#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#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#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
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#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#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#985928: vc4.ko brings unusable&unstable ALSA sinks
From: Ryutaroh Matsumoto Subject: vc4.ko brings unusable&unstable 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#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#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#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 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#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#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#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: 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#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#970211: gdm3: XDMCP Authentication is required to create a color profile
Package: gdm3 Version: 3.37.90-2 Severity: minor Dear Maintainer, When gdm3 responds to an XDMCP query, it always displays (at least the default installation with Debian installer weekly build of Sept. 2020) "Authentication Required Authentication is required to create a color profile" One can click "cancel" and both gdm3 and gnome session work fine. This is a minor cosmetic problem, but the default installation can be hopefully more friendly... I do not see a similar message with LightDM XDMCP login... 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.8.0-1-amd64 (SMP w/12 CPU threads) 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 gdm3 depends on: ii accountsservice 0.6.55-3 ii adduser 3.118 ii dbus 1.12.20-1 ii dconf-cli 0.36.0-1 ii dconf-gsettings-backend 0.36.0-1 ii debconf [debconf-2.0] 1.5.74 ii gir1.2-gdm-1.03.37.90-2 ii gnome-session [x-session-manager] 3.37.0-2 ii gnome-session-bin 3.37.0-2 ii gnome-session-common 3.37.0-2 ii gnome-settings-daemon 3.37.92-1 ii gnome-shell 3.37.92-3 ii gnome-terminal [x-terminal-emulator] 3.36.2-3 ii gsettings-desktop-schemas 3.37.2-1 ii libaccountsservice0 0.6.55-3 ii libaudit1 1:2.8.5-3+b1 ii libc6 2.31-3 ii libcanberra-gtk3-00.30-7 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-02.40.0+dfsg-5 ii libgdm1 3.37.90-2 ii libglib2.0-0 2.64.4-1 ii libglib2.0-bin2.64.4-1 ii libgtk-3-03.24.22-1 ii libkeyutils1 1.6.1-2 ii libpam-modules1.3.1-5 ii libpam-runtime1.3.1-5 ii libpam-systemd246.4-1 ii libpam0g 1.3.1-5 ii librsvg2-common 2.48.8+dfsg-1 ii libselinux1 3.1-2 ii libsystemd0 246.4-1 ii libx11-6 2:1.6.10-3 ii libxau6 1:1.0.8-1+b2 ii libxcb1 1.14-2 ii libxdmcp6 1:1.1.2-3 ii lsb-base 11.1.0 ii mutter [x-window-manager] 3.36.5-1 ii policykit-1 0.105-29 ii procps2:3.3.16-5 ii ucf 3.0043 ii x11-common1:7.7+20 ii x11-xserver-utils 7.7+8 Versions of packages gdm3 recommends: ii at-spi2-core2.36.1-1 ii desktop-base10.0.3 ii x11-xkb-utils 7.7+5 ii xserver-xephyr 2:1.20.8-2 ii xserver-xorg1:7.7+20 ii zenity 3.32.0-5 Versions of packages gdm3 suggests: pn gnome-orca pn libpam-fprintd ii libpam-gnome-keyring 3.36.0-1 -- Configuration Files: /etc/gdm3/daemon.conf changed: [daemon] [security] [xdmcp] Enable=true ShowLocalGreeter=false [chooser] [debug] -- debconf information: * shared/default-x-display-manager: gdm3 gdm3/daemon_name: /usr/sbin/gdm3
Bug#970212: gdm3: XDMCP does not work with ShowLocalGreeter=true
Package: gdm3 Version: 3.37.90-2 Severity: important Dear Maintainer, [xdmcp] Enable=true ShowLocalGreeter=false works almost fine. But with ShowLocalGreeter=true gdm3 does not show a login window to a remote X server, even without touching keyboard nor mouse of the computer running gdm3. If the combination of ShowLocalGreeter=true and Enable=true in [xdmcp], the Enable=true should also mean ShowLocalGreeter=false. 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.8.0-1-amd64 (SMP w/12 CPU threads) 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 gdm3 depends on: ii accountsservice 0.6.55-3 ii adduser 3.118 ii dbus 1.12.20-1 ii dconf-cli 0.36.0-1 ii dconf-gsettings-backend 0.36.0-1 ii debconf [debconf-2.0] 1.5.74 ii gir1.2-gdm-1.03.37.90-2 ii gnome-session [x-session-manager] 3.37.0-2 ii gnome-session-bin 3.37.0-2 ii gnome-session-common 3.37.0-2 ii gnome-settings-daemon 3.37.92-1 ii gnome-shell 3.37.92-3 ii gnome-terminal [x-terminal-emulator] 3.36.2-3 ii gsettings-desktop-schemas 3.37.2-1 ii libaccountsservice0 0.6.55-3 ii libaudit1 1:2.8.5-3+b1 ii libc6 2.31-3 ii libcanberra-gtk3-00.30-7 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-02.40.0+dfsg-5 ii libgdm1 3.37.90-2 ii libglib2.0-0 2.64.4-1 ii libglib2.0-bin2.64.4-1 ii libgtk-3-03.24.22-1 ii libkeyutils1 1.6.1-2 ii libpam-modules1.3.1-5 ii libpam-runtime1.3.1-5 ii libpam-systemd246.4-1 ii libpam0g 1.3.1-5 ii librsvg2-common 2.48.8+dfsg-1 ii libselinux1 3.1-2 ii libsystemd0 246.4-1 ii libx11-6 2:1.6.10-3 ii libxau6 1:1.0.8-1+b2 ii libxcb1 1.14-2 ii libxdmcp6 1:1.1.2-3 ii lsb-base 11.1.0 ii mutter [x-window-manager] 3.36.5-1 ii policykit-1 0.105-29 ii procps2:3.3.16-5 ii ucf 3.0043 ii x11-common1:7.7+20 ii x11-xserver-utils 7.7+8 Versions of packages gdm3 recommends: ii at-spi2-core2.36.1-1 ii desktop-base10.0.3 ii x11-xkb-utils 7.7+5 ii xserver-xephyr 2:1.20.8-2 ii xserver-xorg1:7.7+20 ii zenity 3.32.0-5 Versions of packages gdm3 suggests: pn gnome-orca pn libpam-fprintd ii libpam-gnome-keyring 3.36.0-1 -- Configuration Files: /etc/gdm3/daemon.conf changed: [daemon] [security] [xdmcp] Enable=true ShowLocalGreeter=true [chooser] [debug] -- debconf information: gdm3/daemon_name: /usr/sbin/gdm3 * shared/default-x-display-manager: gdm3
Bug#970634: linux-image-5.8.0-1-arm64: Kernel image misaligned at boot on raspi 4B
Package: src:linux Version: 5.8.7-1 Severity: minor Dear Maintainer, With a recent SD card image from raspi.debian.net, running on Raspberry Pi 4B 8GB (board revision 1.4), I see Sep 14 15:04:42 rpi4-20200909 kernel: [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader! I have no functional problem, though. Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.8.0-1-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 (2020-09-05) ** Command line: video=HDMI-A-1:3840x2160M@30,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48 dma.dmachans=0x71f5 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 console=ttyS1,115200 root=/dev/mmcblk1p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 rootwait ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [ 35.811564] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2dxsettings-autostart.service, startup phases are not supported. [ 35.831413] systemd-xdg-autostart-generator[1975]: kde-systemd-start-condition not found: No such file or directory [ 35.844863] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2dscreensaver\x2dproxy-autostart.service, startup phases are not supported. [ 35.865776] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2dcolor-autostart.service, startup phases are not supported. [ 35.885280] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.PrintNotifications-autostart.service, startup phases are not supported. [ 35.910138] systemd-xdg-autostart-generator[1975]: gnome-systemd-autostart-condition not found: No such file or directory [ 35.923850] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.Wwan-autostart.service, startup phases are not supported. [ 35.942947] systemd-xdg-autostart-generator[1975]: gnome-systemd-autostart-condition not found: No such file or directory [ 35.957811] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.ScreensaverProxy-autostart.service, startup phases are not supported. [ 35.977740] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-gnome\x2dkeyring\x2dsecrets-autostart.service, startup phases are not supported. [ 35.996632] systemd-xdg-autostart-generator[1975]: kde-systemd-start-condition not found: No such file or directory [ 36.010080] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-xfce4\x2dclipman\x2dplugin\x2dautostart-autostart.service, it is hidden. [ 36.032819] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2dxrandr-autostart.service, startup phases are not supported. [ 36.052914] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-pulseaudio-autostart.service, startup phases are not supported. [ 36.070574] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2dmouse-autostart.service, startup phases are not supported. [ 36.090536] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-at\x2dspi\x2ddbus\x2dbus-autostart.service, startup phases are not supported. [ 36.109234] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-gnome\x2dkeyring\x2dssh-autostart.service, startup phases are not supported. [ 36.127828] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.Color-autostart.service, startup phases are not supported. [ 36.151803] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.Keyboard-autostart.service, startup phases are not supported. [ 36.171779] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-cinnamon\x2dsettings\x2ddaemon\x2da11y\x2dkeyboard-autostart.service, startup phases are not supported. [ 36.193418] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.Power-autostart.service, startup phases are not supported. [ 36.212906] systemd-xdg-autostart-generator[1975]: Not generating service for XDG autostart app-org.gnome.SettingsDaemon.Sound-autostart.service, startup phases
Bug#971059: linux-image-5.8.0-2-armmp-lpae: PCI invisible on Raspberry Pi 4B 8GB
Package: src:linux Version: 5.8.10-1 Severity: normal Dear Maintainer, I am reporting a similar symptom to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968109 for a different kernel package (armmp-lpae). PCI peripherals of Raspberry Pi 4B (8GB model) are completely invisible. lspci shows nothing. As a result, USB is unusable. Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.8.0-2-armmp-lpae (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-8) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.10-1 (2020-09-19) ** Command line: video=HDMI-A-1:3840x2160M@30,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48 dma.dmachans=0x71f5 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 console=ttyS1,115200 root=/dev/mmcblk1p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 rootwait ** Tainted: CE (9216) * staging driver was loaded * unsigned module was loaded ** Kernel log: [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.8.0-2-armmp-lpae (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-8) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.10-1 (2020-09-19) [0.00] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] OF: fdt: Machine model: Raspberry Pi 4 Model B Rev 1.4 [0.00] Memory policy: Data cache writealloc [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] Zone ranges: [0.00] DMA [mem 0x-0x2fff] [0.00] Normal empty [0.00] HighMem [mem 0x3000-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: 2304 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 196608 pages, LIFO batch:63 [0.00] HighMem zone: 1864704 pages, LIFO batch:63 [0.00] percpu: Embedded 21 pages/cpu s54220 r8192 d23604 u86016 [0.00] pcpu-alloc: s54220 r8192 d23604 u86016 alloc=21*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 2059008 [0.00] Kernel command line: video=HDMI-A-1:3840x2160M@30,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48 dma.dmachans=0x71f5 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 console=ttyS1,115200 root=/dev/mmcblk1p2 rw elevator=deadline fsck.repair=yes net.ifnames=0 rootwait [0.00] Kernel parameter elevator= does not have any effect anymore. Please use sysfs to set IO scheduler for individual devices. [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:on, heap free:off [0.00] software IO TLB: mapped [mem 0x23985000-0x27985000] (64MB) [0.00] Memory: 7974884K/8245248K available (10240K kernel code, 1263K rwdata, 3228K rodata, 2048K init, 336K bss, 204828K reserved, 65536K cma-reserved, 7393280K highmem) [0.00] random: get_random_u32 called from __kmem_cache_create+0x48/0x570 with crng_init=0 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] ftrace: allocating 35987 entries in 71 pages [0.00] ftrace: allocated 71 pages with 4 groups [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] 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: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] GIC: Using split EOI/Deactivate mode [0.09
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Control: tags 930292 + fixed-upstream I believe that the problem is spotted and fixed at https://github.com/u-fischer/luaotfload/issues/55 The above seems to be uploaded to ctan on July 15. Maybe the next release of texlive-luatex package will close this issue without special effort. Ryutaroh
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Control: tags 930292 - fixed-upstream Control: forwarded 930292 https://github.com/u-fischer/luaotfload/issues/49 Sorry I was wrong. The issue in the upstream is still open as above. Ryutaroh
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Hi Hilmar, Thank you for your response. I have checked this issue under TeXLive 2019 as of July 18 (installed by "install-tl") under ubuntu 19.04 (not debian/ubuntu packages) The memory consumption of the latex file included in this bug report was "only" 1.8 GB after rm -rf ~/.texlive2019. Noto CJK fonts versions are those of ubuntu 19.04 (not the latest ones). It was 6 GB when I filed this report. Maybe 32-bit Linux can now handle the Noto CJK fonts. At least we can say significant improvement is in the upstream, though 1.8 GB seems a bit larger than necessary... I again compiled the same latex file by xelatex, but the processing finished immediately and I could not see the memory consumption by "top"... Ryutaroh From: =?UTF-8?Q?Hilmar_Preu=c3=9fe?= Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts Date: Thu, 18 Jul 2019 16:24:39 +0200 > On 18.07.19 13:39, Ryutaroh Matsumoto wrote: > > Hi Ryutaroh, > >> I believe that the problem is spotted and fixed at >> https://github.com/u-fischer/luaotfload/issues/55 >> >> The above seems to be uploaded to ctan on July 15. >> Maybe the next release of texlive-luatex package will close >> this issue without special effort. >> > > 2019-05-18 luaotfload v2.97 > * fix issue #47 > * fix whatsits interfering with letterspacing (issue #53) > * fix luaotfload-tool switches version and find not working > correctly (PR#59) > * fix luaotfload-tool support of ttc fonts (PR#58) > * sync with context files from 2019-05-18 (improves handling of > large fonts, see e.g. issue #55 and PR#58) > > So, I'd expect that v2.97 solves the problem. This version however is in > Debian unstable, hence I gave it another try. I've noticed a virtual > memory allocation of luatex having a size of 1,9 GB when building the > cache. Not sure, if this is an significant improvement over the initial > situation. > > Hilmar > -- > sigfault > #206401 http://counter.li.org >
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Hi Hilmar, I forgot to mention one thing. The version of luaotfload was 2.98 (almost the same as your 2.97). What I saw may be the same as what you told. I tend to agree with the upstream developer as he also consideres this issue as an open bug at https://github.com/u-fischer/luaotfload/issues/49 Anyway 1.8 GB is much better (for Japanese) than 6GB. Ryutaroh From: Ryutaroh Matsumoto Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts Date: Fri, 19 Jul 2019 10:39:30 +0900 (JST) > Hi Hilmar, > > Thank you for your response. > I have checked this issue under TeXLive 2019 as of July 18 > (installed by "install-tl") under ubuntu 19.04 > (not debian/ubuntu packages) > > The memory consumption of the latex file included in this > bug report was "only" 1.8 GB after rm -rf ~/.texlive2019. > Noto CJK fonts versions are those of ubuntu 19.04 > (not the latest ones). > It was 6 GB when I filed this report. > Maybe 32-bit Linux can now handle the Noto CJK fonts. > > At least we can say significant improvement is in the upstream, > though 1.8 GB seems a bit larger than necessary... > > I again compiled the same latex file by xelatex, > but the processing finished immediately and > I could not see the memory consumption by "top"... > > Ryutaroh > > > From: =?UTF-8?Q?Hilmar_Preu=c3=9fe?= > Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto > CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto > CJK fonts > Date: Thu, 18 Jul 2019 16:24:39 +0200 > >> On 18.07.19 13:39, Ryutaroh Matsumoto wrote: >> >> Hi Ryutaroh, >> >>> I believe that the problem is spotted and fixed at >>> https://github.com/u-fischer/luaotfload/issues/55 >>> >>> The above seems to be uploaded to ctan on July 15. >>> Maybe the next release of texlive-luatex package will close >>> this issue without special effort. >>> >> >> 2019-05-18 luaotfload v2.97 >> * fix issue #47 >> * fix whatsits interfering with letterspacing (issue #53) >> * fix luaotfload-tool switches version and find not working >> correctly (PR#59) >> * fix luaotfload-tool support of ttc fonts (PR#58) >> * sync with context files from 2019-05-18 (improves handling of >> large fonts, see e.g. issue #55 and PR#58) >> >> So, I'd expect that v2.97 solves the problem. This version however is in >> Debian unstable, hence I gave it another try. I've noticed a virtual >> memory allocation of luatex having a size of 1,9 GB when building the >> cache. Not sure, if this is an significant improvement over the initial >> situation. >> >> Hilmar >> -- >> sigfault >> #206401 http://counter.li.org >>
Bug#961578: lxc-tests: fails in autopkgtest-virt-qemu of cgroup2 / unified hierachy
Package: lxc-tests Version: 1:4.0.2-1 Severity: minor User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Add "systemd.unified_cgroup_hierarchy=1" to /etc/default/grub in a QEMU testbed created by autopkgtest-build-qemu, and run update-grub in it. Then autopkgtest -B -o some-directory lxc -- qemu /var/lib/libvirt/images/sid-cgroup2-ext4.img shows FAIL: lxc-tests: /usr/bin/lxc-test-cgpath --- cgpath.c:73 lxc_cmd_get_cgroup_path returned NULL It seems a non-essential symptom, though. Best regards, Ryutaroh Matsumoto
Bug#961695: minissdpd: could start before miniupnpd
Package: minissdpd Version: 1.5.20190210-1+b1 Severity: minor Tags: patch Dear Maintainer, apt-cache show minissdpd says Just make sure that MiniSSDPd is started before any other UPnP program on the computer. But systemctl list-dependencies --before minissdpd does not include miniupnpd. I suggest the following content to the systemd service file: [Unit] Before=miniupnpd.service Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages minissdpd depends on: ii debconf [debconf-2.0] 1.5.74 ii init-system-helpers1.57 ii libc6 2.30-8 ii libnfnetlink0 1.0.1-3+b1 ii lsb-base 11.1.0 minissdpd recommends no packages. minissdpd suggests no packages. -- debconf information: * minissdpd/listen: 192.168.1.2 * minissdpd/ip6: false minissdpd/why_I_am_here: * minissdpd/start_daemon: true
Bug#961701: miniupnpd: does not use binaries in net-tools
Package: miniupnpd Version: 2.1-6.1 Severity: minor Dear Maintainer, miniupnpd package depends on the net-tools package, but no file in net-tools seems being used by miniupnpd. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages miniupnpd depends on: ii debconf [debconf-2.0] 1.5.74 ii init-system-helpers1.57 ii iproute2 5.6.0-1 ii iptables 1.8.4-3 ii libc6 2.30-8 ii libip4tc2 1.8.4-3 ii libip6tc2 1.8.4-3 ii lsb-base 11.1.0 ii net-tools 1.60+git20180626.aebd88e-1 ii uuid-runtime 2.35.2-2 miniupnpd recommends no packages. miniupnpd suggests no packages. -- debconf information: * miniupnpd/force_igd_desc_v1: false * miniupnpd/start_daemon: true * miniupnpd/iface: ip6tnl1 * miniupnpd/listen: enp0s25 * miniupnpd/ip6script: false
Bug#961723: miniupnpd: does not work with the default iptables by update-alternatives
Package: miniupnpd Version: 2.1-6.1 Severity: important Dear Maintainer, When iptables Debian package is installed, we have two versions, iptables-nft and iptables-legacy. The default in Buster and Bullseye is iptables-nft, as https://wiki.debian.org/iptables /etc/miniupnpd/iptables_init.sh registers chain MINIUPNPD by iptables_nft. But https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/netfilter/iptcrdr.c tries to find chain MINIUPNPD by the legacy interface, and miniupnpd fails with chain MINIUPNPD not found when a new redirection is added. It MIGHT be good idea to build the package with ./configure --firewall=nftables ... Or, call update-alternatives --set iptables /usr/sbin/iptables-legacy by the installation script... Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages miniupnpd depends on: ii debconf [debconf-2.0] 1.5.74 ii init-system-helpers1.57 ii iproute2 5.6.0-1 ii iptables 1.8.4-3 ii libc6 2.30-8 ii libip4tc2 1.8.4-3 ii libip6tc2 1.8.4-3 ii lsb-base 11.1.0 ii net-tools 1.60+git20180626.aebd88e-1 ii uuid-runtime 2.35.2-2 miniupnpd recommends no packages. miniupnpd suggests no packages. -- debconf information: * miniupnpd/ip6script: false * miniupnpd/start_daemon: true * miniupnpd/listen: enp0s25 * miniupnpd/iface: ip6tnl1 * miniupnpd/force_igd_desc_v1: false
Bug#961877: miniupnpd: configure should not be called with --leasefile
Package: miniupnpd Version: 2.1-6.1 Severity: minor The current debian/rules has >override_dh_auto_build: >dh_auto_build -- CONFIG_OPTIONS="--igd2 --ipv6 --leasefile --vendorcfg > \ >--pcp-peer --portinuse" At https://github.com/miniupnp/miniupnp/issues/463#issuecomment-636299732 the upstream developer said > In that context, I advise to disable lease file completely. So it seems better not to use --leasefile in Debian packaging. Best regards, Ryutaroh Matsumoto
Bug#962088: miniupnpd: stronger sandbox is possible in systemd service file
Package: miniupnpd Version: 2.1-6.1 Severity: wishlist Tags: patch Dear Maintainers, I am using the latest git version of miniupnpd, with nftables backend instead of iptables used in the Debian package. A much stronger sandboxing in miniupnpd.service works for me, shown below. Systemd service file in the Debian package can also use a stronger sandbox. Also, "Type=exec" seems better than "Type=simple" used in the Debian package. [Unit] Description=UPnP Internet Gateway Device Daemon Documentation=man:miniupnpd(8) After=network-online.target minissdpd.service [Service] TasksMax=2 #for /etc/miniupnpd/nft_removeall.sh. miniupnpd alone needs only 1. CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BROADCAST CAP_NET_RAW CAP_SYSLOG MountAPIVFS=yes NoNewPrivileges=yes PrivateMounts=yes PrivateDevices=yes PrivateTmp=yes MemoryDenyWriteExecute=yes ProtectSystem=full ProtectHome=yes ProtectHostname=yes ProtectClock=yes ProtectKernelTunables=yes ProtectKernelModules=yes ProtectKernelLogs=yes ProtectControlGroups=yes LockPersonality=yes RestrictRealtime=yes RestrictNamespaces=yes RestrictSUIDSGID=yes Type=exec ExecStartPre=/etc/miniupnpd/nft_init.sh -i ip6tnl1 ExecStart=/usr/sbin/miniupnpd -d -f /etc/miniupnpd/miniupnpd.conf ExecStopPost=/etc/miniupnpd/nft_removeall.sh -i ip6tnl1 [Install] WantedBy=multi-user.target Best regards, Ryutaroh Matsumoto
Bug#943981: Proposal: Switch to cgroupv2 by default
Hi Michael, I am replying to your email on April. From: Michael Biebl Subject: Re: Bug#943981: Proposal: Switch to cgroupv2 by default Date: Thu, 23 Apr 2020 12:52:48 +0200 > (once lxc v4 enters testing)? For me lxc is the main blocker and we > probably can't wait for docker (I would document that in the release > notes / NEWS entry instead what docker users can do) lxc 4 is blocked to migrate to testing, because lxc 4 does not work well under docker https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961584 According to 961584, Salsa CI uses Docker. If change to pure cgroup2 of systemd breaks docker in Salsa CI (I think it will), change to pure cgroup2 does not seem to be accepted. Best regards, Ryutaroh
Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64
> As I said in debian-private (which, of course, is not read by > everybody), I am in a [VAC] period. I am having quite limited > available time, and this will continue at least until the beginning of > 2021. So, please, if you have an upload to make - NMU the package at > will! Hi Gunnar, CC: Christian vmdb 0.21 appeared in the upstream: http://git.liw.fi/vmdb2/log/?showmsg=1 I wonder if you have available time to package vmdb 0.21 for Debian Bullsyeye before its deadline. Best regards, Ryutaroh
Bug#977647: 5.10.4 Debian kernel does not boot on amd64 with btrfs rootfs
Control: retitle 977647 5.10.4 Debian kernel does not boot on amd64 with btrfs rootfs Control: reassign 977647 linux-image-5.10.0-1-amd64 5.10.4-1 I installed (signed) linux-image-5.10.0-1-amd64 5.10.4-1 on my laptop incompatible with Linux 5.10.2. It still fails to boot. On the other hand, I re-confirm that linux-image-5.9.0-5-amd64 5.9.15-1 boots well and there seems no problem with it... Best regards, Ryutaroh Matsumoto
Bug#977645: 5.10.1 Debian kernel does not boot on raspi 4 with ext4 rootfs and sdcard
Control: reassign -1 linux-image-5.10.0-1-arm64 5.10.4-1 Control: severity -1 important I checked the reported symptom with linux-image-5.10.0-1-arm64 5.10.4-1 It booted with completely garbled screen output. disable_fw_kms_setup=1 in config.txt did not help. Removing vc4.ko let the screen output normal. /proc/cmdline looked like dma.dmachans=0x71f5 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 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=64M rootwait Ryutaroh
Bug#977694: 5.10.4 Debian kernel does not boot on raspi 4 with ext4 rootfs and usb-msd
Control: reassign -1 linux-image-5.10.0-1-arm64 5.10.4-1 Control: retitle -1 5.10.4 Debian kernel does not boot on raspi 4 with ext4 rootfs and usb-msd I checked the reported symptom with linux-image-5.10.0-1-arm64 5.10.4-1 The symptom remains the same, unlike https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977645 I have checked the symptom with two usb msds, one is hdd and the other is ssd. Ryutaroh
Bug#979187: 5.9.15 Debian kernel stopped booting on raspi 4 with Elecom USB MSD 056e:6a13
Package: llinux-image-5.9.0-5-arm64 Version: 5.9.15-1 Severity: normal Dear Debian kernel maintainers, This is a report different from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977694 Debian kernel earlier than 5.9.14 booted with the following Elecom USB MSD. But Debian kernel 5.9.15 stopped working, while it boots with another USB MSD from Elecom... Best regards, Ryutaroh Matsumoto # lsusb -v Bus 002 Device 005: ID 056e:6a13 Elecom Co., Ltd ESD-EMN Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x056e Elecom Co., Ltd idProduct 0x6a13 bcdDevice 11.00 iManufacturer 1 ELECOM iProduct2 ESD-EMN iSerial 3 20B10164305600A9 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0079 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 504mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 8 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 8 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 8 MaxStreams 4 Data-out pipe (0x04) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 8 MaxStreams 4 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 8 MaxStreams 4 Status pipe (0x02) Binary Object Store Descriptor: bLength 5 bDescriptorType15 wTotalLength 0x0016 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType16 bDevCapabilityType 2 bmAttributes 0x0002 HIRD Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength10
Bug#979187: screenshot attached
Sorry, I forgot to attach the screenshot of boot fail... Please have a look at https://photos.app.goo.gl/gCHUEXJB74hsWQtTA
Bug#979187: 5.9.15 Debian kernel stopped booting on raspi 4 with Elecom USB MSD 056e:6a13
Hi, > reportbug linux-image-5.9.0-5-arm64 > while booted with this kernel and select the option to Follow-Up to this > bug (you might want to have the bug number handy), so that reportbug can > collect more information about your system. I wanted to do that, but as the kernel does not boot with the problematic USB MSD, I cannot use reportbug on it. Did you mean that I should boot linux-image-5.9.0-5-arm64 on an sdcard or another usb msd, and run reportbug on it? As I wrote in another email, screenshot of failing boot is placed at https://photos.app.goo.gl/gCHUEXJB74hsWQtTA Ryutaroh
