Re: ulpt vs kernel relinking
On Fri, 10 May 2019, Benjamin Baier wrote: On Fri, 10 May 2019, Antoine Jacoutot wrote: On Thu, 09 May 2019, Theo de Raadt wrote: config -e is incompatible with the KARL relinking sequence. You can probably do something like this in /etc/rc.shutdown: printf 'disable ulpt\nq\n' | config -ef /bsd sha256 /bsd >/var/db/kernel.SHA256 +KERNEL_CONF=/etc/kernel.conf +# Configure custom kernel options +if [[ -f $KERNEL_CONF ]]; then + while read _option; do + printf "%s\nquit" "$_option" | config -fe bsd + done < $KERNEL_CONF +fi Hi all, Sorry to dredge up an old thread, but I just wanted to mention that I ran into a similar problem today, and a Google search brought me here... After running "syspatch", I too noticed the following... error? warning? kernel relinking failed; see /usr/share/relink/kernel/GENERIC.MP/relink.log Following the directions, I also synced up the sha256 checksum: root# sha256 -h /var/db/kernel.SHA256 /bsd then re-ran "/usr/libexec/reorder_kernel" and rebooted... Unfortunately, this left my system in a completely unusable state! :-( The problem was, I needed to "disable inteldrm", but reorder_kernel "un-disables" that, and my system completely locked up trying to talk out the HDMI port. (And this fracking Dell has HDMI _AND_ DisplayPort, but *NO VGA!*) [Aside: To make matters even worse, the UKC> prompt I get when I "boot -c" won't recognize my USB keyboard — even though the boot prompt did — and of course there's no PS2 option to fall back to, either! But that's a whole 'nother issue... «sigh»] Anyway, I ended up booting from CD and doing: # mount /dev/sd0a /mnt # chroot /mnt # mount -a # config -ef /bsd UKC> disable inteldrm UKC> quit # reboot But then when "/etc/rc" tried to call "/usr/libexec/reorder_kernel" again, I was right back to the old "kernel relinking failed" message... At any rate, I just wanted to add my voice to the list of people affected by this. Benjamin's patch seems the most like what I would expect... Antoine's is good, too, but I worry that "rc.shutdown" could be too late; if the power goes out, or something, it might never run. My only other thought was similar to what Ted Unangst proposed here: https://www.mail-archive.com/tech@openbsd.org/msg51628.html i.e., teaching "config -c " to read from a file — or even command-line arguments. (And, by extension, it would be nice if "boot -c" inherited this behavior as well, since I need this to run before "/etc/rc" has run.) Cheers, -- :- Dabe
Re: ulpt vs kernel relinking
10.05.2019 8:37, Thuban пишет: Hi, I have a printer that require ulpt to be disabled as mentionned in /usr/local/share/doc/pkg-readmes/cups. And it works. # config -fe /bsd disable ulpt quit After a reboot, I can notice : reorder_kernel: kernel relinking failed; see /usr/share/relink/kernel/GENERIC.MP/relink.log Ok, so I run, as mentioned in the above file : sha256 -h /var/db/kernel.SHA256 /bsd However, at next reboot, ulpt is reenabled. How can I still have KARL and use my printer ? My machine doesn't boot with pcppi enabled, so, to use patched kernel I do config -e -o /bsd.nopcppi /bsd and create /etc/boot.conf with this: boot bsd.nopcppi
Re: ulpt vs kernel relinking
I cooked up a diff like this once, but I dont really use it any more.
diff --git a/libexec/reorder_kernel/reorder_kernel.sh
b/libexec/reorder_kernel/reorder_kernel.sh
index d8b8a2d24a..b59faca992 100644
--- a/libexec/reorder_kernel/reorder_kernel.sh
+++ b/libexec/reorder_kernel/reorder_kernel.sh
@@ -26,6 +26,7 @@ df -t nfs /usr/share >/dev/null 2>&1 && exit 1
KERNEL=$(sysctl -n kern.osversion)
KERNEL=${KERNEL%#*}
KERNEL_DIR=/usr/share/relink/kernel
+KERNEL_CONF=/etc/kernel.conf
LOGFILE=$KERNEL_DIR/$KERNEL/relink.log
PROGNAME=${0##*/}
SHA256=/var/db/kernel.SHA256
@@ -63,6 +64,14 @@ fi
cd $KERNEL_DIR/$KERNEL
make newbsd
+
+# Configure custom kernel options
+if [[ -f $KERNEL_CONF ]]; then
+ while read _option; do
+ printf "%s\nquit" "$_option" | config -fe bsd
+ done < $KERNEL_CONF
+fi
+
make newinstall
echo "\nKernel has been relinked and is active on next reboot.\n"
On Thu, 09 May 2019 23:41:17 -0600
"Theo de Raadt" wrote:
> config -e is incompatible with the KARL relinking sequence.
>
> For now, we consider KARL more valuable than config -e usage
> patterns.
>
> We've thought about this but for now we don't have a clever
> solution to solve this.
>
> Thuban wrote:
>
> > Hi,
> > I have a printer that require ulpt to be disabled
> > as mentionned in /usr/local/share/doc/pkg-readmes/cups. And it works.
> >
> > # config -fe /bsd
> > disable ulpt
> > quit
> >
> > After a reboot, I can notice :
> >
> > reorder_kernel: kernel relinking failed; see
> > /usr/share/relink/kernel/GENERIC.MP/relink.log
> >
> > Ok, so I run, as mentioned in the above file :
> >
> > sha256 -h /var/db/kernel.SHA256 /bsd
> >
> > However, at next reboot, ulpt is reenabled.
> >
> > How can I still have KARL and use my printer ?
> >
> >
> > --
> > thuban
> >
>
Re: ulpt vs kernel relinking
* Antoine Jacoutot le [10-05-2019 14:41:08 +0200]: > On Thu, May 09, 2019 at 11:41:17PM -0600, Theo de Raadt wrote: > > config -e is incompatible with the KARL relinking sequence. > > > > For now, we consider KARL more valuable than config -e usage > > patterns. > > > > We've thought about this but for now we don't have a clever > > solution to solve this. > Thanks for enlightenment. > Usual disclaimer, you're on your own etc... > You can probably do something like this in /etc/rc.shutdown: > > printf 'disable ulpt\nq\n' | config -ef /bsd > sha256 /bsd >/var/db/kernel.SHA256 Indeed, this removes wanings. Thank you.
Re: ulpt vs kernel relinking
On Thu, May 09, 2019 at 11:41:17PM -0600, Theo de Raadt wrote: > config -e is incompatible with the KARL relinking sequence. > > For now, we consider KARL more valuable than config -e usage > patterns. > > We've thought about this but for now we don't have a clever > solution to solve this. Usual disclaimer, you're on your own etc... You can probably do something like this in /etc/rc.shutdown: printf 'disable ulpt\nq\n' | config -ef /bsd sha256 /bsd >/var/db/kernel.SHA256 > Thuban wrote: > > > Hi, > > I have a printer that require ulpt to be disabled > > as mentionned in /usr/local/share/doc/pkg-readmes/cups. And it works. > > > > # config -fe /bsd > > disable ulpt > > quit > > > > After a reboot, I can notice : > > > > reorder_kernel: kernel relinking failed; see > > /usr/share/relink/kernel/GENERIC.MP/relink.log > > > > Ok, so I run, as mentioned in the above file : > > > > sha256 -h /var/db/kernel.SHA256 /bsd > > > > However, at next reboot, ulpt is reenabled. > > > > How can I still have KARL and use my printer ? > > > > > > -- > > thuban > > > -- Antoine
ulpt vs kernel relinking
Hi, I have a printer that require ulpt to be disabled as mentionned in /usr/local/share/doc/pkg-readmes/cups. And it works. # config -fe /bsd disable ulpt quit After a reboot, I can notice : reorder_kernel: kernel relinking failed; see /usr/share/relink/kernel/GENERIC.MP/relink.log Ok, so I run, as mentioned in the above file : sha256 -h /var/db/kernel.SHA256 /bsd However, at next reboot, ulpt is reenabled. How can I still have KARL and use my printer ? -- thuban
Re: ulpt vs kernel relinking
config -e is incompatible with the KARL relinking sequence. For now, we consider KARL more valuable than config -e usage patterns. We've thought about this but for now we don't have a clever solution to solve this. Thuban wrote: > Hi, > I have a printer that require ulpt to be disabled > as mentionned in /usr/local/share/doc/pkg-readmes/cups. And it works. > > # config -fe /bsd > disable ulpt > quit > > After a reboot, I can notice : > > reorder_kernel: kernel relinking failed; see > /usr/share/relink/kernel/GENERIC.MP/relink.log > > Ok, so I run, as mentioned in the above file : > > sha256 -h /var/db/kernel.SHA256 /bsd > > However, at next reboot, ulpt is reenabled. > > How can I still have KARL and use my printer ? > > > -- > thuban >
