On Mon, Jun 26, 2017 at 02:35:55PM -0600, Theo de Raadt wrote:
> There is a diff in snapshots which does kernel relinking during
> install or upgrade.
>
> Really amazing...
>
I have an issue regarding kernel relinking during upgrade.
Not a big chunk, but I prefer to report it to see the better way to
change my workflow or to change operations order in installer.
I use /upgrade.site file in order to patch in advance (from the
installer, and before rebooting) the kernel in order to disable ulpt to
let cups using my usb printer using libusb.
# cat /upgrade.site
#!/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# disable ulpt if cupsd installed
[[ -x /etc/rc.d/cupsd ]] && echo 'disable ulpt*\nquit' | config -f -e /bsd.mp
exit 0
The current order of operation in the installer is (after manual
inspection):
- do install/upgrade stuff
- run /$MODE.site in chroot (here upgrade.site)
- MAKEDEV and installboot
- bsd.mp renaming to bsd if MULTIPROCESS
- KARL stuff
- generating sha256 from /bsd
- relinking to create an unique kernel
- adding sysmerge and fw_update in rc.* files
- few other stuff and rebooting
The interaction between /upgrade.site (patching /bsd) and KARL makes the
reconfiguration stuff to be discarded... and my printers to not be
functional using libusb at reboot (due to ulpt).
Some questions/options:
- should /$MODE.site to ran a bit later ? (after KARL)
- should /$MODE.site to ran after "generating sha256 from /bsd" and
before "relinking to create an unique kernel" ? it should let "make
newbsd" detect /bsd modification, and not relinking the kernel.
- what is the expected way to disable KARL in the installer ?
(I assume removing /usr/share/compile.tgz and /usr/share/compile
should be enough)
- does patch for something like config(8) script would be acceptable, in
order to have an official way to apply config(8) modification *and*
to have KARL at same time ?
For me, patching the kernel in rc.firsttime wouldn't be a great option: it will
require a reboot to apply settings.
Thanks.
--
Sebastien Marie
