Thanks Antonio, good info and more Q's
From what I've read, creating a bootable CD for a
VAX consists of
essentially building a bootable file system on a 650m hard drive,
reading that drive into a binary image, and writing that image to
a CD.
That might work. It will give you something bootable but you
would normally need to do some VMS tweaking to persuade
it that the system disk is not writeable. Might not be
necessary beyond V7 or so since I believe that the latest
VMS distribution CDs are directly bootable (from [SYS1] iirc).
I left out an important point - I'm really only interested in booting
stand-alone backup off of the CD.
I successfully did this under the simulator since my last message.
I couldn't figure out how to make stand-alone backup write to a saveset
on a disk drive - It kept telling me that I had to have only a device
name in the destination. I had hoped that I could just install stand-alone
backup on a blank disk and then use it to create it's own saveset from
the system disk...
So I did:
Mounted a scratch disk on DUA1
Stand-alone backuped/image DUA0 (the boot disk to DUA1) - Now DUA1
is a copy of the system disk.
Rebooted to DUA0, then used live BACKUP to backup/image DUA1 to
a file called SYSTEM.SAV on DUA0 (There's lots of space)
INIT/index=beginning DUA1:
[I used /index=beginning to put the storage allocation information
at the beginning of the CD so it wouldn't have to keep seeking out
to the middle - Other than that, I assume it would work without it.]
Then I used @stabackit to install stand-alone backup to DUA1:,
then I copied SYSTEM.SAV to DUA1:[000000]SYSTEM.SAV
Shutdown and attached the file formerly on DUA1 to SIMH as a CDROM,
then booted from the CD - stand-along backup came up and I was able
to restore SYSTEM.SAV to another virtual disk, then boot that disk
and it all worked.
Next step is to get an image of my VMS 5.5 drive (probably DD under
netbsd and then FTP it over) and see if I can do it again - once that
works, I'll try and burn a physical CD.
This created a
file 1,047,094,272 bytes in size. Looking at this
I assumed that SIMH must "format" the entire drive when you first
write to it (the file didn't exist until I installed OpenVMS).
drive ... Q1: Anyone know for sure - I would like
to have an
understanding of exactly what is going on?
I don't know what SIMH does: it might well extend as needed.
Do you know a reason why VMS would write that "high" on the drive
during a simple restore (minimal system) and subsequent boot. I
know it would put dir/maps in the middle, but this is a fair way
above the middle.
Checked the
OpenVMS.ISO file that I got from Nero and it was
681,578,496 bytes in size. /512 gives me 1331208. Creating the
virtual DUA2: with this number of blocks worked! - I could
mount and read the CD image as a normal drive.
Q2: Why the large discrepancy between the actual
size of the
CD file and the # blocks reported by SHOW DEV
Now I'm confused. Your CD is 650MiB or so. That works out
to about 1331200 blocks (as you calculated). Can you post
the actual SHOW DEVICE DUA3:/FULL output?
I don't know if I can capture the output of SIMH, but I will
try to do this on a real vax later today and capture the output.
I didn't do /FULL, this was just the #blocks listed in the short
listing.
ANALYZE/DISK
DUA2: reported that the size of the bitmap was
smaller than the physical device (but no other errors except
for "no QUOTA file"). Q4: Why?
No Quota file is because you have no quota file. You don't need one BTW.
I guessed as much.
Reducing the
size of the virtual hard drive to 1331200 blocks
resulted in DUA2 behaving exactly like DUA3 (mounts OK, read
files OK, no longer reports "bitmap too small", does report the
same "Invalid storage control block, RVN 1")...
I'm assuming that you're image and your physical disk size don't
match. I can only think that somewhere along the line you've
misread the output of SHOW DEVICE.
No SHOW DEV involved - the 1331208 number came by dividing the actual
size of the CD image file by 512. - Just looking to understand why it
behaves differently - Perhaps SIMH adjusts the blocksize somehow, so
this is not the actual size of the disk created.
You can do this. Given a large enough spare disk I
would go the
LD device route. Create a logical disk of an appropriate size
on your spare disk, lets callit LDA1:. INIT LDA1:, do an image
backup of your source disk onto LDA1:, dismount LDA1: and disconnect
from LDDRIVER. FTP to PC. Burn to CD.
Wouldn't this result in trying to boot a full image on the CD (although
I could specifically boot stabackup assuming it's on the image). My
goal was to put stabackup and a save set on the CD.
I have quite a
few SCSI drives which are slightly larger than the
1.06g limit ... 1.08 and 1.09 - I've checked, and they do exceed
the original SCSI command set addressing by a few thousand blocks.
I understand that this is a problem for my 3100 series VAXen ...
Is there a way to intentionally initialize a drive with a specific
size (in this case slightly smaller than it's actual size).
This limitation only comes into play if you try to boot from the
disk in question. The limitation applies only to the console drivers
in EPROM used to boot the system (and also to take write a crashdump).
Once OpenVMS is running it will quite happily access data disks of
up to some number of terabytes ... I've used a 9GB drive on a
VAXstation 3100 M76.
If you really do mean you want to boot from a disk that exceeds the
1.073GB limit and you really do have a system that is limited
(any VAXstation 3100 and the early MicroVAX 3100 M10/20 and that's
all iirc), then there are some tricks.
Yes, I really do mean it - I have two 3100 series machines which suffer
from the limitation, and I want to put 1G drives in
them - but all of
my 1G drives are "just a little too big". Please
elaborate on the "tricks".
This would
also be useful to be able to do when creating a drive
to be put on CD.
I'm not sure how you expect to fit a 1GB drive onto a 650MB CD.
Do you mean you just want to install a new system disk
temporarily?
What I mean is that I want to create a 650M image to burn to the CD,
however I don't have any 650M drives - I've got LOTS of 1G drives,
so if I could mount them smaller (650M or less) I could create a
filesystem on them that will fit on a CD.
But I don't think it really matters - What I will probably do is
transfer an image of the drive to SIMH where I can then perform a
backup of it to a virtual disk which can be any size I want.
Q: Is stand-alone backup from OpenVMS 7.x compatible with older
version filesystems? - If I backup my VMS 5.5 disk using stabackup
from 7.2, and restore it with same, will I get a
workable VMS 5.5
system disk again? I haven't tried booting 5.5 under SIMH yet
- If
for some reason it doesn't work, then I may need to do this with
the OpenVMS utilities.
Thanks again,
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools:
www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html