So I was just reminded that I do still have a Xen server that's still running the 8.99.32 kernel and Xen-4.11. I had not been testing on it because it still of course has the vnd(4) CHS size bug (and because it's also hosting my $HOME and /usr/src and I don't want to crash it), and I had not remembered until just now that I can work around that by simply padding out the mini-memstick.img file!
And, so.... It works, A-OK, with all other things remaining the same: # ls -l /dev/xbd0 crw-r----- 1 root operator 0x3a Apr 17 04:31 /dev/xbd0 # newfs /dev/xbd0 /dev/xbd0: 20480.0MB (41943040 sectors) block size 32768, fragment size 4096 using 33 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. super-block backups (for fsck_ffs -b #) at: 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712, 30773952, 32056192, 33338432, 34620672, 35902912, 37185152, 38467392, 39749632, 41031872 # fsck /dev/xbd0 ** /dev/xbd0 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2 files, 2 used, 5076797 free (21 frags, 634597 blocks, 0.0% fragmentation) ***** FILE SYSTEM IS CLEAN ***** # So the problem is almost certainly in NetBSD-current itself, and somewhere in the vast gulf between 8.99.32 (2020-06-09) and 9.99.81 (2021-03-10). Unfortunately I don't have enough hardware that's Xen-capable and up and running well enough to allow me to do any brute-force bisecting. -- Greg A. Woods <gwo...@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <wo...@robohack.ca> Planix, Inc. <wo...@planix.com> Avoncote Farms <wo...@avoncote.ca>
pgpLZpfkSDO0p.pgp
Description: OpenPGP Digital Signature