(I am answering both Lloyd and Christos here, as I couldn't get a grasp on the second email, and to keep the Message-ID dance)Sorry about the Message-ID dance. I'll try and avoid that in future.
You didn't do anything wrong. I was simply trying to explain why I took the occasion of answering both messages at once. In fact, I followed-up on your Message-ID to keep the thread, since your message was all I had.
Is this with NetBSD-current? My experience is with 9.0 and I have root filling almost all of a 500GB disk on a couple of NUCs. I thought the resize_ffs program refused to resize the v2 filesystems that I started with, but maybe it was just complaining about the log and I'm misremembering. Either way, my 9.0 systems are running with FFSv1.
It's 9.0/amd64(xen) here also, either the release or daily snapshots from the netbsd-9 branch.
Maybe you could build with something likenbmakefs -N tree/etc -x -F tree/METALOG.sanitised -s 2g -f 100000 netbsd.ffs tree/
Nice, thanks. Is -x -F critical here? I tried without it and I got the same post-resize corruption with FFSv1.
Is resize_root supposed to give results at the first run already? While seeing the boot message about resizing /, should I therefore be able to check the size of `/` right away, or I am supposed to reboot afterwards?
FWIW, now that I switched to FFSv1, I can mount NetBSD's FFS from GNU/Linux, even read-write, thanks to the CONFIG_UFS_FS=y CONFIG_UFS_FS_WRITE=y kernel features and the appropriate mount options (ufstype=44bsd). It was failing last time I tried to mount a makefs image and it could be because I had FFSv2.
BR -elge