Fired up the newly acquired MicroVAX II today. Twice in fact. First time just to see if it did anything at all. Which it did - power supply kicked in, hard drive span up, I could see lights on the cards.
Second time after connecting a console I fired it up whilst looking at the boot sequence LED on the back - went 9, 7, 6, 5, 4, 3, 2, then back to 8. It's possible the console wasn't connected properly - I think I should have seen the CPU model by this point on the console.
Then the magic smoke let go. Prime candidate for smoke release are the mains filtering capacitors, but I've not extracted the power supply so cannot be sure.
I'm getting a talent for blowing up power supplies these days...
Mark.
That worked! Thanks guys.
Sampsa
On 18 Sep 2011, at 15:29, Peter Coghlan wrote:
Actually,
I would use:
$ set default sys$system
$ mcr sysgen
use current
set startup_p1 ""
write current
exit
$ reboot
The original poster said it boots to a minimal DCL shell. That sounds like
a $ prompt to me. You get left at a $ prompt when SET /STARTUP has been set
to OPA0:. You don't get a $ prompt when STARTUP_P1 is set to "MIN" - you have
to log in as usual.
He also stated that entering @SYS$SYSTEM:STARTUP manually fixed the problem.
If STARTUP_P1 was set to "MIN" then entering @SYS$SYSTEM:STARTUP would not
undo its effects and he would be left back where he started.
It looks more likely to me that SET /STARTUP is the setting that has been
modified not the STARTUP_P1 parameter.
Rather than do a conversational boot, he could do:
$ mcr sysgen
use current
set /startup sys$system:startup.com
write current
exit
$ reboot
For some reason, that method did not occur to me earlier.
Regards,
Peter Coghlan.
Actually,
I would use:
$ set default sys$system
$ mcr sysgen
use current
set startup_p1 ""
write current
exit
$ reboot
The original poster said it boots to a minimal DCL shell. That sounds like
a $ prompt to me. You get left at a $ prompt when SET /STARTUP has been set
to OPA0:. You don't get a $ prompt when STARTUP_P1 is set to "MIN" - you have
to log in as usual.
He also stated that entering @SYS$SYSTEM:STARTUP manually fixed the problem.
If STARTUP_P1 was set to "MIN" then entering @SYS$SYSTEM:STARTUP would not
undo its effects and he would be left back where he started.
It looks more likely to me that SET /STARTUP is the setting that has been
modified not the STARTUP_P1 parameter.
Rather than do a conversational boot, he could do:
$ mcr sysgen
use current
set /startup sys$system:startup.com
write current
exit
$ reboot
For some reason, that method did not occur to me earlier.
Regards,
Peter Coghlan.
Actually,
I would use:
$ set default sys$system
$ mcr sysgen
use current
set startup_p1 ""
write current
exit
$ reboot
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Peter Coghlan
Sent: Sunday, September 18, 2011 08:42
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Noob question here: boot flags and such
I've set my boot_flags to 0,0 in SRM, but it boots to a minimal DCL
shell where I have to type @SYS$SYSTEM:STARTUP to get the ball rolling
How do I stop this?
At some point in the past, you probably did a SET /STARTUP OPA0: in a
conversational boot and omitted to do a SET WRITESYSPARAMS 0 afterwards.
To put things back the way they were, do another conversational boot
ie BOOT -fl 0,1
At the SYSBOOT> prompt, issue the commands:
SET /STARTUP SYS$SYSTEM:STARTUP.COM
CONTINUE
Next time you boot, you should get the full startup automatically.
Regards,
Peter Coghlan.
I've set my boot_flags to 0,0 in SRM, but it boots to a minimal DCL shell
where I have to type @SYS$SYSTEM:STARTUP to get the ball rolling
How do I stop this?
At some point in the past, you probably did a SET /STARTUP OPA0: in a
conversational boot and omitted to do a SET WRITESYSPARAMS 0 afterwards.
To put things back the way they were, do another conversational boot
ie BOOT -fl 0,1
At the SYSBOOT> prompt, issue the commands:
SET /STARTUP SYS$SYSTEM:STARTUP.COM
CONTINUE
Next time you boot, you should get the full startup automatically.
Regards,
Peter Coghlan.
Even more off topic topics. :)
A) I've gone and set CircleMUD up again. Running on a Solaris box at the moment but after we move I plan on getting the VAXen set up again at which point I'll move it to one of those. Mud.4amlunch.net port 4000. Prepare to be bored as there are no users yet. :)
B) If you've not seen Schemaverse yet I *highly* recommend checking it out. www.schemaverse.com. Quite possibly the craziest and coolest thing I've seen in a while. Space game you play in PostgreSQL.
That's my random whatever for the day. :)
-brian
On Sep 17, 2011, at 15:13, Sampsa Laine <sampsa at mac.com> wrote:
Speaking of masochism, I've released a pre-built VM with a very alpha version of my BBS, pyffle:
Pyffle BBS: http://www.uuhec.net/pyffle-bbs/
Demo version running: telnet://pyffle.sampsa.com
``
VM download (pretty big, for the seriously into UUUP etc enthusiastic): http://pyffle.org/dev_pyffle_v0.1_masochist_edition.zip
Sampsa
On 17 Sep 2011, at 19:22, Mark Wickens wrote:
On 17/09/11 19:21, Fred wrote:
Hi all:
I'd like to slap All-in-1 on my VAX. (yes, I'm a masochist)
Anyone have the kit available via HECnet? Or, alternatively you can deposit it on FRUGAL::
Thanks,
Fred
----
Lets call it for what it is - "legacy" is a term that people use in a
polite but derogatory manner to imply that the future direction they
prefer is not that which they view as the current direction.
ALLIN1 is fun!
As you say, for masochists.
I have it on SLAVE, I'll move it so it's available from the default account...
I will do as you suggest. I have a disk in the box itself which is where
the basis for the disk served by SLAVE comes from. So when I got to an
unbootable state I have had to restore the disk.
My good friend Malcolm suggested the following which is what worked with
me without having to autogen:
On 16/09/11 16:55, Malcolm Blunden wrote: Votes:
Why do you run Autogen afterwards? A change of votes doesn't
need any other change that I can think of. How are you changing the
votes? Do you understand the arcane use of CURRENT and ACTIVE by
SYSGEN? To set the votes to zero in a way that will apply at the next
reboot, do
$ MCR SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET VOTES 0
SYSGEN> WRITE CURRENT
SYSGEN> ^Z
That should fix it. Let me know if it doesn't work!
Malcolm is absolutely right. However, you may need to do an AUTOGEN at some
point in the future and it is good to have done one that has worked before
then so that there are no surprises.
(It should have been possible to get past the joining the cluster problem
by doing a conversational boot and setting VAXCLUSTER to 0 so that the
original problem could have been found and fixed rather than having to
recreate the disk)
Regards,
Peter Coghlan.
On 17/09/11 19:21, Fred wrote:
Hi all:
I'd like to slap All-in-1 on my VAX. (yes, I'm a masochist)
Anyone have the kit available via HECnet? Or, alternatively you can deposit it on FRUGAL::
Thanks,
Fred
----
Lets call it for what it is - "legacy" is a term that people use in a
polite but derogatory manner to imply that the future direction they
prefer is not that which they view as the current direction.
Fred,
You can find the kit here:
$$ backup/list SLAVE::DECUS$:[DECUS.VAX_MEDIA]A1032.SAV/sav
Listing of save set(s)
Save set: A1032.SAV
Written by: SYSTEM
UIC: [000001,000004]
Date: 17-SEP-2011 20:16:38.34
Command: BACKUP [.A1032...]*.*; [-]A1032.SAV/SAV
Operating system: OpenVMS VAX version V7.3
BACKUP version: V7.3
CPU ID register: 13000202
Node name: _BUBBLE::
Written on: _$255$DKA400:
Block size: 32256
Group size: 10
Buffer count: 8
On 17/09/11 20:22, Peter Coghlan wrote:
It's all working nicely, but this is before an AUTOGEN. If I may I'll
post the contents of the MODPARAMS.DAT and PARAMS.DAT to see if anyone
recognises something bad.
So, how did you get from where you were to where you are now? Have you
recreated the system disk and got back to the point before you did the AUTOGEN?
If so and you suspect AUTOGEN is going to mess things up again, then
I suggest you record the system parameters before and after the AUTOGEN
(AUTOGEN without the shutdown and reboot phases, that is) and compare them.
Something like this:
$ DEFINE /USER SYS$OUTPUT BEFORE.TXT
$ MCR SYSGEN
SHOW /ALL
SHOW /SPECIAL
^Z
$
$ @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS NOFEEDBACK
$
$ DEFINE /USER SYS$OUTPUT AFTER.TXT
$ MCR SYSGEN
SHOW /ALL
SHOW /SPECIAL
^Z
$
$ DIFF BEFORE.TXT AFTER.TXT
$
If everything looks ok, you can then reboot to get the new sysgen parameters
take effect. If not, you have an opportunity to fix things before the
shutdown and reboot makes things much more difficult to fix.
Regards,
Peter Coghlan.
Hi Peter,
I will do as you suggest. I have a disk in the box itself which is where the basis for the disk served by SLAVE comes from. So when I got to an unbootable state I have had to restore the disk.
My good friend Malcolm suggested the following which is what worked with me without having to autogen:
On 16/09/11 16:55, Malcolm Blunden wrote: Votes:
Why do you run Autogen afterwards? A change of votes doesn't need any other change that I can think of. How are you changing the votes? Do you understand the arcane use of CURRENT and ACTIVE by SYSGEN? To set the votes to zero in a way that will apply at the next reboot, do
$ MCR SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET VOTES 0
SYSGEN> WRITE CURRENT
SYSGEN> ^Z
That should fix it. Let me know if it doesn't work!
- Malcolm.
It's all working nicely, but this is before an AUTOGEN. If I may I'll
post the contents of the MODPARAMS.DAT and PARAMS.DAT to see if anyone
recognises something bad.
So, how did you get from where you were to where you are now? Have you
recreated the system disk and got back to the point before you did the AUTOGEN?
If so and you suspect AUTOGEN is going to mess things up again, then
I suggest you record the system parameters before and after the AUTOGEN
(AUTOGEN without the shutdown and reboot phases, that is) and compare them.
Something like this:
$ DEFINE /USER SYS$OUTPUT BEFORE.TXT
$ MCR SYSGEN
SHOW /ALL
SHOW /SPECIAL
^Z
$
$ @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS NOFEEDBACK
$
$ DEFINE /USER SYS$OUTPUT AFTER.TXT
$ MCR SYSGEN
SHOW /ALL
SHOW /SPECIAL
^Z
$
$ DIFF BEFORE.TXT AFTER.TXT
$
If everything looks ok, you can then reboot to get the new sysgen parameters
take effect. If not, you have an opportunity to fix things before the
shutdown and reboot makes things much more difficult to fix.
Regards,
Peter Coghlan.
