Bypass mount/system request at boot time? - VMS

This is a discussion on Bypass mount/system request at boot time? - VMS ; On Oct 18, 9:42*am, VAXman- @SendSpamHere.ORG wrote: > In article , PR writes: > > >{...snip...} > >(2) Doing a conversational boot under IA64 is slightly more complex > >than under Alphas, and though I had the instructions, > > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

Thread: Bypass mount/system request at boot time?

  1. Re: Bypass mount/system request at boot time?

    On Oct 18, 9:42*am, VAXman- @SendSpamHere.ORG wrote:
    > In article <634e7f9c-502b-4099-a7bf-62c72a74d...@k16g2000hsf.googlegroups..com>, PR writes:
    >
    > >{...snip...}
    > >(2) Doing a conversational boot under IA64 is slightly more complex
    > >than under Alphas, and though I had the instructions,
    > > * * *it was far easier to have them pull the drive (sqeeze the latch,
    > >pull out the lever, and pull gently till it moves 3 inches...

    >
    > Huh? *
    >
    > I have aliases established on my Itanium for boot:
    >
    > Shell> alias
    > * * b * *: fs0:\efi\vms\vms_loader.efi
    > * * bo * : fs0:\efi\vms\vms_loader.efi
    > * * boo *: fs0:\efi\vms\vms_loader.efi
    > * * boot : fs0:\efi\vms\vms_loader.efi
    >
    > So booting would be no different than on Alpha:
    >
    > IA64: Shell> boot -flags 0,1
    > ALpha: >>> boot -flags 0,1
    >
    > You could probably just define an alias such as 'conboot' to simplify the
    > conversation booting of the Itanium. *
    >
    > I have also added items to the boot menu. *Each of my 3 drives contain a
    > version of OpenVMS Itanium (V8.2, V8.3 and V8.3-1H1). *I have menu items
    > for each version as well as conversational variants. *I almost never use
    > them as I have the EFI Shell [Built In] defined first, so the system will
    > always drop to the Shell> prompt.
    >
    > Save for the obnoxious 'chalkboard' color scheme of the Itanium console,
    > I don't find it anymore difficult than that of the Alpha SRM.
    >
    > --
    > VAXman- A Bored Certified VMS Kernel Mode Hacker * * *VAXman(at)TMESIS(dot)COM
    >
    > ... pejorative statements of opinion are entitled to constitutional protection
    > no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)
    >
    > Copr. 2008 Brian Schenkenberger. *Publication of _this_ usenet article outside
    > of usenet _must_ include its contents in its entirety including this copyright
    > notice, disclaimer and quotations.


    Client site Brian- the default boot item in the EFI is to boot the
    normal VMS system. No operator intervention involved, no other obvious
    options available. I think I will come up with a boot option to do
    as you suggest though.

    I wish there was a way to password protect boot options, then I could
    label it 'MAINTENANCE LOGIN - PASSWORD REQUIRED' or something like
    that.

    You would feel right at home on my development systems though.


  2. Re: Bypass mount/system request at boot time?

    In article , PR writes:
    >On Oct 18, 9:42=A0am, VAXman- @SendSpamHere.ORG wrote:
    >> In article <634e7f9c-502b-4099-a7bf-62c72a74d...@k16g2000hsf.googlegroups=

    >..com>, PR writes:
    >>
    >> >{...snip...}
    >> >(2) Doing a conversational boot under IA64 is slightly more complex
    >> >than under Alphas, and though I had the instructions,
    >> > =A0 =A0 =A0it was far easier to have them pull the drive (sqeeze the la=

    >tch,
    >> >pull out the lever, and pull gently till it moves 3 inches...

    >>
    >> Huh? =A0
    >>
    >> I have aliases established on my Itanium for boot:
    >>
    >> Shell> alias
    >> =A0 =A0 b =A0 =A0: fs0:\efi\vms\vms_loader.efi
    >> =A0 =A0 bo =A0 : fs0:\efi\vms\vms_loader.efi
    >> =A0 =A0 boo =A0: fs0:\efi\vms\vms_loader.efi
    >> =A0 =A0 boot : fs0:\efi\vms\vms_loader.efi
    >>
    >> So booting would be no different than on Alpha:
    >>
    >> IA64: Shell> boot -flags 0,1
    >> ALpha: >>> boot -flags 0,1
    >>
    >> You could probably just define an alias such as 'conboot' to simplify the
    >> conversation booting of the Itanium. =A0
    >>
    >> I have also added items to the boot menu. =A0Each of my 3 drives contain =

    >a
    >> version of OpenVMS Itanium (V8.2, V8.3 and V8.3-1H1). =A0I have menu item=

    >s
    >> for each version as well as conversational variants. =A0I almost never us=

    >e
    >> them as I have the EFI Shell [Built In] defined first, so the system will
    >> always drop to the Shell> prompt.
    >>
    >> Save for the obnoxious 'chalkboard' color scheme of the Itanium console,
    >> I don't find it anymore difficult than that of the Alpha SRM.
    >>
    >> --
    >> VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)TME=

    >SIS(dot)COM
    >>
    >> ... pejorative statements of opinion are entitled to constitutional prote=

    >ction
    >> no matter how extreme, vituperous, or vigorously expressed they may be. (=

    >NJSC)
    >>
    >> Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet article =

    >outside
    >> of usenet _must_ include its contents in its entirety including this copy=

    >right
    >> notice, disclaimer and quotations.

    >
    >Client site Brian- the default boot item in the EFI is to boot the
    >normal VMS system. No operator intervention involved, no other obvious
    >options available. I think I will come up with a boot option to do
    >as you suggest though.


    You can add multiple items. The first one is the one that the console
    times out on and executes. If someone has console access, then, after
    the initial system checks, the menu would appear. Simply arrow down to
    the conversation boot and hit enter. This does NOT affect the default
    boot configuration now in place.


    >I wish there was a way to password protect boot options, then I could
    >label it 'MAINTENANCE LOGIN - PASSWORD REQUIRED' or something like
    >that.
    >
    >You would feel right at home on my development systems though.


    OK. Let me at 'em!

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  3. Re: Bypass mount/system request at boot time?

    On Fri, 17 Oct 2008 21:14:39 -0500, David J Dachtera
    wrote:

    >none wrote:
    >>


    >> >

    >>
    >> I'd just like to point out, perhaps unnecessarily, that if the error
    >> is, in fact, a fatal error on the mount (i.e., "-F-"), then the
    >> startup process is not actually stalling or hanging on the mount
    >> request.
    >>
    >> Fatal errors in startup tend to actually *kill* the startup process,
    >> and there is no continuing from that as the job controller will not
    >> start; and you will never get to login. [snip]

    >
    >Actually, the JBC -DOES- start. However, little-known fact: until a SET
    >LOGINS/INTER=n command is issued at least once, JBC will NOT create
    >interactive processes. THAT is why you can't login if STARTUP bombs out
    >before SYSTARTUP_* completes.
    >
    >This is true for hard-wired terminals, CTERM, LAT and UCX/Telnet. Not
    >sure about SSH - never had a chance to test it.
    >
    >The exception is Telnet in Multinet. For Telnet sessions, the
    >MULTINET_SERVER process is the parent of the interactive Telnet
    >sessions. It WILL allow logins as soon as it starts, and is not aware
    >that STARTUP failed. (Not sure about TCPware - never had a chance to
    >test it.)
    >


    Ah, yes, now I recall more clearly. Sorry about that initial
    misinformation, my memory is not as good as it used to be.

    *sigh*.... I really miss being able to manage VMS systems.

    -- jls

  4. Re: Bypass mount/system request at boot time?

    In article <0f71d7a7-45cf-4f1a-8caa-24a40e8a77a2@b31g2000prf.googlegroups.com>, PR writes:
    > I have a remote client that has somehow gotten himself into a mess,
    > and I'm not sure how to get them out of it remotely.
    >
    > They hired a consultant to come in an "work on the network." This -
    > ah - "brilliant person" apparently convinced them he just had to
    > reboot the 2660.
    >
    > He booted the 2660 system with a Linux DVD and somehow or another,
    > managed to format the second drive (used for data storage) with
    > Linux. How is beyond me...


    Because a Linux install disk very early on wants to create one or
    more Linux partitions for you. A VMS disk has no partition table,
    so to the 'expert' this must mean it has no data on it. Voila! Safe
    to write a partition table to it, and, at the very least, a Linux
    swap partition.

    None of which you need to do if you know how to escape out of the
    Linux install (select an alternate console) and go straight to a root
    prompt.

    Not that Linux would be any help diagnosing a VMS system anyway.

    --
    George Cornelius cornelius A T eisner D O T decus D O T org
    cornelius A T mayo D O T edu

    > Anyway, I'm a good 500 miles away from this server physically, and
    > there is a mount/system command in the systartup_vms.com file to mount
    > this noe Linux formatted disk. Which obviously won't mount.
    >
    > The system boot stalls at this mount request. I think I might be able
    > to put an /ASSIST qualifier in there and cancel the mount, but I have
    > to get past the mount request to do that.
    >
    > Is there any easy way around this? Will just pulling the drive enable
    > it to bypass?
    >
    > I'm overnighting a freshly formatted drive that will mount, but if I
    > can get this production box
    > up tonight, it would be a nice thing.
    >
    > Sneaky tricks invited.



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2