CC @lvivier
I just added the S-o-b. I can look into adding fstatat64 later. Let me know what you prefer!
John Paul Adrian Glaubitz (11721a53) at 09 Feb 09:54
seccomp: Don't allow newfstatat syscall on sparc64
The newfstatat syscall is not available on sparc64.
John Paul Adrian Glaubitz (2ea33b80) at 08 Feb 20:04
seccomp: Don't allow newfstatat syscall on sparc64
I think you should still be able to verify the fix on QEMU, no?
It was a kernel bug, not a QEMU bug. Please try the latest image which has been verified to work: https://cdimage.debian.org/cdimage/ports/snapshots/2025-11-11/debian-13.0.0-sparc64-NETINST-1.iso
Can you try this ISO image? https://cdimage.debian.org/cdimage/ports/snapshots/2025-11-11/debian-13.0.0-sparc64-NETINST-1.iso
I built this image today and it works fine for me with QEMU. It uses kernel 6.17.7 which has the necessary fixes for UltraSPARC I/II/III/IV (and also various Niagara and M7 CPUs).
This is most likely not a QEMU bug but a problem with a kernel bug that was recently discovered and is currently being fixed:
https://lore.kernel.org/all/[email protected]/
The reason that the kernel may work on real hardware but not in QEMU is because the emulated CPU is an UltraSPARC II while your hardware is a SPARC T1 which uses different code paths in arch/sparc/lib in the Linux kernel where the patches above fixed issues.
To verify this, please install either of these test kernels (UMP and SMP):
https://people.debian.org/~glaubitz/sparc64/
If you can, please also verify this kernel on your T1000 and report back. We're still missing testing for the patches on Niagara 1 (SPARC T1).
There is a version of Oracle Solaris available these days that is free to use for non-commercial purposes such as the development of open source projects.
It's called Oracle Solaris CBE and can be downloaded here: https://www.oracle.com/solaris/solaris11/downloads/solaris-downloads.html
I would suggest testing with that version of Solaris as it's guaranteed to work on real machines.
Keep in mind though that it requires the OSA2011 instruction set. If OSA2011, Solaris 11.3 would be required which can be found on the Internet Archive.
It still crashes. However, the issue can be fixed by building firebird3.0 with 4 bytes alignment (-malign-int) which is something that I am working for Debian anyways. The problem also doesn't occur with qemu-system, it's an issue with qemu-user only.
Thus, whether to keep this issue or not depends on whether QEMU wants to keep supporting the weird 2 bytes alignment on m68k instead of just switching to 4 bytes alignment.
Here the crash output:
echo create database \'security.tmp\'\; | /build/reproducible-path/firebird3.0-3.0.12.ds7/gen/Release/firebird/bin/isql
/build/reproducible-path/firebird3.0-3.0.12.ds7/gen/Release/firebird/bin/gpre_current -m -z -n /build/reproducible-path/firebird3.0-3.0.12.ds7/src/gpre/std/gpre_meta.epp /build/reproducible-path/firebird3.0-3.0.12.ds7/temp/Release/gpre/std/gpre_meta.cpp
can't format message 17:3 -- message file /usr/lib/m68k-linux-gnu/firebird/3.0/firebird.msg not found
gpre version LI-V3.0.12.33787 Firebird 3.0
g++ -I/build/reproducible-path/firebird3.0-3.0.12.ds7/src/include/gen -I/build/reproducible-path/firebird3.0-3.0.12.ds7/src/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -ggdb -O3 -DLINUX -pipe -MMD -fPIC -DFB_SEND_FLAGS=MSG_NOSIGNAL -fno-delete-null-pointer-checks -fno-rtti -DU_SHOW_CPLUSPLUS_API=0 -DU_SHOW_CPLUSPLUS_HEADER_API=0 -g -ffile-prefix-map=/build/reproducible-path/firebird3.0-3.0.12.ds7=. -fstack-protector-strong -Wformat -Werror=format-security -DUCHAR_TYPE=uint16_t -fno-lifetime-dse -fno-strict-aliasing -O3 -std=gnu++03 -std=gnu++03 -std=gnu++03 -c /build/reproducible-path/firebird3.0-3.0.12.ds7/temp/Release/gpre/std/gpre_meta.cpp -o /build/reproducible-path/firebird3.0-3.0.12.ds7/temp/Release/gpre/std/gpre_meta.o
/build/reproducible-path/firebird3.0-3.0.12.ds7/gen/Release/firebird/bin/gfix -write async msg.fdb
/build/reproducible-path/firebird3.0-3.0.12.ds7/gen/Release/firebird/bin/gfix -write async security.tmp
The futex facility returned an unexpected error code.
qemu: uncaught target signal 6 (Aborted) - core dumped
make[5]: *** [Makefile:379: msg.timestamp] Aborted
make[5]: *** Waiting for unfinished jobs....
The futex facility returned an unexpected error code.
qemu: uncaught target signal 6 (Aborted) - core dumped
make[5]: *** [Makefile:370: security.fdb] Aborted
/build/reproducible-path/firebird3.0-3.0.12.ds7/gen/Release/firebird/bin/gfix -mode read_only metadata.fdb
The futex facility returned an unexpected error code.
qemu: uncaught target signal 6 (Aborted) - core dumped
make[5]: *** [Makefile:359: metadata.fdb] Aborted
make[5]: *** Deleting file 'metadata.fdb'
make[5]: Leaving directory '/build/reproducible-path/firebird3.0-3.0.12.ds7/gen'
make[4]: *** [Makefile:198: master_process] Error 2
make[4]: Leaving directory '/build/reproducible-path/firebird3.0-3.0.12.ds7/gen'
make[3]: *** [Makefile:66: firebird] Error 2
make[3]: Leaving directory '/build/reproducible-path/firebird3.0-3.0.12.ds7/gen'
make[2]: *** [Makefile:6: firebird] Error 2
make[2]: Leaving directory '/build/reproducible-path/firebird3.0-3.0.12.ds7'
dh_auto_build: error: make -j64 QUIET=1 returned exit code 2
make[1]: *** [debian/rules:136: override_dh_auto_build] Error 25
make[1]: Leaving directory '/build/reproducible-path/firebird3.0-3.0.12.ds7'
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2@thuth Let me retest.
Here is the output on my SH-7785LCR evaluation board for reference:
glaubitz@tirpitz:~$ gcc -o math-test math-test.c
glaubitz@tirpitz:~$ ./math-test
Values: a=0x80000000 b=0x1 c=0x1
glaubitz@tirpitz:~$Debian actually just started transitioning to using 64-bit time_t on 32-bit architectures.
So, if the statement by Michael is correct and the most common problem is the assumption that time_t needs to be 64 bits, the issue should mostly fix itself.
The syscall newfsstat is available on 64-bit targets only, so it needs to be replaced with fsstat.
mmap is not available on 32-bit ARM, but it on all the other 32-bit targets.
For a list of currently supported syscalls per architecture, see:
https://marcin.juszkiewicz.com.pl/download/tables/syscalls.html
Many of these issues should be easy to fix.
For example, the libc crate defines time_t for every architecture, so it should simply be used instead of u64. Using u64 is even wrong on 64-bit architectures since it's a signed number on some targets such as FreeBSD/AArch64.
As for the system calls, these are all defined in the libc create, too. So, if they're missing there, we can easily add them and I am happy to do that.
After fixing these two issues, we can tackle the issue with AtomicU64.
I can confirm that procps 4.0.3 with the single patch applied from 133a8339 works properly again:
root@tirpitz:~> ps aux|grep buildd |head -n10
buildd 1169 0.0 0.1 13600 756 ? SNs Mar01 0:45 gpg-agent --homedir /home/buildd/.gnupg --use-standard-socket --daemon
buildd 2584 0.0 0.5 19984 2588 ? Ss Feb28 0:06 /usr/bin/perl /usr/bin/buildd
buildd 2585 0.0 0.4 10096 2196 ? S Feb28 0:01 ssh -l wb-buildd -S buildd.debian.org.ssh -o BatchMode=yes buildd.debian.org -MN
root 2718 0.0 0.3 15892 1736 ? SNs 01:42 0:01 schroot -d /build/kwave-b8MUSo/kwave-22.12.3 -c sid-sh4-sbuild-90f210d8-c314-4553-9a3a-1dcb0dec02bd --run-session -q -u buildd -p -- dpkg-buildpackage --sanitize-env -us -uc -msh4 Build Daemon (tirpitz) <[email protected]> -B -rfakeroot
buildd 2719 0.0 0.0 14200 228 ? SN 01:42 0:07 /usr/bin/perl /usr/bin/dpkg-buildpackage --sanitize-env -us -uc -msh4 Build Daemon (tirpitz) <[email protected]> -B -rfakeroot
buildd 2739 0.0 0.0 2756 228 ? SN 01:43 0:00 /usr/bin/make -f debian/rules binary-arch
buildd 2740 0.0 0.0 11556 228 ? SN 01:43 0:06 /usr/bin/perl /usr/bin/dh binary-arch --with kf5
buildd 3605 0.0 0.0 10364 228 ? SN 01:52 0:04 /usr/bin/perl /usr/bin/dh_auto_build --buildsystem=kf5 -a
buildd 3606 0.0 0.0 2888 228 ? SN 01:52 0:00 make -j1 INSTALL=install --strip-program=true VERBOSE=1
buildd 3609 0.0 0.0 3148 476 ? SN 01:52 0:00 make -f CMakeFiles/Makefile2 all
root@tirpitz:~>Thanks a lot!
I will give it a try later today and report back. Thanks for the quick fix!