From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18871 invoked from network); 4 Aug 2023 19:51:43 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2023 19:51:43 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 56078425AC; Sat, 5 Aug 2023 05:51:39 +1000 (AEST) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) by minnie.tuhs.org (Postfix) with ESMTPS id 7478142594 for ; Sat, 5 Aug 2023 05:51:31 +1000 (AEST) Received: by mail-vk1-xa2c.google.com with SMTP id 71dfb90a1353d-4864cc561aeso950756e0c.0 for ; Fri, 04 Aug 2023 12:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; t=1691178690; x=1691783490; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=v9aXdoLhhoWclddSQ9L1lPeROamEoqrovytUyvBDf3w=; b=CU6cFP5kGfoXn8DCPDuoV/8M6Eh164/2AXMwouiHEgGd3F8KqBdzGdEJsOw8F+5yY/ rgYfKHNMaQYkVUmIjnqOMnshdJB684tN/HACavCgQNay9LcMi0cy4vKyHmr5vugBHCdZ YobYC3qblG+q8Q0ZK3NgTqw7bfdjhqh6hW5WY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691178690; x=1691783490; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=v9aXdoLhhoWclddSQ9L1lPeROamEoqrovytUyvBDf3w=; b=mIYrusz1TwyAncJwAjgSQtRmia6OQfqHrOMdeWw5ib841wrTEWNfAEXG+X7oVHL/kg yvObmWZdTm4PAnTm7Q5ZZ929RQRPCTkm7N5q+dcR7S8Lk92NexUldNaGGKb4a623SpSc 0GEJK8sOnN5+18W3ISC+t8xdHT2AN9aMLIhSahIjCS06rfDrNVeulPhAB5+upXG+2dAB LpEZgV+zlBogGSsriadCkYEJuxkAXummjcfS3eC9g+uw5J58bzXKUgr4mqjKC1kSKhSu 6F2tPL1tZByrY/rjkgW8pHEOB1BHq+I7mEfNnmRqVXSZpM1G+xd1fbMIKcog/V/Gkpyo Fj9A== X-Gm-Message-State: AOJu0Yz2Jj2k4ChGJ0nUm3aw/0SOnon/2Vk/awm2lLA3o1WkXBWO2W0w IzJRGO6lwe47p1nMWvckl/zp7OHn0EtEoGON0tvv/hLAnsMSiKrl X-Google-Smtp-Source: AGHT+IEYzP2BTr1aheT5dsSVlBgjSLzlD1pWgqHS6HRuAHTB8YMyMwyqBI67H7cZ2M3VBF0F0wL5lJyulloveWEax6o= X-Received: by 2002:a1f:4c01:0:b0:487:1729:1be6 with SMTP id z1-20020a1f4c01000000b0048717291be6mr1832020vka.7.1691178690075; Fri, 04 Aug 2023 12:51:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Clem Cole Date: Fri, 4 Aug 2023 15:50:54 -0400 Message-ID: To: Will Senn Content-Type: multipart/alternative; boundary="00000000000012f4e506021e398e" Message-ID-Hash: YRFB6AWSN3JXJF4J6IZRH2HWBNNVGYRT X-Message-ID-Hash: YRFB6AWSN3JXJF4J6IZRH2HWBNNVGYRT X-MailFrom: clemc@ccc.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: 3bsd tape image List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000012f4e506021e398e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable below... On Fri, Aug 4, 2023 at 1:17=E2=80=AFPM Will Senn wrot= e: > 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 hav= e > 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=E2=80=A0 files altoge= ther. The > first tape file contains boot- > strapping programs. The second tape file is to be put on one filesystem > called the =E2=80=98root filesystem=E2=80=99, 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=E2=80=A0 files altoge= ther. > > 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 =E2=80=98r= oot > filesystem=E2=80=99, 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 everythin= g > 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 =E1=90=A7 --00000000000012f4e506021e398e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
below...

On Fri, Aug 4, 2023 at 1= :17=E2=80=AFPM Will Senn <will.se= nn@gmail.com> wrote:
=20 =20 =20
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.=C2=A0 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=E2=80=A0 files altogether. The first tape file contains boot-
strapping programs. The second tape file is to be put on one filesystem called the =E2=80=98root filesystem=E2=80=99, 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=E2=80=A0 files altogether.
Refers to everything in 3bsd.tar.gz=C2=A0 - 4130 files.

And this:
The first tape file contains boot-strapping programs.
Refers to the files in sys:
I think not = sys but /stand=C2=A0
boot=C2=A0 mkfs=C2=A0 restor=C2=A0 rp6fmt=C2=A0 rpread
<= /blockquote>
And should have a boot block on it = - with the standalone system=C2=A0-- this is right from V7 and I= thought 32V=C2=A0but I have forgotten - BTW - this t= ape 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 =E2=80=98root filesystem=E2=80=99, and
contains essential binaries and enough other files to allow the system to run.
Right - th= e standalone=C2=A0system is used to create the root FS and=C2=A0= the standalone restore to recreate the root=C2=A0[it&= #39;s 20B or 10240 byte blocked] because by now you have a read device driv= er in either the standalone system or UNIX itself do blocking factors can b= e 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 su= ch 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 se= nse in that it allows everyone some one=C2=A0to read these two without havi= ng 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=C2= =A0if you only one want a couple of files/directors.=C2=A0 =C2= =A0Dump/restore is fine for a complete=C2=A0FS at a time.=
Given just the src and doc directories, wanting to read the doc an= d source from that tape on another system -- say 32V or V7, tar makes it ea= sier.

Clem
3D""=E1=90=A7
--00000000000012f4e506021e398e--