From: "requiem." <rqm@0xde501a7a.net>
Subject: Re: Compiling bsd.rd / bsd.update with custom kernel patches?
To: Stuart Henderson <stu@spacehopper.org>
Cc: tech@openbsd.org
Date: Wed, 2 Jul 2025 14:16:56 +0100


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.