IA64 VMS 8.3 Boot DVD

[R. Verkerk]

Hello,
we are trying to create our own bootable VMS DVD's.
We do following:
- create a ld device
- mount it foreign
- backup/image a system disk to it
- dismount lda device
- mount/over=id lda device
- set bootblock/bootblock=2048 /ia64 lda100:[vms$common.sys$ldr]sys$efi.sys
- dismount lda device

copy lda device and burn a DVD on a system.

The device is not boottable. We see no fs in the EFI shell.

Has anybody seen this working before??

greetings,

Robert Verkerk

[Ian Miller.]

is the cluster factor of the disk you a copying a multiple of 4?

Have you read
http://h71000.www7.hp.com/wizard/wiz_9820.html

[Volker Halle]

Robert,

I have created an OpenVMS I64 E.82 field test DVD and it had worked. Hoff had provided the CD/DVD guielines at that time frame.

Volker.

[R. Verkerk]

hello,

My clustersize is 16.

and on the EFI console I see:
blk0 : Acpi(HWP0002,0)/Pci(2|0)/Ata(Primary,Master)
blk1 : Acpi(HWP0002,0)/Pci(2|0)/Ata(Primary,Master)/HD(Part1,SigD35E32EF)

But I don't see any corresponding fs device. Also mounting this created DVD under OpenVMS is very SLOOOOOOOOW. Takes some time.

I am using a rewritable DVD. Could this be a problem??

I could not open the forementioned article. I get a timeout to that internet page. Could you include it in a answer.

greetings,

Robert Verkerk

[Volker Halle]

Robert,

there seems to be a problem with the HP web server, so I can't either access the ATW page and I therefore can't include it ;-(

There are lots of things that can 'go wrong' when writing and reading home-burned optical media. Especially, if you do a certain type of CD/DVD for the first time...

If you have created a re-writeable DVD, just try again and use a cluster-size of 4 blocks. When mounting is slow, this might indicate that mount is searching for a useable home block across the DVD.

Volker.

[R. Verkerk]

Hello,

I did following:

!!!!!!!!!! create DVD device

SJON01:SYSTEM> ld create $1$dkc200:[DVD_disk]IA64_XX11_SIP_0520A /size=9000000

SJON01:SYSTEM> SET FILE /CACHING_ATTRIBUTE=NO_CACHING -
_SJON01:SYSTEM> $1$dkc200:[DVD_disk]IA64_XX11_SIP_0520A.dsk

$ ld connect $1$DKC200:[DVD_DISK]IA64_XX11_SIP_0520A.DSK lda100:

SJON01:SYSTEM> init/erase/gpt/cluster=4 lda100: leeg

SJON01:SYSTEM> mount/system $1$lda100: leeg
%MOUNT-I-MOUNTED, LEEG mounted on _$1$LDA100: (SJON01)
SJON01:SYSTEM> dismount lda100:

!!!! backup the smxx11 disk to the lda device

SJON01:SYSTEM> mount/foreign $1$LDA100:

SJON01:SYSTEM> backup/image/noinit $1$DKb200: $1$LDA100:
SJON01:SYSTEM> dismount $1$lda100:

!!!! make the device boottable and set the name

SJON01:SYSTEM> mount/system $1$lda100: leeg

SJON01:SYSTEM> set volume/label=smxx11_sys $1$lda100:

SJON01:SYSTEM> SET BOOTBLOCK/BLOCK_SIZE=2048/IA64 -
$1$LDA100:[VMS$COMMON.SYS$LDR]SYS$EFI.SYS;1

SJON01:SYSTEM> dismount $1$lda100:

Create the DVD

SJON01:SYSTEM> copy/recordable/format=wait -
$1$dkc200:[DVD_disk]IA64_XX11_SIP_0520A.dsk dqa0:

Than I try to boot the disk but I have no fs device for it..

What am I missing? I can boot from the dkb200 disk without any problems..

gr,

Robert.

[Volker Halle]

Robert,

you can look at the bootblock data on the DVD and compare it with your bootable disk:

$ setboot:==$sys$setboot
$ setboot -h

The following shows the bootblock data (READ-ONLY !):

$ setboot -s -f device

The boot block is the first 2048 btyes of your disk. You can dump it with:

$ DUMP/BL=COUNT=4 device:

$ DIR/HEAD/BL=COUNT=0 dev:[VMS$COMMON.SYS$LDR]SYS$EFI.SYS

should show the starting block number (LBN) of the EFI boot file and should be the same as 'Boot Address' shown by the command above.

Volker.

[R. Verkerk]

Hello,

I did following:

SJON01:SYSTEM> setboot -s -f lda100:
OpenVMS SETBOOT version V5.2-3
Boot Architecture : IA-64
Boot Address : 0x001a677c : 000001730428
Boot Size : 0x0000fa00 : 000000064000
Boot Identifier GUID : C12A7328F81F11D2BA4B00A0C93EC93B
Boot Signature GUID : 07E4000400AA63B111DB8E99E40E8961
Boot Relative Offset : 0x00000001 : 000000000001
Diagnostics Address : 0x00013ed9 : 000000081625
Diagnostics Size : 0x000249f0 : 000000150000
Diagnostics Identifier GUID : E2A1E72832E311D6A6827B03A0000000
Diagnostics Signature GUID : 07E4000400AA64B111DB8E99E40E8960
Diagnostics Relative Offset : 0x00000004 : 000000000004
Master Boot Record : Protective MBR

SJON01:SYSTEM> dump/head/bl=count=0 lda100:[VMS$COMMON.SYS$LDR]SYS$EFI.SYS

Dump of file LDA100:[VMS$COMMON.SYS$LDR]SYS$EFI.SYS;1 on 18-DEC-2006 18:59:51.99
File ID (2221,2,0) End of file block 256000 / Allocated 256000

File Header

Header area
Identification area offset: 40
Map area offset: 100
Access control area offset: 255
Reserved area offset: 255
Extension segment number: 0
Structure level and version: 2, 1
File identification: (2221,2,0)
Extension file identification: (0,0,0)
VAX-11 RMS attributes
Record type: Fixed
File organization: Sequential
Record attributes:
Record size: 512
Highest block: 256000
End of file block: 256001
End of file byte: 0
Bucket size: 0
Fixed control area size: 0
Maximum record size: 512
Default extension size: 0
Global buffer count: 0
Directory version limit: 0
File characteristics: Contiguous, MoveFile disabled
Caching attribute: Writethrough
Map area words in use: 4
Access mode: 0
File owner UIC: [SYSTEM]
File protection: S:RWED, O:RWED, G:RE, W:
Back link file identification: (31,4,0)
Journal control flags:
Active recovery units: None
File entry linkcount: 0
Highest block written: 256000
Client attributes: None

Identification area
File name: SYS$EFI.SYS;1
Revision number: 3
Creation date: 23-AUG-2006 11:34:01.95
Revision date: 23-AUG-2006 11:36:17.57
Expiration date:
Backup date:

Map area
Retrieval pointers
Count: 256000 LBN: 6921712

Checksum: 13114
SJON01:SYSTEM>

SJON01:SYSTEM> dump/bl=count=4 lda100:

Dump of device LDA100: on 18-DEC-2006 19:01:30.08

Logical block number 0 (00000000), 512 (0200) bytes

206E6120 73692073 69685420 35303030 0005 This is an 000000
74737973 20343649 20534D56 6E65704F OpenVMS I64 syst 000010
65736165 6C502020 2E6B7369 64206D65 em disk. Please 000020
68742072 65746C61 20746F6E 206F6420 do not alter th 000030
20726F6E 202C5450 47202C52 424D2065 e MBR, GPT, nor 000040
69687420 6E6F6974 69747261 702D6572 re-partition thi 000050
756F7920 7473656C 202C6B73 69642073 s disk, lest you 000060
6F442020 2E746920 74707572 726F6320 corrupt it. Do 000070
47206E6F 20646E65 70656420 746F6E20 not depend on G 000080
296E4B4C 4220726F 206E5346 28205450 PT (FSn or BLKn) 000090
00000000 00002167 6E697265 64726F20 ordering!...... 0000A0
00000000 00000000 00000000 00000000 ................ 0000B0
00000000 00000000 00000000 00000000 ................ 0000C0
00000000 00000000 00000000 00000000 ................ 0000D0
00000000 00000000 00000000 00000000 ................ 0000E0
00000000 00000000 00000000 00000000 ................ 0000F0
00000000 00000000 00000000 00000000 ................ 000100
00000000 00000000 00000000 00000000 ................ 000110
00000000 00000000 00000000 00000000 ................ 000120
00000000 00000000 00000000 00000000 ................ 000130
00000000 00000000 00000000 00000000 ................ 000140
00000000 00000000 00000000 00000000 ................ 000150
00000000 00000000 00000000 00000000 ................ 000160
00000000 00000000 00000000 00000000 ................ 000170
00000000 00000000 00000000 00000000 ................ 000180
00000000 00000000 00000000 00000000 ................ 000190
00000000 00000000 00000000 00000000 ................ 0001A0
00000000 7AB7846F 00000000 00000000 ........o.·z.... 0001B0
00000022 550F0000 00010000 00EE0000 ..î........U"... 0001C0
00000000 00000000 00000000 00000000 ................ 0001D0
00000000 00000000 00000000 00000000 ................ 0001E0
AA550000 00000000 00000000 00000000 ..............Uª 0001F0



Dump of device LDA100: on 18-DEC-2006 19:01:30.08

Logical block number 1 (00000001), 512 (0200) bytes

0000005C 00010000 54524150 20494645 EFI PART....\... 000000
00000000 00000001 00000000 A4D74FB5 µOo?............ 000010
00000000 00000022 00000000 0022550F .U"....."....... 000020
11DB8E99 E40E8961 00000000 002254EE îT".....a..ä..à . 000030
00000000 00000002 07E40004 00AA64B1 ±dª...ä......... 000040
00000000 9E875628 00000080 00000080 ........(V...... 000050
00000000 00000000 00000000 00000000 ................ 000060
00000000 00000000 00000000 00000000 ................ 000070
00000000 00000000 00000000 00000000 ................ 000080
00000000 00000000 00000000 00000000 ................ 000090
00000000 00000000 00000000 00000000 ................ 0000A0
00000000 00000000 00000000 00000000 ................ 0000B0
00000000 00000000 00000000 00000000 ................ 0000C0
00000000 00000000 00000000 00000000 ................ 0000D0
00000000 00000000 00000000 00000000 ................ 0000E0
00000000 00000000 00000000 00000000 ................ 0000F0
00000000 00000000 00000000 00000000 ................ 000100
00000000 00000000 00000000 00000000 ................ 000110
00000000 00000000 00000000 00000000 ................ 000120
00000000 00000000 00000000 00000000 ................ 000130
00000000 00000000 00000000 00000000 ................ 000140
00000000 00000000 00000000 00000000 ................ 000150
00000000 00000000 00000000 00000000 ................ 000160
00000000 00000000 00000000 00000000 ................ 000170
00000000 00000000 00000000 00000000 ................ 000180
00000000 00000000 00000000 00000000 ................ 000190
00000000 00000000 00000000 00000000 ................ 0001A0
00000000 00000000 00000000 00000000 ................ 0001B0
00000000 00000000 00000000 00000000 ................ 0001C0
00000000 00000000 00000000 00000000 ................ 0001D0
00000000 00000000 00000000 00000000 ................ 0001E0
00000000 00000000 00000000 00000000 ................ 0001F0



Dump of device LDA100: on 18-DEC-2006 19:01:30.08

Logical block number 2 (00000002), 512 (0200) bytes

C12A7328 F81F11D2 BA4B00A0 C93EC93B ;à >à ..Kºà ..ø(s*à 000000
07E40004 00AA63B1 11DB8E99 E40E8961 a..ä..à .±cª...ä. 000010
00000000 001B617B 00000000 001A677C |g......{a...... 000020
006E0065 0070004F 00000000 00000000 ........O.p.e.n. 000030
00200034 00360049 00200053 004D0056 V.M.S. .I.6.4. . 000040
002E0049 00460045 00240053 00590053 S.Y.S.$.E.F.I... 000050
00000000 00000000 00000053 00590053 S.Y.S........... 000060
00000000 00000000 00000000 00000000 ................ 000070
04010004 00AA448B 11D7DE65 0000000B ....e?o..Dª..... 000080
07E40004 00AA62B1 11DB8E99 E40E8960 `..ä..à .±bª...ä. 000090
00000000 00013ED8 00000000 00000000 ........Ã >...... 0000A0
006E0065 0070004F 00000000 00000000 ........O.p.e.n. 0000B0
00200034 00360049 00200053 004D0056 V.M.S. .I.6.4. . 0000C0
0020006B 00730069 00440073 00790053 S.y.s.D.i.s.k. . 0000D0
00200079 0061006C 00720065 0076004F O.v.e.r.l.a.y. . 0000E0
00000000 00000000 00000000 006F004C L.o............. 0000F0
04010004 00AA448B 11D7DE65 0000000C ....e?o..Dª..... 000100
07E40004 00AA62B1 11DB8E99 E40E8961 a..ä..à .±bª...ä. 000110
00000000 00000000 00000000 001B617C |a.............. 000120
006E0065 0070004F 00000000 00000000 ........O.p.e.n. 000130
00200034 00360049 00200053 004D0056 V.M.S. .I.6.4. . 000140
0020006B 00730069 00440073 00790053 S.y.s.D.i.s.k. . 000150
00200079 0061006C 00720065 0076004F O.v.e.r.l.a.y. . 000160
00000000 00000000 00000000 00690048 H.i............. 000170
E2A1E728 32E311D6 A6827B03 A0000000 .....{.?à .ã2(ç¡â 000180
07E40004 00AA64B1 11DB8E99 E40E8960 `..ä..à .±dª...ä. 000190
00000000 000388C8 00000000 00013ED9 Ã >......Ã ....... 0001A0
006E0065 0070004F 00000000 00000000 ........O.p.e.n. 0001B0
00200034 00360049 00200053 004D0056 V.M.S. .I.6.4. . 0001C0
00470041 00490044 00240053 00590053 S.Y.S.$.D.I.A.G. 0001D0
002E0053 00430049 00540053 004F004E N.O.S.T.I.C.S... 0001E0
00000000 00000000 00000053 00590053 S.Y.S........... 0001F0


Dump of device LDA100: on 18-DEC-2006 19:01:30.08

Logical block number 3 (00000003), 512 (0200) bytes

04010004 00AA368F 11D7DE0D CCCCCCCA à à à à .?o..6ª..... 000000
07E40004 00AA63B1 11DB8E99 E40E8960 `..ä..à .±cª...ä. 000010
00000000 001A677B 00000000 000388C9 Ã .......{g...... 000020
006E0065 0070004F 00000000 00000000 ........O.p.e.n. 000030
00200034 00360049 00200053 004D0056 V.M.S. .I.6.4. . 000040
0020006B 00730069 00440073 00790053 S.y.s.D.i.s.k. . 000050
00200079 0061006C 00720065 0076004F O.v.e.r.l.a.y. . 000060
00000000 00000000 00000064 0069004D M.i.d........... 000070
00000000 00000000 00000000 00000000 ................ 000080
00000000 00000000 00000000 00000000 ................ 000090
00000000 00000000 00000000 00000000 ................ 0000A0
00000000 00000000 00000000 00000000 ................ 0000B0
00000000 00000000 00000000 00000000 ................ 0000C0
00000000 00000000 00000000 00000000 ................ 0000D0
00000000 00000000 00000000 00000000 ................ 0000E0
00000000 00000000 00000000 00000000 ................ 0000F0
00000000 00000000 00000000 00000000 ................ 000100
00000000 00000000 00000000 00000000 ................ 000110
00000000 00000000 00000000 00000000 ................ 000120
00000000 00000000 00000000 00000000 ................ 000130
00000000 00000000 00000000 00000000 ................ 000140
00000000 00000000 00000000 00000000 ................ 000150
00000000 00000000 00000000 00000000 ................ 000160
00000000 00000000 00000000 00000000 ................ 000170
00000000 00000000 00000000 00000000 ................ 000180
00000000 00000000 00000000 00000000 ................ 000190
00000000 00000000 00000000 00000000 ................ 0001A0
00000000 00000000 00000000 00000000 ................ 0001B0
00000000 00000000 00000000 00000000 ................ 0001C0
00000000 00000000 00000000 00000000 ................ 0001D0
00000000 00000000 00000000 00000000 ................ 0001E0
00000000 00000000 00000000 00000000 ................ 0001F0
SJON01:SYSTEM>

I saw that the starting address is: 0x001a677c : 000001730428

But where can I see the address of the file in the rest of my dumps??

gr,

Robert..

[R. Verkerk]

Hello,

I already found it.

It states the start address with the first command.

Than the dump with the sys$efi.sys should have the same LBN in the retrieval pointers.

This is different for me.

I will try to find why that is..

greetings,

Robert Verkerk

[Volker Halle]

Robert,

compare this with an original OpenVMS I64 DVD and also with your system disk. There is a factor of 4 involved here somewhere (2048 versus 512 byte blocks).

On my OpenVMS I64 V8.2 system disk, the starting LBN of SYS$EFI.SYS matches the boot address shown. Can't check the DVD at the moment.

Volker.

[Heuser-Hofmann]

Try this:

$ mount/for dqa0:
$ copy dqa0: disk:[dir]dvd.dsk
Burn the file dvd.dsk

Eberhard

Other tools are avail. for that task:

cdrtools (readcd) and dvdwrite (copy&verify)

e.

[GuentherF]

If I remember right the trick is to allocate a boot partition at the beginning of the LD device. To reserve the space at the begining you can define BACKUP$BAD_LBN and BACKUP$BAD_COUNT logicals (see DCL-INITIALIZE/BADBLOCKS) before you do the BACKUP/IMAGE to the LD device. Next you need a program to fill this boot partition (no idea where you get this program from). Next you burn all this to a DVD.

Note: If you make a BACKUP/IMAGE of this LD or DVD then BACKUP ignores the BADBLOCK area. Hence you cannot use this to produce another bootable DVD right away because you 'lost' the boot partition.

/Guenther

[GuentherF]

Forgot to mention...with a typical DVD utility program on your PC you can extract the first partitiom of the OpenVMS DVD onto a file which also should give you the size of this partition. Once you have create the LD device with the reserved (badblocks) partition starting at LBN:0 all you need is a little program to copy the boot partition file with logical I/Os into that reserved area on the LD.

/Guenther

[R. Verkerk]

Hello,

I just did a comparison between a standard Openvms DVD and the DVD I burned:

Standard OpenVMS:
ITA1:SYSTEM> setboot -s -f dqa0:
OpenVMS SETBOOT version V5.2-3
Boot Architecture : IA-64
Boot Address : 0x0018ae2c : 000001617452
Boot Size : 0x00001f40 : 000000008000
Boot Relative Offset : 0x00000002 : 000000000002
Master Boot Record : Legacy MBR


Home Grown DVD:
SJON01:SYSTEM> setboot -s -f $1$LDA100:
OpenVMS SETBOOT version V5.2-3
Boot Architecture : IA-64
Boot Address : 0x001b6148 : 000001794376
Boot Size : 0x0000fa00 : 000000064000
Boot Identifier GUID : C12A7328F81F11D2BA4B00A0C93EC93B
Boot Signature GUID : 07E4000400AA7BBB11DB8F60941729E1
Boot Relative Offset : 0x00000001 : 000000000001
Diagnostics Address : 0x000238a5 : 000000145573
Diagnostics Size : 0x000249f0 : 000000150000
Diagnostics Identifier GUID : E2A1E72832E311D6A6827B03A0000000
Diagnostics Signature GUID : 07E4000400AA7CBB11DB8F60941729E0
Diagnostics Relative Offset : 0x00000004 : 000000000004
Master Boot Record : Protective MBR


So there is some difference in the master boot record..

I will have to look further.. for it.

gr,

Robert.

[GuentherF]

Robert,

you are looking with setboot at the VMS known boot information. The real think on the bootable VMS DVD is in the 'badblocks' on the DVD which setboot doesn't look at. The VMS 'visible' boot information on the DVD is set to 'legacy' boot block which uses LBN 0 only. The setboot program uses the GPT
(Global Partition Table) style which uses a VMS visible file [000000]GPT.SYS to cover the partition areas inclusive the boot partition. In both cases (legacy and GPT) the boot partition points to a file system covered by SYS$LOADABLE_IMAGES:SYS$EFI.SYS. This is not the problem when creating a bootable DVD.

/Guenther

[alfred schreyer_2]

I have the same problem, the only bootable DVD I had produced was a 1 to 1 copy of the openvms distribution dvd. The problem seems to be explained very simple but I can not fix it myself. The cdrom filesystem is simply missing on every dvd which was made with the I64VMS$PCSI_INSTALL_MIN.COM. The image I made from the original distribution can be mounted with mount/media=cdrom and you can see the efi files on it. On every self made image, of course made by following exactly the instructions, dont have a cdrom portion. Besides I tried to get support with HP, they showed me the link to the mentioned documents about making bootable cd's in VMS but nobody really knows how it works and can not help. Even with dspp is no solution in sight.
greetings alfred

[R. Verkerk]

Hello,

I made a call within HP to get an answer. I will update it if I have a solution. (or not)

greetings,

Robert Verkerk

[R. Verkerk]

Hello,

This is the answer form HP:

From my experience, it seems a bootable DVD can be made if GPT is not used.

I use one of the following commands.

$ initialize /nogpt /cluster_size=4 lda:

or

$ run sys$system:sys$setboot
...
...
By default, the EFI console expects to see the Master Boot Record
(MBR) structure and GUID Partitioning Table (GPT) disk structures.
Use of both MBR and GPT is expected and is the default when the
disk is initialized for operations on OpenVMS I64. GPT operations
specifically require the file [000000]GPT.SYS be present. If the
GPT.SYS file is not present, MBR operations will be selected, and
no GPT operations are possible. If GPT.SYS is present, you can
optionally select the non-default MBR bootstrap. Do you wish to
override the expected selection process, and specifically use MBR?

Override selection? (Use MBR? YES or NO; default: NO) YES


What I did was use the second solution:

$ run sys$system:sys$setboot

After this I could boot from my DVD.

greetings,

Robert Verkerk

[R. Verkerk]

Fixed problem by using second solution from HP..

[Hoff]

I booted GPT-based DVDs all the time. Works fine.

Key is to follow the sequence from that Ask The Wizard topic 9820 exactly as written -- that's the sequence that was used for testing.

I added an error check for a mis-located GPT file and several other errors into setboot in V8.3. Prior to that, a mis-located GPT.SYS was capable of causing behaviour such as you have reported here.

If you find your disks are not booting with a GPT.SYS present, then it is probably a mis-located GPT (the MBR and GPT structures exist underneath the [000000]GPT.SYS file), and older (pre-V8.2) versions of BACKUP can easily produce these files.

There's a setboot option (SET BOOTBLOCK/MBR, IIRC) and a lower-level foreign-command option to force use of the MBR. The keyword is -m, IIRC. This disables the GPT path, and use of GPT.SYS. (If you do NOT have GPT.SYS, setboot automatically selects the MBR path.)

There are a bunch of qualifiers on SET BOOTBLOCK you can find with the Freeware VERB utility, and the help text at the setboot foreign command lists most everything at that level.

You can confirm location of [000000]GPT.SYS with a DUMP/HEADER. You should see exactly two extents, one at the front of the disk and one at the back. If you don't, then GPT.SYS is not correctly located on the target disk.

EFI uses the native sector size for its sector offsets, which is why you will see a factor of four difference between a disk-based bootstrap and a DVD-based bootstrap, and why you need to use either the /block_size=2048 qualifier, or the -2 on the foreign command, or the specification on the prompting-mode invoked by RUN.

The OpenVMS bootable DVD uses the El Torito bootstrap structures, and not the MBR or MBR/GPT bootstrap that's discussed here. El Torito is a variation of ISO-9660 that embeds the boot partition information into the ISO-9660 structures. If you want to create one of these, this is what Guenther is likely recalling -- using the bad block mechanism on INITIALIZE is one of the ways to deal with this, and to reserve the storage. (That step is not needed for MBR and for MBR/GPT bootstrap operations.)

There are tools in SYS$ETC: to copy block ranges, compare disks, and other such. See the CDDVD$TOOLS.CLD file.

DVD creation using programmed I/O is quite slow, and this is the speed enforced by the driver; the IDE I/O bus hardware and DQDRIVER stack on most OpenVMS systems is not anywhere near as speedy as most anyone would want. PCs and Macs will have hardware that will record significantly faster. Somewhat surprisingly, even USB 1.1 can be faster.

I'm posting up directions for creating CD and DVD media on OpenVMS over at the HoffmanLabs site. Contact me off-line if you'd like a review copy of the material.