guest (08/18/82)
I guess I'll get more specific about solutions to problems we had
with 2.8bsd. I don't know how much to say about some of them because
they were pretty configuration-dependent. Also, I don't want to sound
like I'm complaining because there were problems. There was lots of
good software there. We run straight version 7 UNIX and tar'd the 2.8
sources to it. Vi, csh, and several other utilities were there in
binary. They run fine and were well worth the price of the tape.
The first thing we discovered is that our drive type register is
not what Berkeley expected. We run RM02 drives supplied by Plessy,
and the register reads 025 instead of 024. This caused us lots of problems
later. It meant we had to delve into the programs in /usr/ucb/kernel/
src/cmd/standalone to get a 1kboot that would boot separate I/D kernels
and treat our drives right. The fix was in libsa/xp.c, simply changing
the constant RM to 025 and changing what had been defined as 025 to some
unusual number we'll never see. We then ran the makefile in
.../standalone. This makefile ran another makefile in ./bootstrap
which compiled ../c.c but left the c.o in ./bootstrap. Then the makefile
linked a bogus c.o in .../standalone in with all the other stuff
to make the boot program, which then didn't work. Discovering this,
we copied the c.o in .../standalone/bootstrap into .../standalone, and
then ran the makefile again. This worked.
In order to boot from disk instead of tape you have to get the first
stage boot program onto block 0 of your disk. We tried rmboot in
.../kernel/mdec but it was apparently for RM05's. We changed the number
of surfaces called out in the code from 19 to 5 and it worked.
Now for the kernel. We had no experience coming up with a c.c and
l.s but guessed based on the ones in v7 UNIX. We then ran the kernel
makefile. Some errors surfaced. We discovered that tm.c wasn't
compiled or archived (we have a Kennedy 9000 which appears to act like
a TU10). We have an Able DH11 card and needed the dh.c driver. It
had a line which read '#ifdef MENLO70'. Well, MENLO70 wasn't defined
anywhere and this made several arrays have zero dimensions. We removed
the #ifdef and #endif. As I mentioned earlier, libc.a is no good. I got
a letter from Carl Smith at Berkeley who said they knew of the problem
already. There was a typo in .../libc/gen/pkon.c where TIO... was spelled
DIO..., sorry I don't remember the line number.
Several people kindly wrote to me about the message fsck hits us
with occasionally. It tells us that inode 1 is partially allocated.
Everyone said not to sweat it, that inode isn't essential anyway so go
ahead and clear it. Strangely, icheck and dcheck don't complain at all.
If we clear inode 1 then fsck starts talking about all the other bad inodes.
We clear them, too. (inode 2 isn't mentioned.) Eventually fsck craps out.
If you run it again it says ROOT INODE NOT ALLOCATED. TERMINATING.
Then you haul out your dump tape (ouch). What's happening?
Bill Carter, INSYSTEC
...!decvax!duke!ucf-cs!guestnrh (08/19/82)
Could your problem be that your are trying to fsck the raw devices? According to the documentation, seeks on raw devices don't work. Does anyone know why? I'm also interested in the 2.81 distribution. What's different? Does anyone know when it is due out for "general" release?