foreign floppies on the 3b1

[John Hood]

This was not fun to see...

Over the weekend, I was at Dave Shevett's house.  We were moving net
software in every conceivable direction-- he has a 3b1 (labii), I have
a 386 running Microport.  I tried to make a cpio disk that the
Xenix/386 machine he had around temporarily could read.  I didn't know
what device on the 3b1 corresponded to a plain, dumb block device with
no funny volume header blocks, and the 3.5 manuals are no help.  (Nor
was Dave ;-) Eventually, I figured out that maybe I could format an 8
sector disk (FDnl), cpio to /dev/rfp020 and feed that to Xenix, using
its /dev/fd048ds8.  I noticed that after writing anything to the
[r]fp020 device, the disk became unrecognizable by the 3b1, presumably
because the volume header block gets stomped on.

I think I was just getting close to succeeding in this quest when the
3b1 panicked with a bad block in the free list, halfway through
cpio-ing to a disk.  I let it go through the automatic reboot/fsck
cycle (twenty-twenty hindsight shows that this was probably *NOT* a
good idea), and when it came back up after two automatic reboots, most
of /usr was in lost+found and some of it was gone, as was about 3/4ths
of /etc.  We spent a good ten or so hours picking up pieces, copying
them off to floppy, and doing a complete reinstall.  It will be a few
days before Dave has his system back up on the net.

It may well have been coincidence (the system had been acting a little
bit weird), but needless to say, I didn't dare do anything even
vaguely unusual with 3b1 floppies after that.

Would somebody please explain how the floppies are laid out, what the
two floppy devices do and what they're for, and how to get around the
volume header block for 3b1 <-> PC-family disk transfer?  (I vaguely
recall that there is a utility out there that specifically handles
PC-Unix style disks, but we didn't have it, and it would be nice to
know a way to do without it.)

And does anyone know whether the 3B1 is particular about the contents
of the disks fed to it, to the point of tripping over itself and
panicking on ones it doesn't like?

And a final note: I suspect that the reason the machine lost files may
have been that the lost+found directory was not large enough to
accommodate all the recovered files, and fsck automatically threw
files away.  It was only 1024 bytes or 32 files long.  Make sure your
lost+found directory is at least as large as the largest directory on
your system; it's cheap insurance.

  --jh
-- 
John Hood, Biar Games snail: 10 Spruce Lane, Ithaca NY 14850 BBS: 607 257 3423
domain: jhood at biar.uu.net bang: anywhere!uunet!biar!jhood
You may redistribute this article only to those who may freely do likewise.