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 <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp5BSGilncPw.pgp
Description: OpenPGP Digital Signature