Solved SIGSYS when launching ported software on a fresh install

J

jbo@

Developer
Scenario: Freshly installed stable/13 (2022-01-03 state) on a Lenovo ThinkPad. Ports compiled on a different host (also running stable/13 but a different commit) using ports-mgmt/poudriere.

The systems itself seems to be running. But launching software from ports tends to throw SIGSYS.

x11/alacritty:
Code: 
'alacritty' terminated by signal SIGSYS (Bad system call)

www/firefox:
Code: 
'firefox' terminated by signal SIGSYS (Bad system call)

What's going on here? Could this be caused by the stable/13 running on the poudriere host being a couple of weeks older? If so, how would one manage a stable/13 poudriere server to ensure that stable/13 clients (i.e. the consumers of the pkg repo) stay "in sync"?

The poudriere host runs the GENERIC kernel config.
The kernel config on the ThinkPad showing the SIGSYSs:
Code: 
include GENERIC
ident CARBON_X1G9

# Compatibility
nooptions COMPAT_FREEBSD4
nooptions COMPAT_FREEBSD5
nooptions COMPAT_FREEBSD6
nooptions COMPAT_FREEBSD7
nooptions COMPAT_FREEBSD8
nooptions COMPAT_FREEBSD9
nooptions COMPAT_FREEBSD10
nooptions COMPAT_FREEBSD11

# Floppy drives
nodevice fdc

# RAID controllers (SCSI)
nodevice amr
nodevice arcmsr
nodevice ciss
nodevice iir
nodevice ips
nodevice mly
nodevice twa
nodevice smartqpi
nodevice tws

# RAID controllers
nodevice aac
nodevice aacp
nodevice aacraid
nodevice ida
nodevice mfi
nodevice mlx
nodevice mrsas
nodevice pmspcv
nodevice pst
nodevice twe

# VirtIO
nodevice virtio
nodevice virtio_pci
nodevice vtnet
nodevice virtio_blk
nodevice virtio_scsi
nodevice virtio_balloon

# HyperV
nodevice hyperv
 
jbodenmann said:
[...] What's going on here? Could this be caused by the stable/13 running on the poudriere host being a couple of weeks older? If so, how would one manage a stable/13 poudriere server to ensure that stable/13 clients (i.e. the consumers of the pkg repo) stay "in sync"?
Click to expand...
My guess is that that shouldn't matter but, I would feel slightly anxious about it. Perhaps there's an incompatibility in pulled in dependencies on the build server versus clients.

Having written this—not very helpfull comment—I'm really interested in the answers :-)
 
Code: 
#define    SYS_freebsd11_mknod    14
#define    SYS_freebsd10_pipe    42
#define    SYS_freebsd11_vadvise    72
#define    SYS_freebsd11_stat    188
#define    SYS_freebsd11_fstat    189
#define    SYS_freebsd11_lstat    190
#define    SYS_freebsd11_getdirentries    196
#define    SYS_freebsd11_getdents    272
#define    SYS_freebsd11_nstat    278
#define    SYS_freebsd11_nfstat    279
#define    SYS_freebsd11_nlstat    280
#define    SYS_freebsd11_fhstat    299
#define    SYS_freebsd11_kevent    363
#define    SYS_freebsd11_getfsstat    395
#define    SYS_freebsd11_statfs    396
#define    SYS_freebsd11_fstatfs    397
#define    SYS_freebsd11_fhstatfs    398
#define    SYS_freebsd11_fstatat    493
#define    SYS_freebsd11_mknodat    498
your kernel does not have these and maybe for some reason firefox or its libs call it
 
jbodenmann said:
Could this be caused by the stable/13 running on the poudriere host being a couple of weeks older?
Click to expand...
This shouldn't make much of a difference. At least for 'regular' ports. Kernel modules might be a different matter. But most of the time my -STABLE systems aren't quite in sync with each other either. Most of the time this isn't an issue, although pkg(8) might sometimes complain that the ABI version is different.

jbodenmann said:
Could you be a bit more specific?
Click to expand...
Look at the kernel configurations of the two -STABLE machines. Make sure you keep COMPAT_FREEBSD11 and COMPAT_FREEBSD12 in your custom kernel config. I know several ports are still using pre-12 kernel structures and will fail to work correctly (or at all) without COMPAT_FREEBSD11 in the kernel. If I remember correctly x11/nvidia-driver even requires COMPAT_FREEBSD10 (you get a weird error when trying to do anything with OpenGL).
 
I've rebuilt the kernel with leaving compatibility for 12, 11 and 10 in there and now those applications indeed work as expected.

How would one go about figuring out if/what kernel version infrastructure a port relies on?
 
It's a bit of a hit and miss. I ran into this on 12-STABLE when I built my kernels without any COMPAT_FREEBSD## thinking everything should be working if you build it on the same 12-STABLE version. And everything will build and package just fine, it's when you run the actual application you start getting a lot of unexpected errors in strange places. The first one I ran into quite quickly was the Zabbix agent (forgot which version exactly) stopped working. After a lot of digging I realized the Zabbix agent was using pre-12 structures (filesystem related if I remember correctly). Simply adding COMPAT_FREEBSD11 to the kernel was enough to make it work again.

The second one was the NVidia driver. That one actually makes some sense because the driver is partially a closed source blob. But took me a while to figure out too. Everything would work, X works just fine. Except when you tried to use OpenGL you get some weird error it's not supported.
 
You must log in or register to reply here.
Back
Top