Discussion:
booting from newer SANS
Add Reply
p***@gmail.com
2020-12-11 00:02:44 UTC
Reply
Permalink
I have run into an issue where we brought in a Primera 630 all SSD drives and have it connected to a rx2660 (test) and a rx8640 (production)

I am running 8.4-1H1, and I am able to mount and shadow volumes between this and an EVA6400. the one thing I cannot get to happen is a boot from the Primera.

Loading.: SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
Load of SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D failed: Not Found
Press any key to continue

well I have been told that 8.4-1H1 is not supported on it and I would have to go to 8.4-2L1. which I did this evening to test it.

same message as above
and it was validated as it was under 8.4-1H1

Validate EFI Boot Options list: Timeout = 7 secs.
--------------------------------------------------------------------------------
3 SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D -fl 0,0
$1$DGA3010 PCI(0|3|0|0) Fibre(20310002AC026B0D,Lun2000000000000)
efi$bcfg: Option Validated. Success.

4 SSD Boot Device $1$DGA3010: FGA0.2131-0002-AC02-6B0D -fl 0,0
$1$DGA3010 PCI(0|3|0|0) Fibre(21310002AC026B0D,Lun2000000000000)
efi$bcfg: Option Validated. Success.

--------------------------------------------------------------------------------
2 entries validated.


the vendor would like to bring in a 3PAR 8400 next week for us to test.

I'm afraid we will have the same outcome.

any thoughts?

thanks
Paul
Jan-Erik Söderholm
2020-12-11 00:47:07 UTC
Reply
Permalink
Post by p***@gmail.com
I have run into an issue where we brought in a Primera 630 all SSD drives and have it connected to a rx2660 (test) and a rx8640 (production)
I am running 8.4-1H1, and I am able to mount and shadow volumes between this and an EVA6400. the one thing I cannot get to happen is a boot from the Primera.
Loading.: SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
Load of SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D failed: Not Found
Press any key to continue
well I have been told that 8.4-1H1 is not supported on it and I would have to go to 8.4-2L1. which I did this evening to test it.
same message as above
and it was validated as it was under 8.4-1H1
Validate EFI Boot Options list: Timeout = 7 secs.
--------------------------------------------------------------------------------
3 SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D -fl 0,0
$1$DGA3010 PCI(0|3|0|0) Fibre(20310002AC026B0D,Lun2000000000000)
efi$bcfg: Option Validated. Success.
4 SSD Boot Device $1$DGA3010: FGA0.2131-0002-AC02-6B0D -fl 0,0
$1$DGA3010 PCI(0|3|0|0) Fibre(21310002AC026B0D,Lun2000000000000)
efi$bcfg: Option Validated. Success.
--------------------------------------------------------------------------------
2 entries validated.
the vendor would like to bring in a 3PAR 8400 next week for us to test.
I'm afraid we will have the same outcome.
any thoughts?
thanks
Paul
Just a shot in the dark...
Does these SANs also require the "LUN-0" device to be available for
full VMS support? But I'm not sure if it is boot support specifically
that requires the LUN-0 to be defined...
p***@gmail.com
2020-12-11 01:00:53 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by p***@gmail.com
I have run into an issue where we brought in a Primera 630 all SSD drives and have it connected to a rx2660 (test) and a rx8640 (production)
I am running 8.4-1H1, and I am able to mount and shadow volumes between this and an EVA6400. the one thing I cannot get to happen is a boot from the Primera.
Loading.: SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
Load of SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D failed: Not Found
Press any key to continue
well I have been told that 8.4-1H1 is not supported on it and I would have to go to 8.4-2L1. which I did this evening to test it.
same message as above
and it was validated as it was under 8.4-1H1
Validate EFI Boot Options list: Timeout = 7 secs.
--------------------------------------------------------------------------------
3 SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D -fl 0,0
$1$DGA3010 PCI(0|3|0|0) Fibre(20310002AC026B0D,Lun2000000000000)
efi$bcfg: Option Validated. Success.
4 SSD Boot Device $1$DGA3010: FGA0.2131-0002-AC02-6B0D -fl 0,0
$1$DGA3010 PCI(0|3|0|0) Fibre(21310002AC026B0D,Lun2000000000000)
efi$bcfg: Option Validated. Success.
--------------------------------------------------------------------------------
2 entries validated.
the vendor would like to bring in a 3PAR 8400 next week for us to test.
I'm afraid we will have the same outcome.
any thoughts?
thanks
Paul
Just a shot in the dark...
Does these SANs also require the "LUN-0" device to be available for
full VMS support? But I'm not sure if it is boot support specifically
that requires the LUN-0 to be defined...
I have not seen that documented any where, not saying it's not the case, not sure giving it a LUN # was an option. I'll take a look.
p***@gmail.com
2020-12-11 15:11:49 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by p***@gmail.com
I have run into an issue where we brought in a Primera 630 all SSD drives and have it connected to a rx2660 (test) and a rx8640 (production)
I am running 8.4-1H1, and I am able to mount and shadow volumes between this and an EVA6400. the one thing I cannot get to happen is a boot from the Primera.
Loading.: SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
Load of SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D failed: Not Found
Press any key to continue
well I have been told that 8.4-1H1 is not supported on it and I would have to go to 8.4-2L1. which I did this evening to test it.
same message as above
and it was validated as it was under 8.4-1H1
Validate EFI Boot Options list: Timeout = 7 secs.
--------------------------------------------------------------------------------
3 SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D -fl 0,0
$1$DGA3010 PCI(0|3|0|0) Fibre(20310002AC026B0D,Lun2000000000000)
efi$bcfg: Option Validated. Success.
4 SSD Boot Device $1$DGA3010: FGA0.2131-0002-AC02-6B0D -fl 0,0
$1$DGA3010 PCI(0|3|0|0) Fibre(21310002AC026B0D,Lun2000000000000)
efi$bcfg: Option Validated. Success.
--------------------------------------------------------------------------------
2 entries validated.
the vendor would like to bring in a 3PAR 8400 next week for us to test.
I'm afraid we will have the same outcome.
any thoughts?
thanks
Paul
Just a shot in the dark...
Does these SANs also require the "LUN-0" device to be available for
full VMS support? But I'm not sure if it is boot support specifically
that requires the LUN-0 to be defined...
I have not seen that documented any where, not saying it's not the case, not sure giving it a LUN # was an option. I'll take a look.
and no it's not there to set... just to be sure I also did a
$ SET BOOTBLOCK /PRESERVE=SIGNATURES /I64 $1$DGA3010:

which didn't help either.
Stephen Hoffman
2020-12-11 15:24:26 UTC
Reply
Permalink
... Loading.: SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
... Load of SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
failed: Not Found
That command doesn't do what you think it does.

If you're concerned about mismatched boot signatures (and the boot
signature includes system disk files locations), remove and re-add the
device alias entry at EFI.

Or use the BOOT_OPTIONS tool with OpenVMS running (from optical or
otherwise), and remove and re-add the EFI device boot alias entry from
there.
--
Pure Personal Opinion | HoffmanLabs LLC
p***@gmail.com
2020-12-11 15:36:11 UTC
Reply
Permalink
Post by Stephen Hoffman
... Loading.: SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
... Load of SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
failed: Not Found
That command doesn't do what you think it does.
If you're concerned about mismatched boot signatures (and the boot
signature includes system disk files locations), remove and re-add the
device alias entry at EFI.
Or use the BOOT_OPTIONS tool with OpenVMS running (from optical or
otherwise), and remove and re-add the EFI device boot alias entry from
there.
--
Pure Personal Opinion | HoffmanLabs LLC
oh! interesting! I had found it the 8.4-2l1 install documentation and thought it might help if there was an issue with the backup/image I did,

thanks
Stephen Hoffman
2020-12-12 19:35:07 UTC
Reply
Permalink
Post by p***@gmail.com
Post by Stephen Hoffman
... Loading.: SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
... Load of SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
failed: Not Found
That command doesn't do what you think it does.
...
oh! interesting! I had found it the 8.4-2l1 install documentation and
thought it might help if there was an issue with the backup/image I did,
That command is intended to preserve the usefulness of an existing boot
alias, by preserving the existing signature. If the existing signature
wasn't working, preserving it is moot.

EFI prefers that the operating system to assign a new signature for
each device and for each partition. EFI boots partitions. OpenVMS knows
not of partitions and boots devices, whether newly installed or
restored. OpenVMS doesn't align with EFI expectations there, and
OpenVMS users tend to get cranky about having to remove and re-add boot
aliases, that either from EFI directly, or from BOOT_OPTIONS.COM tool.

With no partitioning support, OpenVMS hacks up a whole device by
creating between three and five partitions depending on file
alignments. This to avoid console-level operations clobbering storage
based on the expected partitioning map stored within GPT.

BACKUP, BTW, calls SYS$SETBOOTSHR, which is the underpinnings of SET
BOOTBLOCK, and of the SYS$SETBOOT tool.

To see some more information, invoke SYS$SETBOOT as a foreign command.
There's a simplistic partition-viewing and partition-reporting tool
available there, too. There are four interfaces available underneath;
CLD, RUN, foreign command, and callable API.

TL;DR: When EFI-based bootstraps go sideways, remove and re-add the
boot alias entry, and try again.
--
Pure Personal Opinion | HoffmanLabs LLC
p***@gmail.com
2020-12-14 21:09:20 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by p***@gmail.com
Post by Stephen Hoffman
... Loading.: SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
... Load of SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
failed: Not Found
That command doesn't do what you think it does.
...
oh! interesting! I had found it the 8.4-2l1 install documentation and
thought it might help if there was an issue with the backup/image I did,
That command is intended to preserve the usefulness of an existing boot
alias, by preserving the existing signature. If the existing signature
wasn't working, preserving it is moot.
EFI prefers that the operating system to assign a new signature for
each device and for each partition. EFI boots partitions. OpenVMS knows
not of partitions and boots devices, whether newly installed or
restored. OpenVMS doesn't align with EFI expectations there, and
OpenVMS users tend to get cranky about having to remove and re-add boot
aliases, that either from EFI directly, or from BOOT_OPTIONS.COM tool.
With no partitioning support, OpenVMS hacks up a whole device by
creating between three and five partitions depending on file
alignments. This to avoid console-level operations clobbering storage
based on the expected partitioning map stored within GPT.
BACKUP, BTW, calls SYS$SETBOOTSHR, which is the underpinnings of SET
BOOTBLOCK, and of the SYS$SETBOOT tool.
To see some more information, invoke SYS$SETBOOT as a foreign command.
There's a simplistic partition-viewing and partition-reporting tool
available there, too. There are four interfaces available underneath;
CLD, RUN, foreign command, and callable API.
TL;DR: When EFI-based bootstraps go sideways, remove and re-add the
boot alias entry, and try again.
--
Pure Personal Opinion | HoffmanLabs LLC
deleting it and adding it back in didn't make a difference, VSI now believes that the so called AH400 HBA is not a true AH400. Vendor is checking on this.
I've also asked the vendor to put on hold in bringing anything else in since this nay be the issue and nothing to do with the actual SAN.

thanks every one
p***@gmail.com
2020-12-23 19:08:14 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by p***@gmail.com
Post by Stephen Hoffman
... Loading.: SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
... Load of SSD Boot Device $1$DGA3010: FGA0.2031-0002-AC02-6B0D
failed: Not Found
That command doesn't do what you think it does.
...
oh! interesting! I had found it the 8.4-2l1 install documentation and
thought it might help if there was an issue with the backup/image I did,
That command is intended to preserve the usefulness of an existing boot
alias, by preserving the existing signature. If the existing signature
wasn't working, preserving it is moot.
EFI prefers that the operating system to assign a new signature for
each device and for each partition. EFI boots partitions. OpenVMS knows
not of partitions and boots devices, whether newly installed or
restored. OpenVMS doesn't align with EFI expectations there, and
OpenVMS users tend to get cranky about having to remove and re-add boot
aliases, that either from EFI directly, or from BOOT_OPTIONS.COM tool.
With no partitioning support, OpenVMS hacks up a whole device by
creating between three and five partitions depending on file
alignments. This to avoid console-level operations clobbering storage
based on the expected partitioning map stored within GPT.
BACKUP, BTW, calls SYS$SETBOOTSHR, which is the underpinnings of SET
BOOTBLOCK, and of the SYS$SETBOOT tool.
To see some more information, invoke SYS$SETBOOT as a foreign command.
There's a simplistic partition-viewing and partition-reporting tool
available there, too. There are four interfaces available underneath;
CLD, RUN, foreign command, and callable API.
TL;DR: When EFI-based bootstraps go sideways, remove and re-add the
boot alias entry, and try again.
--
Pure Personal Opinion | HoffmanLabs LLC
deleting it and adding it back in didn't make a difference, VSI now believes that the so called AH400 HBA is not a true AH400. Vendor is checking on this.
I've also asked the vendor to put on hold in bringing anything else in since this nay be the issue and nothing to do with the actual SAN.
thanks every one
update:
well after many attempts we are trying another HBA tonight. not sure it matters but in the EFI shell I was able to run "info all -a" "devtree" "pci" I don't see any mention of the 8Gb HBA, the 4Gb one is seen.
Marc Van Dyck
2020-12-11 16:09:31 UTC
Reply
Permalink
Post by p***@gmail.com
the vendor would like to bring in a 3PAR 8400 next week for us to test.
I can certainly confirm that this setup works. All our systems (25 of
them) boot from this disk array model and have done so since 2016 (was
from EVA before). We use both 8.4-2 and 8.4-2L1.
--
Marc Van Dyck
Loading...