I am not sure there was any debate on that, whether syspatch check of number of CPU OR what current kernel is running (MP or SP)
I made a quick check and at last one cloud service that have OpenBSD uses MP by default - as a result syspatch do not work (on small instances) as it try to patch SP kernel where in-fact MP kernel is in use (that’s one is Swiss Exoscale, but i suspect others have same problem…) _ Zbyszek Żółkiewski > Wiadomość napisana przez Steven Surdock <[email protected]> w dniu > 14.12.2017, o godz. 12:36: > > This was, in fact, the reason. I had an MP kernel running on a VM with a > single CPU. > > I ended up moving to an SP kernel, but I needed to copy > /usr/share/compile/GENERIC for a working i386 SP machine. To make sure > everything was updated I also reverted syspatches and then re-applied them. > Everything looks good now. > >> -----Original Message----- >> From: Zbyszek Żółkiewski [mailto:[email protected]] >> Sent: Thursday, December 14, 2017 6:24 AM >> To: [email protected] >> Cc: Steven Surdock <[email protected]> >> Subject: Re: syspatch not updating kernel >> >> Hi, >> >> perhaps this might be a reason, syspatch, around line number 274: >> >> (($(sysctl -n hw.ncpufound) > 1)) && _BSDMP=true || _BSDMP=false >> >> your kernel looks like MP on i386 ? >> >> _ >> Zbyszek Żółkiewski >> >>> Wiadomość napisana przez Steven Surdock <[email protected]> >> w dniu 13.12.2017, o godz. 14:33: >>> >>> I just ran syspatch on a 6.2/i386 host and the kernel did not change >> as it has on my other patched machines. It appears that >> pub/OpenBSD/syspatch/6.2 was updated on 12/10. >>> >>> root@rad03 [/root]# syspatch -l >>> 002_fktrace >>> 003_mpls >>> root@rad03 [/root]# uname -a >>> OpenBSD cts-rad03.ctstelecom.com 6.2 GENERIC.MP#166 i386 >>> >>> >>> -Steve S. >>> >
smime.p7s
Description: S/MIME cryptographic signature
