PDP-11 disk image question

[Bill Gunshannon]

On 2/18/19 4:35 PM, Paul Koning wrote:
> 
> 
>> 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.

Pretty much all of them.  :-)


> 
> 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.
> 
>> 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

And there is the problem.  If I had a kitI would  just do a clean
install on the 11/93.  :-)

> 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