Lloyd wrote: > I've run across this a few times, where I've improperly shut down > a VM (tapped the wrong button for power off vs ACPI shutdown) and > this lead to an unbootable image with the message before boot: > > booting hd0a:/bsd: hd0a:/bsd: Inappropriate file type or format > failed(79). will try /bsd > boot> > > To recover, I usually boot into bsd.rd and fsck the filesystems, > but in most cases the cause is a corrupted /bsd. Indeed, the last > encounter with this, /bsd had a size of only a few dozen kilobytes. > > To fix, I rm /bsd && cp /bsd.booted /bsd - reboot, re-calculate > the checksum and I'm on my way again. I'd like to understand why > this is happening. Is this plain unlucky FFS corruption or did I > trigger the power-off during the kernel reorder sequence and it > had only partially written out the file to disk? > > Since I have encountered this more than once now, is there a way > to increase the resiliency? The host is on UPS power, so the > cause is almost always user error (accidental power off). Could > disabling kernel relinking in the image improve the situation?
Hi Llyod, I definitely think a server should be able to boot after a hard reboot like that. This sounds frustrating. To be clear, fscking does not correct the issue with /bsd? It's still just several KB? Is this random, or do you have the ability to readily reproduce it? I think softupdates was pulled (somewhat) recently, and disabled for a while, so I'm assuming softupdates aren't at play. I'm not sure if this is related or not, but I recall Solene's post about FFS corruption: https://dataswamp.org/~solene/2024-11-15-why-i-stopped-using-openbsd.html#_Reliability I've had no corruption on OpenBSD yet. I am using older hardware. I wonder if the cause of corruption in her case is similar to yours? I assume that your / is not mounted with wxallowed? I can't really see either way why /bsd would have changes. Not sure how often people run into FFS corruption issues on OpenBSD and if there are any trends. -Henrich
