18 Feb
2019
18 Feb
'19
2:24 p.m.
On 2/18/19 4:35 PM, Paul Koning wrote:
Pretty much all of them. :-)
On Feb 18, 2019, at 3:46 PM, Bill Gunshannon via
cctalk <cctalk at classiccmp.org> wrote:
SO, to start a wrap up on this topic. I had heard of people
copying images made on SIMH to real disks and using them. It
now seems there are some serious strings attached to that idea.
I know it works for small disks as I have done it with RL02
and RX/Ry disks.
I'm not sure which comments you're replying to.
For the case of RSTS, small or large is not a consideration. What matters, as I
mentioned, is that RSTS has a file system layout that is dependent on the device size. So
(unlike some other file systems like FAT32) is isn't always valid to do an image copy
from one device to a larger device.
My reference to small vs. large had to do with moving images from
SIMH virtual disks to real physical disks. I have done it with
small disks which means the physical format of the virtual disk
in SIMH does, in fact, match the format of a\real equivalents.
At least for smaller disks. I am fairly certain I have heard of
people doing it with RQ disks as well. This was my first foray
into trying to do it with something the size of an RA disk.
Theoretically, the SIMH emulated RA81 and the CMD emulated real
disk RA81 should be the same size because they are both supposed
to be RA81's.
If the input and output devices are the same size, and error free, image copy is always
valid. MSCP devices are error free;
All of this sounds good on paper, but so far I have had no luck
actually accomplishing it. I have tried copying with different block
sizes, copying from different media used to move the image. The results
are always the same.
some older devices are also normally error free (like
RK05 or RP03).
It would be interesting if you can post the exact sizes in blocks of the SIMH image, and
the real disk you copied it to. That would help confirm my guess that it's a size
issue.
If it's a size issue then one of them is doing it wrong because the
size of an RA81 constant.
If that's not the answer, it would be possible to
use INIT ODT to catch the error and analyze what specifically it's unhappy about, but
that's not straightforward.
If you do have a size mismatch, fixing thatbefore you retry would be a good thing.
And there is the problem. If I had a kitI would just do a clean
install on the 11/93. :-)
Too bad there is not some form of Standalone
Backup like
VMS has. I am open to any suggestions about how one can
get RSTS installed on real hardware when no usable tape
drive is available. I don't suppose that hidden deep
in the bowels of RSTS is a procedure for making Installation
Kits on various media like Ultrix-11 has.
RSTS doesn't have any released mechanisms for creating installation kits. Those
scripts existed on the RSTS development systems. Possibly they can be found in source
kits (which are rare).
In the early days, RSTS came with a standalone image backup program: ROLLIN. Around V6
that was replaced by a file system aware standalone backup program: the SAVRES option in
INIT. That was retired in V9 when the new fast BACKUP program was released.
The reasoning here is that standalone backup isn't a feature -- instead, the feature
is a way to do a full system restore starting from a dead system. RSTS does this by
copying a few minimal features from the installation device: INIT.SYS, a monitor (such as
SYSGEN.SIL), DCL, BACKUP, and perhaps one or two other files. Then you start that minimal
system and issue a RESTORE command to restore everything from your backup. So there is no
need for the maintenance headache of a "standalone" backup tool. SAVRES had a
pile of hairy bugs and major maintenance headaches, and making a standalone PDP11 tool do
streaming tape support was just way too painful. That's why V9 went the route of
doing everything with BACKUP, since that's where the streaming support was added.
The steps for bare metal restore go roughly like this:
1. Boot a kit 2. Use the DSKINT option to initialize the output
disk
3. Use the COPY option to copy the minimal files to the output disk, which is then
booted.
4. Start that minimal system on the output disk.
5. Use RESTORE to copy everything from your backup.
I don't remember if there is a documented procedure for creating a minimal kit. For
disk based ones, it's pretty simple:
a. Initialize the kit device as read-only.
b. Mount it, overriding the read-only setting.
c. Copy the minimal files.
d. Hook INIT.SYS.
e. To test it, boot the kit; it should boot correctly and act as a kit (by offering to
copy to the output device rather than by going to the usual INIT prompt).
You can do this for any RSTS disk that's big enough, and for which INIT still has a
boot loader. For example, even in V10.1 you can boot an RK05, so you can make an RK05
kit.
If the device isn't big enough for all the minimal files, it gets a bit tricky but it
still can be done; the Micro-RSTS RX50 based kit is an example. I don't have the
details at my fingertips but I can dig them out if needed.
Well, this sounds like the most interesting and possible way.
If it cold be done on RX50's it should be doable on other
media. Maybe RX33 or maybe even TU58. (Emulated, of course!)
I haven't given up yet but it is turniong out to be a lot more
of a challenge than I expected. I wonder what the chances are
I could get something like an RD31 or RD33 to work and use it as
an intermediate for the big disk setup? Good thing it's only
a hobby cause I certainly can't see anyone paying me to do this
kind of stuff.
bill