On 2019-10-02, Sean Kamath <kam...@moltingpenguin.com> wrote:
> Hi.
>
> I’m hoping someone either has a cluebat or some helpful suggestions beyond
> “reinstall”.
>
> I had an alix 2d13 running OpenBSD 6.3. I finally got around to upgrading to
> 6.4 (via https://www.openbsd.org/faq/upgrade64.html), and that seemed to go
> just fine (I used the Upgrading Manually section, since I don’t have (easy)
> access to the console).
>
> I let that run for a day, just to make sure all was well, and then attempted
> an upgrade to 6.5 (via https://www.openbsd.org/faq/upgrade65.html), again
> using the “Upgrading Manually” section.
>
> This time, between smtpd and relinking the kernel, it appears my Alix board
> is quickly running out of memory. Within a few seconds the sr rate is in the
> 20K range. I stopped the ld for relinking, and killed SMTPD in order to
> finish the install (the makedev ALL, sysmerge, pkg_update -u bits), and that
> all ran fine. But about 15-20 minutes after a reboot, the box just goes off
> the network, and there’s not much I can do.
>
> I can download and reinstall 6.5, but was hoping to avoid that pain, but I
> just want to make sure 6.5 has no issues on the Alix boards. . .
>
> Thanks! I’d attach dmesg, but the box is dead again. . . If anyone wants to
> dive into what’s going on, just let me know what info you want to see.
>
> Sean
>
>
After boot, the kernel is relinked in a random order in the background
("/usr/libexec/reorder_kernel &" in /etc/rc). This is done so that
there will be a different memory layout on different boots, making
it harder to carry out types of attack that rely on knowing where
things are in the kernel.
Unfortunately the Alix doesn't have much RAM and if you have pretty
much anything other than a minimal set of daemons running it won't
cope well.
You can disable the reordering by removing /var/db/kernel.SHA256
but be aware that syspatch relies on the reorder_kernel mechanism in
order to apply kernel patches. So if you do this and need to apply
such patches, re-enable it temporarily before running syspatch:
"sha256 -h /var/db/kernel.SHA256 /bsd" - stop any unnecessary
processes - then run syspatch. After syspatch has finished
you can remove kernel.SHA256 again before rebooting.
