[Info-vax] InfoServer 150

[Stephen Hoffman]

On 2019-01-27 15:32:42 +0000, John E. Malmberg said:

> On 1/27/2019 8:12 AM, Bob Wilson wrote:
>> On Sunday, January 27, 2019 at 8:32:18 AM UTC-5, Hans Vlems wrote:
>>> It’s just bits, no problem there. Creating an image backup from a disk 
>>> still won’t work when that file gets written to a cdrom. The output of 
>>> dd or backup/physical may be used as input for cd writer programs on 
>>> Windows. And if necessary the filetype iso should be appended to the 
>>> filename.
> 
>> I agree (re: "it's just bits")...a "ISO image" is just a 
>> sector-by-sector copy of physical media, which may or may not be a 
>> ISO-9660 volume. Sort of like a spiral-read of the volume from block 0 
>> - maxblock.
> You are getting the terms wrong, and that can cause problems.

The terminology ship here sailed decades ago, alas.

> A disk image is a block by block image of the disk contents.
> 
> An ISO image is an image that conforms to the ISO-9660 standard.
> 
> Several disk blocks of a disk images are not used with ISO-9660 media. 
> This is intentional to allow dual format disk images by the ISO 
> committee.
> 
> The issue that the hobbyist disks disk images have a .iso extensions 
> yet are not burned as ISO images when making CD-ROM is a frequent cause 
> of confusion on the https://www.openvmshobbyist.com/forum .
> 
> While some CD-Burner programs may treat disk images and ISO images the 
> same, many now do not.

It's worse than that.

The cited tools do (did) work, and some of the not-cited tools do not 
or did not.

Some of the packages and some of the commercial packages do not work.

Nero was one very popular tool that had substantial troubles a dozen or 
so years ago.  More than a few debates over that one, too.

Dragging folks off of non-working-for-their-purposes Windows tools was 
surprisingly difficult.

> Especially GUI based ones that validate the file contents.  If they do 
> not find the ISO structure in an alleged ISO image, they can default to 
> creating an ISO file structure and putting the disk image in it as a 
> file.
> 
> And for disk images that are dual format ISO and other format, some 
> burner programs when you tell it that the source is an ISO image, may 
> only burn the ISO portion of the image, and not all of the disk 
> contents.

Correct.  It was quite common for some of the commercial tools to not 
burn the first part of a disk as that was reserved in the ISO-9660 
format, and that range was central to OpenVMS and to dual-format media. 
 To record OpenVMS native and OpenVMS dual-format images, the tool has 
to be capable of sector-by-sector burns.  Raw disk images.  Not file 
system.

> So you need to find disk burning software that supports burning image 
> files, not just ISO images.
> 
> Only one of the hobbyist disk images have ISO-9660 content, the IA64 
> system install disk.  And that one is dual format.  The rest are disk 
> images.

The EFI disk is sorta-kinda dual format with ISO-9660 with El Torito, 
but only as far as being able to fool EFI into accepting the sorry 
state of OpenVMS file system and bootstrap support and 
lack-of-partitioning.  The dual format hack dumps some sectors over a 
specified range of the disk, and doesn't even remotely attempt to map 
the ODS file system and the ISO-9660 file system.

> Due to their age, I suspect that the Inforserver disk images are not 
> iso images, even though that they may be named as such.

They are ISO images in the usage of ISO as a raw disk image and not in 
the usage of ISO as ISO-9660.  ISO was and variously sometimes still 
used to indicate a raw, sector-by-sector burn, confusing as that may be.

> HPE/VSI has an internal port of mkiosf that is used as part of creating 
> that disk image.  It may not be usable for making other types of 
> images, as stuff that was not needed for making the IA64 boot was 
> removed if it caused compile/link issues.  (There is a layer in the 
> source that is a wrapper for all the syscalls that was removed)

Last I looked at this dual-format stuff, the tool was effectively a 
sector-level patch into the generated volume structure, with some 
shenanigans around declaring bad blocks to reserve room at the right 
address range for the patch.  Might well have changed in the ensuing 
years, but it was originally an entirely brute-force tool.

> This was needed for creating the El-Torito DVD boot required by the 
> Itanium console, which existing ports of mkiosf did not support.

EFI also allowed a so-called legacy boot, and which did (still does?) 
work with the OpenVMS I64 boot disks, and was (is?) supported by the 
OpenVMS bootstrap-related tools.  Legacy boot looked a whole lot like 
the BTB bootblock stuff used on VAX and Alpha, too.

> f someone is motivated to properly update the port of mkiosf to VMS, it 
> would be nice to add dual format ISO/OD5 support natively.  With that 
> support, when you mount the disk as ISO-9660, you would also see all 
> the VMS files.  That would likely involve making sure that the 
> trans.tbl files are generated for full compatibility.

Completely different issue than what's going on here though, with 
getting a block burn of these images, and getting mkisofs will run 
afoul of the sorry state of ISO-9660 support on OpenVMS.  Which really 
hasn't been updated from ISO-9660:1988.


-- 
Pure Personal Opinion | HoffmanLabs LLC