Hello All,

Thanks for the answers, I have gotten multiple good solutions here. Yes Indeed I have not provided some key details, well the OpenBSD 5.2 boxes were running in Vmware Server 2.X free until they were migrated to Vmware Workstation 8,9 and finally to Workstation 12 boxes.
HDD was set to IDE since that is what Vmware recommends for OpenBSD.

The crashes and filesystem corruptions never been OpenBSD's fault but outside circumstances (power outages, vm servers run out of memory froze the vms, disk DMA errors caused whole VMM to hang until reboot etc).

I have now successfully tested OpenBSD6.0's auto recovery in Vmware 12.0 by copying bunch of small files from other machine through ftp and pulling the plug (killing the VMX pid), at start it always fixed all the errors so upgrading to 6.0 will be the solution I choose.

Good to see the clean and precise system engineering work which went into OpenBSD, hopefully it will never get corrupted by System(d) and alikes, in the future I should migrate even more servers to OpenBSD.

On 2016-11-28 12:36, Stuart Henderson wrote:
On 2016-11-24, Peter N. M. Hansteen <pe...@bsdly.net> wrote:
As far as I can remember, OpenBSD does indeed run a file system check at boot if there are indications that the system did not shut down cleanly.
I don't think the system has changed very much in that respect at all
for a very long time.

Correct. But /etc/rc uses fsck -p which only allows minor repairs
automatically and requires intervention for major repairs (which are
more likely to lose data).

On simple remote firewall boxes (where failing to boot is as big a problem
as a toasted filesystem) I modify this.

Next, look into what caused those file systems to go bad in the first

Yes, very much this.

Reply via email to