29 Oct
2001
29 Oct
'01
8:58 a.m.
Gunther Schadow wrote:
I did try MUB0 (because that's how VMS calls it for me), but
that doesn't work. I just like VMS calls my disk DUA0 but to
boot from it I have to call it just DU0. So MU0 it should be.
The CSA1 is weird, because it's really MUC6 for VMS, and it
should be another MU.
The console's idea of a device
name and VMS's idea of a device
name will not always agree.
For MSCP SDI disks (like your RA90)
the device name will usually be DUAn:,
where n: is the unit number you have
given it. OpenVMS will sort out how
to get from that unit number to a specific
path to the device (possibly hanging off a CI
rather than on your local machine!)
The console usually does not bother with such
shenanigans. It wants you to tell it how to find the
device. For example, on a VAX 82x0/83x0 box you
would boot as:
B DUsn:
where s is something like the VAXBI slot
number in hex, and n is the unit
number (also in hex IIRC). Of course
if you put your KDB50 in slot ten then you can do:
B DUAn:
but that just hides the difference :-)
Once VMS boots you can do:
$ MC SYSGEN
A A /L
(that's AUTOCONFIGURE ALL /LOG)
and it will go off and find most things.
Then SHOW DEVICE D will list the disks
(really any device that starts with D) and
SHOW DEV M will show the Magtapes.
The Console Storage device (CS) is
generally not visible without being explicitly
made so via SYSGEN, so it will generally
not show up.
Yes, that would be the crucial question? Can you even
boot from
TU81+. Given the rest of the orthogonal DEC design, I would be
highly surprized if one could not. Also, I'm pretty sure that
BSD used to be distributed on 9-track, bootable, presumably. But
I would appreciate a confirmation of this. If someone could test
copying a bootable TK to TU and then try TU booting?
I don't know whether the VAX 6000 can cope with
booting from TU81+, nor do I know what, if any,
controller support it expects for a device to be bootable.
(I don't know how much of a boot driver is
implemented in the console and how much needs
to be provided by the controller).
If you do want to backup your system disk, the steps
are as follows:
1. Install standalone backup on the system disk.
$ @SYS$UPDATE:STABACKIT SYS$SYSDEVICE:
This *should* (if I've remembered it correctly) create
a standalone backup in root SYSE (i.e.
$ DIR SYS$SYSDEVICE:[SYSE]
should now have something in it ... don't
mess or delete any of this though, most of
it is effectively symlinks to stuff that matters!)
2. Boot as normal but with R5's top byte set to E,
typically /R5:E0000000 should do this for you.
3. Standalone Backup should come up in
a few minutes rather than a few hours!
4. $ BACKUP/IMAGE/VERIFY/IGNORE=LABEL SYS$SYSDEVICE:
mua0:SYSTEM.BCK /SAVE
mua0: is whatever the tape device wants to be called
(MUB0:,
MUB1: CSA1:, whatever).
SYSTEM.BCK is just the saveset filename
/IGNORE=LABEL means "I don't care how valuable that
tape is, I know what I'm doing so wipe it!!"
/VERIFY means it will take twice as long but there
is a possibility that you may be able to restore the
data one day :-)
It's been a while, so this probably won't work first time.
Antonio