What are the permissions on the bsd.upgrade that's left behind? If they are still +x then your issue is with the boot loader, maybe that boot.conf otto suggested. If they are -x then the boot loader started the install kernel but something went wrong.
On 14 February 2021 18:02:07 CET, Judah Kocher <koche...@hotmail.com> wrote: >Hello folks, > >I am having an issue with sysupgrade and I have had trouble finding the > >source of the problem so I hope someone here might be able and willing >to point me in the right direction. > >I have 6 small systems running OpenBSD -current and I have a basic >script which upgrades to the latest snapshot weekly. The systems are >all >relatively similar. Three are the exact same piece of hardware, two are > >slightly different, and one is a VM configured to match the first three > >as closely as possible with virtual hardware. > >The script checks the current kernel version, (e.g. "GENERIC.MP#302") >logs it, runs sysupgrade, and after the reboot it checks the kernel >version again. If it is different it logs it as a "success" and if it >is >still the same it logs it as a failure. > >All 6 systems were configured using the same autoinstall configuration >and the upgrade script is identical on each unit. However, two of the >three identical units always fail. When I remote into either system and > >manually run the upgrade script it also fails. I was able to get onsite > >with one of them where I connected a monitor and keyboard and manually >ran the script to observe the results but oddly enough it succeeded so >I >learned nothing actionable. However it continues to fail the weekly >upgrade. I have confirmed that the script permissions are identical on >the working and nonworking units. > >The 4 units that successfully upgrade leave a mail message with a log >of >the upgrade process. However I have been unable to find any record or >log on the systems that are failing to help me figure out why this >isn't >working. The only difference I can identify between the systems is that > >"auto_upgrade.conf" and "bsd.upgrade" are both present in "/" on the >two >systems that fail, but are properly removed on the 4 that succeed. > >I would appreciate any suggestions of what else I can try or check to >figure out what is causing this issue. > >Thanks > >Judah -- Sent from a mobile device. Please excuse poor formating.
