Re: ulpt vs kernel relinking

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: ulpt vs kernel relinking

Dabrien 'Dabe' Murphy
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

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:

i.e., teaching  "config -c <kernel.conf>" 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.)


:- Dabe