>> booting fd0a:netbsd.gz
>> 958464exec: short read
>> boot: fd0a:netbsd.gz: Input/output error
> Boots for me without error.

I would assume it boots for _someone_ without error; anyone making
snapshots is surely not clueless enough to put such a thing up without
at least smoke-testing it. :-)

>> I copied the image to a NetBSD/i386 machine, mounted it thanks to
>> the good graces of the vnd driver, and appended 337 bytes from
>> /dev/zero to the netbsd.gz file, that being the number necessary to
>> pad it to a multiple of 512
> The error happens early in netbsd.gz, before even the data segment is
> started.  It your fix helps, then it is due to side effects imo,
> perhaps rewrite of another sector, removing a physical error.

Physical error?  I've seen no errors reported for that floppy, though
I'll try it with another floppy on Monday.  I doubt this is it, though;
see below.

When I was trying both images, it was done by rewriting the same
physical floppy, so it's not a question of a sector being written wrong
once by chance.  Nor is it a bad media sector; netbsd.gz occupies
exactly the same blocks in the two images.  The only differences I can
find are

	- The "last mounted on" string in the superblock
	- Timestamps (access/modify on files, last mount in superblock)
	- The size of netbsd.gz as recorded in its inode
	- Potentially, the data stored in "unused" areas, such as the
	   space after EOF in the last block of netbsd.gz

Note that I padded netbsd.gz to a multiple of 512 bytes, but as it
happens not to a multiple of any larger power of two (the new size is
1108480 = 0x10ea00 bytes).  Since the filesystem has fragsize=512
blocksize=4096, this pads to a frag boundary but not a block boundary;
since netbsd.gz is large enough to use indirect blocks, the last block
is entirely allocated.

As for the error happening early, before even the data segment is
started: could it be that the entire data segment fits inside a single
compression block, and the error occurred while reading the last
compression block before uncompressing it?  Indeed, gzip tends to use
compression blocks large enough that it would not have surprised me to
find that all of netbsd.gz fit in a single compression block.

I'll be glad to send a copy of either/both of the floppy images in
question to anyone who wants; I can also test stuff.  I may be able to
mechanically capture a copy of /kern/msgbuf while booted off the
working floppy image, if that would help.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B