[Info-vax] Error mounting system device after cluster creation

[Stephen Hoffman]

On 2019-07-08 09:54:31 +0000, hb said:

> On 7/7/19 6:20 PM, Stephen Hoffman wrote:
>> %SYSINIT-E-FAIMOUBOO, failed to mount system bootstrap storage device
>> -SYSINIT-I-FORMORINF, for more info, use HELP /MESSAGE %x007280B4
> 
> You probably mean "HELP /MESSAGE /STATUS=%X007280B4"

Looking at that, the OpenVMS syntax tends toward wordy-arcane rather 
than short-arcane, doesn't it?

I'd prefer having that error message and recovery text displayed here 
without needing to find a working OpenVMS box and entering the HELP 
/MESSAGE command, too.

But yes, whatever the DCL syntax for that is.

> And one could dream of getting to a command line prompt to fix the 
> problem, something like busybox, when this happens on Linux.

Or the Recovery environment of macOS, which provides for GUI-based 
recovery, reinstallation, restoration, and repair tools available, 
and—as would be helpful in this case—provides a path to allow the user 
to get help online, and can be booted either locally or booted over the 
internet.  Downloading macOS over the internet from Apple servers is 
now routine, for instance.  Remote MOP and InfoServer, in OpenVMS 
terminology.

https://support.apple.com/en-us/HT201314

Or something I'd not expect to find from OpenVMS, save the boot-time 
errors in some scratch area, and have the bootstrap or have the 
recovery able to toss some YAML containing the error at VSI, and get 
back some recovery YAML from remote servers.  Or from other OpenVMS 
servers on the local network, for that matter.

OpenVMS—for once having started out with some of the most advanced 
networking available and once routinely used to connect disparate 
computers—has unfortunately fallen behind what's common in this era.  
That gap then pops up all over the place, including in the bootstrap 
and recovery environments, crash logging and recovery, telemetry, 
software patch installation, and various other areas.

>> Why not display the translated output for the code?  The boot 
>> environment is limited in what it can do and what gets dragged along 
>> here.  Not that embedding the error messages is a particular problem in 
>> this current era and not that the EFI/UEFI boot environment isn't 
>> vastly more capable than the old home-grown stuff from earlier eras, 
>> but what the boot environment could do and what it could reasonably 
>> drag along was once limited.  The developer tossed out what they 
>> thought was a pretty good message at the time, too.
> 
> SYSINIT is the first user mode* program activated during system start. 
> That's long after any EFI/UEFI boot code ran. But it is activated 
> before the file system and RMS are initialized. So it is limited in how 
> and what it can access on the boot disk.

Us OpenVMS folks do love our arcana.

But which end-users care whether this is martian-mode code invoked from 
the gonzo-cookie-monster mode, or part of the universally extremely 
fuzzy interface?  It's a bad error.  It's always been a bad error.

Pragmatically, I'd like to have the system boot, and if it didn't boot 
then tell the user why and what to do about it.  And without having to 
wade through hundreds of lines of noise from a normal bootstrap.

None of this bootstrap stuff was architected for ease of use nor for 
manageability nor for automation, and what's presently available here 
is decades of accretion.

> * Activated in user mode but most of its code is running in inner modes.

The existing bootstrap environment is an under-documented and 
overly-chatty and generally user-hostile morass that experienced and 
long-time OpenVMS users tend not to see.

There's vastly more spew and chaff from any of the consoles and from 
the startups than should ever be displayed too, and EFI certainly part 
of that problem.

Whether it's the EFI stuff, or the older home-grown stuff, it's a mess.

ps: And as for the Alpha and VAX consoles mentioned in another reply 
here, that's the "old home-grown stuff from earlier eras".



-- 
Pure Personal Opinion | HoffmanLabs LLC