I gave this some additional thought. Something is not setting an error
condition when being able to write past end-of-disk when the FS is full.
That means it isn't necessarily reorder_kernel at all, that is the
symptom, maybe not the cause. The cause could be somewhere deeper
(linker, filesystem, etc.)
Lloyd wrote:
> > Synopsis: reorder_kernel generates corrupted /bsd when /usr is full
> > Category: system
> > Environment:
>
> System : OpenBSD 7.7
> Details : OpenBSD 7.7 (GENERIC) #619: Sun Apr 13 08:19:34 MDT 2025
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>
> Architecture: OpenBSD.amd64
> Machine : amd64
>
> > Description:
>
> If /usr is nearly full, /usr/libexec/reorder_kernel will complete without
> error, but generate a corrupted kernel which is moved into /bsd. This
> will result in an unbootable system on the next boot.
>
> > How-To-Repeat:
>
> 1. assess free space in /usr
> 2. subtract a few MB, dd if=/dev/zero of=/usr/foo bs=1m count=<xxx>
>
> 3. reboot so reorder_kernel will run
> 4. the following message will echo to console during the reorder:
> uvn_flush: obj=<address>, offset=<address>. error during pageout.
>
> uvn_flush: WARNING: changes to page may be lost!
> 5. note the reorder completes, filesize of /bsd will be less than expected
> the correct hash for bad /bsd has been written to /var/db/kernel.SHA256
>
> contents of relink.log for a corrupted/truncated kernel:
>
> (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}
> text data bss dec hex
> 26728562 488512 1351680 28568754 1b3ecb2
> mv newbsd newbsd.gdb
> ctfstrip -S -o newbsd newbsd.gdb
> rm -f bsd.gdb
> mv -f newbsd bsd
> install -F -m 700 bsd /bsd && sha256 -h /var/db/kernel.SHA256 /bsd
>
> Kernel has been relinked and is active on next reboot.
>
> SHA256 (/bsd) =
> 75600b28045794fa983d0823435c3a07c276b13dbbf11dc01dca71a2d4fe8d6d
>
> 6. reboot
> 7. system will not boot. you must boot into bsd.rd to remove offending kernel.
>
> > Fix:
>
> Unknown. Workaround is to disable kernel reordering or ensure
> enough free space in /usr for reorder_kernel to complete successfully.
