That will be from reorder_kernel. If you're currently building on
a different machine then the easiest way around it while keeping the
reordering is probably to build on the mac instead. Or you can disable
the reordering by overwriting /var/db/kernel.SHA256 


On 2025/07/02 14:16, requiem. wrote:
> 
> I seem to be having an issue with this, it seems -- the custom kernel
> boots fine for the first time however it seems to somehow revert to a
> "stock" kernel when I boot a second time. I find this rather
> confusing, I have no idea where the stock kernel even comes from. 
> 
> I have followed the instructions closely; I also tried just running
> "make install" rather than copying the new kernel over as suggested in
> the FAQ article.
> 
> What am I missing, what is causing this behaviour?
> 
> 
> On Thu, 19 Jun 2025 08:29:49 +0100
> Stuart Henderson <stu@spacehopper.org> wrote:
> > On 2025/06/18 20:06, requiem. wrote:
> > > I can and successfully have done it before a few times but the
> > > problem is that whenever I need to upgrade the system on -current
> > > the bugs return as non-patched "bsd" and "bsd.rd" / "bsd.upgrade"
> > > files get installed via the normal install process. I would then
> > > need to wait out the long boot on upgrade and first boot, re-patch
> > > and install the kernel in place, etc.  
> > 
> > I would handle this by doing the upgrade differently. Basically follow
> > the steps from https://www.openbsd.org/faq/upgrade77.html#NoInstKern
> > but after untarring the sets, attempt to compile and install a
> > GENERIC.MP kernel from updated source (probably simpler on the
> > machine itself rather than another one). It won't always work (the
> > newly untarred binaries won't always work on the booted older kernel)
> > but most of the time it will, and the first stage will leave you with
> > an updated bsd and bsd.rd that you can boot (obviously with the extra
> > delay) as a fallback should you need it - though you're not likely to
> > need it very often.
> > 
> > > I have been trying to speed up this process by compiling the kernel
> > > on another machine running the same version. However I have not
> > > been too successful so I am asking for some guidance:
> > > 
> > > Here's what I would hope to achieve:
> > > - on the affected mac, run `sysupgrade -ns && pkg_update -u -Dsnap`
> > > and not reboot
> > > - compile the patched bsd.rd and bsd.mp on another machine
> > > - swap out the mac's /bsd.upgrade with the patched bsd.rd as well
> > >   as /home/_sysupgrade/bsd.rd and /home/_sysupgrade/bsd.mp
> > > - hopefully then reboot the macbook and boot normally without
> > > getting stuck for hours due to the acpi firmware bug it has
> > > 
> > > Here's what I tried:
> > > - on the mac: `sysupgrade -ns`
> > > - on the other machine:
> > > ```
> > > # patch < mypatch.diff
> > > # cd /sys/arch/amd64/compile/RAMDISK
> > > # make obj
> > > # make config
> > > # make
> > > # cp obj/bsd.gdb ~/bsd.rd.tocopy
> > > # cd /sys/arch/amd64/compile/GENERIC.MP
> > > # make obj
> > > # make config
> > > # make
> > > # cp obj/bsd.gdb ~/bsd.mp.tocopy
> > > ```
> > > - copy over the new `bsd.{rd,mp}.tocopy` to the Macbook over the lan
> > > 
> > > - on the mac again:
> > > ```
> > > # cp ~/bsd.rd.tocopy /bsd.upgrade
> > > # cp ~/bsd.rd.tocopy /home/_sysupgrade/bsd.rd
> > > # cp ~/bsd.mp.tocopy /home/_sysupgrade/bsd.mp
> > > # reboot
> > > ```
> > > 
> > > Here's what happens:
> > > 
> > > ```
> > > upgrade detected: switching to /bsd.upgrade  
> > > boot>   
> > > booting sr0a:/bsd.upgrade [...]
> > > fchmod a-x sr0a/bsd.upgrade: failed
> > > entry point at 0x1001000
> > > 
> > > [machine reboots]
> > > ```
> > > 
> > > What am I doing wrong? How can I compile the ramdisk kernel only?  
> > 
> > That's done as part of "make release", see release(8). It needs a
> > built base system as well though. Manual upgrade is probably a lot
> > simpler for this situation though.
>