On 2026-06-11, Zeljko Jovanovic <[email protected]> wrote: > On 6/11/26 15:13, Nick Holland wrote: > > ... >> you built a broken system. > > It was built a long time ago by somebody else. > I was just been assigned the task of upgrading it. > > This particular server used to be OpenBSD on a SPARC physical machine, > which was later migrated to x86_64 VM. Probably the image of its original > disk was just mounted under VM, and x86_64 OS version installed over it. > In that way, data and configuration files stayed in place.
I don't think that's possible with UFS from a machine of a different endianness. I don't think you can do this through the usual install script though, so it seems likely that something special was done. >> well...you can do a manual upgrade, and push your problem down the road a >> bit. >> >> But...your system was built incorrectly. You need to rebuild it. Better to >> do it on your schedule, rather than in a panic when it breaks worse. >> >> It actually surprises me it works at all. But what you have is a totally >> unsupported configuration; it isn't something that is tested for, it isn't >> something that may work at all in future releases. >> >> Nick. > > Thank you for your insight. The clean install is definitely the best way to > go. I think this is the only way. Also if it's been upgraded over many releases you may have FFS1 filesystems that could be replaced with FFS2 (y2038, and much faster fsck on non-full filesystems) and make sure they're sized with room for growth. I'd probably go about this by configuring a new machine/VM, and use dump over ssh, e.g. cd $target_dir ssh root@source-machine "cd $source_dir && dump -0 -f-" | restore rf - -- Please keep replies on the mailing list.
