Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104
> Since Keith seems to still be busy, I'm wondering how to best fix this FTBFS > via an NMU without doing a huge change like importing a new upstream release. > > What do you think of doing a minimal NMU which just temporarily (until a new > upstream version is packaged) disables the tests? In an upstream github issue that Keith responded to a week or more ago he did say he couldn't do anything immediately as he was "off flying rockets" - I took that to mean he is likely enjoying a vacation but may be back to tackle this soon.
Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104
Source: picolibc Followup-For: Bug #1077452 X-Debbugs-Cc: tj.iam...@proton.me The package needs updating to the current (2024-09-05) upstream HEAD /and/ build-testing via sbuild to ensure it builds and tests correctly. There are an entire series of TIMEOUT issues in the arm and aarch64 tests that are fixed by various patches since 1.8.6. It is not worth trying to pick out the commits to fix the failures - I've done that extensively and it is not practical. The arm tests failed due to two issues; MMU not being enabled (commit 5252f4dd236e4) and exception vector table being generated with Thumb instructions not ARM32 (commit dd711267309fbc3d and b2d921a71ea011d4c1c) but other commits are needed preceding those. With all the arm tests fixed there are 32 failed aarch64 tests and no idea if other architectures will also have failures. Building with latest origin/main all tests pass and package builds successfully.
Bug#1080524: QUILT_PATCHES, QUILT_SERIES ignored if .pc/.quilt_{series,patches} exist
Package: quilt
Version: 0.67+really0.66-1
Severity: normal
X-Debbugs-Cc: tj.iam...@proton.me
It is confusing that despite the man-page describing the environment
over-rides that can be set either on command-line or via ~/.quiltrc,
etc., these are ignored if there are already files in ./pc/ containing
the "original" values, even when no patches are currently applied.
This caught me out whilst manually generating patches for a package that
covers multiple architectures and after initial work on a single
architecture I decided to create patch sub-dirs for each architecture
along with separate series files.
With the layout:
debian/patches/arm/
debian/patches/aarch64/
...
I then created series files for each initially as
debian/patches/series.${architecture}
and was confused that doing:
$ QUILT_SERIES=series.aarch64
$ quilt push
still used debian/patches/series that listed only the 'arm' patches.
Then I tried adding:
$ QUILT_PATCHES=debian/patches/aarch64
$ quilt push
And it still used the original ./debian/patches/series
Initially I thought either /etc/quilt.quiltrc or ~/.quiltrc were causing
this but commenting out QUILT_PATCHES in ~/.quiltrc didn't change the
result.
Eventually I read the quilt source which tipped me off that when the
./pc/ directory contains .quilt_series .quilt_patches etc., the environment
variable over-rides are ignored entirely.
This is surprising and unexpected especially when no patches are
currently applied.
man-page says:
"Files in the .pc directory are automatically removed when they are no longer
needed, so there is no need to clean up manually"
But this makes me wonder what state is required for that to be the case;
the tool should certainly make clear if it ignores *command-line* environment
variable over-rides but preferrably should honour them.
-- System Information:
Debian Release: 12.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'stable'), (100, 'proposed-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages quilt depends on:
ii bsdextrautils 2.38.1-5+deb12u1
ii bsdmainutils12.1.8
ii bzip2 1.0.8-5+b1
ii diffstat1.65-1
ii ed 1.19-1
ii gettext 0.21-12
ii patch 2.7.6-7
ii perl5.36.0-7+deb12u1
ii sensible-utils 0.0.17+nmu1
Versions of packages quilt recommends:
ii less 590-2.1~deb12u2
Versions of packages quilt suggests:
ii exim4-daemon-light [mail-transport-agent] 4.96-15+deb12u5
ii graphviz 2.42.2-7+b3
pn procmail
-- no debconf information
Bug#1079835: Regression: QEMU 9 makes picolibc FTBFS (failing tests)
Source: qemu-system-arm
Followup-For: Bug #1079835
X-Debbugs-Cc: tj.iam...@proton.me
With the failed sbuild environment still available one can debug the
FAIL or TIMEOUT test binaries from outside:
$ base=/srv/NAS/Sunny/SourceCode/builds/tmp.sbuild.voDevnvR
A FAIL test:
$ sudo qemu-system-arm -m 1G -chardev stdio,mux=on,id=stdio0
-semihosting-config enable=on,chardev=stdio0,arg=program-name -monitor none
-serial none -machine none,accel=tcg -cpu cortex-a7 -device
loader,file=$base/build/picolibc-ZiYfA8/picolibc-1.8.6/debian/build/arm-none-eabi/test/printff_scanff_thumb_v7_nofp,cpu-num=0
-nographic
hello world 1
checking floating point
checking pos args
ARM fault: undef
R0: 0x0002
R1: 0x6fc7
R2: 0x201ffeb4
R3: 0x2020
R4: 0x
R5: 0x2004
R6: 0x201ffecc
PC: 0x0342
A TIMEOUT test (process hangs indefinitely):
$ sudo qemu-system-arm -m 1G -chardev stdio,mux=on,id=stdio0
-semihosting-config enable=on,chardev=stdio0,arg=program-name -monitor none
-serial none -machine none,accel=tcg -cpu cortex-a7 -device
loader,file=$base/build/picolibc-ZiYfA8/picolibc-1.8.6/debian/build/arm-none-eabi/newlib/libm/test/math_test_thumb_v7_a_nofp,cpu-num=0
-nographic
Debugging via gdb:
Terminal A:
$ sudo qemu-system-arm -gdb tcp:: -S -m 1G -chardev stdio,mux=on,id=stdio0
-semihosting-config enable=on,chardev=stdio0,arg=program-name -monitor none
-serial none -machine none,accel=tcg -cpu cortex-a7 -device
loader,file=$base/build/picolibc-ZiYfA8/picolibc-1.8.6/debian/build/arm-none-eabi/test/printff_scanff_thumb_v7_nofp,cpu-num=0
-nographic
Terminal B:
$ sudo gdb-multiarch -ex "directory
/srv/NAS/Sunny/SourceCode/builds/tmp.sbuild.voDevnvR/build/picolibc-ZiYfA8/picolibc-1.8.6/debian/build/arm-none-eabi"
-ex "file
/srv/NAS/Sunny/SourceCode/builds/tmp.sbuild.voDevnvR/build/picolibc-ZiYfA8/picolibc-1.8.6/debian/build/arm-none-eabi/test/printff_scanff_thumb_v7_nofp"
-ex "set sysroot $base" -ex "target remote localhost:" -ex "break main"
-ex "break ../../../test/printf_scanf.c:254"
GNU gdb (Debian 13.1-3) 13.1
...
Source directories searched:
/srv/NAS/Sunny/SourceCode/builds/tmp.sbuild.voDevnvR/build/picolibc-ZiYfA8/picolibc-1.8.6/debian/build/arm-none-eabi:$cdir:$cwd
Reading symbols from
/srv/NAS/Sunny/SourceCode/builds/tmp.sbuild.voDevnvR/build/picolibc-ZiYfA8/picolibc-1.8.6/debian/build/arm-none-eabi/test/printff_scanff_thumb_v7_nofp...
Remote debugging using localhost:
_start () at ../../../picocrt/machine/arm/crt0.c:117
117 __asm__("mov sp, %0" : : "r" (__stack));
Breakpoint 1 at 0x140: file ../../../test/printf_scanf.c, line 185.
Breakpoint 2 at 0x1ec: ../../../test/printf_scanf.c:254. (2 locations)
(gdb) c
Continuing.
Breakpoint 1, main () at ../../../test/printf_scanf.c:185
185 {
(gdb) c
Continuing.
Breakpoint 2.1, main () at ../../../test/printf_scanf.c:254
254 for (x = 0; x <= 6; x++) {
(gdb) s
256 char tbuf[10] = "x";
(gdb) s
arm_data_abort_vector () at ../../../picocrt/machine/arm/crt0.c:284
284 VECTOR_COMMON;
(gdb) s
285 __asm__("mov r1, #" REASON(REASON_UNDEF));
(gdb) s
286 __asm__("bl arm_fault");
(gdb) s
arm_fault (f=0x201fffe0, reason=0) at ../../../picocrt/machine/arm/crt0.c:251
251 printf("ARM fault: %s\n", reasons[reason]);
Bug#1079443: fts_build() calling __getdents breaks 32bit on 64bit
Source: glibc Followup-For: Bug #1079443 X-Debbugs-Cc: tj.iam...@proton.me This seems to confirm the cause: debvm$ sudo chroot debvm.fs apt-get install libc6-dev debvm$ grep -rn 'define .*TIMESIZE' debvm.fs/usr/include debvm.fs/usr/include/arm-linux-gnueabihf/bits/timesize.h:20:#define __TIMESIZE 32
Bug#1079443: fts_build() calling __getdents breaks 32bit on 64bit
Source: glibc Followup-For: Bug #1079443 X-Debbugs-Cc: tj.iam...@proton.me fts_* functions, and fts_read() -> fts_build() end up calling > sysdeps/unix/sysv/linux/readdir.c: #if !_DIRENT_MATCHES_DIRENT64 __readdir_unlocked() So follow this back to see why it is (not) set (on armhf) > sysdeps/unix/sysv/linux/bits/dirent.h: #if defined __OFF_T_MATCHES_OFF64_T && defined __INO_T_MATCHES_INO64_T /* Inform libc code that these two types are effectively identical. */ # define _DIRENT_MATCHES_DIRENT64 1 #else # define _DIRENT_MATCHES_DIRENT64 0 #endif > sysdeps/unix/sysv/linux/bits/typesizes.h: #if defined __LP64__ || (__TIMESIZE == 64 && __WORDSIZE == 32) /* Tell the libc code that off_t and off64_t are actually the same type for all ABI purposes, even if possibly expressed as different base types for C type-checking purposes. */ # define __OFF_T_MATCHES_OFF64_T 1 /* Same for ino_t and ino64_t. */ # define __INO_T_MATCHES_INO64_T 1 > sysdeps/unix/sysv/linux/arm/bits/timesize.h: #define __TIMESIZE 32 > or bits/timesize.h: #define __TIMESIZE 64 > sysdeps/wordsize-32/bits/wordsize.h: #define __WORDSIZE 32 > sysdeps/wordsize-64/bits/wordsize.h: #define __WORDSIZE 64 Debian 2.39-7 build log: $ getbuildlog glibc 2.39-7 armhf ... echo -n "Build started: " ; date --rfc-2822; \ echo "---"; \ cd build-tree/armhf-libc && \ CC="arm-linux-gnueabihf-gcc-13 -U_FILE_OFFSET_BITS -U_TIME_BITS" \ CXX="arm-linux-gnueabihf-g++-13 -U_FILE_OFFSET_BITS -U_TIME_BITS" \ ... and gcc's options have early in their list: -I../sysdeps/unix/sysv/linux/arm that likely means any #include will be using > sysdeps/unix/sysv/linux/arm/bits/timesize.h: #define __TIMESIZE 32
Bug#1079443: fts_build() calling __getdents breaks 32bit on 64bit
Source: glibc Followup-For: Bug #1079443 X-Debbugs-Cc: tj.iam...@proton.me To ensure we capture all relavent info I'm copying here some test results Chris produced using a custom-written executable. Using emulation: $ sudo chroot /mnt/e4/armhf /pdents-armhf fd = 3 dp = 0x403190 entry 0 ino 10302 off 1335313586018546964 name ublk_drv.ko.xz dp = 0x4031b8 entry 1 ino 10298 off 144146656300210 name nbd.ko.xz dp = 0x4031d8 entry 2 ino 10304 off 2208640688691778334 name xen-blkback dp = 0x4031f8 entry 3 ino 10216 off 240007329322655 name .. dp = 0x403210 entry 4 ino 10301 off 2568612365796029161 name rbd.ko.xz dp = 0x403230 entry 5 ino 10295 off 2642141484322030168 name loop.ko.xz dp = 0x403250 entry 6 ino 10292 off 3028993804646130172 name brd.ko.xz dp = 0x403270 entry 7 ino 10307 off 3830214992999727188 name zram dp = 0x403288 entry 8 ino 10290 off 3870617626237255389 name aoe dp = 0x4032a0 entry 9 ino 10303 off 4740941134542001648 name virtio_blk.ko.xz dp = 0x4032c8 entry 10 ino 10293 off 5108466411937333823 name drbd dp = 0x4032e0 entry 11 ino 10296 off 6213628172795130112 name mtip32xx dp = 0x403300 entry 12 ino 10306 off 7520475764088490632 name xen-blkfront.ko.xz dp = 0x403328 entry 13 ino 10289 off 8124502982319486926 name . dp = 0x403340 entry 14 ino 10299 off 9223372036854775807 name null_blk dp = 0x403360 entry 15 ino 0 off 0 name --- fts: /lib/modules/6.10.6-armmp/kernel/drivers/block fts: /lib/modules/6.10.6-armmp/kernel/drivers/block --- Direct: $ ./pdents fd = 3 dp = 0xe272e2a0 entry 0 ino 10302 off 1335313586018546964 name ublk_drv.ko.xz dp = 0xe272e2c8 entry 1 ino 10298 off 144146656300210 name nbd.ko.xz dp = 0xe272e2e8 entry 2 ino 10304 off 2208640688691778334 name xen-blkback dp = 0xe272e308 entry 3 ino 10216 off 240007329322655 name .. dp = 0xe272e320 entry 4 ino 10301 off 2568612365796029161 name rbd.ko.xz dp = 0xe272e340 entry 5 ino 10295 off 2642141484322030168 name loop.ko.xz dp = 0xe272e360 entry 6 ino 10292 off 3028993804646130172 name brd.ko.xz dp = 0xe272e380 entry 7 ino 10307 off 3830214992999727188 name zram dp = 0xe272e398 entry 8 ino 10290 off 3870617626237255389 name aoe dp = 0xe272e3b0 entry 9 ino 10303 off 4740941134542001648 name virtio_blk.ko.xz dp = 0xe272e3d8 entry 10 ino 10293 off 5108466411937333823 name drbd dp = 0xe272e3f0 entry 11 ino 10296 off 6213628172795130112 name mtip32xx dp = 0xe272e410 entry 12 ino 10306 off 7520475764088490632 name xen-blkfront.ko.xz dp = 0xe272e438 entry 13 ino 10289 off 8124502982319486926 name . dp = 0xe272e450 entry 14 ino 10299 off 9223372036854775807 name null_blk dp = 0xe272e470 entry 15 ino 0 off 0 name --- fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/ublk_drv.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/nbd.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/xen-blkback fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/xen-blkback/xen-blkback.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/xen-blkback fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/rbd.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/loop.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/brd.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/zram fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/zram/zram.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/zram fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/aoe fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/aoe/aoe.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/aoe fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/virtio_blk.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/drbd fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/drbd/drbd.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/drbd fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/mtip32xx fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/mtip32xx/mtip32xx.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/mtip32xx fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/xen-blkfront.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/null_blk fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/null_blk/null_blk.ko.xz fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block/null_blk fts: /mnt/e4/armhf/lib/modules/6.10.6-armmp/kernel/drivers/block ---
Bug#1079443: glibc: Change bug title
Source: glibc Followup-For: Bug #1079443 X-Debbugs-Cc: tj.iam...@proton.me Control: retitle -1 fts_build() calling __getdents breaks 32bit on 64bit mjt identified that as well as this report's armhf emulation on 64 bit host he can reproduce the apparent problem with i386: Quotes: see comment #12 in [0] it looks like the prob is in fts in glibc, who calls __getdents() instead of __getdents64 gdb'ing this on i386 also leads to __readdir and not __readdir64 if it called getdents() instead of __getdents(), it would be aliased to getdents64 with LFS [0] https://sourceware.org/bugzilla/show_bug.cgi?id=23960#c12
Bug#1079443: dracut-install ... -m =drivers/XXX is ignored
Package: dracut-install Followup-For: Bug #1079443 X-Debbugs-Cc: tj.iam...@proton.me Control: reassign -1 glibc After considerable discussion and investigation on IRC #debian-devel on 20240824 after 1000 UTC the consensus is this is a glibc issue with the (rarely used) fts_* functions calling __getdents() instead of getdents().
Bug#1079443: dracut-install ... -m =drivers/XXX is ignored
Package: dracut-install
Followup-For: Bug #1079443
X-Debbugs-Cc: tj.iam...@proton.me
Control: affects -1 + qemu glibc
I think this will need re-assigning to another package but not clear
which as yet.
Thanks to Chris's investigations in the last few hours he's identified a
couple of bug reports that may be the cause or related; they do seem to
shed some needed insights from glibc experts onto this and contain quite
a few patch attempts.
>From my initial reading of both and considering our experience here with
the debvm arch-test succeeding a week ago but failing now I wonder if
this is simply because the host running the CI jobs previously had
offsets that fitted inside 32 bits but later exceeded that and so an
overflow occurred (since host is returning 64 bits but the emulated
qemu-arm 32-bit glibc throws away the top 32 bits).
glibc <> qemu-user (going on since 2018):
[2.28 Regression]: New getdents{64} implementation breaks qemu-user
https://sourceware.org/bugzilla/show_bug.cgi?id=23960
kernel ext4 <> glibc:
Ext4 64 bit hash breaks 32 bit glibc 2.28+
https://bugzilla.kernel.org/show_bug.cgi?id=205957
Bug#1079443: dracut-install ... -m =drivers/XXX is ignored
Package: dracut-install
Followup-For: Bug #1079443
X-Debbugs-Cc: tj.iam...@proton.me
Further debugging leads to the getdents64 syscall returning -1 at
https://sources.debian.org/src/glibc/2.39-7/sysdeps/unix/sysv/linux/getdents.c/?hl=56#L58
I'm including a dump of the gdb session including my attempts to examine
values as it went. Due to the compiler optimsing the code gdb jumps
around a bit and it is confusing since some apparent statement
executions aren't reached.
__readdir_unlocked (dirp=0x400180d8) at ../sysdeps/unix/sysv/linux/readdir.c:38
38bytes = __getdents (dirp->fd, dirp->data, maxread);
(gdb) p *dirp
$2 = {fd = 5, lock = 1, allocation = 32768, size = 0, offset = 0, filepos = 0,
errcode = 0, data = 0x400180f8 "\f"}
(gdb) s
__getdents (fd=5, buf0=buf0@entry=0x400180f8, nbytes=32768) at
../sysdeps/unix/sysv/linux/getdents.c:35
35 {
(gdb) s
56retval = INLINE_SYSCALL_CALL (getdents64, fd, kbuf, kbytes);
(gdb) p *buf0
Attempt to dereference a generic pointer.
(gdb) p fd
$3 = 5
(gdb) p kbuf
$4 = (union {...} *) 0x400180f8
(gdb) p *kbuf
$5 = {k = {d_ino = 12, d_off = 1, d_reclen = 24, d_type = 4 '\004',
d_name =
".\000\337{\006\004\000\000\000\000\000\000\000oׯ\002\000\000\000\000\030\000\004..\000ti\r\000\000\000\000\000\000\000\344\r[\006\000\000\000\000
\000\buevent\000\000runti:\030\000\000\000\000\000\000\243\246\307\016\000\000\000\000
\000\004reg-dummy\000es\000\250F\000\000\000\000\000\000\262dU\022\000\000\000\000
\000\004kgdboc\000\brunti=\031\000\000\000\000\000\000{j\210\023\000\000\000\000\030\000\004PCCT\000\272%\000\000\000\000\000\000\026\331?$\000\000\000\000
\000\004acpi-cpufreq\000\016\000\000\000\000\000\000\000\322\375\217&\000\000\000\000
\000\004p"...}, u = {d_ino = 12, d_off = 0, d_reclen = 1,
d_type = 0 '\000',
d_name =
"\000\000\000\000\000\030\000\004.\000\337{\006\004\000\000\000\000\000\000\000oׯ\002\000\000\000\000\030\000\004..\000ti\r\000\000\000\000\000\000\000\344\r[\006\000\000\000\000
\000\buevent\000\000runti:\030\000\000\000\000\000\000\243\246\307\016\000\000\000\000
\000\004reg-dummy\000es\000\250F\000\000\000\000\000\000\262dU\022\000\000\000\000
\000\004kgdboc\000\brunti=\031\000\000\000\000\000\000{j\210\023\000\000\000\000\030\000\004PCCT\000\272%\000\000\000\000\000\000\026\331?$\000\000\000\000
\000\004acpi-cpufreq\000\016\000\000\000\000\000\000\000\322\375\217&"...}, b
= "\f"}
(gdb) p kbytes
$6 = 32768
(gdb) s
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:40
40 push{r7, lr}
(gdb) s
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:45
45 mov r7, ip
(gdb) s
46 swi 0x0
(gdb) s
__getdents (fd=5, buf0=buf0@entry=0x400180f8, nbytes=32768) at
../sysdeps/unix/sysv/linux/getdents.c:56
56retval = INLINE_SYSCALL_CALL (getdents64, fd, kbuf, kbytes);
(gdb) s
66while (&inp->b < &kbuf->b + retval)
(gdb) p retval
$7 =
(gdb) p *kbuf
$8 = {k = {d_ino = 10304, d_off = 1020342120631249655, d_reclen = 40, d_type =
0 '\000',
d_name =
"ublk_drv.ko.xz\000\257\002\000\000\000\000?,\000\000\000\000\000\000\235\026\253\206v\344n\016\030\000\000aoe\000\000?\"\000\000\000\000\000\000dž\260W\257\322\321\030\030\000\000.\000\000\000\000@J\000\000\000\000\000\000\234\276\374\342\215\317Y%\030\000\000zram\000?\032\000\000\000\000\000\000<\311C\272Xz_'
\000\000brd.ko.xz\000nti?\034\000\000\000\000\000\000\202\177\242\026\220\3141<\030\000\000drbd\000@*\000\000\000\000\000\000\333\002\325\tC\246|A
\000\000null_blk\000req\000@Z\000\000\000\000\000\000\247?i\330$\336d\\
\000\000x"...}, u = {d_ino = 10304, d_off = 0, d_reclen = 10999, d_type = 152
'\230',
d_name =
"\261\300\373(\016(\000\000ublk_drv.ko.xz\000\257\002\000\000\000\000?,\000\000\000\000\000\000\235\026\253\206v\344n\016\030\000\000aoe\000\000?\"\000\000\000\000\000\000dž\260W\257\322\321\030\030\000\000.\000\000\000\000@J\000\000\000\000\000\000\234\276\374\342\215\317Y%\030\000\000zram\000?\032\000\000\000\000\000\000<\311C\272Xz_'
\000\000brd.ko.xz\000nti?\034\000\000\000\000\000\000\202\177\242\026\220\3141<\030\000\000drbd\000@*\000\000\000\000\000\000\333\002\325\tC\246|A
\000\000null_blk\000req\000@Z\000\000\000\000\000\000\247?i\330"...}, b = "@"}
(gdb) n
72size_t old_reclen = inp->k.d_reclen;
(gdb) n
82memmove (outp->u.d_name, inp->k.d_name,
(gdb) n
79const int64_t d_off = inp->k.d_off;
(gdb) p outp->u.d_name
$9 =
"\261\300\373(\016(\000\000ublk_drv.ko.xz\000\257\002\000\000\000\000?,\000\000\000\000\000\000\235\026\253\206v\344n\016\030\000\000aoe\000\000?\"\000\000\000\000\000\000dž\260W\257\322\321\030\030\000\000.\000\000\000\000@J\000\000\000\000\000\000\234\276\374\342\215\317Y%\030\000\000zram\000?\032\000\000\000\000\000\000<\311C\272Xz_'
\000\000brd.ko.xz\000nti?\034\000\000\000\000\000\000\202\177\242\026\220\3141<\030\000\000drbd\000@*\000\000\000\000\000\000\333\002\325\tC\246|A
\000\000null_blk\
Bug#1079443: dracut-install ... -m =drivers/XXX is ignored
Package: dracut-install
Followup-For: Bug #1079443
X-Debbugs-Cc: tj.iam...@proton.me
I've managed to set up a gdb-multilib debug session and have been
single-stepping through the glibc fts_* code that seems to be affected.
As Chris has found that xfs file-system doesn't seem to be affected but
ext4 is (the host file-system, not the file-system created by debvm)
that confuses the issue somewhat since the reproducers also work on a
several different kernel versions. I'm using a mainline build of
v6.10.6 amd64; Chris reported 6.1.0-23-arm64.
In my debug case the setup is in two terminals. I execute dracut-install
directly using qemu (rather than in the chroot) in order to be able to
do:
debian/debvm$ base=$PWD/debvm.fs; qemu-arm-static -g -L $base
$base/usr/lib/dracut/dracut-install -D $base/var/tmp/ --kerneldir
$base/lib/modules/6.10.6-armmp --firmwaredirs
$base/lib/firmware/updates/6.10.6-armmp:$base/lib/firmware/updates:$base/lib/firmware/6.10.6-armmp:$base/lib/firmware
--debug -m =drivers/block
I fetched the glibc source so gdb can use it:
$ cd /srv/NAS/Sunny/SourceCode/glibc
$ dget -x http://deb.debian.org/debian/pool/main/g/glibc/glibc_2.39-7.dsc
In the second terminal, in the dracut-ng base directory, I do:
dracut-ng$ gdb-multiarch -ex "directory
/srv/NAS/Sunny/SourceCode/glibc/glibc-2.39" -ex "file
/srv/NAS/Sunny/SourceCode/debian/debvm/debvm.fs/usr/lib/dracut/dracut-install"
-ex "set sysroot /srv/NAS/Sunny/SourceCode/debian/debvm/debvm.fs" -ex "target
remote localhost:" -ex "break install_modules" -ex "break fts_open" -ex
"break fts_build if sp->fts_path[2] != 'y'"
That last conditional breakpoint is to avoid it stopping for all nodes at
or under "/sys/devices/platform".
Then using 'c' to fast-forward to the useful points, looking for the
".../kernel/drivers/block" in sp->fts_path
(gdb) p *sp
$8 = {fts_cur = 0x400160f8, fts_child = 0x0, fts_array = 0x0, fts_dev = 1792,
fts_path = 0x40012450
"/srv/NAS/Sunny/SourceCode/debian/debvm/debvm.fs/lib/modules/6.10.6-armmp/kernel/drivers/block",
fts_rfd = 0,
fts_pathlen = 4352, fts_nitems = 0, fts_compar = 0x0, fts_options = 15}
>From here the loop that I believe should be iterating over the files and
sub-dirs via calling __readdir() does zero iterations due to __readdir()
presumably returning NULL and setting an error code.
I've not yet traced into that; that's for another day I think.
The loop:
https://codesearch.debian.net/show?file=glibc_2.39-7%2Fio%2Ffts.c&line=723#L723
Bug#1079443: dracut-install ... -m =drivers/XXX is ignored
Package: dracut-install Followup-For: Bug #1079443 X-Debbugs-Cc: tj.iam...@proton.me Control: affects -1 + debvm Results of further diagnosis. First, discovered that -v overrides --debug: removing -v from the command line allowed debug messages and removing -o means any missing modules causes an error, so now the small reproducer reports: dracut-install: Handle module '=drivers/block' dracut-install: Handling =drivers/block dracut-install: Ignoring /lib/modules/6.10.6-armmp/extra/drivers/block dracut-install: Ignoring /lib/modules/6.10.6-armmp/kernel/drivers/block dracut-install: Ignoring /lib/modules/6.10.6-armmp/kernel/drivers/block dracut-install: Ignoring /lib/modules/6.10.6-armmp/updates/drivers/block dracut-install: ERROR: installing '=drivers/block' The "Ignoring" message is generated in install_modules() when an FTSENT is not a file nor a symbolic link. There are 13 files and sub-directories in the directory but we only see 2 messages for the module's path. Since the directory is visited twice by the fts* functions, once for preorder and again for postorder, that suggests something interesting is going on. I note fts_open( ... FTS_NOSTAT ...) and confirm with strace that no stat*() functions are called on the contents of the directory. This would imply that the FTSENT fts_info == FTS_NSOK and that would explain the results being seen.
Bug#1079443: dracut-install ... -m =drivers/XXX is ignored
Package: dracut-install Version: 103-1.1 Severity: important X-Debbugs-Cc: tj.iam...@proton.me debvm in the last week is failing armhf/armel build tests because virtio_blk kernel module is not installed in the initrd.img. This was reported and help requested by Helmut Grohne on IRC #debian-devel. Builds a week ago succeed [0] but latest builds [1] fail. I've been diagnosing the issue and began by focusing on any packages being installed for the test. That is kernel, udev, initramfs-tools, and dracut-install. I reproduced the issue on a Bookworm amd64 host but Helmut was unable to on an Unstable amd64 host. After instrumenting initramfs-tools with additional log messages it confirmed that the correct list of modules, and module directories, is being passed to dracut-install. I tried adding --debug to gain more insight but it seems to ignore it or not hit any code paths that use log_debug(). However a log from update-initramfs -vu or executing dracut-install directly in the armhf chroot both show it ignores =drivers/XXX entries in the module list. A simple reproducer is: $ apt-get install debvm $ git clone https://salsa.debian.org/helmutg/debvm.git $ cd debvm $ tests/create-and-run.sh armhf unstable 2>&1 | /usr/bin/tee c-a-r.01.log $ # kill the 'stuck' qemu guest process $ mkdir debvm.fs $ ldev="$( /usr/sbin/losetup --find --show test.ext4 )" $ sudo mount $ldev ./debvm.fs $ sudo /usr/sbin/chroot ./debvm.fs/ /usr/lib/dracut/dracut-install --debug -D /var/tmp/ --kerneldir /lib/modules/6.10.6-armmp --firmwaredirs /lib/firmware/updates/6.10.6-armmp:/lib/firmware/updates:/lib/firmware/6.10.6-armmp:/lib/firmware --debug -v -o -m 8139cp =drivers/block acenic dracut-install: mkdir '/var/tmp/usr' dracut-install: mkdir '/var/tmp/usr/lib' dracut-install: ln -s 'usr/lib' '/var/tmp/lib' dracut-install: mkdir '/var/tmp/lib/modules' dracut-install: mkdir '/var/tmp/lib/modules/6.10.6-armmp' dracut-install: mkdir '/var/tmp/lib/modules/6.10.6-armmp/kernel' dracut-install: mkdir '/var/tmp/lib/modules/6.10.6-armmp/kernel/drivers' dracut-install: mkdir '/var/tmp/lib/modules/6.10.6-armmp/kernel/drivers/net' dracut-install: mkdir '/var/tmp/lib/modules/6.10.6-armmp/kernel/drivers/net/ethernet' dracut-install: mkdir '/var/tmp/lib/modules/6.10.6-armmp/kernel/drivers/net/ethernet/realtek' dracut-install: cp '/lib/modules/6.10.6-armmp/kernel/drivers/net/ethernet/realtek/8139cp.ko.xz' '/var/tmp/lib/modules/6.10.6-armmp/kernel/drivers/net/ethernet/realtek/8139cp.ko.xz' dracut-install: cp '/lib/modules/6.10.6-armmp/kernel/drivers/net/mii.ko.xz' '/var/tmp/lib/modules/6.10.6-armmp/kernel/drivers/net/mii.ko.xz' dracut-install: mkdir '/var/tmp/lib/modules/6.10.6-armmp/kernel/drivers/net/ethernet/alteon' dracut-install: cp '/lib/modules/6.10.6-armmp/kernel/drivers/net/ethernet/alteon/acenic.ko.xz' '/var/tmp/lib/modules/6.10.6-armmp/kernel/drivers/net/ethernet/alteon/acenic.ko.xz' dracut-install: Missing firmware acenic/tg2.bin for kernel module acenic dracut-install: Missing firmware acenic/tg1.bin for kernel module acenic Note how the =drivers/block is apparently ignored here. [0] https://salsa.debian.org/helmutg/debvm/-/jobs/6127012 [1] https://salsa.debian.org/helmutg/debvm/-/jobs/6164782
Bug#1077190: curl: pkgconf --cflags libcurl failing due to missing deps
Source: curl
Followup-For: Bug #1077190
X-Debbugs-Cc: tj.iam...@proton.me
This is a result of upstream commit f057de5a1a which results in
libcurl.pc having:
Name: libcurl
URL: https://curl.se/
Description: Library to transfer files with ftp, http, etc.
Version: 8.9.0
Requires:
Requires.private:
libidn2,zlib,libbrotlidec,libzstd,gnutls,libpsl,libssh2,librtmp,libnghttp2,libngtcp2,libngtcp2_crypto_gnutls,libnghttp3
Libs: -L${libdir} -lcurl
Libs.private: -lnghttp3 -lngtcp2_crypto_gnutls -lngtcp2 -lnghttp2 -lidn2 -lrtmp
-lssh2 -lssh2 -lpsl -lnettle -lgnutls -lgssapi_krb5 -llber -lldap -llber -lzstd
-lbrotlidec -lz
Cflags: -I${includedir}
commit f057de5a1a950a90d1920021db152a4b695f1a8a
Author: Viktor Szakats
Date: Sat Jun 8 00:41:24 2024 +0200
libcurl.pc: add `Requires.private`, `Requires` for static linking
- cmake: populate for dependencies.
- autotools: populate for dependencies.
(including mbedtls, though the script does not detect
mbedtls through pkgconfig. mbedtls 3.6.0 now supports it.)
Skip dealing with gssapi in this patch.
Fixes #864
Closes #13911
Bug#989229: Fw: Re: Bug#989229: grub-install: warning: Cannot read EFI Boot* variables.
The reporter "retired" the PC but directly replied to me; copying in for completeness. --- Forwarded Message --- From: Joseph Maher Date: On Wednesday, 17 July 2024 at 07:22 Subject: Re: Bug#989229: grub-install: warning: Cannot read EFI Boot* variables. To: Tj > Thanks! You can close this bug - I have retired that laptop... > > Joseph
Bug#1076438: taskwarrior: If moving to v3.x please retain v2.x
Package: taskwarrior Version: 2.6.2+dfsg-1 Severity: wishlist X-Debbugs-Cc: tj.iam...@proton.me Since v3.0 was recently released I expect there will be a move to it at some point. I'd like to request keeping v2.x and v3.x in parallel for the following reasons (or at least until they are no longer significant): v3.x has a LOT of regression bugs v3.x has removed many features v3.x has replaced the data(base) storage v3.x has completely removed taskd server The last issue in particular is problematic since the suggested workaround is to host the (new) sqlite database in "Cloud Storage" that, currently, only is Google Cloud Platform. The 'local' option is shared directory (which infers NFS/CIFS/sshfs and similar) for local networked instances whereas v2.x taskd uses internal TLS. Using TaskChampion's replacement for taskd TLS means one has to nominate one client as the 'master' to avoid recurrence sync/duplication bugs. It seems like the move to TaskChampion store/sync engine was premature since it is "currently best described as a reference implementation of the Taskchampion sync protocol." https://github.com/GothenburgBitFactory/taskchampion-sync-server/blob/main/README.md
Bug#989229: grub-install: warning: Cannot read EFI Boot* variables.
Source: linux Followup-For: Bug #989229 X-Debbugs-Cc: tj.iam...@proton.me Control: tag -1 moreinfo This is in all probability a system (manufacturer's) firmware bug. The kernel is doing what it is designed to do; that is, try to recover from the system's UEFI Runtime Services causing a Page Fault. There are new firmware releases available for that model - upgrading may fix the bug: https://www.acer.com/gb-en/support/product-support/SP111-31N/ Latest listed is v1.11 2018-12-25. Bug report shows: [Sun Jul 11 20:36:36 2021] Hardware name: Acer Spin SP111-31N/Ironhide_AP, BIOS V1.02 01/04/2017 There was a similar report back in 2019 via Ubuntu and Upstream and the response upstream is informative: "Note that this is *not* a kernel panic. The kernel does exactly what we intended, which is to contain the page fault caused by the buggy firmware, and proceed without EFI runtime services. Unfortunately, this means that the installer cannot update the boot path so that grub gets invoked at boot by default. The only way to achieve this is probably to use 'bcfg' from the UEFI shell. Since this is closed source firmware provided by the hardware vendor, there is really very little we can do about this except complaining to them that their firmware is buggy. " https://bugzilla.kernel.org/show_bug.cgi?id=204289#c7
Bug#1075713: linux: Change to firmware fb device parent broke X fbdev
Package: linux-image-6.9.7+debian+tj Followup-For: Bug #1075713 X-Debbugs-Cc: tj.iam...@proton.me It does help to include the references! [0] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1714
Bug#1075713: linux: Change to firmware fb device parent broke X fbdev
Package: linux-image-6.9.7+debian+tj
Followup-For: Bug #1075713
X-Debbugs-Cc: tj.iam...@proton.me
This is best fixed in xorg-server. I've opened an upstream issue [0] and
sent the patch to xorg-devel@.
In the meantime here's a patch tested with kernel v6.8.12 and v6.9.7
using the device subsystem path as recommended by Thomas Zimmerman.
>From c7458db8a1701e9beb76831afe5f15d3351e1a47 Mon Sep 17 00:00:00 2001
From: Tj
Date: Mon, 15 Jul 2024 10:45:17 +0100
Subject: [PATCH] fbdevhw: fix sysfs path PCI device detection
Linux kernel v6.9 has changed the symlink to point to the parent device.
This breaks fbdev_open() detection logic. Change it to use the subsystem
symlink instead which will remain stable.
Kernel v6.8:
[14.067] (II) fbdev_open() sysfs_path=/sys/class/graphics/fb0
[14.067] (II) fbdev_open()
buf=../../devices/platform/vesa-framebuffer.0/graphics/fb0
Kernel v6.9:
[15.609] (II) fbdev_open() sysfs_path=/sys/class/graphics/fb0
[15.609] (II) fbdev_open()
buf=../../devices/pci:00/:00:01.0/vesa-framebuffer.0/graphics/fb0
Originally found in automated Debian ISO QA testing [0] and confirmed in
Linux [1].
Tested on kernels v6.9.7 and v6.8.12
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075713
[1]
https://lore.kernel.org/lkml/lLyvPFC_APGHNfyGNHRpQy5izBikkaTPOpHooZIT3fFAoJPquSI31ZMueA99XTdr8ysir3X7O7IMdc6za-0m79vr_claeparHhoRouVgHOI=@proton.me/
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1714
Signed-off-by: Tj
---
hw/xfree86/fbdevhw/fbdevhw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/fbdevhw/fbdevhw.c b/hw/xfree86/fbdevhw/fbdevhw.c
index 76bc4809f..019af305b 100644
--- a/hw/xfree86/fbdevhw/fbdevhw.c
+++ b/hw/xfree86/fbdevhw/fbdevhw.c
@@ -378,9 +378,9 @@ fbdev_open(int scrnIndex, const char *dev, char **namep)
node++;
}
-if (asprintf(&sysfs_path, "/sys/class/graphics/%s", node) < 0 ||
+if (asprintf(&sysfs_path, "/sys/class/graphics/%s/device/subsystem",
node) < 0 ||
readlink(sysfs_path, buf, sizeof(buf) - 1) < 0 ||
-strstr(buf, "devices/pci")) {
+strstr(buf, "bus/pci")) {
free(sysfs_path);
close(fd);
return -1;
--
2.39.2
Bug#1075713: Regression: firmware/sysfb.c device path
On Monday, 15 July 2024 at 10:22, Thomas Zimmermann wrote: > We should definitely get your patch into the Xorg upstream. Working on that now.
Bug#1075713: Regression: firmware/sysfb.c device path
On Monday, 15 July 2024 at 07:44, Thomas Zimmermann wrote: > > See hw/xfree86/fbdevhw/fbdevhw.c::fbdev_open() > > > > https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/fbdevhw/fbdevhw.c?ref_type=heads#L381 > > > Amazing debugging skills! > > The patch that causes the regression in X sets the PCI device as parent > for the VESA framebuffer. That means that the PCI device won't be > unplugged or suspended while the VESA framebuffer is still in use. > Without, results are undefined. > > Therefore, could this be fixed in X' fbdev driver? I was in two minds about this one. On the 'perfection' side I agree Xorg should not rely on a symbolic link at all - though that is easy to say; I wasn't the one that had to find a way to do what fbdevhw has to do at the time! But the other me argues that kernel ought not to break userspace and as it is a pretty common scenario across distros that userspace stays relatively stable (sans security bugs) but kernels can and do move on quite rapidly and frequently the kernel ought to play nice here :) With this in mind I can foresee many systems that work perfectly fine will break when only the kernel is upgraded and thus it'll have the finger of blame pointed at it. Since this is more likely to strike in automated test harness scenarios (due to it being relatively obscure) as well there may well be circumstances where changing a userspace library immediately is extremely problematical. I wonder if there's some half-way deprecation measure here that would allow a period of transition? I can imagine one way would be a custom udev rule (for systemd-udevd hosts - not sure about non-udevd) that replaces the new symlink with the old - but if a distro does that it's almost as easy to patch and rebuild fbdevhw - and far more brittle. > A fix could look like this: > > 1) readlink /sys/class/graphics/fb0/device/subsystem > 2) strcmp to "bus/pci" This works and doesn't cause a regression in v6.8.12: ~ # uname -r; grep fbdev /var/log/Xorg.0.log 6.9.7-amd64 [31.376] (==) Matched fbdev as autoconfigured driver 2 [31.377] (II) LoadModule: "fbdev" [31.377] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [31.377] (II) Module fbdev: vendor="X.Org Foundation" [31.377] (II) FBDEV: driver for framebuffer: fbdev [31.410] fbdev trace: FBDevPciProbe() [31.410] (II) Loading sub module "fbdevhw" [31.410] (II) LoadModule: "fbdevhw" [31.410] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [31.410] (II) Module fbdevhw: vendor="X.Org Foundation" [31.410] fbdev trace: FBDevPciProbe() return [31.410] (WW) Falling back to old probe method for fbdev [31.410] fbdev trace: FBDevProbe() [31.410] (II) Loading sub module "fbdevhw" [31.410] (II) LoadModule: "fbdevhw" [31.410] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [31.410] (II) Module fbdevhw: vendor="X.Org Foundation" [31.410] fbdev: FBDevProbe() for() numDevSection=0 [31.410] fbdev: FBDevProbe() isPci0 isISA=0 [31.410] fbdev: FBDevProbe() calling fbdevHWProbe(NULL, '(null)', NULL) [31.410] (II) fbdev_open(scrnIndex=-1, dev=(null), namep=(nil)) [31.410] (II) fbdev_open() using dev from env FRAMEBUFFER=(null) [31.410] (II) fbdev_open() using default dev=/dev/fb0 [31.410] (II) fbdev_open() sysfs_path=/sys/class/graphics/fb0/device/subsystem [31.410] (II) fbdev_open() buf=../../../../bus/platform [31.410] (II) fbdev_open() returning file descriptor 11 [31.410] fbdev trace: FBDevProbe() fbdevHWProbe() [31.410] fbdev trace: FBDevProbe() else xf86ClaimFbSlot() [31.410] fbdev trace: FBDevProbe() return [31.410] (II) UnloadModule: "fbdev" [31.410] (II) UnloadSubModule: "fbdevhw" [31.410] fbdev: PreInit 0 [31.410] (II) FBDEV(0): fbdev_open(scrnIndex=0, dev=(null), namep=(nil)) [31.410] (II) FBDEV(0): fbdev_open() using dev from env FRAMEBUFFER=(null) [31.410] (II) FBDEV(0): fbdev_open() using default dev=/dev/fb0 [31.410] (II) FBDEV(0): fbdev_open() sysfs_path=/sys/class/graphics/fb0/device/subsystem [31.410] (II) FBDEV(0): fbdev_open() buf=../../../../bus/platform [31.410] (II) FBDEV(0): fbdev_open() returning file descriptor 12 ~ # uname -r; grep fbdev /var/log/Xorg.0.log 6.8.12-amd64 [14.225] (==) Matched fbdev as autoconfigured driver 2 [14.225] (II) LoadModule: "fbdev" [14.225] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [14.225] (II) Module fbdev: vendor="X.Org Foundation" [14.225] (II) FBDEV: driver for framebuffer: fbdev [14.252] fbdev trace: FBDevPciProbe() [14.252] (II) Loading sub module "fbdevhw" [14.252] (II) LoadModule: "fbdevhw" [14.252] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [14.252] (II) Module fbdevhw: vendor="X.Org Foundation" [14.253] fbdev trace: FBDevPciProbe() return [14.253] (WW) Falling back to old probe method for fbdev [14.253] fbdev trace: FBDevProbe() [14.25
Bug#1072004: linux: regression in the 9p protocol in 6.8 breaks autopkgtest qemu jobs (affecting debci)
Package: linux-image-6.9.7+debian+tj Followup-For: Bug #1072004 X-Debbugs-Cc: tj.iam...@proton.me I've completed 10 successful passes of the autopkgtest reproducer with the proposed patch in the kernel bugzilla from Dominique Martinet on current mainline, so with luck that might squeeze in to 6.10.
Bug#1075713: Regression: firmware/sysfb.c device path
The recent commits to add the parent device path broke Debian's kvm based QA workers for testing installer ISOs after a kernel upgrade from v6.8.12 to v6.9.7. For the details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075713 It took some time to track it down since the superficial symptom appeared to involve the QXL driver. It turned out however to be the fbdev driver; specifically the change in the parent device path in sysfs reported between the two kernels: 6.8.12: /sys/class/graphics/fb0 -> ../../devices/platform/vesa-framebuffer.0/graphics/fb0 6.9.7: /sys/class/graphics/fb0 -> ../../devices/pci:00/:00:01.0/vesa-framebuffer.0/graphics/fb0 This breaks xserver-xorg-core's libfbdevhw.so because it differentiates code-paths based on whether "devices/pci" is matched in the symlink. See hw/xfree86/fbdevhw/fbdevhw.c::fbdev_open() https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/fbdevhw/fbdevhw.c?ref_type=heads#L381
Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl
Package: linux-image-6.9.7+debian+tj Followup-For: Bug #1075713 X-Debbugs-Cc: tj.iam...@proton.me After reverting the recent sysfb commits: linux$ git l -n 15 e932a4281dfd4 2024-07-13 17:27:49 +0100 N Tj Revert "firmware/sysfb: Set firmware-framebuffer parent device" c16bbb2e6863d 2024-07-13 17:27:49 +0100 N Tj Revert "firmware/sysfb: Create firmware device only for enabled PCI devices" a0e9d42816f8b 2024-07-13 17:27:49 +0100 N Tj Revert "firmware/sysfb: Update screen_info for relocated EFI framebuffers" ccadd360898d6 2024-07-13 17:27:48 +0100 N Tj Revert "firmware/sysfb: fix an error code in sysfb_init()" 10b1da91d6e42 2024-07-13 17:27:48 +0100 N Tj Revert "firmware: sysfb: Fix reference count of sysfb parent device" 4b3921872d1e1 2024-07-12 09:20:11 +0100 N Tj defconfig: x86 debian+tj clang 02b5bfe1d3d5a 2024-07-12 09:20:11 +0100 N Tj defconfigs: add x86 debian+tj_defconfig 137efe9707741 2024-07-12 09:20:11 +0100 N Tj ath: add module_param country_default for regulatory domain control 8f630feb117a2 2024-07-12 09:20:11 +0100 N Tj cfg80211: suppress regdom warning when phy not ready 0ebc0f862b706 2024-07-12 09:20:10 +0100 N Tj debian: call linux-update-symlinks from postinst 4e2330e67f16f 2024-07-12 09:20:10 +0100 N Tj debian: no -dbg package using KDEB_NO_DBG=1 45970aeccdb2a 2024-07-12 09:20:10 +0100 N Tj firmware: report each loaded firmware file 28fdf45184830 2024-07-11 12:51:24 +0200 N Greg Kroah-Hartman Linux 6.9.9 This confirms those commits are the cause of the issue; here we have the same successful result as with v6.8.12 ~ # uname -r; grep fbdev /var/log/Xorg.0.log 6.9.9+debian+tj [18.029] (==) Matched fbdev as autoconfigured driver 2 [18.029] (II) LoadModule: "fbdev" [18.029] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so [18.030] (II) Module fbdev: vendor="X.Org Foundation" [18.030] (II) FBDEV: driver for framebuffer: fbdev [18.063] fbdev trace: FBDevPciProbe() [18.063] (II) Loading sub module "fbdevhw" [18.063] (II) LoadModule: "fbdevhw" [18.063] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [18.063] (II) Module fbdevhw: vendor="X.Org Foundation" [18.063] fbdev trace: FBDevPciProbe() return [18.063] (WW) Falling back to old probe method for fbdev [18.063] fbdev trace: FBDevProbe() [18.063] (II) Loading sub module "fbdevhw" [18.063] (II) LoadModule: "fbdevhw" [18.063] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so [18.063] (II) Module fbdevhw: vendor="X.Org Foundation" [18.063] fbdev: FBDevProbe() for() numDevSection=0 [18.063] fbdev: FBDevProbe() isPci0 isISA=0 [18.063] fbdev: FBDevProbe() calling fbdevHWProbe(NULL, '(null)', NULL) [18.063] (II) fbdev_open(scrnIndex=-1, dev=(null), namep=(nil)) [18.063] (II) fbdev_open() using dev from env FRAMEBUFFER=(null) [18.063] (II) fbdev_open() using default dev=/dev/fb0 [18.063] (II) fbdev_open() sysfs_path=/sys/class/graphics/fb0 [18.063] (II) fbdev_open() buf=../../devices/platform/vesa-framebuffer.0/graphics/fb0 [18.063] (II) fbdev_open() returning file descriptor 11 [18.063] fbdev trace: FBDevProbe() fbdevHWProbe() [18.063] fbdev trace: FBDevProbe() else xf86ClaimFbSlot() [18.063] fbdev trace: FBDevProbe() return [18.063] (II) UnloadModule: "fbdev" [18.063] (II) UnloadSubModule: "fbdevhw" [18.063] fbdev: PreInit 0 [18.063] (II) FBDEV(0): fbdev_open(scrnIndex=0, dev=(null), namep=(nil)) [18.063] (II) FBDEV(0): fbdev_open() using dev from env FRAMEBUFFER=(null) [18.063] (II) FBDEV(0): fbdev_open() using default dev=/dev/fb0 [18.063] (II) FBDEV(0): fbdev_open() sysfs_path=/sys/class/graphics/fb0 [18.063] (II) FBDEV(0): fbdev_open() buf=../../devices/platform/vesa-framebuffer.0/graphics/fb0 [18.063] (II) FBDEV(0): fbdev_open() returning file descriptor 12
Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl
Source: debian-installer
Followup-For: Bug #1075713
X-Debbugs-Cc: tj.iam...@proton.me
Finally managed to build the v6.8.12 initrd; process is quite convoluted
due to having to manually identify, install, and depmod modules.
However...
... it works (both with and without a hard-coded xorg.conf fragment).
The Xorg.0.log trace messages I added show that the call to
fbdevHWProbe() succeeds, falls through to the subordinate 'else' clause
and calls xf86ClaimFbSlot():
With the hard-coded fragment:
~ # grep fbdev /var/log/Xorg.0.log
[88.861] (II) LoadModule: "fbdev"
[88.861] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[88.861] (II) Module fbdev: vendor="X.Org Foundation"
[88.861] (II) FBDEV: driver for framebuffer: fbdev
[88.894] fbdev trace: FBDevPciProbe()
[88.894] (II) Loading sub module "fbdevhw"
[88.894] (II) LoadModule: "fbdevhw"
[88.894] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[88.894] (II) Module fbdevhw: vendor="X.Org Foundation"
[88.894] fbdev trace: FBDevPciProbe() return
[88.894] (WW) Falling back to old probe method for fbdev
[88.894] fbdev trace: FBDevProbe()
[88.894] (II) Loading sub module "fbdevhw"
[88.894] (II) LoadModule: "fbdevhw"
[88.894] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[88.894] (II) Module fbdevhw: vendor="X.Org Foundation"
[88.894] fbdev: FBDevProbe() for() numDevSection=0
[88.894] fbdev: FBDevProbe() isPci0 isISA=0
[88.895] fbdev: FBDevProbe() calling fbdevHWProbe(NULL, '/dev/fb0', NULL)
[88.895] fbdev trace: FBDevProbe() fbdevHWProbe()
[88.895] fbdev trace: FBDevProbe() else xf86ClaimFbSlot()
[88.895] fbdev trace: FBDevProbe() return
[88.895] (II) UnloadModule: "fbdev"
[88.895] (II) UnloadSubModule: "fbdevhw"
[88.895] fbdev: PreInit 0
[88.895] (**) FBDEV(0): Option "fbdev" "/dev/fb0"
Auto-detection without hard coded fragment:
~ # grep fbdev /var/log/Xorg.0.log
[ 213.290] (==) Matched fbdev as autoconfigured driver 2
[ 213.291] (II) LoadModule: "fbdev"
[ 213.291] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 213.291] (II) Module fbdev: vendor="X.Org Foundation"
[ 213.291] (II) FBDEV: driver for framebuffer: fbdev
[ 213.324] fbdev trace: FBDevPciProbe()
[ 213.324] (II) Loading sub module "fbdevhw"
[ 213.324] (II) LoadModule: "fbdevhw"
[ 213.324] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 213.324] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 213.324] fbdev trace: FBDevPciProbe() return
[ 213.324] (WW) Falling back to old probe method for fbdev
[ 213.324] fbdev trace: FBDevProbe()
[ 213.324] (II) Loading sub module "fbdevhw"
[ 213.324] (II) LoadModule: "fbdevhw"
[ 213.324] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 213.324] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 213.325] fbdev: FBDevProbe() for() numDevSection=0
[ 213.325] fbdev: FBDevProbe() isPci0 isISA=0
[ 213.325] fbdev: FBDevProbe() calling fbdevHWProbe(NULL, '(null)', NULL)
[ 213.325] fbdev trace: FBDevProbe() fbdevHWProbe()
[ 213.325] fbdev trace: FBDevProbe() else xf86ClaimFbSlot()
[ 213.325] fbdev trace: FBDevProbe() return
[ 213.325] (II) UnloadModule: "fbdev"
[ 213.325] (II) UnloadSubModule: "fbdevhw"
[ 213.325] fbdev: PreInit 0
Notice here both of these succeed:
fbdev: FBDevProbe() calling fbdevHWProbe(NULL, '/dev/fb0', NULL)
fbdev: FBDevProbe() calling fbdevHWProbe(NULL, '(null)', NULL)
This leads back to:
xorg-server-${VERSION}/hw/xfree86/fbdevhw/fbdevhw.c
Bool
fbdevHWProbe(struct pci_device *pPci, char *device, char **namep)
{
int fd;
if (pPci)
fd = fbdev_open_pci(pPci, namep);
else
fd = fbdev_open(-1, device, namep);
if (-1 == fd)
return FALSE;
close(fd);
return TRUE;
}
So I now instrument xserver-xorg-core's
hw/xfree86/fbdevhw/fbdevhw.c::fbdev_open()
With v6.8.12 Xorg reports:
~ # uname -r; grep fbdev /var/log/Xorg.0.log
6.8.12-amd64
[14.033] (==) Matched fbdev as autoconfigured driver 2
[14.033] (II) LoadModule: "fbdev"
[14.033] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[14.033] (II) Module fbdev: vendor="X.Org Foundation"
[14.033] (II) FBDEV: driver for framebuffer: fbdev
[14.066] fbdev trace: FBDevPciProbe()
[14.066] (II) Loading sub module "fbdevhw"
[14.066] (II) LoadModule: "fbdevhw"
[14.066] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[14.066] (II) Module fbdevhw: vendor="X.Org Foundation"
[14.067] fbdev trace: FBDevPciProbe() return
[14.067] (WW) Falling back to old probe method for fbdev
[14.067] fbdev trace: FBDevProbe()
[14.067] (II) Loading sub module "fbdevhw"
[14.067] (II) LoadModule: "fbdevhw"
[14.067] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[14.067] (II) Module fbdevhw: vendor="X.Org Foundation"
[14.067] fbdev: FBDevProbe() for() numDevSection=0
[14.067] fbdev: FBDevProbe() isPci0 isISA=0
[14.067] fbdev: FBDevProbe() calling fbdevHWProbe(NULL, '(null)', NUL
Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl
Source: debian-installer
Followup-For: Bug #1075713
X-Debbugs-Cc: tj.iam...@proton.me
Creating a modified non-ISO bootable image that can be interactively
debugged proved a trial and a half, but after creating a custom initrd
and modifying several of the d-i scripts that mess with console I've
finally got there!
I added a few TRACE/DEBUG messages into xorg's fbdev_drv FBDevProbe() to
learn the control flow.
https://sources.debian.org/src/xserver-xorg-video-fbdev/1%3A0.5.0-2/src/fbdev.c/#L312
Omitting the superfluous Xorg log entries this reveals:
$ grep fbdev mnt/img/var/log/Xorg.0.log
[50.418] (==) Matched fbdev as autoconfigured driver 2
[50.418] (II) LoadModule: "fbdev"
[50.418] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[50.418] (II) Module fbdev: vendor="X.Org Foundation"
[50.418] (II) FBDEV: driver for framebuffer: fbdev
[50.445] fbdev trace: FBDevPciProbe()
[50.445] (II) Loading sub module "fbdevhw"
[50.445] (II) LoadModule: "fbdevhw"
[50.445] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[50.445] (II) Module fbdevhw: vendor="X.Org Foundation"
[50.445] fbdev trace: FBDevPciProbe() return
[50.445] (WW) Falling back to old probe method for fbdev
[50.445] fbdev trace: FBDevProbe()
[50.445] (II) Loading sub module "fbdevhw"
[50.445] (II) LoadModule: "fbdevhw"
[50.445] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[50.445] (II) Module fbdevhw: vendor="X.Org Foundation"
[50.445] fbdev: FBDevProbe() for() numDevSection=0
[50.445] fbdev: FBDevProbe() isPci0 isISA=0
[50.445] fbdev: FBDevProbe() calling fbdevHWProbe(NULL, '(null)', NULL)
[50.445] fbdev trace: FBDevProbe() return
[50.445] (II) UnloadModule: "fbdev"
[50.445] (II) UnloadSubModule: "fbdevhw"
The crux here is
fbdevHWProbe(NULL, '(null)', NULL)
that is for the code:
if (fbdevHWProbe(NULL,dev,NULL)) {
The 2nd argument should be the framebuffer name but it is only set
earlier if there is a manual xorg.conf Device section for this driver
with "fbdev" set:
dev = xf86FindOptionValue(devSections[i]->options,"fbdev");
So without a real name the call fails since there is no device to open:
fbdevHWProbe(struct pci_device *pPci, char *device, char **namep)
{
int fd;
if (pPci)
fd = fbdev_open_pci(pPci, namep);
else
fd = fbdev_open(-1, device, namep);
if (-1 == fd)
return FALSE;
close(fd);
return TRUE;
}
But adding a manual config:
~ # cat /usr/share/X11/xorg.conf.d/05-fbdev.conf
Section "Device"
Identifier "fbElusive"
Driver "fbdev"
Option "fbdev" "/dev/fb0"
EndSection
Still fails:
[ 207.890] fbdev: FBDevProbe() calling fbdevHWProbe(NULL, '/dev/fb0', NULL)
[ 207.890] fbdev trace: FBDevProbe() return
If it succeeded the first statement in the if() clause would report:
TRACE("FBDevProbe() fbdevHWProbe()");
Since this code hasn't changed in a while I'm currently struggling to
figure out how this ever worked!
I'm now going to create another custom initrd for the v6.8.12 kernel
and add it to this image to see if that will make a difference although
I cannot see how, unless it affects the PCI detection logic in some way.
If that doesn't work I cannot see how the fbdev fallback path can work as in
the v6.8.12 ISO although there it obviously does.
Bug#1075844: xserver-xorg-video-fbdev: ./revert-ae0aeffae665746.diff in source package
Package: xserver-xorg-video-fbdev Version: 1:0.5.0-2 Severity: minor X-Debbugs-Cc: tj.iam...@proton.me Whilst researching a bug in other packages and inspecting how fbdev interacts with them I found the source package (.diff.gz) fetched with dget contains the file ./revert-ae0aeffae665746.diff It is not applied but as it changes a code path I'm inspecting closely I thought to report and ask if there is some issue it is related to, since that may inform my investigation into bug #1075713.
Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl
Source: debian-installer Followup-For: Bug #1075713 X-Debbugs-Cc: tj.iam...@proton.me To be explicit this issue is not related to the QXL driver; that is a red herring. The problem is the fbdev driver is failing to handle the kernel's /dev/fb0. Digging further I compared the kernel configs and see nothing incriminating. I then started both ISOs using libvirt and the video QXL driver to easily enable network so I can transfer files in. Then using fetch-url I copied in fbset and captured info using: # fbset -i Both are identical. Then I started Xorg on both; although it runs on 20240628 it results in a black screen on VT2 since there is no window manager or anything else. However, on the console it reported a warning: (WW) FBDEV(0): The fbdev driver didn't call xf86SetGamma() to initialise the gamma values. (WW) FBDEV(0): PLEASE FIX THE `fbdev' DRIVER! But this is a long-standing issue, e.g. bug #747042 from 2014. The clue (from the GOOD image) I am following is: (II) FBDEV(2): using default device This message is only emitted by FBDevProbe() in src/fbdev.c ( from xserver-xorg-video-fbdev-0.5.0 ) There is another occurance but it is preceded by another message which we do not see, emitted by FBDevPciProbe(): ... "claimed PCI slot %d@%d:%d:%d\n" So now I'm working back through function FBDevProbe() to identify why variable pScreen is NULL at this point and causing the failure and hence not writing these messages. Build logs indicate the fbdev module is built with libpciaccess so that helps figure which preprocessor conditional code is compiled in and therefore executed. I intend to put gdbserver in the guest (if possible) and debug remotely. Once we know how it is failing that should lead to the cause.
Bug#1075713: debian-installer: Not caused by kvm version
Source: debian-installer Version: 20230607+deb12u6 Followup-For: Bug #1075713 X-Debbugs-Cc: tj.iam...@proton.me Thank-you to Philip for pointing me to the OpenQA assets and details. I had explored those pages but totally missed that those words were actually hyperlinks to additional page content! Thanks also to Cyril for pointing me to the daily-image archives - very useful. My workstation is Bookworm amd64 with qemu 1:7.2+dfsg-7+deb12u6 >From snapshots I fetched and installed 1:7.2+dfsg-7+deb12u5 $ kvm --version QEMU emulator version 7.2.9 (Debian 1:7.2+dfsg-7+deb12u5) Good: gtk/mini.20240628.iso Fail: gtk/mini.20240629.iso So in all likelyhood we can rule out Qemu as a cause here (but still keep it in mind). I've looked at the upstream qemu commit history v7.2.9..v7.2.11 and do not see anything obviously touching on QXL (so far - will continue looking). Back to the 2 ISOs. Comparing the build logs nothing stands out aside from the kernel version 6.8.12 -> 6.9.7 although: debian-installer git tree head: 0cf307b35662c758828f12977d286edf2cb86f59 -> c0030a2713385804a392ff9d3ae46d9301373ce4 I now move on to executing the guests with serial console so I can capture the logs. $ kvm -m 1G -vga qxl -serial stdio -cdrom ... I interrupt the isolinux boot menu pressing Tab to edit it. I change it to begin: linux init=/bin/sh console=ttyS0,115200 console=tty0 ... To capture the kernel log: # dmesg > /dev/ttyS0 To capture Xorg log: # Xorg -logverbose 9 -logfile /dev/ttyS0 This reveals the Xorg fbdev driver is unable to manage the framebuffer /dev/fb0. $ diff <(grep -o ') .*' xorg-20240628.log ) <( grep -o ') .*' xorg-20240629.log ) 21d20 < ) FBDEV(2): using default device 27,40c26,29 < ) FBDEV(0): Creating default Display subsection in Screen section < ) FBDEV(0): Depth 16, (==) framebuffer bpp 16 < ) FBDEV(0): RGB weight 565 < ) FBDEV(0): Default visual is TrueColor < ) FBDEV(0): hardware: VESA VGA (video memory: 1875kB) < ) xf86MergeOutputClassOptions unsupported bus type 0 < ) FBDEV(0): checking modes against framebuffer device... < ) FBDEV(0): checking modes against monitor... < ) FBDEV(0): Virtual size is 800x600 (pitch 800) < ) FBDEV(0): Built-in mode "current": 48.0 MHz, 46.9 kHz, 75.1 Hz < ) FBDEV(0): Modeline "current"x0.0 48.00 800 832 928 1024 600 604 608 624 -hsync -vsync -csync (46.9 kHz b) < ) FBDEV(0): DPI set to (96, 96) < ) Loading sub module "fb" < ) LoadModule: "fb" --- > ) Device(s) detected, but none match those in the config file. > ) no screens found(EE) > ) Please also check the log file at "/dev/ttyS0" for additional information. > ) Server terminated with error (1). Closing log file. The key here is that first line which shows that 20240628 manages to open /dev/fb0 but 20240629 does not. This suggests we're back to considering a kernel change. I'm now inspecting the framebuffer related changes between v6.8..v6.9 and will likely do some git bisect kernel builds to test likely culprits.
Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl
Source: debian-installer
Followup-For: Bug #1075713
X-Debbugs-Cc: tj.iam...@proton.me
I've done some further research via debian-installer repo, build logs,
and inspecting fb-modules-*-amd64-di packages.
Focusing on just 6.8.12-1 and 6.9.7-1 I cannot see any difference in the
ISO builds. That is, for both:
* linux-image-*-amd64 does include drivers/gpu/drm/qxl/qxl.ko*
* fb-modules-*-amd64-di.udeb does not
* kernel-image-*-amd64-di does not
* d-i Makefile's DRM_MODULES has/does not list/copy qxl.ko
This makes me wonder if the 20240628_0519 daily netinst really did have
this module but as I cannot find a copy of the ISO I cannot check.
If it did not then something must have changed in the qemu/kvm side.
I went on to analyse the ISO package content diff using the attached awk
script. It strips out packages where the only difference is the version
embedded in the package name. The resulting list does not appear to show
anything that would control inclusion of the qxl modulei although it
does seem to indicate a lot of churn:
apt-cdrom-setup -
apt-mirror-setup -
apt-setup-udeb -
base-installer -
bootstrap-base -
btrfs-modules amd64-di - -6.8.12-
btrfs-progs-udeb -
choose-mirror-bin -
clock-setup -
crypto-modules amd64-di - -6.8.12-
debian-archive-keyring-udeb -
debootstrap-udeb -
depthcharge-tools-installer -
di-utils-mapdevfs -
disk-detect -
dmidecode-udeb -
dosfstools-udeb -
e2fsprogs-udeb -
efi-modules amd64-di - -6.8.12-
eject-udeb -
ethdetect -
ext4-modules amd64-di - -6.8.12-
finish-install -
fuse3-udeb -
gpgv-udeb -
grub-installer -
grub-mount-udeb -
jfs-modules amd64-di - -6.8.12-
jfsutils-udeb -
kickseed-common -
libaio1-udeb -
libdevmapper1.02.1-udeb -
libfuse3 udeb - -3-
libgcrypt20-udeb -
libgpg-error0-udeb -
libinih1-udeb -
libisns-udeb -
libiw30-udeb -
liblzo2 udeb - -2-
libmount1-udeb -
libnl-3 udeb - -200-
libnl-genl-3 udeb - -200-
libparted-fs-resize0-udeb -
libparted2-udeb -
liburcu8-udeb -
loop-modules amd64-di - -6.8.12-
lvm2-udeb -
md-modules amd64-di - -6.8.12-
mdadm-udeb -
mtd-core-modules amd64-di - -6.8.12-
ndisc6-udeb -
netcfg -
network-preseed -
nic-modules amd64-di - -6.8.12-
nic-pcmcia-modules amd64-di - -6.8.12-
nic-shared-modules amd64-di - -6.8.12-
nic-usb-modules amd64-di - -6.8.12-
nic-wireless-modules amd64-di - -6.8.12-
nobootloader -
ntfs-3g-udeb -
open-iscsi-udeb -
os-prober-udeb -
partman-auto -
partman-auto-crypto -
partman-auto-lvm -
partman-auto-raid -
partman-base -
partman-basicfilesystems -
partman-basicmethods -
partman-btrfs -
partman-cros -
partman-crypto -
partman-efi -
partman-ext3 -
partman-iscsi -
partman-jfs -
partman-lvm -
partman-md -
partman-partitioning -
partman-target -
partman-utils -
partman-xfs -
pkgsel -
rdate-udeb -
rdnssd-udeb -
systemd-boot-installer -
tzsetup-udeb -
user-setup-udeb -
wide-dhcpv6-client-udeb -
wpasupplicant-udeb -
xfs-modules amd64-di - -6.8.12-
xfsprogs-udeb -
/^(\+|-)/ {
l[NR]=gensub( /^(.)([^\t ]+).*/, "\\2 \\1", "1", $0);
l[NR]=gensub( /^(.+?)(-([[:digit:]]|\.)+-)(.*)/, "\\1 \\4 \\2", "1",
l[NR] );
}
END {
asort(l);
for(key in l) {
if(key>1) {
if( gensub(/^([^ ]+).*/, "\\1", "g", l[key-1]) == \
gensub(/^([^ ]+).*/, "\\1", "g",
l[key]) ) {
delete l[key-1];
delete l[key];
}
}
}
for(key in l) {
if( length(l[key]) > 0)
print l[key]
}
}
Bug#1075713: linux: ISO missing qxl.ko.xz kernel module
Source: linux Followup-For: Bug #1075713 X-Debbugs-Cc: tj.iam...@proton.me debian-b...@lists.debian.org I've inspected the arch-latest amd64 ISO from: https://get.debian.org/images/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso It is missing drivers/gpu/drm/qxl/qxl.ko.xz kernel module. We need to review the ISO build log(s) and the Debian Image scripts but I've been unable to track them down. I also noticed that in /usr/lib/modules/6.9.7-amd64/kernel/drivers/gpu/drm/ all 6 modules there are named *.ko but the other 818 modules in the installer image are *.ko.xz This may be a clue!
Bug#1074404: apt-cacher-ng: 302 Location redirect fails for snapshot.debian.org
Package: apt-cacher-ng
Followup-For: Bug #1074404
X-Debbugs-Cc: tj.iam...@proton.me
As soon as I re-read the proposed patch I realised it is wrong in two
ways:
1. it would be triggered by // protocol specificier
2. there is already a later stanza to deal with path-only
However the existing path-only is pre-empted by the // protocol
detection.
This revised patch moves the existing path detection before // protocol
but ensures the second character is not also '/'.
>From dcedac77092b08c358cb9017767c70025f92aee4 Mon Sep 17 00:00:00 2001
From: Tj
Date: Wed, 26 Jun 2024 01:39:16 +0100
Subject: [PATCH] Location: handle /path/ redirects
Fixes 302 Location redirects on snapshot.debian.org.
Signed-off-by: Tj
---
src/dlcon.cc | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/dlcon.cc b/src/dlcon.cc
index 935e41f..978118e 100644
--- a/src/dlcon.cc
+++ b/src/dlcon.cc
@@ -209,6 +209,11 @@ struct tDlJob
auto sLocationDecoded = UrlUnescape(pNewUrl);
+ if (startsWithSz(sLocationDecoded, "/") && sLocationDecoded[1]
!= '/')
+ {
+ m_remoteUri.sPath = sLocationDecoded;
+ return true;
+ }
tHttpUrl newUri;
if (newUri.SetHttpUrl(sLocationDecoded, false))
{
@@ -237,11 +242,6 @@ struct tDlJob
m_remoteUri.sPath += sPathBackup;
}
- if (startsWithSz(sLocationDecoded, "/"))
- {
- m_remoteUri.sPath = sLocationDecoded;
- return true;
- }
// ok, must be relative
m_remoteUri.sPath += (sPathSepUnix + sLocationDecoded);
return true;
--
2.39.2
Bug#1074404: apt-cacher-ng: 302 Location redirect fails for snapshot.debian.org
Package: apt-cacher-ng
Version: 3.7.4-1+b2
Severity: normal
Tags: patch
X-Debbugs-Cc: tj.iam...@proton.me
Originally discovered and discussed in #debian-mentors IRC which got me
to debugging it as shown here.
$ http_proxy=http://127.0.0.1:3142 wget -S
http://snapshot-mlm-01.debian.org/archive/debian/20240617T023617Z/dists/unstable/InRelease
--2024-06-26 00:37:20--
http://snapshot-mlm-01.debian.org/archive/debian/20240617T023617Z/dists/unstable/InRelease
Connecting to 127.0.0.1:3142... connected.
Proxy request sent, awaiting response...
HTTP/1.1 500 Remote or cache error
Content-Length: 492
Content-Type: text/html
Connection: Keep-Alive
Date: Tue, 25 Jun 2024 23:37:38 GMT
Server: Debian Apt-Cacher NG/3.7.4
2024-06-26 00:37:38 ERROR 500: Remote or cache error.
apt-cacher-ng-3.7.4/src# gdb --directory $PWD --args /usr/sbin/apt-cacher-ng -c
"/etc/apt-cacher-ng" ForeGround=1
GNU gdb (Debian 13.1-3) 13.1
...
Reading symbols from /usr/sbin/apt-cacher-ng...
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.debian.net>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading separate debug info for /usr/sbin/apt-cacher-ng
Reading symbols from
/root/.cache/debuginfod_client/00ddd159ae04921c4537ad1eefb870636580ec62/debuginfo...
(gdb) start
Temporary breakpoint 1 at 0x2520: file ./src/apt-cacher.cc, line 312.
Starting program: /usr/sbin/apt-cacher-ng -c /etc/apt-cacher-ng ForeGround=1
...
Temporary breakpoint 1, main (argc=4, argv=0x7fffe348) at
./src/apt-cacher.cc:312
312 {
(gdb) break RewriteSource
Breakpoint 2 at 0x77ec7300: file ./src/dlcon.cc, line 190.
(gdb) c
Continuing.
Loaded 11 backend descriptors
Loaded mappings for 1558 hosts and 2228 paths
[New Thread 0x76e006c0 (LWP 1770177)]
[New Thread 0x764006c0 (LWP 1770178)]
[Switching to Thread 0x764006c0 (LWP 1770178)]
Thread 3 "apt-cacher-ng" hit Breakpoint 2, acng::tDlJob::RewriteSource
(this=this@entry=0x70023710,
pNewUrl=0x7fffe80081a0 "/file/63b5c6e98e9fb2ff206f8043a9ff68014c7cf771") at
./src/dlcon.cc:190
190 inline bool RewriteSource(const char *pNewUrl)
(gdb) p pNewUrl
$1 = 0x7fffe80081a0 "/file/63b5c6e98e9fb2ff206f8043a9ff68014c7cf771"
(gdb) n
199 if (!pNewUrl || !*pNewUrl)
(gdb) n
206 m_pCurBackend = nullptr;
(gdb) n
210 auto sLocationDecoded = UrlUnescape(pNewUrl);
(gdb) n
238 ~_Guard() { if (_M_guarded) _M_guarded->_M_dispose(); }
(gdb) p sLocationDecoded
$2 = ""
(gdb) n
216 m_remoteUri = newUri;
(gdb) p newUri
$3 = {nPort = 0, sHost = "file", sPath =
"/63b5c6e98e9fb2ff206f8043a9ff68014c7cf771", sUserPass = "", bSSL = false}
(gdb) p sLocationDecoded
$4 = "/file/63b5c6e98e9fb2ff206f8043a9ff68014c7cf771"
Shown here sHost has been incorrectly assigned the first segment of the path
and sPath is set to a non-existent value which in this case confuses the
snapshot server.
With my patch we see success:
$ http_proxy=http://127.0.0.1:3142 wget -S
http://snapshot-mlm-01.debian.org/archive/debian/20240617T023617Z/dists/unstable/InRelease
--2024-06-28 04:19:32--
http://snapshot-mlm-01.debian.org/archive/debian/20240617T023617Z/dists/unstable/InRelease
Connecting to 127.0.0.1:3142... connected.
Proxy request sent, awaiting response...
HTTP/1.1 200 OK
Content-Type: octet/stream
Last-Modified: Mon, 17 Jun 2024 02:57:43 GMT
Content-Length: 198381
X-Original-Source:
http://snapshot-mlm-01.debian.org/file/63b5c6e98e9fb2ff206f8043a9ff68014c7cf771
Connection: Keep-Alive
Date: Fri, 28 Jun 2024 03:19:33 GMT
Server: Debian Apt-Cacher NG/3.7.4
Length: 198381 (194K) [octet/stream]
Saving to: ‘InRelease’
InRelease
100%[===>]
193.73K 700KB/sin 0.3s
2024-06-28 04:19:34 (700 KB/s) - ‘InRelease’ saved [198381/198381]
$ head InRelease
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Origin: Debian
Label: Debian
Suite: unstable
Codename: sid
Changelogs:
https://metadata.ftp-master.debian.org/changelogs/@CHANGEPATH@_changelog
Date: Mon, 17 Jun 2024 02:15:25 UTC
Valid-Until: Mon, 24 Jun 2024 02:15:25 UTC
>From 51961164a89c562b333efcbc3dcd8537794d2ed6 Mon Sep 17 00:00:00 2001
From: Tj
Date: Wed, 26 Jun 2024 01:39:16 +0100
Subject: [PATCH] Location: handle /path/ redirects
Fixes 302 Location redirects on snapshot.debian.org.
Signed-off-by: Tj
---
src/dlcon.cc | 8
1 file changed, 8 insertions(+)
diff --git a/src/dlcon.cc b/src/dlcon.cc
index 935e41f..8d280ad 100644
--- a/src/dlcon.cc
+++ b/src/dlcon.cc
@@ -209,6 +209,14 @@ struct tDlJob
auto sLocationDecoded = UrlUnescape(pNewUrl);
+
Bug#1067462: ERROR: Failed to create organization
Package: taskd Version: 1.1.0+dfsg-4+b2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: deb...@iam.tj Dear Maintainer, After installation and following the instructions in README.Debian I found that adding an organisation fails. It is due to two things: 1. The package fails to create /var/lib/taskd/orgs/ see https://github.com/GothenburgBitFactory/taskserver/issues/82 2. Permissions on /var/lib/taskd/ are incorrect; since taskd uses Debian-taskd user that user needs write permissions to everything under /var/lib/taskd/ . Additionally Others should not have access. -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.7+debian+tj (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages taskd depends on: ii adduser3.134 ii gnutls-bin 3.7.9-2+deb12u2 ii init-system-helpers1.65.2 ii libc6 2.36-9+deb12u4 ii libgcc-s1 12.2.0-14 ii libgnutls303.7.9-2+deb12u2 ii libstdc++6 12.2.0-14 ii libuuid1 2.38.1-5+b1 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 taskd recommends no packages. Versions of packages taskd suggests: pn taskwarrior -- Configuration Files: /etc/taskd/config changed [not included] -- no debconf information
Bug#1067444: FileNotFoundError: [Errno 2] ... /usr/lib/python3/dist-packages/bugwarrior/docs/configuration.rst
Package: bugwarrior
Version: 1.8.0-7
Severity: grave
Justification: renders package unusable
Dear Maintainer,
With a fresh install and manually creating the user's configuration file
I hit this error. The path reported seems to indicate the package is not
shipping the file mentioned. I tried moving the user config directory and
saw the error caused by it being missing, put it back, and hit this package
config file issue agian.
$ bugwarrior-pull
CRITICAL:bugwarrior.command:Could not load configuration. Maybe you have not
created a configuration file.
FileNotFoundError: [Errno 2] No such file or directory:
'/home/tj/.config/bugwarrior/bugwarriorrc'
$ mv ~/.config/bugwarrior{.bak,}
$ bugwarrior-pull
CRITICAL:bugwarrior.command:Could not load configuration. Maybe you have not
created a configuration file.
FileNotFoundError: [Errno 2] No such file or directory:
'/usr/lib/python3/dist-packages/bugwarrior/docs/configuration.rst'
$ cat ~/.config/bugwarrior/bugwarriorrc
[general]
targets = debianbts my_github
[debianbts]
service = bts
bts.email = deb...@iam.tj
$ dpkg -S docs/configuration.rst
dpkg-query: no path found matching pattern *docs/configuration.rst*
$ apt-file search docs/configuration.rst
$
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'stable'), (100, 'proposed-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Versions of packages bugwarrior depends on:
ii libjs-sphinxdoc5.3.0-4
ii python33.11.2-1+b1
ii python3-click 8.1.3-2
ii python3-dateutil 2.8.2-2
ii python3-dogpile.cache 1.1.8-2
ii python3-future 0.18.2-6
ii python3-jinja2 3.1.2-1
ii python3-lockfile 1:0.12.2-2.2
ii python3-requests 2.28.1+dfsg-1
ii python3-six1.16.0-4
ii python3-taskw 2.0.0-1
ii python3-tz 2022.7.1-4
Versions of packages bugwarrior recommends:
ii python3-google-auth-oauthlib 0.4.2-1
ii python3-googleapi 1.7.12-1
ii python3-jira 3.4.1-1
ii python3-keyring 23.9.3-2
ii python3-phabricator 0.7.0-1.1
ii python3-pypandoc 1.7.4+ds0-2
bugwarrior suggests no packages.
-- no debconf information
Bug#1066883: alg: ecdh-nist-p256: test failed on vector 2, err=-14
Source: linux Severity: important Same as: Bug #1061262 I've been seeing this with builds since 6.7 cycle started. It seems to show up mostly for hosts with bluetooth hardware since the bluetooth module depends on ecdh. The trace indicates ecdh_generic is still loading when the test is attempted. journalctl --grep 'alg: self-tests for ecdh-nist-p256' | grep -- '-- Boot' | while read -r a b hash d; do journalctl --boot $hash | head -n 1 | grep -oE 'version [^ ]+' done | sort -u version 6.7.0-rc5+debian+tj version 6.7.1+debian+tj version 6.7.4+debian+tj version 6.8.0+debian+tj crypto algo self-tests 'alg: ecdh-nist-p256: test failed on vector 2, err=-14 -14 is "EFAULT 14 / Bad address */ and the log shows Modules linked in: ecdh_generic(+) ... where the "(+)" means module loading. This only seems to occur on hosts with Bluetooth hardware and "bluetooth" module (requires ECDH) when those modules are in the initrd.img. It feels like the self-tests are running before the module is fully loaded - in fact the tcrypt module (CONFIG_CRYPTO_TEST) isn't loaded according to "Modules linked in:" report and it isn't contained in the initrd.img so these tests seem to be occuring without it. root@t300chi:/tmp/initrd# unmkinitramfs /boot/initrd.img-6.8.0+debian+tj . root@t300chi:/tmp/initrd# ls early main root@t300chi:/tmp/initrd# ls main/usr/lib/modules/6.8.0+debian+tj/kernel/crypto/ af_alg.ko algif_skcipher.ko async_tx crc32c_generic.ko crct10dif_common.ko crct10dif_generic.ko ecc.ko ecdh_generic.ko xor.ko xts.ko root@t300chi:/tmp/initrd# ls main/usr/lib/modules/6.8.0+debian+tj/kernel/drivers/bluetooth/ btbcm.ko btintel.ko btmtk.ko btrtl.ko btusb.ko root@t300chi:/tmp/initrd# ls main/usr/lib/modules/6.8.0+debian+tj/kernel/net/bluetooth/ bluetooth.ko root@t300chi:/tmp/initrd# find . /usr/lib/modules/6.8.0+debian+tj/kernel -type f -name '*tcrypt*' /usr/lib/modules/6.8.0+debian+tj/kernel/crypto/tcrypt.ko.xz Mar 14 06:30:29 t300chi kernel: alg: ecdh-nist-p256: test failed on vector 2, err=-14 Mar 14 06:30:29 t300chi kernel: alg: self-tests for ecdh-nist-p256 using ecdh-nist-p256-generic failed (rc=-14) Mar 14 06:30:29 t300chi kernel: [ cut here ] Mar 14 06:30:29 t300chi kernel: alg: self-tests for ecdh-nist-p256 using ecdh-nist-p256-generic failed (rc=-14) Mar 14 06:30:29 t300chi kernel: WARNING: CPU: 0 PID: 197 at crypto/testmgr.c:5888 alg_test+0x42b/0x580 Mar 14 06:30:29 t300chi kernel: Modules linked in: ecdh_generic(+) ecc crc16 sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_commo> Mar 14 06:30:29 t300chi kernel: CPU: 0 PID: 197 Comm: cryptomgr_test Not tainted 6.8.0+debian+tj #158 Mar 14 06:30:29 t300chi kernel: Hardware name: ASUSTeK COMPUTER INC. T300CHI/T300CHI, BIOS T300CHI.209 04/18/2019 Mar 14 06:30:29 t300chi kernel: RIP: 0010:alg_test+0x42b/0x580 Mar 14 06:30:29 t300chi kernel: Code: 89 ea 48 89 ee 4c 89 f7 e8 d2 e8 ff ff 41 89 c0 e9 36 fd ff ff 44 89 c1 48 89 ea 4c 89 e6 48 c7 c7 58 9c 2b 8a e8 b5 0> Mar 14 06:30:29 t300chi kernel: RSP: 0018:a53a80627e08 EFLAGS: 00010282 Mar 14 06:30:29 t300chi kernel: RAX: RBX: 1e00 RCX: Mar 14 06:30:29 t300chi kernel: RDX: 0002 RSI: 0002 RDI: Mar 14 06:30:29 t300chi kernel: RBP: 8e5241213800 R08: 0867 R09: 000a Mar 14 06:30:29 t300chi kernel: R10: 0001 R11: 20726f6620737473 R12: 8e5241213880 Mar 14 06:30:29 t300chi kernel: R13: 0008 R14: 0078 R15: Mar 14 06:30:29 t300chi kernel: FS: () GS:8e535700() knlGS: Mar 14 06:30:29 t300chi kernel: CS: 0010 DS: ES: CR0: 80050033 Mar 14 06:30:29 t300chi kernel: CR2: 7f389404ee24 CR3: 7761c001 CR4: 003706f0 Mar 14 06:30:29 t300chi kernel: DR0: DR1: DR2: Mar 14 06:30:29 t300chi kernel: DR3: DR6: fffe0ff0 DR7: 0400 Mar 14 06:30:29 t300chi kernel: Call Trace: Mar 14 06:30:29 t300chi kernel: Mar 14 06:30:29 t300chi kernel: ? alg_test+0x42b/0x580 Mar 14 06:30:29 t300chi kernel: ? __warn+0x7d/0x130 Mar 14 06:30:29 t300chi kernel: ? alg_test+0x42b/0x580 Mar 14 06:30:29 t300chi kernel: ? report_bug+0x18d/0x1c0 Mar 14 06:30:29 t300chi kernel: ? handle_bug+0x3c/0x70 Mar 14 06:30:29 t300chi kernel: ? exc_invalid_op+0x13/0x60 Mar 14 06:30:29 t300chi kernel: ? asm_exc_invalid_op+0x16/0x20 Mar 14 06:30:29 t300chi kernel: ? alg_test+0x42b/0x580 Mar 14 06:30:29 t300chi kernel: ? alg_test+0x42b/0x580 Mar 14 06:30:29 t300chi kernel: ? finish_task_switch.isra.0+0x9b/0x2f0 Mar 14 06:30:29 t300chi kernel: ? __sc
Bug#1064283: nftlb: Upstream has moved
Source: nftlb Version: 1.0.7-1 Severity: important Tags: upstream The upstream repo was archived read-only in January 2024. From a netfilter-devel mailing-list post in September 2023 it appears the upstream moved: https://lore.kernel.org/netfilter-devel/CAF90-Wg4NTjfUE7pomw8VnQAjSQC2OXa5FQFH_XwK=zf1no...@mail.gmail.com/ to https://github.com/relianoid/nftlb
Bug#1064008: vncsnapshot: Recommends vnc4server but unable to find a Provides: vnc4server
Source: vncsnapshot
Version: 1.2a-5.2
Severity: normal
Whilst investigating guacamole-server I noticed that libguac-client-vnc0
and vncsnapshot recommends "vnc4server" but I've been unable to find any
packages that
provide that.
~/tmp/debian-sid$ awk '/^Package:/{p=$0} /^Recommends: .*vnc4server/{print p;
print $0} /^Package: vnc4server/{print $0}' var/lib/apt/lists/deb.debian.org_de
bian_dists_sid_main_binary-amd64_Packages
Package: libguac-client-vnc0
Recommends: vnc4server
Package: vncsnapshot
Recommends: vnc4server | tightvncserver
Bug#1064007: Recommends vnc4server but cannot find any package doing Provides: vnc4server
Package: libguac-client-vnc0
Version: 1.3.0-1.1+b3
Severity: normal
Whilst investigating guacamole-server I noticed that libguac-client-vnc0
recommends "vnc4server" but I've been unable to find any packages that
provide that.
~/tmp/debian-sid$ awk '/^Package:/{p=$0} /^Recommends: .*vnc4server/{print p;
print $0} /^Package: vnc4server/{print $0}'
var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_binary-amd64_Packages
Package: libguac-client-vnc0
Recommends: vnc4server
Package: vncsnapshot
Recommends: vnc4server | tightvncserver
Bug#1058638: grub-installer: boot fails: $bootdev empty [BIOS/MBR, Vista, 2 disks]: Installing grub on ''
Source: grub-installer Version: 1.194 Followup-For: Bug #1058638 I fetched the proposed patch and applied it to grub-installer inside the installer and can confirm it solved this issue. syslog now shows "grub-installer: info: Installing grub on '/dev/vdb' and examining sector 0 of the disk image file shows the expected boot-strap code and a reboot correctly starts Debian: hexdump -n 512 -C disk2-debian-12.bin eb 63 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.c..| 0010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.!..| 0020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |8.uu| 0030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.|...t..| 0040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.|.| 0050 00 00 00 00 00 00 00 00 00 00 00 80 01 00 00 00 || 0060 00 00 00 00 ff fa 90 90 f6 c2 80 74 05 f6 c2 70 |...t...p| 0070 74 02 b2 80 ea 79 7c 00 00 31 c0 8e d8 8e d0 bc |ty|..1..| 0080 00 20 fb a0 64 7c 3c ff 74 02 88 c2 52 be 80 7d |. ..d|<.t...R..}| 0090 e8 17 01 be 05 7c b4 41 bb aa 55 cd 13 5a 52 72 |.|.A..U..ZRr| 00a0 3d 81 fb 55 aa 75 37 83 e1 01 74 32 31 c0 89 44 |=..U.u7...t21..D| 00b0 04 40 88 44 ff 89 44 02 c7 04 10 00 66 8b 1e 5c |.@.D..D.f..\| 00c0 7c 66 89 5c 08 66 8b 1e 60 7c 66 89 5c 0c c7 44 ||f.\.f..`|f.\..D| 00d0 06 00 70 b4 42 cd 13 72 05 bb 00 70 eb 76 b4 08 |..p.B..r...p.v..| 00e0 cd 13 73 0d 5a 84 d2 0f 83 d8 00 be 8b 7d e9 82 |..s.Z}..| 00f0 00 66 0f b6 c6 88 64 ff 40 66 89 44 04 0f b6 d1 |.fd.@f.D| 0100 c1 e2 02 88 e8 88 f4 40 89 44 08 0f b6 c2 c0 e8 |...@.D..| 0110 02 66 89 04 66 a1 60 7c 66 09 c0 75 4e 66 a1 5c |.f..f.`|f..uNf.\| 0120 7c 66 31 d2 66 f7 34 88 d1 31 d2 66 f7 74 04 3b ||f1.f.4..1.f.t.;| 0130 44 08 7d 37 fe c1 88 c5 30 c0 c1 e8 02 08 c1 88 |D.}70...| 0140 d0 5a 88 c6 bb 00 70 8e c3 31 db b8 01 02 cd 13 |.Zp..1..| 0150 72 1e 8c c3 60 1e b9 00 01 8e db 31 f6 bf 00 80 |r...`..1| 0160 8e c6 fc f3 a5 1f 61 ff 26 5a 7c be 86 7d eb 03 |..a.&Z|..}..| 0170 be 95 7d e8 34 00 be 9a 7d e8 2e 00 cd 18 eb fe |..}.4...}...| 0180 47 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 |GRUB .Geom.Hard | 0190 44 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f 72 |Disk.Read. Error| 01a0 0d 0a 00 bb 01 00 b4 0e cd 10 ac 3c 00 75 f4 c3 |...<.u..| 01b0 00 00 00 00 00 00 00 00 13 43 3c 32 00 00 80 04 |.C<2| 01c0 01 04 83 fe c2 ff 00 08 00 00 00 90 3b 00 00 00 |;...| 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| 0200
Bug#1058638: grub-installer: boot fails: $bootdev empty [BIOS/MBR, Vista, 2 disks]: Installing grub on ''
Source: grub-installer Version: 1.194 Followup-For: Bug #1058638 I think this may be due to the same cause as #1035096 and possibly also #1035085
Bug#1058638: grub-installer: boot fails: $bootdev empty [BIOS/MBR, Vista, 2 disks]: Installing grub on ''
Source: grub-installer Version: 1.194 Severity: important Tags: d-i Whilst helping user "mavaviij" in matrix Debian room I was able to reproduce in a virtual machine a bug that causes the Debian install to fail to boot with a blinking cursor after install. After a lot of code-chasing it appears the problem is that grub-installer script fails to set its $bootdev variable: grub-installer: info: Installing grub on '' (note the empty quotes) The target system has two 'disks'. The first has Microsoft Windows Vista with 2 NTFS partitions using msdos label/MBR. The second is empty and intended for the Debian OS and boot-loader. The system boots in BIOS/Legacy/CSM mode. I've not been able to trace back through the code to figure out why the failure occurs. I have however identifed what may be a clue: the Debian OS disk sector 0 appears to contain GRUB's g2hdr.img which makes me wonder if grub-ntldr-img was used - although not sure how that is done and see no sign of it in the (saved) installer logs. Reproducer: Using debian-12.4.0-amd64-netinst.iso fallocate -l 10 disk1-windows-vista.bin fallocate -l 20 disk2-debian-12.bin fdisk disk1-windows-vista.bin #new: 1, default,512M #type: 1, 07 #new: 2, default, default #type: 2, 07 #write sudo losetup -P --show -f disk1-windows-vista.bin # /dev/loop0 sudo mount /dev/loop0p1 /mnt/tmp/ # fool os-prober into detecting Vista sudo mkdir /mnt/tmp/boot sudo touch /mnt/tmp/bootmgr echo "W i n d o w s V i s t a " | sudo dd of=/mnt/tmp/boot/bcd find /mnt/tmp/ -ls; hexdump -C /mnt/tmp/boot/bcd 5 4 drwxrwxrwx 1 root root 4096 Dec 13 14:41 /mnt/tmp/ 64 0 drwxrwxrwx 1 root root0 Dec 13 14:42 /mnt/tmp/boot 65 1 -rwxrwxrwx 1 root root 27 Dec 13 14:32 /mnt/tmp/boot/bcd 67 0 -rwxrwxrwx 1 root root0 Dec 13 14:41 /mnt/tmp/bootmgr 57 20 69 20 6e 20 64 20 6f 20 77 20 73 20 20 20 |W i n d o w s | 0010 56 20 69 20 73 20 74 20 61 20 0a |V i s t a .| 001b sudo umount /mnt/tmp sudo os-prober /dev/loop0p1:Windows Vista:Windows:chain Now create a (libvirt/QEMU) VM guest with the 2 disk images attached and go through the install procedure choosing the unpartitioned second disk as the target. At the question about installing the boot loader to the "primary disk" answer No, then when the option to select which boot device to use choose the 2nd disk where Debian is installed. Save debug logs, restart VM, and even if using the SeaBIOS boot menu via pressing Esc key, choosing the VirtIO boot device results in blinking cursor. Examine disk images and note that disk2 appears to have GRUB's g2hdr.img in sector 0. hexdump -C -n 512 disk2-debian-12.bin fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 || 0010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.!..| 0020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |8.uu| 0030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.|...t..| 0040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.|.| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01b0 00 00 00 00 00 00 00 00 13 43 3c 32 00 00 00 04 |.C<2| 01c0 01 04 83 fe c2 ff 00 08 00 00 00 90 3b 00 00 00 |;...| 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| 0200 NOTE: on an UEFI system doing the reproducer one needs to edit /usr/lib/os-probes/mounted/20microsoft and comment out the test for UEFI on lines 11-14 if wanting to manually test os-prober outside the running installer.
Bug#1053101: qemu-user-static: Remove --disable-pie
Package: qemu-user-static
Version: 1:7.2+dfsg-7+deb12u2
Followup-For: Bug #1053101
After several experiments and using `readelf -l` to check that there is
no INTERP Program Header and testing with
qemu-7.2+dfsg/b/user-static/qemu-aarch64 -d page
sid-aarch64/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 --verify
sid-aarch64/usr/bin/aarch64-linux-gnu-g++-13
I am reasonably confident that removing --disable-pie is the solution
for this.
The only caveat is the tests are specific to amd64 host and aarch64
target and I cannot test all the other potential combinations for a
regression.
However I've included a debdiff with the proposed change.
diff -Nru qemu-7.2+dfsg/debian/changelog qemu-7.2+dfsg/debian/changelog
--- qemu-7.2+dfsg/debian/changelog 2023-08-17 10:33:57.0 +0100
+++ qemu-7.2+dfsg/debian/changelog 2023-11-26 09:26:24.0 +
@@ -1,3 +1,9 @@
+qemu (1:7.2+dfsg-7+deb12u2.1) UNRELEASED; urgency=medium
+
+ * user-static: build position independent executable. Closes: #1053101.
+
+ -- Tj Sun, 26 Nov 2023 09:26:24 +
+
qemu (1:7.2+dfsg-7+deb12u2) bookworm; urgency=medium
* d/rules: add the forgotten --enable-virtfs for the xen build.
diff -Nru qemu-7.2+dfsg/debian/rules qemu-7.2+dfsg/debian/rules
--- qemu-7.2+dfsg/debian/rules 2023-08-17 10:33:57.0 +0100
+++ qemu-7.2+dfsg/debian/rules 2023-11-26 09:26:24.0 +
@@ -363,7 +363,7 @@
cd b/user-static && \
../../configure ${common_configure_opts} \
--extra-cflags="${extra-cflags}$(if $(filter
${DEB_HOST_ARCH},arm64), -fno-pie -no-pie,)" \
- --static --disable-pie --disable-system --disable-xen \
+ --static --disable-system --disable-xen \
--target-list="$(addsuffix -linux-user,${user_targets})"
touch $@
build-user-static: b/user-static/built
Bug#1053101: qemu-user-static: Without PIE emulator and targets map to same address
Package: qemu-user-static Version: 1:7.2+dfsg-7+deb12u2 Followup-For: Bug #1053101 After building without `--disable-pie` and observing differences and results I suspect the cause is something that is so obvious I missed it! The emulator - when totally static - maps to 0x0004 itself. Then in the target ld-linux-aarch64.so.1 tries to map a static aarch64 executable to the same address (0x0004) and since qemu doesn't translate that in any way (could it?) the SIGSEGV occurs because the emulator (qemu-aarch64-static) already uses that address. However... the mmap() documentation suggests it should return -1 and set errno and I'd expect that to be EEXIST MAP_FIXED_NOREPLACE. However #2... those same docs state SIGSEGV when "Attempted write into a region mapped as read-only" and that does make sense if the emulator's .text is mapped there (presumably as PROT_EXEC|PROT_READ and MAP_DENYWRITE).
Bug#1056727: qemu-user-static: FTBFS when linux-libc-dev /usr/include/linux/btrfs.h installed
Package: qemu-user-static
Version: 1:7.2+dfsg-7+deb12u2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Whilst investigating #1053101 and needing to build the
qemu-aarch64-static without `--disable-pie` I hit an FTBFS with:
qemu-7.2+dfsg$ mkdir b
qemu-7.2+dfsg$ fakeroot debian/rules build-user-static
...
FAILED: libqemu-i386-linux-user.fa.p/linux-user_syscall.c.o
cc -m64 -mcx16 -Ilibqemu-i386-linux-user.fa.p -I. -I../.. -Itarget/i386
-I../../target/i386 -I../../common-user/host/x86_64
-I../../linux-user/include/host/x86_64 -I../../
linux-user/include -Ilinux-user -I../../linux-user -Ilinux-user/i386
-I../../linux-user/i386 -Iqapi -Itrace -Iui/shader -I/usr/include/capstone
-I/usr/include/glib-2.0 -I/
usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall
-Winvalid-pch -std=gnu11 -O2 -g -isystem
/srv/NAS/Sunny/SourceCode/qemu/qemu-7.2+dfsg/linux-header
s -isystem linux-headers -iquote . -iquote
/srv/NAS/Sunny/SourceCode/qemu/qemu-7.2+dfsg -iquote
/srv/NAS/Sunny/SourceCode/qemu/qemu-7.2+dfsg/include -iquote /srv/NAS/Sunny
/SourceCode/qemu/qemu-7.2+dfsg/tcg/i386 -pthread -U_FORTIFY_SOURCE
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wundef -
Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security
-Wformat-y2k -W
init-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels
-Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs
-Wno-shift-negative-v
alue -Wno-psabi -fstack-protector-strong -g -O2
-ffile-prefix-map=/srv/NAS/Sunny/SourceCode/qemu/qemu-7.2+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security
-Wdate-time -g -O2
-ffile-prefix-map=/srv/NAS/Sunny/SourceCode/qemu/qemu-7.2+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE
=2 -fPIE -isystem../../linux-headers -isystemlinux-headers -DNEED_CPU_H
'-DCONFIG_TARGET="i386-linux-user-config-target.h"'
'-DCONFIG_DEVICES="i386-linux-user-config-devic
es.h"' -MD -MQ libqemu-i386-linux-user.fa.p/linux-user_syscall.c.o -MF
libqemu-i386-linux-user.fa.p/linux-user_syscall.c.o.d -o
libqemu-i386-linux-user.fa.p/linux-user_sys
call.c.o -c ../../linux-user/syscall.c
In file included from /usr/include/linux/btrfs.h:29,
from ../../linux-user/syscall.c:163:
/usr/include/linux/fs.h:50:8: error: redefinition of ‘struct file_clone_range’
50 | struct file_clone_range {
|^~~~
../../linux-user/syscall.c:129:8: note: originally defined here
129 | struct file_clone_range {
The workaround is:
$ sudo mv /usr/include/linux/btrfs.h{,.disabled}
However I'm not sure what the proper fix for this would be. For usual
package building this file wouldn't be installed BUT the configure
script does detect it with HAVE_BTRFS_H:
$ grep -rn HAVE_BTRFS_H *
b/user-static/config-host.h:366:#undef HAVE_BTRFS_H
docs/devel/build-system.rst:287: config_host_data.set('HAVE_BTRFS_H',
cc.has_header('linux/btrfs.h'))
linux-user/syscall_defs.h:980:#ifdef HAVE_BTRFS_H
linux-user/syscall.c:162:#ifdef HAVE_BTRFS_H
meson.build:1952:config_host_data.set('HAVE_BTRFS_H',
cc.has_header('linux/btrfs.h'))
So I think this is a genuine bug that probaby needs squashing upstream.
I've not had chance to test this with latest upstream so far but will do
at some point and report an upstream issue if it still exists.
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'stable'), (100, 'proposed-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
qemu-user-static depends on no packages.
Versions of packages qemu-user-static recommends:
ii binfmt-support 2.2.2-2
ii systemd 252.17-1~deb12u1
Bug#1053101: qemu-user-static: Trace results
Package: qemu-user-static Version: 1:7.2+dfsg-7+deb12u2 Followup-For: Bug #1053101 Sharing some further in-depth debugging results. Everything seems to point to the executables with ELF type 3 (Linux) not marked as PIE suffering the same fate. The address that faults is always 0x40 so I'm hunting for that in glibc's ld.so since I suspect it is a hard-coded default when not asking the kernel to suggest an address with mmap(NULL, ...) that ends up with an address that matches the host process virtual addresses. $ /usr/bin/qemu-aarch64-static -d page,strace,cpu,exec,trace:guest_user_syscall,trace:target_mmap sid-aarch64/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 --verify sid-aarch64/usr/bin/aarch64-linux-gnu-g++-13 host mmap_min_addr=0x1 Locating guest address space @ 0x0 target_mmap start=0x0 len=0x2041360 prot=0x0 flags=0x4022 fd=-1 offset=0x0 page layout changed following mmap startend size prot 0055-005502042000 02042000 --- target_mmap start=0x55 len=0x26000 prot=0x5 flags=0x12 fd=3 offset=0x0 ... Trace 0: 0x7f4f18029a00 [01009331/005566ac/0001/] PC=005566ac X00=0040 X01=00504968 X02=00504968 X03= X04=6474e551 X05=1730 X06=005502841270 X07=0006 X08=6098 X09= X10=0002 X11= X12=004fe8d0 X13=1000 X14=0001 X15= X16=0001 X17=f000 X18=004fe000 X19=2000 X20=0003 X21= X22=005500041390 X23=005500041360 X24=005502840de0 X25=00104968 X26=005502840de0 X27=00550003f000 X28=0055028412b0 X29=005502841010 X30= SP=005502840db0 PSTATE=8000 N--- EL0t SVCR= -- BTYPE=0 Linking TBs 0x7f4f18029a00 index 0 -> 0x7f4f18029bc0 Trace 0: 0x7f4f18029bc0 [01009331/005566c0/0001/] PC=005566c0 X00=005502840e50 X01=00504968 X02=00504968 X03= X04=6474e551 X05=1730 X06=005502841270 X07=0006 X08=6098 X09= X10=0002 X11= X12=004fe8d0 X13=1000 X14=0001 X15= X16=0001 X17=f000 X18=004fe000 X19=2000 X20=0003 X21= X22=005500041390 X23=005500041360 X24=005502840de0 X25=00104968 X26=005502840de0 X27=00550003f000 X28=0055028412b0 X29=005502841010 X30= SP=005502840db0 PSTATE=8000 N--- EL0t SVCR= -- BTYPE=0 Linking TBs 0x7f4f18029bc0 index 0 -> 0x7f4f18029d80 Trace 0: 0x7f4f18029d80 [01009331/005566cc/0001/] PC=005566cc X00=0040 X01=004e5000 X02=00504968 X03= X04=6474e551 X05=1730 X06=005502841270 X07=0006 X08=6098 X09= X10=0002 X11= X12=004fe8d0 X13=1000 X14=0001 X15= X16=0001 X17=f000 X18=004fe000 X19=2000 X20=0003 X21= X22=005500041390 X23=005500041360 X24=005502840de0 X25=00104968 X26=005502840de0 X27=00550003f000 X28=0055028412b0 X29=005502841010 X30= SP=005502840db0 PSTATE=2000 --C- EL0t SVCR= -- BTYPE=0 Trace 0: 0x7f4f18029fc0 [01009331/00550001ab90/0001/] PC=00550001ab90 X00=0040 X01=000e5000 X02=0005 X03=0812 X04=0003 X05= X06=005502841270 X07=0006 X08=6098 X09= X10=0002 X11= X12=004fe8d0 X13=1000 X14=0001 X15= X16=0001 X17=f000 X18=004fe000 X19=2000 X20=0003 X21= X22=005500041390 X23=005500041360 X24=005502840de0 X25=00104968 X26=005502840de0 X27=00550003f000 X28=0055028412b0 X29=005502841010 X30=005566f4 SP=005502840db0 PSTATE=2000 --C- EL0t SVCR= -- BTYPE=0 Linking TBs 0x7f4f18029fc0 index 0 -> 0x7f4f1802a140 Trace 0: 0x7f4f1802a140 [01009331/00550001ab98/0001/] PC=00550001ab98 X00=0040 X01=000e5000 X02=0005 X03=0812 X04=0003 X05= X06=005502841270 X07=0006 X08=6098 X09= X10=0002 X11= X12=004fe8d0 X13=1000 X14=0001 X15= X16=0
Bug#1053101: qemu-user-static: PIE and mmap()
Package: qemu-user-static Version: 1:7.2+dfsg-7+deb12u2 Followup-For: Bug #1053101 Debugging across an architecture boundary when the architecture is emulated is... painful! However, as I dig in from both sides this is pointing to an issue with PIE handling. E.g.: $ qemu-aarch64-static -strace sid-aarch64/usr/lib/ld-linux-aarch64.so.1 --verify sid-aarch64/usr/bin/aarch64-linux-gnu-g++-13 482357 brk(NULL) = 0x005500042000 482357 openat(AT_FDCWD,"sid-aarch64/usr/bin/aarch64-linux-gnu-g++-13",O_RDONLY|O_CLOEXEC) = 3 482357 read(3,0x2841280,832) = 832 482357 getcwd(0x5500041980,128) = 18 482357 mmap(0x0040,937984,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0)Segmentation fault (core dumped) $ qemu-aarch64-static -strace sid-aarch64/usr/lib/ld-linux-aarch64.so.1 --verify sid-aarch64/usr/bin/ls 493812 brk(NULL) = 0x005500042000 493812 openat(AT_FDCWD,"sid-aarch64/usr/bin/ls",O_RDONLY|O_CLOEXEC) = 3 493812 read(3,0x28412a0,832) = 832 493812 getcwd(0x5500041970,128) = 18 493812 mmap(NULL,334096,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x005502844000 493812 mmap(0x00550285,268560,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x00550285 493812 munmap(0x005502844000,49152) = 0 493812 munmap(0x005502892000,14608) = 0 493812 mprotect(0x005502873000,114688,PROT_NONE) = 0 493812 mmap(0x00550288f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2f000) = 0x00550288f000 493812 mmap(0x005502891000,2320,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x005502891000 493812 close(3) = 0 493812 exit_group(0) Take a close look at the address of the mmap()s: 0x0040 vs 0x00550285 - this hints at the difference handling of PIE and non-PIE. The latter (for the PIE executable `ls`) does an initial `mmap(NULL, length_of_binary+64k), ...` This looks like it may be a sign of PIE and Address Space Layout Randomisation getting confused in the QEMU code between the qemu binary itself and the target it is interpretting for. For a GCC binary that is PIE it works: file /usr/bin/aarch64-linux-gnu-ld.gold /usr/bin/aarch64-linux-gnu-ld.gold: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=21bf827bc36e1b6cd7d8b280d5b5d385b4946d17, for GNU/Linux 3.7.0, stripped $ qemu-aarch64-static -strace sid-aarch64/usr/lib/ld-linux-aarch64.so.1 --verify sid-aarch64/usr/bin/aarch64-linux-gnu-ld.gold 505564 brk(NULL) = 0x005500042000 505564 openat(AT_FDCWD,"sid-aarch64/usr/bin/aarch64-linux-gnu-ld.gold",O_RDONLY|O_CLOEXEC) = 3 505564 read(3,0x2841280,832) = 832 505564 getcwd(0x5500041980,128) = 18 505564 mmap(NULL,5765104,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x005502844000 505564 mmap(0x00550285,5699568,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x00550285 505564 munmap(0x005502844000,49152) = 0 505564 munmap(0x005502dc,14320) = 0 505564 mprotect(0x005502d72000,73728,PROT_NONE) = 0 505564 mmap(0x005502d84000,184320,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x524000) = 0x005502d84000 505564 mmap(0x005502db1000,59376,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x005502db1000 505564 close(3) = 0 505564 exit_group(0) In the qemu code in `./accel/tcg/translate-all.c::page_find_alloc()` there are calls to the built-in glib-2.0 g_new0() on the host. Maybe PIE affects how the glib functions form the underlying mmap() call?
Bug#1053101: qemu-user-static: PIE conflicts?
Package: qemu-user-static Version: 1:7.2+dfsg-7+deb12u2 Followup-For: Bug #1053101 I forgot to note that Michael's observation that building qemu-user-static without --disable-pie might reveal a conflict between the emulator and target linking: # file /usr/bin/ls /usr/bin/ls: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=6cc2da196ef5482b32870624563242ff38023843, for GNU/Linux 3.7.0, stripped # file /usr/bin/aarch64-linux-gnu-g++-13 /usr/bin/aarch64-linux-gnu-g++-13: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=30e11cf9cf6aec0c01374a11a36b1687195905cb, for GNU/Linux 3.7.0, stripped # objdump -f /usr/bin/ls /usr/bin/ls: file format elf64-littleaarch64 architecture: aarch64, flags 0x0150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x5cc0 # objdump -f /usr/bin/aarch64-linux-gnu-g++-13 /usr/bin/aarch64-linux-gnu-g++-13: file format elf64-littleaarch64 architecture: aarch64, flags 0x0112: EXEC_P, HAS_SYMS, D_PAGED start address 0x0042e3c0 So `ls` is a "pie executable" and does not have "EXEC_P" where g++ is just "executable" and has "EXEC_P". The interpreter has: # file /lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 /lib/aarch64-linux-gnu/ld-linux-aarch64.so.1: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=65beabffba8dc9cab560b4338b8b0d568d21c964, stripped # objdump -f /lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 /lib/aarch64-linux-gnu/ld-linux-aarch64.so.1: file format elf64-littleaarch64 architecture: aarch64, flags 0x0150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x0001a1c0
Bug#1053101: qemu-user-static: Host debug trace
Package: qemu-user-static
Version: 1:7.2+dfsg-7+deb12u2
Followup-For: Bug #1053101
Initially I noticed the ELF types shown for ls (0 a.k.a. SYSV) and
aarch64-linux-gnu-g++-13 (3 a.k.a. GNU/Linux) are different.
This is octet offset 7 of the ELF header, e_ident[EI_OSABI]. When it is 3 the
following field (offset 8) e_ident[EI_ABIVERSION] contains
the ABI version of the dynamic linker.
Since the issue seems related to some interaction with static vs dynamic this
may be a clue!
Doing some debugging on amd64 host with an aarch64 sid chroot build we get a
clearer idea of what is going wrong. It looks like in
accel/tcg/translate-all.c::page_find_alloc()
`void **lp` is the problem but has been optimised out by the compiler so I'll
need to build
qemu without optimisations and retry.
$ gdb --directory /srv/NAS/Sunny/SourceCode/qemu/qemu-7.2+dfsg/tcg/aarch64
--args /usr/libexec/qemu-binfmt/aarch64-binfmt-P
sid-aarch64/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 --verify
sid-aarch64/usr/bin/aarch64-linux-gnu-g++-13
Reading symbols from /usr/libexec/qemu-binfmt/aarch64-binfmt-P...
Reading symbols from
/usr/lib/debug/.build-id/7b/ef74adf0c2ded7f731079d47cc8ca9dcc579e1.debug...
(gdb) start
Temporary breakpoint 1 at 0x401b90: file ../../linux-user/main.c, line 664.
Starting program: /usr/libexec/qemu-binfmt/aarch64-binfmt-P
sid-aarch64/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 --verify
sid-aarch64/usr/bin/aarch64-linux-gnu-g++-13
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x77ff86c0 (LWP 250079)]
Thread 1 "aarch64-binfmt-" hit Temporary breakpoint 1, main (argc=4,
argv=0x7fffdb68, envp=0x7fffdb90) at ../../linux-user/main.c:664
664 {
(gdb) break page_find_alloc
(gdb) break do_syscall1 if num == 222
(gdb) c
Thread 1 "aarch64-binfmt-" hit Breakpoint 6, page_find_alloc
(index=index@entry=89128960, alloc=alloc@entry=true) at
../../accel/tcg/translate-all.c:431
431 lp = l1_map + ((index >> v_l1_shift) & (v_l1_size - 1));
(gdb) info break
Num Type Disp Enb AddressWhat
6 breakpoint keep y 0x0061ab70 in page_find_alloc at
../../accel/tcg/translate-all.c:431
breakpoint already hit 1 time
8 breakpoint keep y 0x0063a660 in do_syscall1 at
../../linux-user/syscall.c:8615
stop only if num == 222
(gdb) disable 6
(gdb) c
Continuing.
Thread 1 "aarch64-binfmt-" hit Breakpoint 8, do_syscall1
(cpu_env=cpu_env@entry=0xe44220, num=num@entry=222, arg1=arg1@entry=4194304,
arg2=arg2@entry=937984,
arg3=arg3@entry=5, arg4=arg4@entry=2066, arg5=3, arg6=0, arg8=,
arg7=) at ../../linux-user/syscall.c:8615
8615static abi_long do_syscall1(CPUArchState *cpu_env, int num, abi_long
arg1,
(gdb) enable 6
(gdb) c
Continuing.
Thread 1 "aarch64-binfmt-" hit Breakpoint 6, page_find_alloc
(index=index@entry=1024, alloc=alloc@entry=true) at
../../accel/tcg/translate-all.c:431
431 lp = l1_map + ((index >> v_l1_shift) & (v_l1_size - 1));
(gdb) p lp
$1 =
(gdb) p l1_map
$5 = {0xe9e3f0, 0x0 }
(gdb) p v_l1_shift
$6 = 40
(gdb) p v_l1_size
$7 = 4096
(gdb) p index
$8 = 1024
(gdb) p ((index >> v_l1_shift))
$9 = 0
(gdb) p ((index >> v_l1_shift) & (v_l1_size -1))
$10 = 0
(gdb) p l1_map + ((index >> v_l1_shift) & (v_l1_size -1))
$11 = (void **) 0xe04580
(gdb) n
Thread 1 "aarch64-binfmt-" received signal SIGSEGV, Segmentation fault.
page_find_alloc (index=index@entry=1024, alloc=alloc@entry=true) at
../../accel/tcg/translate-all.c:431
431 lp = l1_map + ((index >> v_l1_shift) & (v_l1_size - 1));
(gdb) p lp
$12 =
(gdb) n
host_signal_handler (host_sig=11, info=0x7fffb8f0, puc=0x7fffb7c0) at
../../linux-user/signal.c:783
783 {
(gdb) n
793 void *sigmask = host_signal_mask(uc);
(gdb) n
784 CPUArchState *env = thread_cpu->env_ptr;
(gdb)
Bug#1040373: lsof does not work correctly with btrfs subvolumes
Package: lsof
Version: 4.95.0-1
Followup-For: Bug #1040373
This seems to be related to upstream issue:
https://github.com/lsof-org/lsof/issues/152 "LTlock fails on btrfs"
Small test-case:
SUBVOL_FILE="/mnt/machines_old/test";
sudo findmnt -oTARGET,SOURCE,FSTYPE,MAJ:MIN "${SUBVOL_FILE%/*}"
sudo stat --format="%n%Hd:%Ld"
"$SUBVOL_FILE"
flock "$SUBVOL_FILE" grep ":$(stat --format="%i" "$SUBVOL_FILE")" /proc/locks
| tee >(bc <<< "ibase=16; $(cut -d: -f 3)")
TARGETSOURCE FSTYPE MAJ:MIN
/mnt/machines_old /dev/mapper/SUNNY-machines_old btrfs0:100
/mnt/machines_old/test0:101
20: FLOCK ADVISORY WRITE 378526 00:64:395 0 EOF
100
Bug#1054040: cups: 'make clean' fails in man/Makefile - master file 'backend.7' does not exist
Package: cups Version: 2.4.2-3+deb12u4 Severity: minor Tags: l10n Whilst cherry-picking an upstream commit to Bookworm (2.4.2-3+deb12u4) to fix #1039983 I discovered an 'un'build failure doing either: debian/rules clean make clean ... Cleaning in man... make[3]: Entering directory '/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man' make[3]: warning: -j12 forced in submake: resetting jobserver mode. /usr/bin/rm -f mantohtml mantohtml.o /usr/bin/rm -f cancel.1 cups.1 cups-config.1 cupstestppd.1 ippeveprinter.1 ippfind.1 ipptool.1 lp.1 lpoptions.1 lpq.1 lprm.1 lpr.1 lpstat.1 ppdc.1 ppdhtml.1 ppdi.1 ppdmerg e.1 ppdpo.1 classes.conf.5 client.conf.5 cups-files.conf.5 cups-snmp.conf.5 cupsd.conf.5 cupsd-logs.5 ipptoolfile.5 mailto.conf.5 mime.convs.5 mime.types.5 ppdcfile.5 prin ters.conf.5 subscriptions.conf.5 backend.7 filter.7 ippevepcl.7 notifier.7 cupsaccept.8 cupsctl.8 cupsfilter.8 cups-lpd.8 cups-snmp.8 cupsd.8 cupsd-helper.8 cupsenable.8 l padmin.8 lpinfo.8 lpmove.8 lpc.8 for lang in de fr pt; do make -C $lang clean; done make[4]: Entering directory '/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/de' /usr/bin/rm -f mantohtml mantohtml.o make[4]: Leaving directory '/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/de' make[4]: Entering directory '/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/fr' /usr/bin/rm -f mantohtml mantohtml.o make[4]: Leaving directory '/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/fr' make[4]: Entering directory '/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/pt' /usr/bin/rm -f mantohtml mantohtml.o make[4]: Leaving directory '/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man/pt' # Make sure the PO files are updated and remove generated # translations. po4a --previous --rm-translations ../debian/manpage-po4a/cups.cfg ../debian/manpage-po4a/cups.cfg:3: The master file 'backend.7' does not exist. make[3]: *** [Makefile:104: clean] Error 255 make[3]: Leaving directory '/srv/NAS/Sunny/SourceCode/cups/cups-openprinting/man' make[2]: *** [Makefile:92: clean] Error 1 make[2]: Leaving directory '/srv/NAS/Sunny/SourceCode/cups/cups-openprinting' dh_auto_clean: error: make -j12 distclean returned exit code 2 make[1]: *** [debian/rules:259: override_dh_auto_clean] Error 2 make[1]: Leaving directory '/srv/NAS/Sunny/SourceCode/cups/cups-openprinting' make: *** [debian/rules:24: clean] Error 2 It looks like debian/patches/0016-Debian-po4a-infrastructure-and-translations-for-manp.patch assumes the clean target is operating in the build directory (./debian/tmp/) where a 'master' man-page does exist.
Bug#1008092: antiword: Possible related RedHat-reported buffer overflow
Package: antiword Followup-For: Bug #1008092 A package search on the RedHat bugzilla shows other reports including tracking bugs for the referenced (security) bug #2064638. https://bugzilla.redhat.com/buglist.cgi?component=antiword&product=Fedora It might be worth contacting Adrian Reber for info on this.
Bug#1008092: antiword: Possible unsanitised input data
Package: antiword Followup-For: Bug #1008092 As requested here's a summary of one potential unsanitised input data issue that may be leading to this (or other) error(s). `vSetSummaryInfoOLE()` calls `pucAnalyseSummaryInfoHeader()` that does: `if (!bReadBuffer(pFile, ... aucBuffer, ...) ... return aucBuffer;` and then calls `vAnalyseSummaryInfo(pucBuffer)` - there-in if `ulOffset` is especially large the following: `tPropType = (size_t)ulGetLong(ulOffset, aucBuffer);` could be outside of `aucBuffer` since the size of the buffer is not passed to this function and therefore cannot be checked.
Bug#1052290: cryptsetup-initramfs: askpass is not executed; cryptroot-unlock fails
On 20/09/2023 08:35, Guilhem Moulin wrote:
Control: tag -1 moreinfo
On Tue, 19 Sep 2023 at 22:39:40 +0100, Tj wrote:
Error: Timeout reached while waiting for askpass.
After using `break=mount` and investigating with `sh -x
/bin/cryptsetup-unlock` it seems it fails because it is not finding
`askpass` in the process list.
cryptsetup-unlock waits until the initramfs boot script is blocking on
passphrase prompt. This is only useful for injecting passphrases from
outside the initramfs console (for instance from a remote shell).
When you set ‘break=mount’ our boot script isn't running in the
background, so cryptsetup-unlock timeouts. This is expected. Why are
you running cryptsetup-unlock in the first place instead of relying on
the builtin initramfs logic? Also, FWIW ‘break=mount’ breaks *after*
unlocking whatever block devices need to be unlocked, so cryptsetup-initramfs
has nothing more to do at this point.
Apologies for a mis-type there; I am using `break=premount`.
The install "appears" to fail to find and unlock both LUKS devices;
it "hangs" (pauses) for a very long time with only kernel messages showing but
no passphrase prompt is shown.
After debugging it turns out the kernel command-line option `debug` and
initramfs-tools
`init` script cause the passphrase prompts to be redirected to
`initramfs.debug` when askpass
is using "console" output.
It might be better if askpass writes the prompt directly to `/dev/console`.
I've done a basic
test and this does work when stdin/stderr are redirected. See end of this
email.
Tapping `[Enter]` a few times will sometimes cause a few blank lines to
scroll and seem to move things on since a few more kernel messages are
generated (showing that more udev rules are being triggered).
Eventually, after more taps of `[Enter]` (or maybe due to a coincidental
timeout)
it does drop to shell. This is after something like 600 seconds (10 minutes).
Then I find:
REASON=ALERT! UUID=cb2a... does not exist. Dropping to shell!
`/proc/cmdline`: BOOT_IMAGE=/@/boot/vmlinuz... root=UUID=cb2a... ro
rootflags=subvol=@ debug systemd.log_level=info
Looking at `/run/initramfs/initramfs.debug` today I see the reason for it
failing:
when using `debug` the init script does:
```
debug)
debug=y
quiet=n
if [ -n "${netconsole}" ]; then
log_output=/dev/kmsg
else
log_output=/run/initramfs/initramfs.debug
fi
set -x
;;
```
And looking at `/run/initramfs/initramfs.debug` it has 'captured' the
passphrase prompts:
```
+ /scripts/local-top/cryptroot
Please unlock disk luks-88faf2e0-400b-4533-bdab-11ddb8d07fa7:
Nothing to read on input.
cryptsetup: ERROR: luks-88faf2e0-400b-4533-bdab-11ddb8d07fa7: cryptsetup
failed, bad password or options?
Please unlock disk luks-88faf2e0-400b-4533-bdab-11ddb8d07fa7:
Nothing to read on input.
cryptsetup: ERROR: luks-88faf2e0-400b-4533-bdab-11ddb8d07fa7: cryptsetup
failed, bad password or options?
Please unlock disk luks-88faf2e0-400b-4533-bdab-11ddb8d07fa7:
Nothing to read on input.
cryptsetup: ERROR: luks-88faf2e0-400b-4533if (fwrite(prompt_ptr, line_len, 1,
stderr) < 1 ||
fwrite("\n", 1, 1, stderr) < 1) {
-bdab-11ddb8d07fa7: cryptsetup
failed, bad password or options?
cryptsetup: ERROR: luks-88faf2e0-400b-4533-bdab-11ddb8d07fa7: maximum number of
tries exceeded
```
Typing the passphrases blind when the kernel messages 'hang' with a decent
pause between them
to allow for the time it takes to 'unlock' allows one to continue starting
successfully.
So the issue isn't askpass not running but the lack of a passphrase prompt when
using
`debug` on kernel command line AND askpass using its "console" method.
I set `debug` by default on all hosts but on most that use cryptsetup-initramfs
the host
is using key-files so never prompts for a passphrase and therefore I never hit
this issue before.
Diagnosing why the prompt is 'lost' `run_keyscript()` does:
```
elif [ "$keyscriptarg" = "none" ]; then
# don't export the prompt message as CRYPTTAB_KEY
keyscript="/lib/cryptsetup/askpass"
keyscriptarg="Please unlock disk $CRYPTTAB_NAME: "
fi
exec "$keyscript" "$keyscriptarg"
```
and that is the source of the prompt (there are 2 places where an identical
prompt
is set/written).
I enabled DEBUG in `askpass` and copied it into the initrd to capture
`/tmp/askpass.debug`
and then allowed init to continue (`exit`).
I had to tap [Enter] a few times to get back to the shell, then looking at the
log:
```
Enabling method systemd
Enabling method fifo
Enabling method plymouth
Enabling method console
method 1 has fd 4 and name fifo
method 3 has fd 0 and name console
Starting select with nfds 5
Writing 0 bytes to stdout
Disabling method ALL
```
This is repeate
Bug#1052290: cryptsetup-initramfs: askpass is not executed; cryptroot-unlock fails
Package: cryptsetup-initramfs
Version: 2:2.6.1-4~deb12u1
Severity: important
Discovered this whilst working on a relatively simple test of multiple
LUKS block devices for LUKS.0 + LUKS.1 > btrfs RAID1 @/ - that is a
BTRFS RAID1 using 2 LUKS block devices.
Two files represent SSD1 and SSD2, which each have GPT with:
1: EFI-SP (ef00)
2: LUKS (8309) for BTRFS
3: LUKS (8309) for swap
added as loop devices and configured. SSD2's EFI-SP partition is not
formatted.
# fallocate -l 12G ssd${x}.raw
# sgdisk --new=... --typecode=... ssd${x}.raw
# losetup --show --partscan --find ssd${x}.raw
mkfs.vfat -F 16 ${SSD1}p1
# next 2 also applied to SSD2
cryptsetup luksFormat --pbkdf pbkdf2 ${SSD1}p2
cryptsetup open ${SSD1}p2 luks-$(UUID_SSD1p2}
mkfs.btrfs -d raid1 -m raid1 /dev/mapper/luks-${UUID_SSD1p2}
/dev/mapper/luks-${UUID_SSD2p2}
mount /dev/mapper/luks-${UUID_SSD1p2} /target
btrfs subvol create /target/@
btrfs subvol create /target/@home
umount /target
mount -o subvol=@ /dev/mapperluks-${UUID_SSD1p2}
debootstrap bookworm /target
# add and configure packages for bootable EFI image
After unmounting and closing devices create a libvirt VM guest using the
two files as virtio storage and configure for UEFI boot.
On startup GRUB correctly opens the LUKS block devices to access vmlinuz
and initrd.img, and its own configuration and modules.
On reaching initialramfs it fails to unlock either of the LUKS devices;
eventually dropping to the shell after reporting:
Error: Timeout reached while waiting for askpass.
After using `break=mount` and investigating with `sh -x
/bin/cryptsetup-unlock` it seems it fails because it is not finding
`askpass` in the process list.
On closer examination and searching I am unable to locate where
/usr/lib/cryptsetup/askpass is actually executed. `cryptsetup-unlock`
correctly locates the file with [ -f ] and ensures it is executable with
[-x ] but I do not see any attempt to actually execute it.
If needed I can either share the 2 SSD files or a script to build them.
-- System Information:
Debian Release: 12.1
Architecture: amd64 (x86_64)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cryptsetup-initramfs depends on:
ii busybox-static [busybox]1:1.36.0-1~exp1
ii cryptsetup 2:2.6.1-4~deb12u1
ii debconf [debconf-2.0] 1.5.82
ii initramfs-tools [linux-initramfs-tool] 0.143~tj01
Versions of packages cryptsetup-initramfs recommends:
ii console-setup 1.221
ii kbd2.5.1-1+b1
Bug#1051535: linux: HW_RANDOM_TPM disabled due to IMA=y
Source: linux Severity: normal Working with a Debian user in Matrix channel #Debian where they report that the TPM hardware random number generator that was available in v5.10* series is missing from v6.1* series for the amd64 kernel. After examining the Kconfig options and the Debian configs I found that due to commit 6e679322d7d "Re-enable IMA" that possibly inadvertently it disabled HW_RANDOM_TPM. The reason being that we have: config HW_RANDOM_TPM bool "TPM HW Random Number Generator support" depends on TCG_TPM && HW_RANDOM && !(TCG_TPM=y && HW_RANDOM=m) And when IMA=y that does: config IMA bool "Integrity Measurement Architecture(IMA)" ... select TCG_TPM if HAS_IOMEM And `select` will force the target to the same value as this option. TCG_TPM is tri-state (n,y,m) but IMA is boolean (n,y) so this select forces TCG_TPM=y. so !(TCG_TPM=y && HW_RANDOM=m) is true and therefore HW_RANDOM_TPM is not set. $ grep -rnE 'CONFIG_(IMA|TCG_TPM|HW_RANDOM)=' debian/config /boot/config-6.1.0-11-amd64 debian/config/config:457:CONFIG_HW_RANDOM=m debian/config/config:7752:CONFIG_IMA=y debian/config/arm64/config:172:CONFIG_TCG_TPM=m debian/config/kernelarch-x86/config:332:CONFIG_TCG_TPM=m debian/config/config.cloud:149:CONFIG_TCG_TPM=m /boot/config-6.1.0-11-amd64:4324:CONFIG_HW_RANDOM=m /boot/config-6.1.0-11-amd64:4352:CONFIG_TCG_TPM=y /boot/config-6.1.0-11-amd64:9774:CONFIG_IMA=y -- System Information: Debian Release: 12.1 Architecture: amd64 (x86_64) Foreign Architectures: i386
Bug#1051481: apt-cacher-ng: Illegal SRV name (underscore not valid except first character of label)
Package: apt-cacher-ng Version: 3.7.4-1+b2 Severity: important In investigating an mDNS SRV discovery issue with `systemd-resolved` I hit a problem where `systemd-resolved` reports: We have `squid-deb-proxy` and `apt-cacher-ng` (and others) that can advertise an mDNS SRV record `_apt_proxy._tcp`. We have tools such as `auto-apt-proxy` and others that can (try to) discover the SRV record (it uses `apt-helper srv-lookup _apt_proxy._tcp.local`) BUT `systemd-resolved` considers `_apt_proxy` an illegal label because it contains an underscore after the first underscore and fails to resolve it with an error report: `Resolve call failed: Invalid SRV service type '_apt_proxy._tcp'`. I've seen this issue caused by `systemd-machined` in the context of using `mkosi` to build containers where mkosi can include an underscore in the machine name but `systemd-machined` treats it as illegal and won't allow it. The solution is to advertise a legal SRV name as well and modify any tools that look-up the SRV record. For `avahi-daemon`: ``` $ cat /etc/avahi/services/apt-cacher-ng.service apt-cacher-ng proxy on %h _apt_proxy._tcp 3142 _apt_proxy._tcp 3142 _apt-proxy._tcp 3142 _apt-proxy._tcp 3142 ``` And for `systemd-resolved`: ``` $ cat /etc/systemd/dnssd/squid-deb-proxy.dnssd [Service] Name=apt-cacher-ng proxy on %H systemd Type=_apt-proxy._tcp Port=3142 ``` -- Package-specific info: -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable'), (100, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0+debian+tj (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-cacher-ng depends on: ii adduser3.134 ii debconf [debconf-2.0] 1.5.82 ii dpkg 1.21.22 ii libbz2-1.0 1.0.8-5+b1 ii libc-ares2 1.18.1-3 ii libc6 2.36-9+deb12u1 ii libevent-2.1-7 2.1.12-stable-8 ii libevent-pthreads-2.1-72.1.12-stable-8 ii libfuse2 2.9.9-6+b1 ii libgcc-s1 12.2.0-14 ii liblzma5 5.4.1-0.2 ii libssl33.0.9-1 ii libstdc++6 12.2.0-14 ii libsystemd0252.14-1~deb12u1 ii libwrap0 7.6.q-32 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages apt-cacher-ng recommends: ii ca-certificates 20230311 Versions of packages apt-cacher-ng suggests: ii avahi-daemon 0.8-10 pn doc-base -- Configuration Files: /etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: '/etc/apt-cacher-ng/security.conf' -- debconf information excluded
Bug#1051479: squid-deb-proxy: Illegal SRV name (underscore not valid except first character of label)
Package: squid-deb-proxy Severity: important In investigating an mDNS SRV discovery issue with `systemd-resolved` I hit a problem where `systemd-resolved` reports: We have `squid-deb-proxy` and `apt-cacher-ng` (and others) that can advertise an mDNS SRV record `_apt_proxy._tcp`. We have tools such as `auto-apt-proxy` and others that can (try to) discover the SRV record (it uses `apt-helper srv-lookup _apt_proxy._tcp.local`) BUT `systemd-resolved` considers `_apt_proxy` an illegal label because it contains an underscore after the first underscore and fails to resolve it with an error report: `Resolve call failed: Invalid SRV service type '_apt_proxy._tcp'`. I've seen this issue caused by `systemd-machined` in the context of using `mkosi` to build containers where mkosi can include an underscore in the machine name but `systemd-machined` treats it as illegal and won't allow it. The solution is to advertise a legal SRV name as well and modify any tools that look-up the SRV record. For `avahi-daemon`: ``` $ cat /etc/avahi/services/squid-deb-proxy.service Squid deb proxy on %h _apt_proxy._tcp 8000 _apt_proxy._tcp 8000 _apt-proxy._tcp 8000 _apt-proxy._tcp 8000 ``` And for `systemd-resolved`: ``` $ cat /etc/systemd/dnssd/squid-deb-proxy.dnssd [Service] Name=Squid deb proxy on %H systemd Type=_apt-proxy._tcp Port=8000 ``` -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable'), (100, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.1+debian+tj (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1051477: dnssd: IPv6: fails to resolve services
Package: systemd-resolved Version: 252.14-1~deb12u1 Severity: normal Tags: ipv6 upstream Reported upstream and tracked as: https://github.com/systemd/systemd/issues/29120 Two hosts on the same link of an IPv6-only network. Host A is unable to resolve a service record advertised by host B using `resolvectl` where each has multiple IPv6 addresses (link-local, ULA, and global). When host A does `resolvectl -i LOCAL service _apt-proxy._tcp local.` it sends from the link-local address. Host B ignores it. When host A does `avahi-browse -rt _apt-proxy._tcp` it sends from a global address. Host B responds but sends the response from its link-local address to the multicast group. This affects tools like `auto-apt-proxy` that uses `apt-helper srv-lookup ...` and that talks to the system resolver configured in `/etc/resolv.conf` which is systemd-resolve's stub entry when systemd-resolved is active. I was hoping to figure it out and have been working in the source-code but so far not identified anything. It looks to be due to how the multicast DNS (`src/resolve/resolved-mdns*`) discards packets for various reasons on reception. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable'), (100, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.1+debian+tj (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd-resolved depends on: ii dbus [default-dbus-system-bus] 1.14.8-2~deb12u1 ii dbus-broker [dbus-system-bus] 33-1 ii libc6 2.36-9+deb12u1 ii libssl3 3.0.9-1 ii libsystemd-shared 252.14-1~deb12u1 ii systemd 252.14-1~deb12u1 Versions of packages systemd-resolved recommends: ii libnss-myhostname 252.14-1~deb12u1 ii libnss-resolve 252.14-1~deb12u1 Versions of packages systemd-resolved suggests: ii policykit-1 122-3 ii polkitd 122-3 -- no debconf information
Bug#1050786: cgget: buffer overflow detected; Aborted (core dumped)
Package: cgroup-tools
Version: 2.0.2-2
Severity: important
I was casually using the tools to explore v2 configuration and found
that a simple:
$ cgget -a
*** buffer overflow detected ***: terminated
Aborted (core dumped)
crashes. Under strace I see:
newfstatat(AT_FDCWD, "/sys/fs/cgroup/cpuset.mems.effective",
{st_mode=S_IFREG|0444, st_size=0, ...}, 0) = 0
newfstatat(AT_FDCWD, "/sys/fs/cgroup/cgroup.subtree_control",
{st_mode=S_IFREG|0644, st_size=0, ...}, 0) = 0
newfstatat(AT_FDCWD, "/sys/fs/cgroup/memory.reclaim", {st_mode=S_IFREG|0200,
st_size=0, ...}, 0) = 0
newfstatat(AT_FDCWD, "/sys/fs/cgroup/cgroup.max.depth", {st_mode=S_IFREG|0644,
st_size=0, ...}, 0) = 0
newfstatat(AT_FDCWD, "/sys/fs/cgroup/cgroup.pressure", {st_mode=S_IFREG|0644,
st_size=0, ...}, 0) = 0
newfstatat(AT_FDCWD, "/sys/fs/cgroup/io.stat", {st_mode=S_IFREG|0444,
st_size=0, ...}, 0) = 0
openat(AT_FDCWD, "/sys/fs/cgroup/io.stat", O_RDONLY|O_CLOEXEC) = 4
newfstatat(4, "", {st_mode=S_IFREG|0444, st_size=0, ...}, AT_EMPTY_PATH) = 0
read(4, "8:64 rbytes=2230784 wbytes=0 rio"..., 4096) = 4096
close(4)= 0
writev(2, [{iov_base="*** ", iov_len=4}, {iov_base="buffer overflow detected",
iov_len=24}, {iov_base=" ***: terminated\n", iov_len=17}], 3*** buffer overflow
detected ***: terminated
) = 45
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fdf94e01000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid()= 138582
getpid()= 138582
tgkill(138582, 138582, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=138582, si_uid=1000} ---
+++ killed by SIGABRT (core dumped) +++
Aborted (core dumped)
-- Package-specific info:
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0+debian+tj (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cgroup-tools depends on:
ii libc6 2.36-9+deb12u1
ii libcgroup2 2.0.2-2
cgroup-tools recommends no packages.
cgroup-tools suggests no packages.
-- no debconf information
Bug#1050719: debootstrap: Leaving wget-log* files in $PWD
Package: debootstrap
Version: 1.0.128+nmu2
Severity: normal
Calling debootstrap from a Makefile as part of building a bootable image
for USB Armory devices I find wget-log* files created in the $PWD which
in this case is a git repository. debootstrap is operating on a rootfs
directory in another path outside the repository.
After adding 'set -x' to
/usr/share/debootstrap/functions::wgetprogress() it revealed:
+ [ ! ]
+ NVSWITCH=-nv
+ local ret=0
+ [ ]
+ wget -nv -O
/srv/NAS/Sunny/SourceCode/builds/usbarmory/mark-one/imx53/rootfs/var/lib/apt/lists/partial/deb.debian.org_debian_dists_bookworm_InRelease
http://deb.debian.org/debian/dists/bookworm/InRelease
Redirecting output to 'wget-log.4'.
+ ret=0
+ set +x
Showing that 'wget -nv' is always forced.
usbarmory-debian-base_image$ ls -latr wget*
-rw-r--r-- 1 root root 241 2023-08-28 10:57 wget-log
-rw-r--r-- 1 root root 351 2023-08-28 10:57 wget-log.1
-rw-r--r-- 1 root root 241 2023-08-28 11:15 wget-log.2
-rw-r--r-- 1 root root 351 2023-08-28 11:15 wget-log.3
-rw-r--r-- 1 root root 241 2023-08-28 13:13 wget-log.4
-rw-r--r-- 1 root root 351 2023-08-28 13:14 wget-log.5
The code looks to have been changed at some point because currently it
has a forced:
[ ! "$VERBOSE" ] && NVSWITCH="-nv"
but later uses a shell conditional with:
wget ${NVSWITCH:+"$NVSWITCH"} "$@"
that makes it seem like at some point in the past NVSWITCH could be
overridden and only pass "-nv" if it were unset or null.
It would be preferable to have some control over this from the calling
command line (or via variable override). I've implemented it with a
one-line change that allows WGETOPTS to be set in the calling
environment and is used if set; then doing:
WGETOPTS="--quiet" debootstrap ...
stops the wget-log files being written.
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0+debian+tj (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debootstrap depends on:
ii wget 1.21.3-1+b2
Versions of packages debootstrap recommends:
ii arch-test 0.20-1
ii debian-archive-keyring 2023.3
ii gnupg 2.2.40-1.1
Versions of packages debootstrap suggests:
ii binutils2.40-2
pn squid-deb-proxy-client
pn ubuntu-archive-keyring
ii xz-utils5.4.1-0.2
ii zstd1.5.4+dfsg2-5
--- a/functions 2022-10-18 23:48:32.0 +0100
+++ b/functions 2023-08-28 15:22:43.525204579 +0100
@@ -94,7 +94,7 @@
ret=$({ { wget $@ 2>&1 >/dev/null || echo $? >&2; } |
"$PKGDETAILS" "WGET%" "$PROGRESS_NOW" "$PROGRESS_NEXT" "$PROGRESS_END" >&3; }
2>&1)
: ${ret:=0}
else
- wget ${NVSWITCH:+"$NVSWITCH"} "$@"
+ wget ${WGETOPTS:-"${NVSWITCH}"} "$@"
ret=$?
fi
return $ret
Bug#1041647: Stepping back and checking basics
Power-off reboot fixed the issue, so can mark this bug report as invalid or similar. $ vainfo libva info: VA-API version 1.17.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/r600_drv_video.so libva info: Found init function __vaDriverInit_1_17 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.17 (libva 2.12.0) vainfo: Driver version: Mesa Gallium driver 22.3.6 for VERDE (, LLVM 15.0.6, DRM 2.50, 6.5.0-rc2+debian+tj+) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileNone : VAEntrypointVideoProc $ journalctl --dmesg --grep 'radeon|gpu' Jul 21 20:13:53 sunny kernel: [drm] radeon kernel modesetting enabled. Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: vgaarb: deactivate vga console Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: No more image in the PCI ROM Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: VRAM: 2048M 0x - 0x7FFF (2048M used) Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: GTT: 2048M 0x8000 - 0x Jul 21 20:13:53 sunny kernel: [drm] radeon: 2048M of VRAM memory ready Jul 21 20:13:53 sunny kernel: [drm] radeon: 2048M of GTT memory ready. Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: radeon/verde_pfp.bin Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: radeon/verde_me.bin Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: radeon/verde_ce.bin Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: radeon/verde_rlc.bin Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: radeon/verde_mc.bin Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: radeon/verde_smc.bin Jul 21 20:13:53 sunny kernel: [drm] radeon: dpm initialized Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: radeon/TAHITI_uvd.bin Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: Firmware loaded: radeon/TAHITI_vce.bin Jul 21 20:13:53 sunny kernel: [drm] GART: num cpu pages 524288, num gpu pages 524288 Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: WB enabled Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 0 use gpu addr 0x8c00 Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 1 use gpu addr 0x8c04 Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 2 use gpu addr 0x8c08 Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 3 use gpu addr 0x8c0c Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 4 use gpu addr 0x8c10 Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 5 use gpu addr 0x00075a18 Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 6 use gpu addr 0x8c18 Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: fence driver on ring 7 use gpu addr 0x8c1c Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: radeon: MSI limited to 32-bit Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: radeon: using MSI. Jul 21 20:13:53 sunny kernel: [drm] radeon: irq initialized. Jul 21 20:13:53 sunny kernel: [drm] Radeon Display Connectors Jul 21 20:13:53 sunny kernel: [drm] Initialized radeon 2.50.0 20080528 for :0a:00.0 on minor 0 Jul 21 20:13:53 sunny kernel: fbcon: radeondrmfb (fb0) is primary device Jul 21 20:13:53 sunny kernel: radeon :0a:00.0: [drm] fb0: radeondrmfb frame buffer device Jul 21 20:13:53 sunny kernel: [drm] amdgpu kernel modesetting enabled. Jul 21 20:13:53 sunny kernel: amdgpu: Ignoring ACPI CRAT on non-APU system Jul 21 20:13:53 sunny kernel: amdgpu: Virtual CRAT table created for CPU Jul 21 20:13:53 sunny kernel: amdgpu: Topology: Add CPU node
Bug#1041647: Stepping back and checking basics
After a walk and a think I sensibly stepped back and realised Xorg.0.log reports problems and with that clue so does the kernel (but I hadn't noticed!). I *suspect* this may be related to having kexec-ed into the current kernel. I'm going to try a poweroff restart after this report: $ grep -E 'DRI|rendering' /var/log/Xorg.0.log [60.448] (==) RADEON(0): DRI3 disabled [60.448] (WW) RADEON(0): Direct rendering disabled [60.510] (II) Initializing extension DRI3 [60.510] (II) AIGLX: Screen 0 is not DRI2 capable [60.852] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [60.852] (II) Initializing extension XFree86-DRI [60.852] (II) Initializing extension DRI2 Jul 14 14:52:59 sunny kernel: [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD) Jul 14 14:52:59 sunny kernel: radeon :0a:00.0: disabling GPU acceleration $ uname -r 6.4.3+debian+tj+
Bug#1041647: Further gdb debugging (more #2)
After solving the relative path issue I now have better info:
(gdb) s
__vaDriverInit_1_17 (ctx=0x555702b0) at
../src/gallium/frontends/va/context.c:123
123if (!ctx)
(gdb) n
126drv = CALLOC(1, sizeof(vlVaDriver));
(gdb) n
127if (!drv)
(gdb) n
130switch (ctx->display_type) {
(gdb) n
142 drv->vscreen = vl_dri3_screen_create(ctx->native_dpy,
ctx->x11_screen);
(gdb) n
143 if (!drv->vscreen)
(gdb) n
144 drv->vscreen = vl_dri2_screen_create(ctx->native_dpy,
ctx->x11_screen);
(gdb) s
vl_dri2_screen_create (display=0xd370, screen=0) at
../src/gallium/auxiliary/vl/vl_winsys_dri.c:375
375 {
(gdb) n
385xcb_generic_error_t *error = NULL;
(gdb) n
394scrn = CALLOC_STRUCT(vl_dri_screen);
(gdb) n
395if (!scrn)
(gdb) n
398scrn->conn = XGetXCBConnection(display);
(gdb) n
399if (!scrn->conn)
(gdb) n
402xcb_prefetch_extension_data(scrn->conn, &xcb_dri2_id);
(gdb) n
404extension = xcb_get_extension_data(scrn->conn, &xcb_dri2_id);
(gdb) n
405if (!(extension && extension->present))
(gdb) n
408dri2_query_cookie = xcb_dri2_query_version (scrn->conn,
(gdb) n
411dri2_query = xcb_dri2_query_version_reply (scrn->conn,
dri2_query_cookie, &error);
(gdb) n
412if (dri2_query == NULL || error != NULL ||
dri2_query->minor_version < 2)
(gdb) n
496free(dri2_query);
(gdb) p dri2_query
$1 = (xcb_dri2_query_version_reply_t *) 0x555f26a0
(gdb) p dri2_query->minor_version
$2 = 0
(gdb) n
497free(error);
(gdb) n
500FREE(scrn);
(gdb) n
501return NULL;
(gdb) n
__vaDriverInit_1_17 (ctx=0x555702b0) at
../src/gallium/frontends/va/context.c:145
145 if (!drv->vscreen)
(gdb) n
231FREE(drv);
(gdb) n
232return VA_STATUS_ERROR_ALLOCATION_FAILED;
(gdb) n
va_openDriver (dpy=dpy@entry=0x55570140, driver_name=out>) at ./va/va.c:535
535 if (VA_STATUS_SUCCESS == vaStatus) {
(gdb) n
583 va_errorMessage(dpy, "%s init failed\n",
driver_path);
(gdb) n
libva error: /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so init failed
584 dlclose(handle);
Bug#1041647: Further gdb debugging (more)
The mesa-va-drivers-dbgsym package seems to have incorrect (relative to
build) paths stored which prevents gdb showing the source lines when it
has the path to the mesa-22.6.3 source, however by blindly stepping and
then looking at the source it narrows down the cause:
(gdb) s
126 in ../src/gallium/frontends/va/context.c
(gdb) s
__libc_calloc (n=n@entry=1, elem_size=elem_size@entry=4208) at
./malloc/malloc.c:3629
3629./malloc/malloc.c: No such file or directory.
(gdb) s
3637in ./malloc/malloc.c
(gdb) finish
Run till exit from #0 __libc_calloc (n=n@entry=1,
elem_size=elem_size@entry=4208) at ./malloc/malloc.c:3637
0x76a69893 in __vaDriverInit_1_17 (ctx=0x555702b0) at
../src/gallium/frontends/va/context.c:126
126 ../src/gallium/frontends/va/context.c: No such file or directory.
Value returned is $1 = (void *) 0x555f1370
(gdb) n
127 in ../src/gallium/frontends/va/context.c
(gdb) n
130 in ../src/gallium/frontends/va/context.c
(gdb) n
142 in ../src/gallium/frontends/va/context.c
(gdb) n
143 in ../src/gallium/frontends/va/context.c
(gdb) n
144 in ../src/gallium/frontends/va/context.c
(gdb) n
145 in ../src/gallium/frontends/va/context.c
(gdb) n
231 in ../src/gallium/frontends/va/context.c
(gdb) n
232 in ../src/gallium/frontends/va/context.c
(gdb) n
va_openDriver (dpy=dpy@entry=0x55570140, driver_name=out>) at ./va/va.c:535
535 if (VA_STATUS_SUCCESS == vaStatus) {
(gdb) n
583 va_errorMessage(dpy, "%s init failed\n",
driver_path);
Line 230-233 is:
error_screen:
FREE(drv);
return VA_STATUS_ERROR_ALLOCATION_FAILED;
}
which will be jumped to early if:
case VA_DISPLAY_X11:
drv->vscreen = vl_dri3_screen_create(ctx->native_dpy,
ctx->x11_screen);
if (!drv->vscreen)
drv->vscreen = vl_dri2_screen_create(ctx->native_dpy,
ctx->x11_screen);
if (!drv->vscreen)
drv->vscreen = vl_xlib_swrast_screen_create(ctx->native_dpy,
ctx->x11_screen);
break;
...
}
if (!drv->vscreen)
goto error_screen;
Bug#1041647: Further gdb debugging
Using
export LIBVA_MESSAGING_LEVEL=2; export LIBVA_DRIVER_NAME=radeonsi; gdb
--directory . --directory ../libva-2.17.0 --directory ../mesa-22.3.6
--args /usr/bin/vainfo
I've stepped through vainfo and focused on va_openDriver() which
eventually leads to:
(gdb) n
libva info: Found init function __vaDriverInit_1_17
502 struct VADriverVTable *vtable = ctx->vtable;
(gdb) n
503 struct VADriverVTableVPP *vtable_vpp =
ctx->vtable_vpp;
(gdb) n
504 struct VADriverVTableProt *vtable_prot =
ctx->vtable_prot;
(gdb) n
507 if (!vtable) {
(gdb) n
508 vtable = calloc(1, sizeof(*vtable));
(gdb) n
509 if (!vtable)
(gdb) n
512 ctx->vtable = vtable;
(gdb) n
514 if (!vtable_vpp) {
(gdb) n
515 vtable_vpp = calloc(1, sizeof(*vtable_vpp));
(gdb) n
516 if (vtable_vpp)
(gdb) n
517 vtable_vpp->version =
VA_DRIVER_VTABLE_VPP_VERSION;
(gdb) n
521 ctx->vtable_vpp = vtable_vpp;
(gdb) n
523 if (!vtable_prot) {
(gdb) n
524 vtable_prot = calloc(1, sizeof(*vtable_prot));
(gdb) n
525 if (vtable_prot)
(gdb) n
526 vtable_prot->version =
VA_DRIVER_VTABLE_PROT_VERSION;
(gdb) n
530 ctx->vtable_prot = vtable_prot;
(gdb) n
532 if (init_func && VA_STATUS_SUCCESS == vaStatus)
(gdb) n
533 vaStatus = (*init_func)(ctx);
(gdb) s
535 if (VA_STATUS_SUCCESS == vaStatus) {
(gdb) p vaStatus
$4 = 2
(gdb) n
583 va_errorMessage(dpy, "%s init failed\n",
driver_path);
Bug#1035842: Namespaces: Operation not permitted. Fails to setgroups due to EPERM
Package: tcpdump Version: 4.99.3-1~bpo11+1.1 Severity: normal Tags: patch upstream tcpdump: Couldn't change to 'root' uid=0 gid=0: Operation not permitted When working with user namespaces tcpdump fails. Upstream has several open issues and at least one pull request for this since 2019. https://github.com/the-tcpdump-group/tcpdump/pull/812 I've created a debdiff that works with 4.99.0 and 4.99.3 (bullseye and bullseye-backports/testing/unstable) using the upstream PR 2-line patch. $ unshare --user --map-root-user --mount --net # id uid=0(root) gid=0(root) groups=0(root),65534(nogroup) # echo $$ 557221 On host side: $ touch mynetns $ sudo mount --bind /proc/557221/ns/net mynetns $ sudo ip link add outside type veth peer inside netns $HOME/mynetns $ sudo ip link set up dev outside In namespace: # ip link set up dev inside # tcpdump -ni inside tcpdump: Couldn't change to 'tcpdump' uid=109 gid=113: Operation not permitted # tcpdump -Z root -ni inside tcpdump: Couldn't change to 'root' uid=0 gid=0: Operation not permitted # strace tcpdump -Z root -ni inside ... rt_sigprocmask(SIG_BLOCK, [HUP USR1 USR2 PIPE ALRM CHLD TSTP URG VTALRM PROF WINCH IO], [], 8) = 0 futex(0x7f491f1e8a18, FUTEX_WAKE_PRIVATE, 2147483647) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 setgroups(1, [0]) = -1 EPERM (Operation not permitted) write(2, "tcpdump: ", 9tcpdump: )= 9 write(2, "Couldn't change to 'root' uid=0 "..., 62Couldn't change to 'root' uid=0 gid=0: Operation not permitted) = 62 write(2, "\n", 1 ) = 1 exit_group(1) = ? +++ exited with 1 +++ -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.2.11-tj+ (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tcpdump depends on: ii adduser 3.118 ii libc6 2.31-13+deb11u6 ii libpcap0.8 1.10.3-1~bpo11+1 ii libssl1.1 1.1.1n-0+deb11u4 tcpdump recommends no packages. Versions of packages tcpdump suggests: ii apparmor 2.13.6-10 -- no debconf information *** /srv/NAS/Sunny/SourceCode/tcpdump/tcpdump_4.99.0-2+deb11u1.1.debdiff diff -Nru tcpdump-4.99.0/debian/changelog tcpdump-4.99.0/debian/changelog --- tcpdump-4.99.0/debian/changelog 2022-05-22 17:22:50.0 +0100 +++ tcpdump-4.99.0/debian/changelog 2023-05-10 06:02:09.0 +0100 @@ -1,3 +1,10 @@ +tcpdump (4.99.0-2+deb11u1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Allow use in namespace; don't call setgroups when already root + + -- Tj Wed, 10 May 2023 06:02:09 +0100 + tcpdump (4.99.0-2+deb11u1) bullseye; urgency=medium * Minor AppArmor profile updates (debian/usr.bin.tcpdump): diff -Nru tcpdump-4.99.0/debian/patches/fix-no-call-setgroup-if-already-uid-0.diff tcpdump-4.99.0/debian/patches/fix-no-call-setgroup-if-already-uid-0.diff --- tcpdump-4.99.0/debian/patches/fix-no-call-setgroups-if-already-uid-0.diff 1970-01-01 01:00:00.0 +0100 +++ tcpdump-4.99.0/debian/patches/fix-no-call-setgroups-if-already-uid-0.diff 2023-05-10 05:57:38.0 +0100 @@ -0,0 +1,16 @@ +Description: Do not setgroup() as roo
Bug#1035558: Acknowledgement (libxml2-utils: xmllint ignores --output option and writes to stdout)
Apologies - email client didn't fill the correct address. This was a reply to bug #1035554 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035554 This can be closed!
Bug#1035554: libxml2-utils: xmllint ignores --output option and writes to stdout
I've done some follow-up debugging (on upstream git) to be sure the
problem seems to exist upstream - unless I'm severely misunderstanding
what --output is supposed to do. Anyhow; the trace shows it reaches
doXPathDump(). Note that 'buf' is hard-coded to use stdout. The call to
xmlOutputBufferClose(buf) causes the output to be sent. In gdb I confirm
'output' is set immediately after that:
$ gdb -directory /srv/NAS/Sunny/SourceCode/libxml2/libxml2 -args
/srv/NAS/Sunny/SourceCode/libxml2/libxml2/.libs/xmllint --output
test.txt --html --xpath '//div[contains(@class,
'\''test'\'')]/div/ul/li/a/@href' xmllint-test.html
2038break;
(gdb) p output
$1 = 0x7fffe1d5 "test.txt"
xmllint.c:
static void doXPathDump(xmlXPathObjectPtr cur) {
switch(cur->type) {
case XPATH_NODESET: {
int i;
xmlNodePtr node;
#ifdef LIBXML_OUTPUT_ENABLED
xmlOutputBufferPtr buf;
if ((cur->nodesetval == NULL) || (cur->nodesetval->nodeNr
<= 0)) {
if (!quiet) {
fprintf(stderr, "XPath set is empty\n");
}
break;
}
buf = xmlOutputBufferCreateFile(stdout, NULL);
if (buf == NULL) {
fprintf(stderr, "Out of memory for XPath\n");
progresult = XMLLINT_ERR_MEM;
return;
}
for (i = 0;i < cur->nodesetval->nodeNr;i++) {
node = cur->nodesetval->nodeTab[i];
xmlNodeDumpOutput(buf, NULL, node, 0, 0, NULL);
xmlOutputBufferWrite(buf, 1, "\n");
}
xmlOutputBufferClose(buf);
Bug#1035558: libxml2-utils: xmllint ignores --output option and writes to stdout
Package: libxml2-utils
I've done some follow-up debugging (on upstream git) to be sure the
problem seems to exist upstream - unless I'm severely misunderstanding
what --output is supposed to do. Anyhow; the trace shows it reaches
doXPathDump(). Note that 'buf' is hard-coded to use stdout. The call to
xmlOutputBufferClose(buf) causes the output to be sent. In gdb I confirm
'output' is set immediately after that:
$ gdb -directory /srv/NAS/Sunny/SourceCode/libxml2/libxml2 -args
/srv/NAS/Sunny/SourceCode/libxml2/libxml2/.libs/xmllint --output
test.txt --html --xpath '//div[contains(@class,
'\''test'\'')]/div/ul/li/a/@href' xmllint-test.html
2038break;
(gdb) p output
$1 = 0x7fffe1d5 "test.txt"
xmllint.c:
static void doXPathDump(xmlXPathObjectPtr cur) {
switch(cur->type) {
case XPATH_NODESET: {
int i;
xmlNodePtr node;
#ifdef LIBXML_OUTPUT_ENABLED
xmlOutputBufferPtr buf;
if ((cur->nodesetval == NULL) || (cur->nodesetval->nodeNr
<= 0)) {
if (!quiet) {
fprintf(stderr, "XPath set is empty\n");
}
break;
}
buf = xmlOutputBufferCreateFile(stdout, NULL);
if (buf == NULL) {
fprintf(stderr, "Out of memory for XPath\n");
progresult = XMLLINT_ERR_MEM;
return;
}
for (i = 0;i < cur->nodesetval->nodeNr;i++) {
node = cur->nodesetval->nodeTab[i];
xmlNodeDumpOutput(buf, NULL, node, 0, 0, NULL);
xmlOutputBufferWrite(buf, 1, "\n");
}
xmlOutputBufferClose(buf);
Bug#1035554: libxml2-utils: xmllint ignores --output option and writes to stdout
Package: libxml2-utils
Version: 2.9.10+dfsg-6.7+deb11u4
Severity: normal
Tags: upstream
xmllint is ignoring --output FILE option. I've done a debug run with gdb and it
correctly reads the option and assigns its value to the 'output' variable but
doesn't read that variable before writing the output. Confirmed with gdb's
hardware watch `awatch output`. The final trace before the output is written to
stdout is:
3701if (repeat) {
(gdb) n
3724nbregister = 0;
(gdb) n
3727if (stream != 0)
(gdb) n
3731if (sax) {
(gdb) n
3734parseAndPrintFile(argv[i], NULL);
$ xmllint --output test.txt --html --xpath '//div[contains(@class,
'\''test'\'')]/div/ul/li/a/@href' xmllint-test.html
href="test0.html"
href="test1.html"
href="test2.html"
href="test3.html"
href="test4.html"
href="test5.html"
href="test6.html"
href="test7.html"
href="test8.html"
href="test9.html"
$ cat xmllint-test.html
xmllint test --output
xmllint test --output
test0
test1
test2
test3
test4
test5
test6
test7
test8
test9
-- System Information:
Debian Release: 11.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Versions of packages libxml2-utils depends on:
ii libc62.31-13+deb11u6
ii libxml2 2.9.10+dfsg-6.7+deb11u4
libxml2-utils recommends no packages.
libxml2-utils suggests no packages.
Bug#1034628: netfilter-persistent: Does not support Netfilter rules!
Package: netfilter-persistent Version: 1.0.15 Severity: normal X-Debbugs-Cc: deb...@iam.tj Despite the package name, control file Description text, and man page there is no support for applying kernel Netfilter rules via nftables etc. This is misleading and causes confusion especially as there is a specific iptables-persistent package containing plugins and as such infers the primary package should be handling Netfilters rules. -- System Information: Debian Release: 11.6 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Versions of packages netfilter-persistent depends on: ii init-system-helpers 1.60 ii lsb-base 11.1.0 netfilter-persistent recommends no packages. Versions of packages netfilter-persistent suggests: ii iptables-persistent 1.0.15 -- no debconf information
Bug#943343: fwupd: Workaround using dbus-broker
Package: fwupd Version: 1.5.7-4 Followup-For: Bug #943343 Following Klaus Kudielka's discovery of the systemd bug and the finding there that dbus-broker does not suffer the same problem as the dbus reference implementation I installed "dbus-broker" following the instructions at https://github.com/bus1/dbus-broker/wiki which boils down to: apt install dbus-broker systemctl enable dbus-broker.service systemctl --global enable dbus-broker.service systemctl reboot $ sudo systemctl start fwupd-refresh $ systemctl status fwupd-refresh ○ fwupd-refresh.service - Refresh fwupd metadata and update motd Loaded: loaded (/lib/systemd/system/fwupd-refresh.service; static) Active: inactive (dead) since Thu 2023-02-02 11:22:20 GMT; 1s ago TriggeredBy: ● fwupd-refresh.timer Docs: man:fwupdmgr(1) Process: 4870 ExecStart=/usr/bin/fwupdmgr refresh (code=exited, status=2) Main PID: 4870 (code=exited, status=2) CPU: 35ms $ systemctl list-units --state failed UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.7-tj-7-g94868ba9f924 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwupd depends on: ii libc6 2.31-13+deb11u5 ii libcurl3-gnutls7.87.0-2~bpo11+1 ii libefiboot137-6 ii libelf10.183-1 ii libflashrom1 1.2-5 ii libfwupd2 1.5.7-4 ii libfwupdplugin11.5.7-4 ii libglib2.0-0 2.66.8-1 ii libgnutls303.7.1-5+deb11u2 ii libgudev-1.0-0 234-1 ii libgusb2 0.3.5-1 ii libjcat1 0.1.3-2 ii libjson-glib-1.0-0 1.6.2-1 ii libpolkit-gobject-1-0 0.105-31+deb11u1 ii libsmbios-c2 2.4.3-1 ii libsqlite3-0 3.34.1-3 ii libsystemd0252.4-1~bpo11+1 ii libtss2-esys-3.0.2-0 3.0.3-2 ii libxmlb1 0.1.15-2 ii shared-mime-info 2.0-1 Versions of packages fwupd recommends: ii bolt 0.9.1-1 ii dbus 1.12.24-0+deb11u1 ii fwupd-amd64-signed [fwupd-signed] 1.5.7+4 ii python33.9.2-3 pn secureboot-db ii udisks22.9.2-2+deb11u1 Versions of packages fwupd suggests: pn gir1.2-fwupd-2.0
Bug#971170: Possible cause?
I also see the same list of errors from sddm-greeter using the default KDE/Plasma Breeze theme on Bullseye. I'm not familiar with the KDE/Plasma QML theme system but I believe I've found a clue/cause. Almost all the errors are related to units.XXX but units isn't available and evaluates to NULL. This KDE page indicates "units.XXX" are a Plasma component/class: https://develop.kde.org/hig/layout/units/ My hypothesis is that sddm-greeter is not finding/importing the file that defines the 'units' class/component whereas when a full Plasma session is operating this class/component is implicitly expected to be available. The solution may be as simple as an additional (conditional) import statement. On the host I see several possible sources for it: $ dpkg -S Units.qml plasma-framework: /usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml qml-module-org-kde-kirigami2: /usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/Units.qml qml-module-org-kde-kirigami2: /usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop/Units.qml plasma-framework: /usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/Plasma/Units.qml The first of these looks likely to be the required definition (on the basis it contains some 'readonly' properties) but I'm not sure how the path would be converted to a correct 'import' statement: /usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml However it may be it should be imported via another dependency.
Bug#1004154: Fwd: Bug#1004154: xserver-xorg-video-qxl: XOrg frequently crashes when using qxl driver: qxl(0): error doing QXL_ALLOC
On Sat, 12 Feb 2022 08:21:55 + Felix Leimbach wrote: I noticed that vgamem_mb was still low (32 MB). So I changed to this (slightly wasteful) command-line and am now running the latest kernel (5.15.0-3-amd64): -vga none -device qxl-vga,ram_size_mb=256,vgamem_mb=256,vram_size_mb=256,vram64_size_mb=256,max_outputs=1 Will report back if that helps. Did the vgamem_mb change fix the issue? This bug is currently keeping the package out of bookworm and, if it was a user-specific issue, ought to be closed and the package reintroduced to bookworm. I'm currently doing a full-upgrade bullseye to bookworm and this removal is a blocker for VMs. OpenPGP_0xEFEC37A429CD6080.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1005899: mplayer: should not release with bookworm
On Wed, 16 Mar 2022 20:09:59 +0100 Diederik de Haas wrote: On 16 Feb 2022 23:25:00 +0100 Sebastian Ramacher wrote: > Source: mplayer > Version: 2:1.4+ds1-3 > Severity: serious > Tags: sid bookworm > > I think we should not include mplayer in bookworm. > mpv is a worthy replacement for mplayer. I just found this report whilst doing a buster > bookworm full-upgrade. I have both mplayer and mencoder installed and both were listed for removal. I require mencoder specifically to handle some old legacy format conversion where I found ffmpeg fails despite many attempts to work around the issues with various command-line options. Specifically RealMedia multi-stream formats originally recorded in the 1999-2004 time-frame.
Bug#1016885: obs-studio: IPv6 bind address handling totally broken
Package: obs-studio Version: 26.1.2+dfsg1-2 Severity: wishlist Due to a bug in upstream all IPv6 address handling is broken. The specific problem is incorrect setting of sin_addr for calls to inet_ntop()/inet_pton() resulting in broken string representation of IPv6 addresses, which percolates up into the user interface. OBS tries to figure out the correct IPv6 source address to bind to, but when setting the BindIP with the corrupted string, causes bind() to fail with "address does not exist" GUI message and: info: [rtmp stream: 'adv_stream'] Binding to IPv6 info: RTMP_Connect0, failed to bind socket: unknown error (99) The fix is in upstream as commit #fb7a037bc "obs-outputs: Fix binding to IPv6 addresses on *nix". I've added this patch on top of the current Debian version and confirmed it fixes the bug.
Bug#991625: debootstrap: extra-suites= broken; attempts Package.* fetches from primary suite
Package: debootstrap
Version: 1.0.123
Severity: important
X-Debbugs-Cc: deb...@iam.tj
Dear Maintainer,
* What led up to the situation?
Attempting to reproduce another bug reported on IRC about Ubuntu and
debootstrap
* What exactly did you do (or not do) that was effective (or
ineffective)?
/usr/sbin/debootstrap --verbose --arch=amd64
--extra-suites=focal-updates focal ./focal-chroot
http://archive.ubuntu.com/ubuntu
* What was the outcome of this action?
I: Checking Release signature
I: Valid Release signature (key id
F6ECB3762474EDA9D21B7022871920D1991BC93C)
I: Validating Packages I: Retrieving Packages I: Validating Packages W:
Retrying failed download of
http://archive.ubuntu.com/ubuntu/dists/focal/main/binary-amd64/Packages.xz
I: Retrieving Packages
* What outcome did you expect instead?
File to be fetched correctly
I inserted debug code and used set -x to narrow down the bug and found
that when EXTRA_SUITES is set, in function download_release_indices(),
in the loop "for s in $SUITE $EXTRA_SUITES; do" that the value of 's' is
being changed in the call to validate_suite() where it does "for s in
$SUITE $EXTRA_SUITES; do" and the first test is successful "if [ "$s" =
"$suite" ] || [ "$s" = "$CODENAME" ]; then return 0".
In the example case this resets the suite being processed from
'focal-updates' to 'focal' and so files are downloaded from the focal
suite but the hashes tested against are from the focal-updates
Releases file, causing the validation to fail.
Patch to fix the issue at the end of this email.
-- System Information:
Debian Release: 11.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.13.0-soggy-02736-g7f1d227e86a3 (SMP w/4 CPU threads;
PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debootstrap depends on:
ii wget 1.21-1+b1
Versions of packages debootstrap recommends:
ii arch-test 0.17-1
ii debian-archive-keyring 2021.1.1
ii gnupg 2.2.27-2
Versions of packages debootstrap suggests:
pn squid-deb-proxy-client
pn ubuntu-archive-keyring
-- no debconf information
--
commit 23bb0a9f3c39b1f23f6c27bd7e8e85f43d7a0316 (HEAD -> master)
Author: Tj
Date: Wed Jul 28 21:27:01 2021 +0100
fix: download correct extra-suites Packages files
diff --git a/functions b/functions
index 09d93f4..ec34d84 100644
--- a/functions
+++ b/functions
@@ -551,7 +551,7 @@ extract_release_components () {
CODENAME=""
validate_suite () {
- local reldest suite
+ local reldest suite s
reldest="$1"
CODENAME=$(sed -n "s/^Codename: *//p" "$reldest")
Bug#637076: ProFTPD file uploads and UserOwner
I believe that the scenario described here: http://bugs.proftpd.org/show_bug.cgi?id=4418#c5 might capture/describe this bug, in which case, it would fall under "working as expected". TJ
Bug#965262: rc.local/FAISERVER fails due to changes in FAI installer
Package: fai-doc
Version: 5.8.4
Severity: normal
When using the FAI installer ISO to create the master server (static and
DHCP server) booting the installed instance results in errors from the
/etc/rc.local script. This script appears to be copied from fai-doc
/usr/share/doc/fai-doc/examples/simple/files/etc/rc.local/FAISERVER
The problem is this script assumes network interfaces are only defined
in /etc/network/interfaces but the installer now writes per-interface
definitions to /etc/network/interfaces.d/$IFACE
We've modified it locally and attach the patch here.
--- FAISERVER.5.8.4 2020-07-18 12:25:45.153764908 +0100
+++ FAISERVER.new 2020-07-18 12:17:16.907529874 +0100
@@ -10,15 +10,17 @@
set -o pipefail
# setup network
-nic=$(awk '/iface/ {print $2}' /etc/network/interfaces |egrep -v ^lo)
-ifup $nic
+nic=$(cat /etc/network/interfaces /etc/network/interfaces.d/* 2>/dev/null | awk '$1 == "iface" && $2 != "lo" {print $2; exit}')
+if [ -n "$nic" ]; then
+ifup $nic
+fi
# regenerate ssh_host keys
ls /etc/ssh/ssh_host_* > /dev/null
if [ $? -ne 0 ]; then
Bug#926078: ITP: node-zen-observable -- implementation of observables for javascript
Package: wnpp Severity: wishlist Owner: Amrithaa.T.J X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-zen-observable Version : 0.8.13 Upstream Author : Microsoft corp. * URL : https://github.com/zenparsing/zen-observable * License : Expat Programming Lang: JavaScript Description :Implementation of observables for javascript creates a new observable object The subscriber function is called when subscribe method of the observable object is invoked. This package has dependency in gitlab. Mr.Praveen has agreed to sponsor the project.
Bug#916967: dwardump: passing any options prevents output
Package: dwarfdump Version: 20180809-1 Severity: important Whilst using dwarfdump (amd64 build) on MIPS ELF files I discovered that adding any command-line options (such as '-v' or '-x abi=mips') somehow prevents the program from writing any output. I then tried it on x86_64 ELF files, and on another system, and got someone else to verify it. This affects (at least) the package versions 20180129-1 and 20180809-1. I then fetched and built the upstream source and it exhibits the same problem.
Bug#880993: enable http2 protocol when http2 module is enabled
I second this. I was expecting something of this sort when I ran "a2enmod http2" and was surprised not to find an accompanying .conf.
Bug#891340: pssh: Update upstream to forked maintained repo
Package: pssh Version: 2.3.1-1 Severity: important Tags: upstream Dear Maintainer, * What led up to the situation? Upstream source was originally moved to code.google.com which was discontinued. Original authors seem to have stopped caring around 2013. A forked new upstream is at https://github.com/lilydjwg/pssh and contains many bug fixes and improvements.
Bug#626524: DefaultAddress not obeyed when SocketBindTight is off
I've tried to clarify the behavior; see: http://www.proftpd.org/docs/modules/mod_core.html#SocketBindTight If you are have: SocketBindTight on And proftpd receives a connection for which there is no configured, the client will receive this response 500 Sorry, no server available to handle request on xxx.xxx.xxx.xxx. EXCEPT if your proftpd.conf has "DefaultServer on" somewhere. If DefaultServer IS used, then that (or "server config") section bearing the "DefaultServer on" setting is used to handle that connection -- that's what the DefaultServer directive is for. Thus if your "SocketBindTight on" configuration is not causing clients to receive the "no server available to handle request" when they try to connect to an unconfigured IP address/port, then it says that your proftpd.conf is using DefaultServer somewhere. Cheers, TJ
Bug#336001: proftpd: improving documentation
Done; see: http://www.proftpd.org/docs/modules/mod_core.html#MaxInstances Cheers, TJ
Bug#691617: mod_ban fails to handle unknown ctrl commands correctly (Bug 691617)
This issue with mod_ban was reported separately upstream, and fixed there; see: http://bugs.proftpd.org/show_bug.cgi?id=3866 Cheers, TJ
Bug#794737: Incorrect (ppc64le) binfmt prevents execution of statically linked executables
Package: qemu-user-binfmt
Version: 1:2.1+dfsg-12+deb8u1
This likely affects all releases and other architectures.
I was helping a user on IRC #debian who was having problems completing the
build of a PPC64LE chroot on amd64.
The specific problem was early failure of "/debootstrap/debootstrap
--second-stage" with:
/sbin/ldconfig.real: Syntax error: "(" unexpected
Using strace I eventually noticed that the ELF header of "/sbin/ldconfg.real" did not
match the magic defined in "/usr/share/binfmts/qemu-ppc64le".
The specific issue appears to be that "ldconfig.real" is statically linked and
byte offset 0x07 is 0x03, which doesn't match the binfmt magic.
"debian/binfmt-update-in" currently contains:
ppc64le_magic='\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15\x00'
ppc64le_mask='\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\x00'
but it should have mask byte offset 0x07 = 0xfc:
ppc64le_magic='\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15\x00'
ppc64le_mask='\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\x00'
^^^
A manual workaround:
# copy this to /usr/share/binfmts/qemu-ppc64le
# install it using "sudo update-binfmts --import qemu-ppc64le
package qemu-user-static
interpreter /usr/bin/qemu-ppc64le-static
credentials yes
offset 0
magic \x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x15\x00
mask
\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\x00
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734390: isomaster: El Torito boot image corrupted by truncation
Package: isomaster Version: 1.3.9-1ubuntu1 Severity: important Tags: patch El Torito Boot records are being truncated resulting in un-bootable ISO images. Discovered on Ubuntu where I've linked the bug report to a bzr branch containg the fix: https://bugs.launchpad.net/ubuntu/+bug/1266461i "Fixes failure of bootable images to boot because the El Torito boot catalog has a hard-coded sector count of 4 (2048 bytes) instead of using the actual boot image size." I have also notified the upstream publisher via his web-based contact form. Description: use actual boot image size in El Torito boot catalog Author: TJ Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+bug/1266461 Forwarded: yes Last-Update: 2014-01-06 Index: isomaster/bk/bkWrite.c === --- isomaster.orig/bk/bkWrite.c 2014-01-06 15:17:49.384136000 + +++ isomaster/bk/bkWrite.c 2014-01-06 15:28:47.808981891 + @@ -1174,9 +1174,8 @@ /* load segment leave it at 0 */ /* system type, leave it at 0 */ /* 1 byte unused, leave it at 0 */ -/* sector count. i have yet to see a boot record with a sector count -* that's not 4 */ -write721ToByteArray(&(buffer[38]), 4); +/* sector count */ +write721ToByteArray(&(buffer[38]), volInfo->bootRecordSize / NBYTES_VIRTUAL_SECTOR); /* logical block number of boot record file. this is not known until * after that file is written */ *bootRecordSectorNumberOffset = wcSeekTell(volInfo) + 40; Index: isomaster/bk/bkInternal.h === --- isomaster.orig/bk/bkInternal.h 2014-01-06 16:13:25.003211000 + +++ isomaster/bk/bkInternal.h 2014-01-06 16:24:38.565597428 + @@ -26,6 +26,8 @@ #define NLS_SYSTEM_AREA 16 /* number of bytes in a logical block (in practice always 2048) */ #define NBYTES_LOGICAL_BLOCK 2048 +/* for el torito boot images */ +#define NBYTES_VIRTUAL_SECTOR 512 /*** * Joliet allows max 128 bytes Index: isomaster/bk/bkRead.c === --- isomaster.orig/bk/bkRead.c 2014-01-06 16:37:21.231168000 + +++ isomaster/bk/bkRead.c 2014-01-06 16:37:39.593470342 + @@ -36,9 +36,6 @@ #define VDTYPE_VOLUMEPARTITION 3 #define VDTYPE_TERMINATOR 255 -/* for el torito boot images */ -#define NBYTES_VIRTUAL_SECTOR 512 - /* this function is really just for use in readRockridgeSymlink() * returns number of chars appended * destMaxLen doesn't include '\0'
Bug#716974: Can't locate File/Path.pm in @INC
Package: sysv-rc Version: 2.88dsf-42 Using pbuilder and deboostrap to create a 'sid' pbuilder from Ubuntu 13.04 I hit what looks to be a dependency issue as util-linux is being unpacked. I have a customised ~/.pbuilderrc to allow me to build Debian releases on Ubuntu which is run thus: $ sudo BUILD_TEST=1 BASE=/home/all/pbuilder/base RELEASE=sid ARCH=i386 pbuilder create --debug debootstrap does its work until this: ... Unpacking util-linux (from .../util-linux_2.20.1-5.5_i386.deb) ... Can't locate File/Path.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/sbin/update-rc.d line 8. BEGIN failed--compilation aborted at /usr/sbin/update-rc.d line 8. dpkg: error processing /var/cache/apt/archives/util-linux_2.20.1-5.5_i386.deb (--unpack): subprocess new pre-installation script returned error exit status 2 $ sudo chroot /var/cache/pbuilder/build/8627/ # dpkg --yet-to-unpack util-linux (no description available) the util-linux preinst script makes a call to /usr/sbin/update-rc.d: ... if [ "$1" = install ] || [ "$1" = upgrade ]; then ... update-rc.d hwclockfirst.sh remove >/dev/null fi sysv-rc's /usr/sbin/update-rc.d calls on a file from perl-modules: ... use File::Path qw(make_path); # in core since Perl 5.001 ... but the sysv-rc package has no dependency on perl-modules or perl, and neither package is unpacked/installed by debootstrap at this point (even though they are due to be installed later). $ grep ' perl' /var/cache/pbuilder/build/8627/debootstrap/debootstrap.log Selecting previously unselected package perl-base. Unpacking perl-base (from .../perl-base_5.14.2-21_i386.deb) ... Setting up perl-base (5.14.2-21) ... Preparing to replace perl-base 5.14.2-21 (using .../perl-base_5.14.2-21_i386.deb) ... Unpacking replacement perl-base ... liblocale-gettext-perl pre-depends on perlapi-5.14.2 perl-base provides perlapi-5.14.2 but is unpacked but not configured. Preparing to replace perl-base 5.14.2-21 (using .../perl-base_5.14.2-21_i386.deb) ... Unpacking replacement perl-base ... liblocale-gettext-perl pre-depends on perlapi-5.14.2 perl-base provides perlapi-5.14.2 but is unpacked but not configured. Preparing to replace perl-base 5.14.2-21 (using .../perl-base_5.14.2-21_i386.deb) ... Unpacking replacement perl-base ... liblocale-gettext-perl pre-depends on perlapi-5.14.2 perl-base provides perlapi-5.14.2 but is unpacked but not configured. Preparing to replace perl-base 5.14.2-21 (using .../perl-base_5.14.2-21_i386.deb) ... Unpacking replacement perl-base ... liblocale-gettext-perl pre-depends on perlapi-5.14.2 perl-base provides perlapi-5.14.2 but is unpacked but not configured. Preparing to replace perl-base 5.14.2-21 (using .../perl-base_5.14.2-21_i386.deb) ... Unpacking replacement perl-base ... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573070: ITP: hivex -- Windows Registry "hive" extraction library
* Package name: hivex Version : 1.2.1 Upstream Author : R. Jones * URL : http://git.annexia.org/?p=hivex.git;a=summary http://libguestfs.org/download/ * License : LGPL 2.1 Programming Lang: C Description : Windows Registry "hive" extraction library libhivex is a library for extracting the contents of Windows Registry "hive" files. It is designed to be secure against buggy or malicious registry files. Unlike many other tools in this area, it doesn't use the textual .REG format for output, because parsing that is as much trouble as parsing the original binary format. Instead it makes the file available through a C API, or there is a separate program to export the hive as XML (see hivexml(1)), or to get individual keys (see hivexget(1)). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#541100: Updates to patches
I attached an incorrect set of patches to my earlier email. This is the
correct set for:
debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff
debian/rules
Apply from the source package's base directory.
As before, the changelog entry is:
openjdk-6 (6b14-1.4.1-0ubuntu12~tj~ppa1j) jaunty; urgency=low
* Fix IcedTeaPlugin failure to start with xulrunner 1.9.1 (LP: #359407).
debian/rules: add patch icedtea-plugin-use-runtime-nsIProcess-IID.diff
-- TJ Thu, 17 Sep 2009 18:00:00 +0100
--- openjdk-6-6b14-1.4.1/debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff 1970-01-01 01:00:00.0 +0100
+++ openjdk-6-6b14-1.4.1-0ubuntu12~tj~ppa1j/debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff 2009-09-17 19:05:59.981677497 +0100
@@ -0,0 +1,29 @@
+diff -uN a/IcedTeaPlugin.cc b/IcedTeaPlugin.cc
+--- a/IcedTeaPlugin.cc
b/IcedTeaPlugin.cc
+@@ -3824,6 +3824,8 @@ void IcedTeaPluginFactory::IcedTeaPluginFactory::WriteToJVM(nsCString& message)
+
+ */
+
++#include
++
+ nsresult
+ IcedTeaPluginFactory::StartAppletviewer ()
+ {
+@@ -3845,9 +3847,15 @@ IcedTeaPluginFactory::StartAppletviewer ()
+ result = file->InitWithNativePath (nsCString (appletviewer_executable));
+ PLUGIN_CHECK_RETURN ("init with path", result);
+
++ // run-time query provided through nsIInterfaceInfoManager
++ nsCOMPtr iim(do_GetService(NS_INTERFACEINFOMANAGER_SERVICE_CONTRACTID));
++ // get the run-time IID of nsIProcess (don't rely on a the build-time IID)
++ nsIID *nsIProcessIID;
++ iim->GetIIDForName("nsIProcess", &nsIProcessIID);
++
+ result = manager->CreateInstanceByContractID (NS_PROCESS_CONTRACTID,
+ nsnull,
+-NS_GET_IID (nsIProcess),
++*nsIProcessIID,
+ getter_AddRefs (applet_viewer_process));
+ PLUGIN_CHECK_RETURN ("create process", result);
+
--- openjdk-6-6b14-1.4.1/debian/rules 2009-09-17 21:18:24.0 +0100
+++ openjdk-6-6b14-1.4.1-0ubuntu12~tj~ppa1j/debian/rules 2009-09-17 19:15:24.273667874 +0100
@@ -663,6 +663,9 @@
test -x /usr/bin/linux32 &&linux32 /bin/uname -a || true
patch --verbose -p0 < debian/patches/zero-port-opt.diff
+ patch --verbose -p1 < debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff
+ # keep a marker to indicate patch is applied
+ touch debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff.stamp
mkdir -p stamps
mkdir -p build
@@ -1027,6 +1030,10 @@
patch --verbose -p0 -R < debian/patches/zero-port-opt.diff; \
rm -f ports/hotspot/src/cpu/zero/vm/bytecodeInterpreter_arm.S; \
fi
+ if [ -f debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff.stamp ]; then \
+ patch --verbose -p1 -R < debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff; \
+ rm -f debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff.stamp; \
+ fi
ifeq (0,1)
for i in $$(find test/jtreg -name '*.gif') overlays/openjdk/jdk/test/com/sun/media/sound/SoftSynthesizer/expresso.mid overlays/openjdk/jdk/test/com/sun/media/sound/SoftSynthesizer/ding.sf2; do \
Bug#541100: Cause found, working patch created.
This bug is marked as upstream from the Ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/359407
so I am reporting the solution.
I've discovered the cause and created a small patch to fix the issue
which is currently attached to the Ubuntu bug. I'm attaching the same
patch to this report.
The patch needs adding to debian/rules but as the Debian and Ubuntu
packages diverge slightly due to security CVE patches I won't attach a
debdiff; instead I've attached a second patch.
The Ubuntu changelog entry reads:
openjdk-6 (6b14-1.4.1-0ubuntu12~tj~ppa1j) jaunty; urgency=low
* Fix IcedTeaPlugin failure to start with xulrunner 1.9.1 (LP: #359407).
debian/rules: add patch icedtea-plugin-use-runtime-nsIProcess-IID.diff
-- TJ Thu, 17 Sep 2009 18:00:00 +0100
--- IcedTeaPlugin.cc
+++ IcedTeaPlugin.cc
@@ -3824,6 +3824,8 @@ void IcedTeaPluginFactory::IcedTeaPluginFactory::WriteToJVM(nsCString& message)
*/
+#include
+
nsresult
IcedTeaPluginFactory::StartAppletviewer ()
{
@@ -3845,9 +3847,15 @@ IcedTeaPluginFactory::StartAppletviewer ()
result = file->InitWithNativePath (nsCString (appletviewer_executable));
PLUGIN_CHECK_RETURN ("init with path", result);
+ // run-time query provided through nsIInterfaceInfoManager
+ nsCOMPtr iim(do_GetService(NS_INTERFACEINFOMANAGER_SERVICE_CONTRACTID));
+ // get the run-time IID of nsIProcess (don't rely on a the build-time IID)
+ nsIID *nsIProcessIID;
+ iim->GetIIDForName("nsIProcess", &nsIProcessIID);
+
result = manager->CreateInstanceByContractID (NS_PROCESS_CONTRACTID,
nsnull,
-NS_GET_IID (nsIProcess),
+*nsIProcessIID,
getter_AddRefs (applet_viewer_process));
PLUGIN_CHECK_RETURN ("create process", result);
--- debian/rules.1 2009-09-17 18:20:21.465667839 +0100
+++ debian/rules 2009-09-17 18:02:43.725667711 +0100
@@ -191,6 +191,7 @@
debian/patches/6804996.patch \
debian/patches/6804997.patch \
debian/patches/6804998.patch \
+debian/patches/icedtea-plugin-use-runtime-nsIProcess-IID.diff \
debian/patches/securitypatches-2009-08.diff
# debian/patches/gcc-mtune-generic.diff \
Bug#525969: udev reports the usage of an invalid parameter '-s'
Package: udev Version: 0.141-1 Severity: critical Justification: breaks the whole system udev reports an invalid parameter '-s'. this doesn't happen with version 0.125-6 of udev. on the log i seen multipathd reporting error when calling scsi_id, for example: "Apr 28 09:27:25 info multipathd: error calling out /lib/udev/scsi_id -g -u -s /block/sda" -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 36 -rw-r--r-- 1 root root 3586 2008-08-28 02:39 50-udev.rules -rw-r--r-- 1 root root 1543 2008-08-28 02:39 60-persistent-input.rules -rw-r--r-- 1 root root 4554 2008-08-28 02:39 60-persistent-storage.rules -rw-r--r-- 1 root root 1582 2008-08-28 02:39 60-persistent-storage-tape.rules -rw-r--r-- 1 root root 523 2008-08-28 02:39 60-persistent-v4l.rules -rw-r--r-- 1 root root 1137 2008-10-01 18:05 65_dmsetup.rules -rw-r--r-- 1 root root 374 2006-10-17 10:47 70-persistent-cd.rules -rw-r--r-- 1 root root 442 2009-04-27 12:05 70-persistent-net.rules -rw-r--r-- 1 root root 452 2008-08-28 02:39 75-cd-aliases-generator.rules -rw-r--r-- 1 root root 3081 2008-08-28 02:39 75-persistent-net-generator.rules -rw-r--r-- 1 root root 2282 2008-08-28 02:39 80-drivers.rules -rw-r--r-- 1 root root 4247 2008-08-28 02:39 91-permissions.rules -rw-r--r-- 1 root root 593 2008-08-28 02:39 95-late.rules lrwxrwxrwx 1 root root 15 2007-05-28 16:59 z60_hdparm.rules -> ../hdparm.rules -rw-r--r-- 1 root root 1240 2008-08-21 10:09 z60_kpartx.rules -rw-r--r-- 1 root root 183 2008-07-02 17:23 z60_mt-st.rules -rw-r--r-- 1 root root 325 2008-07-31 08:39 z60_multipath.rules lrwxrwxrwx 1 root root 20 2009-02-13 15:05 z60_xen-backend.rules -> ../xen-backend.rules -- /sys/: /sys/block/cciss!c0d0/cciss!c0d0p1/dev /sys/block/cciss!c0d0/cciss!c0d0p2/dev /sys/block/cciss!c0d0/cciss!c0d0p3/dev /sys/block/cciss!c0d0/cciss!c0d0p4/dev /sys/block/cciss!c0d0/cciss!c0d0p5/dev /sys/block/cciss!c0d0/cciss!c0d0p6/dev /sys/block/cciss!c0d0/cciss!c0d0p7/dev /sys/block/cciss!c0d0/cciss!c0d0p8/dev /sys/block/cciss!c0d0/dev /sys/block/cciss!c0d1/cciss!c0d1p1/dev /sys/block/cciss!c0d1/dev /sys/block/dm-0/dev /sys/block/dm-10/dev /sys/block/dm-1/dev /sys/block/dm-2/dev /sys/block/dm-3/dev /sys/block/dm-4/dev /sys/block/dm-5/dev /sys/block/dm-6/dev /sys/block/dm-7/dev /sys/block/dm-8/dev /sys/block/dm-9/dev /sys/block/fd0/dev /sys/block/hda/dev /sys/block/ram0/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram1/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/block/sda/dev /sys/block/sda/sda1/dev /sys/block/sdb/dev /sys/block/sdb/sdb1/dev /sys/block/sdc/dev /sys/block/sdc/sdc1/dev /sys/block/sdd/dev /sys/block/sdd/sdd1/dev /sys/block/sdd/sdd2/dev /sys/block/sdd/sdd3/dev /sys/block/sdd/sdd4/dev /sys/block/sde/dev /sys/block/sde/sde1/dev /sys/block/sdf/dev /sys/block/sdf/sdf1/dev /sys/block/sdg/dev /sys/block/sdg/sdg1/dev /sys/block/sdh/dev /sys/block/sdh/sdh1/dev /sys/block/sdh/sdh2/dev /sys/block/sdh/sdh3/dev /sys/block/sdh/sdh4/dev /sys/class/bsg/0:0:0:0/dev /sys/class/bsg/0:0:0:1/dev /sys/class/bsg/0:0:0:2/dev /sys/class/bsg/0:0:0:3/dev /sys/class/bsg/0:0:0:4/dev /sys/class/bsg/0:0:1:0/dev /sys/class/bsg/0:0:1:1/dev /sys/class/bsg/0:0:1:2/dev /sys/class/bsg/0:0:1:3/dev /sys/class/bsg/0:0:1:4/dev /sys/class/bsg/0:0:2:0/dev /sys/class/bsg/0:0:2:1/dev /sys/class/iLO/hpilo!d0ccb0/dev /sys/class/iLO/hpilo!d0ccb1/dev /sys/class/iLO/hpilo!d0ccb2/dev /sys/class/iLO/hpilo!d0ccb3/dev /sys/class/iLO/hpilo!d0ccb4/dev /sys/class/iLO/hpilo!d0ccb5/dev /sys/class/iLO/hpilo!d0ccb6/dev /sys/class/iLO/hpilo!d0ccb7/dev /sys/class/input/input0/event0/dev /sys/class/input/input1/event1/dev /sys/class/input/input2/event2/dev /sys/class/input/input3/event3/dev /sys/class/input/input3/mouse0/dev /sys/class/input/mice/dev /sys/class/misc/cpu_dma_latency/dev /sys/class/misc/device-mapper/dev /sys/class/misc/evtchn/dev /sys/class/misc/hw_random/dev /sys/class/misc/network_latency/dev /sys/class/misc/network_throughput/dev /sys/class/misc/psaux/dev /sys/class/misc/tgt/dev /sys/class/rtc/rtc0/dev /sys/class/scsi_changer/sch0/dev /sys/class/scsi_generic/sg0/dev /sys/class/scsi_generic/sg10/dev /sys/class/scsi_generic/sg11/dev /sys/class/scsi_generic/sg1/dev /sys/class/scsi_generic/sg2/dev /sys/class/scsi_generic/sg3/dev /sys/class/scsi_generic/sg4/dev /sys/class/scsi_generic/sg5/dev /sys/class/scsi_generic/sg6/dev /sys/class/scsi_generic/sg7/dev /sys/class/scsi_generic/sg8/dev /sys/class/scsi_generic/sg9/dev /sys/class/scsi_tape/nst0a/dev /sys/class/scsi_tape/nst0/dev /sys/class/scsi_tape/nst0l/dev /sys/class/scsi_tape/nst0m/dev /sys/class/scsi_tape/st0a/dev /sys/class/scsi_tape/st0/dev /sys/class/scsi_tape/st0l/dev /sys/class/scsi_tape/st0m/dev /sys/class/usb_device/usbdev1.1/dev /sys/class/usb_device/usbdev2.1/dev /sys/class/usb_endpoint/usbdev1.1_ep0
Bug#514358: pdebuild host --debbuildopts inherited by target pbuild
On Mon, 2009-02-09 at 00:02 +0900, Junichi Uekawa wrote: > Hmm > > IMO, That's a feature, not a bug. If this is really biting people, I > might consider adding that... A feature to break the expected functionality? I would agree with you *if* dpkg-source hadn't changed the semantics of -I in versions >= v1.14.7. But, the differences are there and using the parameter format for -I that is acceptable on the host will cause pre v1.14.7 to break the build. The alternative would be to ignore the default -I behaviour in >= v1.14.7 and always pass a file with the exclusion list regardless of version. That requires the file be added to the package though (so it can be picked up inside the pbuild). The other alternative of removing all VCS files and folders from the host source directory before a pdebuild so the -I option can be dropped (and therefore the build succeed) isn't viable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514358: pdebuild host --debbuildopts inherited by target pbuild
Package: pbuilder
Version: 0.183ubuntu1
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
(originally reported as
https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/326216)
This is a latent bug, exposed when building for target releases that
have dpkg-source < v1.14.7.
The problem is that when using pdebuilder and passing --debbuildopts to
both 'sides' (host and target), the target pbuilder dpkg-source
incorrectly inherits the host --debbuildopts.
For example:
HOST_DEB_OPTIONS="--debbuildopts -i -I"
PBUILDER_DEB_OPTIONS="--debbuildopts -Idebian/dpkg-source.excludes"
pdebuild --logfile $LOGNAME ${HOST_DEB_OPTIONS} -- ${PBUILDER_DEB_OPTIONS}
results in the inner dpkg-source seeing:
dpkg-source -i -I -Idebian/dpkg-source.excludes -b kvm-83+dfsg
Which in Hardy and later isn't a problem (since -I is acceptable to
dpkg-source >= v1.14.7). However, if working on back-porting a package
to Gutsy or Feisty or Edgy the versions of dpkg-source in those releases
do not understand the -I option without a file specification
(-I).
This will cause the target pbuild to fail since the source can't be
extracted.
This wouldn't have come to light if it wasn't for my desire to back-port
some packages for use on long-lived servers that are running stable
older releases. In these cases my build_test script generates two
different sets of --debbuildopts for the host (more recent) and target
(older) dpkg-source.
The builds were failing and as can be seen in the example above it is
because the host's --debbuildopts are passing to the target.
--- System information. ---
Architecture: amd64
Kernel: Linux 2.6.24-21-generic
Debian Release: lenny/sid
500 hardy-updates gb.archive.ubuntu.com
500 hardy-security security.ubuntu.com
500 hardy-backports gb.archive.ubuntu.com
500 hardy wine.budgetdedicated.com
500 hardy gb.archive.ubuntu.com
500 hardy archive.canonical.com
--- Package information. ---
Depends (Version) | Installed
=-+-=
coreutils(>= 4.5.8-1) | 6.10-3ubuntu2
debianutils (>= 1.13.1) | 2.28.2-0ubuntu1
debootstrap | 1.0.9~hardy1
OR cdebootstrap |
gcc | 4:4.2.3-1ubuntu6
wget | 1.10.2-3ubuntu1
--- debdiff (Ubuntu-specific changelog entry) ---
diff -Nru pbuilder-0.183ubuntu1/debian/changelog
pbuilder-0.183ubuntu2/debian/changelog
--- pbuilder-0.183ubuntu1/debian/changelog 2008-11-05 15:07:42.0
+
+++ pbuilder-0.183ubuntu2/debian/changelog 2009-02-06 16:20:57.0
+
@@ -1,3 +1,9 @@
+pbuilder (0.183ubuntu2) jaunty; urgency=low
+
+ * Don't pass host --debbuildopts to target (LP: #326216)
+
+ -- TJ Fri, 06 Feb 2009 16:30:00 +
+
pbuilder (0.183ubuntu1) jaunty; urgency=low
* Merge with Debian unstable. Remaining Ubuntu changes:
diff -Nru pbuilder-0.183ubuntu1/pdebuild pbuilder-0.183ubuntu2/pdebuild
--- pbuilder-0.183ubuntu1/pdebuild 2008-11-05 12:19:53.0 +
+++ pbuilder-0.183ubuntu2/pdebuild 2009-02-06 16:19:23.0 +
@@ -60,7 +60,7 @@
echo "W: Unmet build-dependency in source" >&2
fi
echo "dpkg-buildpackage -S -us -uc -r${BUILDSOURCEROOTCMD} $DEBBUILDOPTS"
| perl -pe 's/(^|\s)-[bB](\s|$)/$1$2/g' | /bin/bash
-${PBUILDERROOTCMD} ${PDEBUILD_PBUILDER} --build
${extra_configfi...@]/#/--configfile } --buildresult "${BUILDRESULT}"
--debbuildopts "${DEBBUILDOPTS}" "$@" ../"${PKG_SOURCENAME}_${PKG_VERSION}".dsc
+${PBUILDERROOTCMD} ${PDEBUILD_PBUILDER} --build
${extra_configfi...@]/#/--configfile } --buildresult "${BUILDRESULT}" "$@"
../"${PKG_SOURCENAME}_${PKG_VERSION}".dsc
fi
# do signing with optional key specifier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#501536: open-vm-toolbox: vmware-user does not work correctly, mouse trapped in vmware window
Hi, I spent time looking at this some more. It seems that X was not configured correctly. You can not rely on auto detection, you must add an explicit section for the vmware mouse, which means having sections for everything else. Below is an example minimal config. With vmmouse loaded (although vmmouse claims it needs no option, it does in fact need the minimal options of 'mouse', ie Option "device" "") then the mouse is free to leave the vmware window. With 'mouse', which is what X would auto load, the mouse is stuck. However once I got vmmouse running it seems I fell over another bug. The pointer on screen and where X thinks the pointer is do not line up. Some searching and this seems to be a problem other distributions have seen with the current: xserver-xorg-input-vmmouse There is a work around mentioned here http://communities.vmware.com/docs/DOC-7870, however it does not work for me. So my choice seems to be either use 'mouse' and have a trapped mouse (very annoying), or use 'vmmouse' and only be able to click on things in the bottom right corner of the guest desktop. I would suggest you provide helpers for configuring X, other then that you should probably close this bug report, or assign it to xserver-xorg-input-vmmouse Regards Thorben Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" .. EndSection Section "InputDevice" Identifier "VMware Mouse" Driver "vmmouse" Option "Device""/dev/input/mice" EndSection Section "Device" Identifier "VMware Video Device" Driver "vmware" EndSection Section "Monitor" Identifier "VMware Monitor" VendorName "VMware, inc" HorizSync 1-1 VertRefresh 1-1 EndSection Section "Screen" Identifier "Default Screen" Device "VMware Video Device" Monitor "VMware Monitor" DefaultDepth24 #Modes only needed for login screen, ie before vmware-user is running SubSection "Display" Depth 4 ViewPort0 0 Modes "1280x800" "1024x640" "800x500" EndSubSection SubSection "Display" Depth 8 ViewPort0 0 Modes "1280x800" "1024x640" "800x500" EndSubSection SubSection "Display" Depth 15 ViewPort0 0 Modes "1280x800" "1024x640" "800x500" EndSubSection SubSection "Display" Depth 16 ViewPort0 0 Modes "1280x800" "1024x640" "800x500" EndSubSection SubSection "Display" Depth 24 ViewPort0 0 Modes "1280x800" "1024x640" "800x500" EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "Generic Keyboard" "CoreKeyboard" InputDevice "VMware Mouse" "CorePointer" EndSection 2008/10/8 TJ <[EMAIL PROTECTED]>: > Hi, > > Thank you for looking at this and replying. > > That maintainer looks dead (metaphorically) to me. What it take to > have someone else make a new package, especially since the package > diff still applies cleanly. (somethings in debian/ still need > updating/fixing though) > > While the lack of liburiparser 0.7.0 explains why unity mode is > missing, it does not explain the original mouse issue, which I know > should work without unity mode support. It is only recently that I > packaged and installed the new liburiparser, however before that I > just had unity mode disabled at build time, this did not break > vmware-user's ability to have your mouse move freely in and out of the > vmware window/desktop. > > Maybe it was miss leading for me to mention unity, but I thought it > better to try and be as complete as possible. Please don't postpone > looking into this until after you fix unity mode. (although unity mode > negate the need for an untrapped mouse) > > I will try to see if the mouse being trapped is an upstream issue if I > have the chance. I note that X is unloading vmmouse and faili
Bug#501536: open-vm-toolbox: vmware-user does not work correctly, mouse trapped in vmware window
Hi, Thank you for looking at this and replying. That maintainer looks dead (metaphorically) to me. What it take to have someone else make a new package, especially since the package diff still applies cleanly. (somethings in debian/ still need updating/fixing though) While the lack of liburiparser 0.7.0 explains why unity mode is missing, it does not explain the original mouse issue, which I know should work without unity mode support. It is only recently that I packaged and installed the new liburiparser, however before that I just had unity mode disabled at build time, this did not break vmware-user's ability to have your mouse move freely in and out of the vmware window/desktop. Maybe it was miss leading for me to mention unity, but I thought it better to try and be as complete as possible. Please don't postpone looking into this until after you fix unity mode. (although unity mode negate the need for an untrapped mouse) I will try to see if the mouse being trapped is an upstream issue if I have the chance. I note that X is unloading vmmouse and failing back to mouse at startup. I don't know if this affects vmware-user's ability to sync the mouse without trapping it. Regards Thorben 2008/10/8 Daniel Baumann <[EMAIL PROTECTED]>: > severity 501536 normal > thanks > > Thorben Jändling wrote: >> Also unity mode is not always available, and when it is, it does not >> function correctly. Guest windows receive keyboard events but not any mouse >> input. They can't even be dragged/moved/resized. > > blocked by #493073 and #494680. > > -- > Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist > Email: [EMAIL PROTECTED] > Internet: http://people.panthera-systems.net/~daniel-baumann/ >
Bug#501390: Does not accept multiple --debbuildopts options
Package: pbuilder
Version: 0.176ubuntu2
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
(originally reported as
https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/278213)
pbuilder and pdebuild do not accept or cope with multiple
--debbuildopts. For example (slightly nonsensical example):
HOST_DEB_OPTIONS="--debbuildopts -i -I"
PBUILDER_DEB_OPTIONS="--debbuildopts -i -I"
pdebuild --logfile $LOGNAME ${HOST_DEB_OPTIONS} -- ${PBUILDER_DEB_OPTIONS}
Command line parameter [-I] is not a valid .dsc file name
Impact: Passing multiple debbuildopts through pbuilder/pdebuild results
in the dpkg-source and other devscripts either failing or not using the
specified options (especially problematic when wanting to prevent VCS
files being included (-i -I).
Testcase: Using a source package that has VCS directories
(i.e. ./.git/ ) and "pbuilder ... --debbuildopts -i -I" or "pbuilder ...
--debbootopts -i --debbuildopts -I" results in an error in the first
case, or dpkg-buildpackage reporting a problem for every VCS file in the
latter (since -i was replaced by -I).
The cause is the three helper shell function libraries:
/usr/lib/pbuilderpbuilder-checkparams
/usr/lib/pbuilder/pdebuild-checkparams
/usr/lib/pbuilder/pdebuild-uml-checkparams
because they are coded to only accept one option, and to over-write any
previous option:
--debbuildopts)
DEBBUILDOPTS="$2";
shift; shift;
;;
The solution is to use:
DEBBUILDOPTS="$DEBBUILDOPTS $2";
As a by-product, this change allows the script to accept and use any
options exported to the environment before the tool starts.
--- System information. ---
Architecture: amd64
Kernel: Linux 2.6.24-21-generic
Debian Release: lenny/sid
500 hardy-updates gb.archive.ubuntu.com
500 hardy-security security.ubuntu.com
500 hardy-backports gb.archive.ubuntu.com
500 hardy wine.budgetdedicated.com
500 hardy gb.archive.ubuntu.com
500 hardy archive.canonical.com
--- Package information. ---
Depends (Version) | Installed
=-+-=
coreutils(>= 4.5.8-1) | 6.10-3ubuntu2
debianutils (>= 1.13.1) | 2.28.2-0ubuntu1
debootstrap | 1.0.9~hardy1
OR cdebootstrap |
gcc | 4:4.2.3-1ubuntu6
wget | 1.10.2-3ubuntu1
--- debdiff (Ubuntu-specific changelog entry) ---
diff -Nru pbuilder-0.181ubuntu5/debian/changelog
pbuilder-0.181ubuntu6/debian/changelog
--- pbuilder-0.181ubuntu5/debian/changelog 2008-08-21 11:30:35.0
+0100
+++ pbuilder-0.181ubuntu6/debian/changelog 2008-10-04 18:46:47.0
+0100
@@ -1,3 +1,9 @@
+pbuilder (0.181ubuntu6) intrepid; urgency=low
+
+ * Fix: correctly handle multiple --debbuildopts (LP: #278213).
+
+ -- TJ <[EMAIL PROTECTED]> Sat, 4 Oct 2008 18:30:00 +0200
+
pbuilder (0.181ubuntu5) intrepid; urgency=low
* Fix condition that makes build twice in a row the default behavior.
diff -Nru pbuilder-0.181ubuntu5/pbuilder-checkparams
pbuilder-0.181ubuntu6/pbuilder-checkparams
--- pbuilder-0.181ubuntu5/pbuilder-checkparams 2008-08-04 10:34:27.0
+0100
+++ pbuilder-0.181ubuntu6/pbuilder-checkparams 2008-10-04 18:45:22.0
+0100
@@ -137,7 +137,7 @@
shift; shift;
;;
--debbuildopts)
- DEBBUILDOPTS="$2";
+ DEBBUILDOPTS="$DEBBUILDOPTS $2";
shift; shift;
;;
--logfile)
diff -Nru pbuilder-0.181ubuntu5/pdebuild-checkparams
pbuilder-0.181ubuntu6/pdebuild-checkparams
--- pbuilder-0.181ubuntu5/pdebuild-checkparams 2008-05-24 23:54:05.0
+0100
+++ pbuilder-0.181ubuntu6/pdebuild-checkparams 2008-10-04 18:45:42.0
+0100
@@ -42,7 +42,7 @@
shift; shift;
;;
--debbuildopts)
- DEBBUILDOPTS="$2";
+ DEBBUILDOPTS="$DEBBUILDOPTS $2";
shift; shift;
;;
--configfile)
diff -Nru pbuilder-0.181ubuntu5/pdebuild-uml-checkparams
pbuilder-0.181ubuntu6/pdebuild-uml-checkparams
--- pbuilder-0.181ubuntu5/pdebuild-uml-checkparams 2008-05-24
23:54:05.0 +0100
+++ pbuilder-0.181ubuntu6/pdebuild-uml-checkparams 2008-10-04
18:46:00.0 +0100
@@ -66,7 +66,7 @@
shift;
;;
--debbuildopts)
- DEBBUILDOPTS="$2";
+ DEBBUILDOPTS="$DEBBUILDOPTS $2";
shift; shift;
;;
--buildresult)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
