Hi Bugs list and Theo, I modified rc to have the line: ktrace -di -f /usr/local/ktrace.outX /usr/libexec/reorder_kernel
and then used kdump: kdump -f /usr/local/ktrace.outX > /usr/local/kdumpX In case it is helpful you could look at the full kdump on the run which did not relink: https://coiloptic.org/uploads/kdump3-crashed I don't know what to look for but I had a look anyway. One thing I noticed on the versions that succeeded linking: the lines containing "size GIO" were followed by ELF headers or similar, but on the ktrace that failed, one of those lines is followed by "newbsd: not object file or archive" (see the extract below). Another thing I noticed was the ktrace on the succesful relinks was 121M, while the one that did not link was 28.7M. Perhaps that is expected. ... 47317 size RET read 16384/0x4000 47317 size CALL kbind(0x7f7fffff9c58,24,0x681f76db094ac55d) 47317 size RET kbind 0 47317 size CALL lseek(3,0,SEEK_CUR) 47317 size RET lseek 16384/0x4000 47317 size CALL kbind(0x7f7fffff9c58,24,0x681f76db094ac55d) 47317 size RET kbind 0 47317 size CALL write(2,0x7f7fffff9480,0x6) 47317 size GIO fd 2 wrote 6 bytes "size: " 47317 size RET write 6 47317 size CALL write(2,0x7f7fffff9560,0x22) 47317 size GIO fd 2 wrote 34 bytes "newbsd: not object file or archive" ... Thanks, Brett. ===== On Sun, 2 Feb 2020 01:50:14 -0700 (MST) Theo de Raadt <[email protected]> wrote: | There have been a few reports, but nothing with a clue for us yet. | | Can you modify your /etc/rc to run prepend something like | "ktrace -di -o /somewherewithspace/ktrace.out" to the relink operation, | and when it fails, kdump and look for clues? | | >On Thu, 30 Jan 2020 21:14:20 +1100 | >Brett Mahar <[email protected]> wrote: | > | >| | >| | | >| | ----- | >| | | >| | After booting bsd.mp, I got the console message: | >| | "reorder_kernel: failed -- see /usr/share/relink/kernel/GENERIC.MP/relink.log" | >| | | >| | ----- | >| | | >| | in relink.log: | >| | | >| | (SHA256) /bsd: OK | >| | LD="ld" sh makegap.sh 0xcccccccc gapdummy.o | >| | ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS} | >| | size: newbsd: not object file or archive | >| | *** Error 1 in /usr/share/relink/kernel/GENERIC.MP (Makefile:1437 'newbsd': @size newbsd ; umask 007; e | >| | cho mv newbsd newbsd.gdb; rm -f newb...) | >| | | >| | >| Hi again, | >| | >| I just installed the newest snapshot of -current (OpenBSD 6.6-current (GENERIC.MP) #625: Wed Jan 29 23:51:39 MST 2020) | >| | >| I rebooted successfully two times post-install, I then saw the same error message "reorder_kernel: failed -- see /usr/share/relink/kernel/GENERIC.MP/relink.log" and on the next reboot the machine went into the same endless reboot cycle. | >| | >| So the endless reboots seem related to the relinking failing. | >| | >| I get these failures with both bsd.sp or bsd.mp | >| | >| Brett. | >| | >| | >' | > | >Upgrading again to [OpenBSD 6.6-current (GENERIC.MP) #626: Thu Jan 30 19:26:22 MST 2020], and running: | > | >sha256 -h /var/db/kernel.SHA256 /bsd | >/usr/libexec/reorder_kernel | > | >I still see these linking problems, but not every time. It confuses me why it would link sometimes and not others. The linking seems to fail more when the /usr/libexec/reorder_kernel command runs after boot. It nearly always succeeds when I run it manually. | > | >For now I have added to rc.shutdown: | > | >sha256 -h /var/db/kernel.SHA256 /bsd | >sync | >/usr/libexec/reorder_kernel | >sync | > | >and so far, so good. | > | >Brett. | > | > | > | > | >
