On 5/21/26 17:22, Steve Shockley wrote:
Hi, I have a VM under QEMU (Proxmox) that I've just upgraded from 7.8 to 7.9 that fails to relink the kernel after boot. It boots normally, then at the login prompt the console prints "reorder_kernel: failed -- see /usr/share/relink/kernel/GENERIC/relink.log". I have two other similar VMs that upgraded without a hitch. Running /usr/libexec/reorder_kernel manually gives the same result. Any suggestions? Thanks./usr/share/relink/kernel/GENERIC/relink.log: (SHA256) /bsd: OK LD="ld" sh makegap.sh 0xcccccccc gapdummy.o ld -T ld.script -X --warn-common -nopie --no-mmap-output-file -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS} ld: error: vfs_syscalls.o: symbol (10) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (11) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (12) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (13) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (14) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (15) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (16) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (17) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (18) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (19) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (20) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (21) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (22) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (23) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (24) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (25) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (26) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (27) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (28) has invalid binding: 0 ld: error: vfs_syscalls.o: symbol (29) has invalid binding: 0 ld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors) *** Error 1 in /usr/share/relink/kernel/GENERIC (Makefile:2477 'newbsd': @echo ld -T ld.script -X --warn-common -nopie --no-mmap-output-file...) df -h Filesystem Size Used Avail Capacity Mounted on /dev/sd0a 986M 83.7M 853M 9% / /dev/sd0k 12.8G 14.3M 12.1G 1% /home /dev/sd0d 2.4G 12.0K 2.3G 1% /tmp /dev/sd0f 4.3G 1.5G 2.6G 37% /usr /dev/sd0g 986M 346M 591M 37% /usr/X11R6 /dev/sd0h 5.2G 378M 4.6G 8% /usr/local /dev/sd0j 5.8G 2.0K 5.5G 1% /usr/obj /dev/sd0i 1.8G 2.0K 1.7G 1% /usr/src /dev/sd0e 3.8G 18.1M 3.6G 1% /var dmesg: OpenBSD 7.9 (GENERIC) #399: Wed May 6 13:01:58 MDT 2026 [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 519938048 (495MB) avail mem = 477065216 (454MB)
This is a (by today's standards) tiny system. How big is your swap space? How much of your main memory is in use by the time kernel rebuild is taking place? (keep in mind, kernel reordering takes place after all your services have started.) yes, 512MB RAM is a lot for a running OpenBSD system, but that kernel reordering takes a LOT of memory. MANY years ago, shortly after i386 switched to llvm, I noticed that if the system didn't have enough RAM to run the relink without swap, the relink would crash. At that time, the magic number seemed to be 512MB for i386. IIRC, that particular issue was fixed, but I also decided that waiting 20 minutes (or whatever it was) for the old P90 system to become usable after boot was just not worth it, and retired that machine. 512MB was required to avoid swapping on i386 a long time ago, I'm sure nothing is smaller on amd64 today. :) As this is a VM, a simple test might be to crank the memory up to 1G, and see if the problem goes away. If so, it's a memory problem, if not, I'm barking up the wrong tree. If it is memory related, booting it and immediately firing up "top" to see if swap is being exhausted (or even used!) might be educational. Nick.
