Subject: RE: finally....
To: None <port-vax@NetBSD.ORG>
From: Allison J Parent <allisonp@world.std.com>
List: port-vax
Date: 08/14/1997 11:10:43
<From gunnar@bitcon.no Thu Aug 14 07:54:39 1997
<Not really, it's in section 3.16 of the FAQ.
Well I'll take all the fluff out of that sections that applies to this and:
#mount /dev/ra0a /mnt
#mount /dev/ra0f /mnt/usr /* I have the user partition as ra0f */
#cp /gennetbsd /mnt/netbsd /* that what's written, I assume that was one
of many typos and /Gennnetbsd is /netbsd */
#cp /boot /mnt/boot
All done and seems to have been error free.
The text has this whole thing about using a dec mips to gunzip the the files
first... to make the tar tape. I can't, this is currently the only
useful(*?*) unix boxen I have.
* brief review here.
-I do have a pro350 with venix... not useful at this point as it does
not have tape and gunzip is not on it.
-somewhere along the line I messed up my vax vms 5.4 disk and that's
unavailable and will take a major rebuild. It did not have gunzip on it.
-I do have a vs2k with ultrix 4.2 on it but I have no idea how to get it
to talk to the TQK50/tk50 attached. I don't think it has gunzip on it
either.
-I do have a another microvax I can take the vs2k disk to and circumvent
and hardware issues of hooking the tk50 to but... there is that issue of
gunzip.
So I have a tape with bin.tar.gz and ect.tar.gz! In essence that
text says do majik here and then...
#cd /mnt
#tar --unlink -xpvf /dev/nrmt8
It assumes I have something I dont a tape with only tar files not gzipped
tarfiles. My foolish assumption is that when I got to this point enough of
netbsd would be there to handle this detail.
Also I still am dependent on ra0b as root. How do I get the root on ra0a?
This would allow swapping to be started and also normal access to all the
partitions.
The rest of the faq goes on about using nfs and making tapes by smoke and
mirrors. The nfs option is only remotely possible as now I have to build a
viable net from the only system that can FTP off the internet, my PC dosbox.
I have a major design problem with this... it's call lumping untested and
new hardware/software onto a problem thereby increasing the number of
variables for why it doesn't work. So far I've had to build a system to
copy floppies across different hardware and filesystems and it' has not
been close to error free. So whenever a step doesn't work it means was
netBSD is bad or the transmission of that piece. If it is was not netBSD
then I have to debug the stream of transmission as well.
Allison