From: Stuart Henderson Subject: Re: Compiling bsd.rd / bsd.update with custom kernel patches? To: "requiem." Cc: tech@openbsd.org Date: Wed, 2 Jul 2025 14:26:01 +0100 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 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. >