[Info-vax] I64 generic drive boot pointer w/o embedded GUID?

[Stephen Hoffman]

On 2019-11-29 12:41:29 +0000, Rod Regier said:

> Since my area of interest is BACKUP /IMAGE for backup and restore...

BACKUP /IMAGE won't work.  This because BACKUP /IMAGE inherently moves 
structures around, and again because this is more than the GUID as 
other details including the boot partition size and the partition 
sector address are also included in the EFI boot aliases.  There was 
work in BACKUP to place the GPT structures, and BACKUP calls into the 
sys$setbootshr API to write the boot sectors.  (The sys$setboot 
commands and the sys$setbootshr API can read and write boot blocks for 
all three architectures. But I digress.)

BACKUP /PHYSICAL probably will work as it doesn't relocate structures, 
though you'll want to test that.  If you go this route, you'll 
absolutely want volume expansion enabled on your master.

There used to be a weirdness here around dynamic volume expansion and 
the GPT structures.  I don't recall off-hand if that's been addressed; 
if the secondary GPT is moved to the highest addresses of the volume 
when the volume is expanded.

> the alternatives appear even more complicated than simply using 
> standalone execution of BOOT_OPTIONS to update as needed.

Having spent a whole lot of time in BOOT_OPTIONS again over the past 
couple of months, that tool is just really clunky.  But it works, and 
works well enough, for what it does.  The lack of menuing support for 
scripting and/or DCL apps strikes anew, with every damned menu around 
OpenVMS and layered products and apps all implemented differently, too. 
 But I digress.  You'll probably want to lengthen the boot timeouts, 
too.

> Fortunately it's rare I need to perform restores.

Fortunate?  That rarity is actually rather unfortunate. That means 
you're going to have less experience and less practice with the 
sequence, and there'll undoubtedly be the usual pressure to quickly 
recover.

And—as I've stated various times, and having told several different 
bunches here recently—that we're not re-installing OpenVMS regularly is 
arguably a mistake in all of our processes and practices.

> My largest area of interest for this would be onsite cold server spares 
> and on-demand delivered server spares from offsite.

I use completely different approaches for that.  And I'd have the spare 
warm at least periodically, as I've had a few cold spares go catatonic 
when needed.

> In a perfect world, those units would be pre-configured so that the 
> drives from a failed server could simply be moved over to the 
> replacement server w/o any special setup.

Use an external storage array and re-cable it as needed, and stuff a 
couple of pre-installed OpenVMS volumes into the server.

The "proper" approach here is of course clustering, but DEC 
short-sightedly decided long ago that the use of one of its best 
competitive lock-ins was never to be encouraged for the majority of its 
customers.

> I can achieve that for Alphaservers plus OpenVMS, but the GUID 
> interlock for the Integrity servers makes it an apparently impractical 
> proposition :-(

Whether the work is impractical is your call, but yes, you're going to 
have to do some work to get where you want here.  This as described in 
the previous reply with a hunk of bootable optical media to 
"consecrate" the newly-installed or re-installed configuration, or as 
described above.

There's certainly fodder here for VSI to work on enhancements, too.  
EFI is inherently getting updated with the x86-64 port, but we're still 
dealing with it for the foreseeable future, including the folks 
(eventually?) migrating to x86-64 from AlphaServer.  There's a new boot 
manager that's been occasionally discussed by VSI.  Whether that 
follows the path of one of the other vendors that's using a 
vendor-specific front-end on EFI (and which was arguably the whole idea 
behind EFI, though that whole concept was long ago lost), or if the new 
VSI boot manager heads off in some other or new direction, we shall 
learn.


-- 
Pure Personal Opinion | HoffmanLabs LLC