[TUHS] 3bsd tape image

[Clem Cole]

below...

On Fri, Aug 4, 2023 at 1:17 PM Will Senn <will.senn at gmail.com> wrote:

> On 8/3/23 23:41, Warner Losh wrote:
>
>
>
> The TUHS stuff matches what we have on Kirk's CDs.
>
> And it looks like one could build a boot tape from what's in sys in the
> tarball.  It has the usual standalone files that look like V7 files.
>
> There's usr/man/man8/sysgen.8
>
> sysgen \- UNIX system generation from the distribution tape
>
> I've not tried to grab that tape to see if it has the same bits as in the
> archive.
>
> Warner
>
>
> Hi Warner,
>
> I would love to be able to recreate the bootable tape(s) from what we have
> available (the tarball) and document that process along the way. In the
> setup manual, it says:
>
> The tape contains binary images of the system and all the user level
> programs, along with source and
> manual sections for them. There are about 4200 UNIX† files altogether. The
> first tape file contains boot-
> strapping programs. The second tape file is to be put on one filesystem
> called the ‘root filesystem’, and
> contains essential binaries and enough other files to allow the system to
> run. The third tape file has all of
> the source and documentation. Altogether the files provided on the tape
> occupy approximately 40000 512
> byte blocks
>
> Taking this apart, it seems like:
>
> The tape contains binary images of the system and all the user level
> programs, along with source and
> manual sections for them. There are about 4200 UNIX† files altogether.
>
> Refers to everything in 3bsd.tar.gz  - 4130 files.
>
> And this:
>
> The first tape file contains boot-strapping programs.
>
> Refers to the files in sys:
>
I think not sys but /stand

> boot  mkfs  restor  rp6fmt  rpread
>
> And should have a boot block on it - with the standalone system -- this
is right from V7 and I thought 32V but I have forgotten - BTW - this tape
file will have a block size of 512 bytes because of how it is used and boot
roms will read 512 bytes at time.

> And this:
>
> The second tape file is to be put on one filesystem called the ‘root
> filesystem’, and
> contains essential binaries and enough other files to allow the system to
> run.
>
> Right - the standalone system is used to create the root FS and the
standalone restore to recreate the root [it's 20B or 10240 byte blocked]
because by now you have a read device driver in either the standalone
system or UNIX itself do blocking factors can be handled.

> Refers to everything except /usr/src and /usr/doc.
>
What worries me a little is V7 had a dump format of /usr at this point -
the rootfs did not have enough space for the everything in /usr such as
/usr/{bin,lib,share...} and much less doc and src.


> While this:
>
> The third tape file has all of the source and documentation.
>
> Refers to /usr/src and /usr doc.
>
That makes sense in that it allows everyone some one to read these two
without having to ferret it from a restore/dump format.

>
> If I'm understanding things, this means I would create three tape images -
> one with just the 5 files in sys and that's it, the second with everything
> except for /usr/src/ and /usr/doc, and the third with just /usr/src and
> /usr/doc. The first tape would have blocksize 512, the other two, 10240. I
> could then use any of the plethora of maketape scripts around to put the
> tape together.
>
> In looking at what was done previously, it looks like the root fs was on
> the tape as a dump, whereas the usr files were on the tape as a .tar. Why
> not just have root and usr as .tar on the tape?
>
Tar is easier when trying in read mode, particularly if you only one want a
couple of files/directors.   Dump/restore is fine for a complete FS at a
time.
Given just the src and doc directories, wanting to read the doc and source
from that tape on another system -- say 32V or V7, tar makes it easier.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20230804/3f947879/attachment-0001.htm>