Lloyd <[email protected]> writes:
>>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
>
> [email protected]:/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!
so it means that the uvn_flush error doesn't propagate from kernel to
userland ? or a userland tool (lld, ctfstrip ?) ignored it and exited
with 0 ?
the reorder logic is Makefile:
/usr/share/relink/kernel/GENERIC.MP/Makefile
2433 │ newbsd:
2434 │ ${MAKE_GAP}
2435 │ ${SYSTEM_LD_HEAD}
2436 │ ${SYSTEM_LD} swapgeneric.o
2437 │ ${SYSTEM_LD_TAIL}
2438 │ rm -f bsd.gdb
2439 │ mv -f newbsd bsd
I quickly checked ctfstrip, and it isn't very robust against errors:
(I almost filled my /tmp before testing)
$ ctfstrip -S -o bsd /usr/share/relink/kernel/GENERIC.MP/bsd && echo ok
/tmp: write failed, file system is full
LLVM ERROR: IO failure on output stream: No space left on device
ok
$
it isn't the same error, but if ENOSPC occured during ctfstrip phase,
Makefile will happily use a truncated bsd file.
I suppose the same could occurs with lld (untested for now).
Regards.
--
Sebastien Marie
