28 Jul
2020
28 Jul
'20
12:39 a.m.
I'm trying to get 2bsd.tar extracted into v7. Does anyone have any
recollection how to do this. Here's what I'm seeing:
in simh:
simh> att tm0 -V -F TAR 2bsd.tar
Tape Image '2bsd.tar' scanned as TAR format.
contains 4935680 bytes of tape data (482 records, 1 tapemarks)
c
and in v7:
tar xv0
tar: bin/ - cannot create
directory checksum error
# ls
bin
What gives - it says it can't create the dir, but it does, it's there...
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
28 Jul
28 Jul
1:14 a.m.
Will, on your local system, take the tarball and pull off Joy's tar binary
then move it over using dd and the trick with the disks. Joy's label told
you to use his program. So try it. By
on you mac:
tar xvf 2bsd.tar tar src/tar <-- the later one
because he gave you two
ls -l tar <-- you
may want a byte and block count
dd if=tar of=ucbtar bs=1b conv=sync <-- pad to disk block size
then on simh: att ucbtar to the rk05
and attach your tape 2bsd.tar like you did before
on v7: dd if=/dev/rrkN of=ucbtar bs=1 <-- this should pull the
binary with the padded last block in
if you want to strip off the extra bytes, feel free but I don't think it's
going to matter.
chmod 755 ucbtar
./ucbtar vt0 <--- see it works
If that fails, try the other tar he left you on the tape.
My guess is that the tarball Warren has was written with a more modern tar
and the old tar can not handle the tar threaded tape directory. This is
possible as a lot was added to later versions tars and it's clear this is
not exactly the tape image that Joy wrote/distributed. So, Ken's original
version might just be unable to handle it. Hopefully, it is the contents,
but it was not written with Joy's 'tarit' script and maybe not on a V7/2BSD
system.
Clem
On Mon, Jul 27, 2020 at 8:41 PM Will Senn <will.senn(a)gmail.com> wrote:
I'm trying to get 2bsd.tar extracted into v7.
Does anyone have any
recollection how to do this. Here's what I'm seeing:
in simh:
simh> att tm0 -V -F TAR 2bsd.tar
Tape Image '2bsd.tar' scanned as TAR format.
contains 4935680 bytes of tape data (482 records, 1 tapemarks)
c
and in v7:
tar xv0
tar: bin/ - cannot create
directory checksum error
# ls
bin
What gives - it says it can't create the dir, but it does, it's there...
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
3:02 a.m.
On 7/27/20 8:14 PM, Clem Cole wrote:
on v7: dd if=/dev/rrkN of=ucbtar bs=1 <--
this should pull
the binary with the padded last block in
Your instructions held up until I tried to read from the rk device -
here's my attach:
in simh:
set rk0 rk05
att rk0 ucbtar
then in v7 the rk's aren't in /dev, so:
looked in c.c, rk is major dev 0, and rrk is dev 9, so...
/etc/mknod /dev/rk0 b 0 0
/etc/mknod /dev/rrk0 c 9 0
chmod 640 /dev/*rk*
and
dd if=/dev/rrk0 of=ucbtar bs=1
cannot open: /dev/rrk0
Look reasonable?
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
3:20 a.m.
On 7/27/20 10:02 PM, Will Senn wrote:
On 7/27/20 8:14 PM, Clem Cole wrote:
OK. I remembered that I needed to recompile the kernel, so in addition
to the above:
in v7:
chdir /usr/sys/conf
cc mkconf.c
mv a.out mkconf
echo rk >> myconf
cat myconf
hp
root hp 0
swap hp 1
swplo 0
nswap 8778
tm
4dc
rk
mkconf < myconf
console at 60
clock at 100
clock at 104
parity at 114
rk at 220
tm at 224
hp at 254
dc at 300
dc at 310
dc at 320
dc at 330
as - -o l.o l.s
cc -c c.c
ld -o unix -X -i l.o mch.o c.o ../sys/LIB1 ../dev/LIB2
mv unix /munix
rebooted and:
dd if=/dev/rrk0 of=ucbtar bs=1
read: Bad address
0+0 records in
0+0 records out
on v7: dd if=/dev/rrkN of=ucbtar bs=1
<-- this should pull
the binary with the padded last block in
Your instructions held up until I tried to read from the rk device -
here's my attach:
in simh:
set rk0 rk05
att rk0 ucbtar
then in v7 the rk's aren't in /dev, so:
looked in c.c, rk is major dev 0, and rrk is dev 9, so...
/etc/mknod /dev/rk0 b 0 0
/etc/mknod /dev/rrk0 c 9 0
chmod 640 /dev/*rk*
and
dd if=/dev/rrk0 of=ucbtar bs=1
cannot open: /dev/rrk0
Look reasonable?
Will
3:21 a.m.
try 1b for the blocking.
On Mon, Jul 27, 2020 at 11:20 PM Will Senn <will.senn(a)gmail.com> wrote:
On 7/27/20 10:02 PM, Will Senn wrote:
On 7/27/20 8:14 PM, Clem Cole wrote:
on v7: dd if=/dev/rrkN of=ucbtar bs=1 <-- this should pull the
binary with the padded last block in
Your instructions held up until I tried to read from the rk device -
here's my attach:
in simh:
set rk0 rk05
att rk0 ucbtar
then in v7 the rk's aren't in /dev, so:
looked in c.c, rk is major dev 0, and rrk is dev 9, so...
/etc/mknod /dev/rk0 b 0 0
/etc/mknod /dev/rrk0 c 9 0
chmod 640 /dev/*rk*
and
dd if=/dev/rrk0 of=ucbtar bs=1
cannot open: /dev/rrk0
Look reasonable?
Will
OK. I remembered that I needed to recompile the kernel, so in addition to
the above:
in v7:
chdir /usr/sys/conf
cc mkconf.c
mv a.out mkconf
echo rk >> myconf
cat myconf
hp
root hp 0
swap hp 1
swplo 0
nswap 8778
tm
4dc
rk
mkconf < myconf
console at 60
clock at 100
clock at 104
parity at 114
rk at 220
tm at 224
hp at 254
dc at 300
dc at 310
dc at 320
dc at 330
as - -o l.o l.s
cc -c c.c
ld -o unix -X -i l.o mch.o c.o ../sys/LIB1 ../dev/LIB2
mv unix /munix
rebooted and:
dd if=/dev/rrk0 of=ucbtar bs=1
read: Bad address
0+0 records in
0+0 records out
3:47 a.m.
On 7/27/20 10:21 PM, Clem Cole wrote:
try 1b for the blocking.
Hmm:
dd if=/dev/rrk0 of=ucbtar bs=1b
no space on dev 6/0
write: No space left on device
1175+0 records in
1175+0 records out
ls -l
-rw-rw-r-- 1 root 601088 Dec 31 19:41 ucbtar
df
bad free count, b=1
/dev/rp0 0
yeah, well no kidding, that file is WAY bigger than the file on the
host. so...
rm ucbtar (or bad things WILL happen with no space left)
set bs explicitly on the mac side of things
dd if=tar of=ucbtar bs=512 conv=sync
27+1 records in
28+0 records out
ls -l
-rwxr-x--- 1 wsenn staff 14156 Jul 27 22:32 tar
-rw-r--r-- 1 wsenn staff 14336 Jul 27 22:44 ucbtar
so back in v7:
set bs explicity and # blocks to read (otherwise it reads past the size
of the file, simh quirk?)
dd if=/dev/rrk0 of=ucbtar bs=512 count=28
28+0 records in
28+0 records out
# chmod 0755 ucbtar
# ls -l
total 28
-rwxr-xr-x 1 root 14336 Dec 31 19:47 ucbtar
# ./ucbtar x
tar: bin/ - cannot create
directory checksum error
echo $?
2
Haha, I'm learning, but I wanna cry :).
3:55 a.m.
On 7/27/20 10:47 PM, Will Senn wrote:
On 7/27/20 10:21 PM, Clem Cole wrote:
And the other copy of tar:
ucbtar x
Tar: blocksize = 20
tar: bin/ - cannot create
directory checksum error
# echo $?
2
Ah well, I'll pick it back up tomorrow. I remember doing this on v6. I'm
gonna see if I can dig up some old notes. Maybe I unpacked the tar on
the host and used simtools to repack as magtape... just seems like this
oughta work.
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
try 1b for the blocking.
Hmm:
dd if=/dev/rrk0 of=ucbtar bs=1b
no space on dev 6/0
write: No space left on device
1175+0 records in
1175+0 records out
ls -l
-rw-rw-r-- 1 root 601088 Dec 31 19:41 ucbtar
df
bad free count, b=1
/dev/rp0 0
yeah, well no kidding, that file is WAY bigger than the file on the
host. so...
rm ucbtar (or bad things WILL happen with no space left)
set bs explicitly on the mac side of things
dd if=tar of=ucbtar bs=512 conv=sync
27+1 records in
28+0 records out
ls -l
-rwxr-x--- 1 wsenn staff 14156 Jul 27 22:32 tar
-rw-r--r-- 1 wsenn staff 14336 Jul 27 22:44 ucbtar
so back in v7:
set bs explicity and # blocks to read (otherwise it reads past the
size of the file, simh quirk?)
dd if=/dev/rrk0 of=ucbtar bs=512 count=28
28+0 records in
28+0 records out
# chmod 0755 ucbtar
# ls -l
total 28
-rwxr-xr-x 1 root 14336 Dec 31 19:47 ucbtar
# ./ucbtar x
tar: bin/ - cannot create
directory checksum error
echo $?
2
Haha, I'm learning, but I wanna cry :).
1:38 p.m.
After much travail, I found a post in some ancient Asian language
(Japanese) and was reminded of Wolfgang's enblock. I didn't bother to
translate, but just did the enblock:
gunzip -d 2bsd.tar.gz
cat 2bsd.tar | enblock > 2bsd.tap
I attached the result, et voila:
tar xv0
tar: bin/ - cannot create
x bin/csh, 40412 bytes, 79 tape blocks
tar: bin/etc/ - cannot create
x bin/etc/htmp, 0 bytes, 0 tape blocks
x bin/etc/install, 81 bytes, 1 tape blocks
The cannot create messages are filthy lies :).
That brought it all back to me - just like when I built tar from tape
for v6... sheesh, why does it have to be so painfully difficult to
remember these tricky bits?!
Anyhow, afterward, I went back, did the translation from Japanese to
English (or google did), and it was good stuff about how to apply
2bsd.tar to v6:
https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%…
Thanks for the help and patience.
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
1:50 p.m.
Glad it's working. We probably need to create Joy's tarball in the future
with the same file ordering he used and get that the Warren. The trick is
getting a v6tar that properly works. Maybe one thing we should do is
write a tp format 'tape' with the v6tar binary on it and get that in the
archives independently.
When V7 came out, there was a way to create v6tar (which I suspect is
somehow part of Joy's image). The issue is that some of the system calls
changed in small but important ways. tar was a much better way to move
files around than tp which is why it so quickly became the archive scheme
in the Unix community.
On Tue, Jul 28, 2020 at 9:38 AM Will Senn <will.senn(a)gmail.com> wrote:
After much travail, I found a post in some ancient
Asian language
(Japanese) and was reminded of Wolfgang's enblock. I didn't bother to
translate, but just did the enblock:
gunzip -d 2bsd.tar.gz
cat 2bsd.tar | enblock > 2bsd.tap
I attached the result, et voila:
tar xv0
tar: bin/ - cannot create
x bin/csh, 40412 bytes, 79 tape blocks
tar: bin/etc/ - cannot create
x bin/etc/htmp, 0 bytes, 0 tape blocks
x bin/etc/install, 81 bytes, 1 tape blocks
The cannot create messages are filthy lies :).
That brought it all back to me - just like when I built tar from tape
for v6... sheesh, why does it have to be so painfully difficult to
remember these tricky bits?!
Anyhow, afterward, I went back, did the translation from Japanese to
English (or google did), and it was good stuff about how to apply
2bsd.tar to v6:
https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%…
Thanks for the help and patience.
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
3:20 a.m.
below..
On Mon, Jul 27, 2020 at 11:02 PM Will Senn <will.senn(a)gmail.com> wrote:
This is what I have:
; RK05 data disks (4 drives)...
;; SET RK ENABLE
SET RK0 WRITEENABLED
SET RK1 WRITEENABLED
SET RK2 WRITEENABLED
SET RK3 WRITEENABLED
SET RK4 DISABLED
SET RK5 DISABLED
SET RK6 DISABLED
SET RK7 DISABLED
ATTACH RK0 ./scratch.rk05
SHOW RK
> then in v7 the rk's aren't in
/dev, so:
there is a makefile in /dev that creates them.
Take a look and see what
its doing.
looked in c.c, rk is major dev 0, and rrk is dev 9, so...
> /etc/mknod /dev/rk0 b 0 0
> /etc/mknod /dev/rrk0 c 9 0
> chmod 640 /dev/*rk*
> and
> dd if=/dev/rrk0 of=ucbtar bs=1
bs=1b sorry -- my error, but I don't
think that's the issue.
try this for grins: dd if=/dev/rrk0 of=/dev/null bs=1b
cannot open: /dev/rrk0
Hmm... be good to see what the errno value is,
i.e. why?
Maybe a small C program that tries to open /dev/rrk0 and prints out errno
on failure.
On 7/27/20 8:14 PM, Clem Cole wrote:
on v7: dd if=/dev/rrkN of=ucbtar bs=1 <-- this should pull the
binary with the padded last block in
ouch my screw up... should be 1b
Your instructions held up until I tried to read from the rk device -
here's my attach:
in simh:
set rk0 rk05
att rk0 ucbtar
1726
days inactive
1726
days old
9 comments
2 participants
participants (2)
-
Clem Cole -
Will Senn