18 Feb
2019
18 Feb
'19
1:35 p.m.
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.
If the input and output devices are the same size, and error free, image copy is always
valid. MSCP devices are error free; 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 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.
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.
paul