PR: Add ability to provide custom image simultaneously with a custom automatic install (answerfile / xml)

[lly-c232733]

Documentation of the specific feature can be found in the updated readme provided in this pull request.

[lly-c232733]

this addresses #441

[lly-c232733]

I did test this in my own environment and here are the startup logs showing that the code works

❯ Starting Windows for Docker v3.00...
❯ For support visit https://github.com/dockur/windows
❯ CPU: 13th Gen Intel Core TM i9 13900H | RAM: 29/31 GB | DISK: 890 GB (ext4) | HOST: 5.15.146.1-microsoft-standard-WSL2...
❯ Extracting local ISO image...
❯ Adding custom.xml for automatic installation...
❯ Building ISO image...
❯ Creating a 64G growable disk image in raw format...
❯ Booting Windows...
3h3h3hBdsDxe: failed to load Boot0002 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0xA,0x0)/Scsi(0x0,0x0): Not Found
BdsDxe: loading Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x5,0x0)/Scsi(0x0,0x0)
BdsDxe: starting Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x5,0x0)/Scsi(0x0,0x0)
❯ Windows started succesfully, visit http://localhost:8006/ to view the screen...

Here is my compose file:

version: "3"
services:
  windows:
    image: dockurr/windows
    container_name: windows
    devices:
      - /dev/kvm
    cap_add:
      - NET_ADMIN
    ports:
      - 8007:8006
      - 3389:3389/tcp
      - 3389:3389/udp
    stop_grace_period: 2m
    restart: on-failure
    volumes: 
      - /srv/qemu/win-test:/storage
      - /srv/qemu/InstallerCustomISO/win19_cbkw.iso:/storage/custom.iso
      - /srv/qemu/InstallerAnswerfiles/win2019-eval.xml:/run/assets/custom.xml
      - /srv/qemu/InstallerAnswerfiles/install.sh:/run/install.sh 

[kroese]

If instead of:

      volumes:
      - /srv/qemu/InstallerAnswerfiles/win2019-eval.xml:/run/assets/custom.xml

you had used:

      volumes:
      - /srv/qemu/InstallerAnswerfiles/win2019-eval.xml:/run/assets/win2019-eval.xml

there was no need for this feature anymore.

So I am thinking in which kind of situations it would be an advantage. Because I can think of disadvantages: for example, if you switch ISO files a lot, this method will cause problems (because the custom Server 2019 XML in custom.xml will suddenly be used for Windows Vista for example).

So everytime you place a different ISO in your /storage folder, you will need to modify your compose file (or the custom xml). In the old method, this worked okay because as soon as a different version is detected it will use a different XML.

So can you explain a little why its useful for you to do it in this way, because I might be overlooking something obvious?

[lly-c232733]

Maybe I'm doing something wrong. because /srv/qemu/InstallerAnswerfiles/win2019-eval.xml:/run/assets/win2019-eval.xml did not work for me when I was using a custom ISO.

Compose:

version: "3"
services:
  windows:
    image: dockurr/windows
    container_name: windows2
    environment:
      VERSION: "2019"
    devices:
      - /dev/kvm
    cap_add:
      - NET_ADMIN
    ports:
      - 8007:8006
      - 3389:3389/tcp
      - 3389:3389/udp
    stop_grace_period: 2m
    restart: on-failure
    volumes: 
      - /srv/qemu/win-test2:/storage
      - /srv/qemu/InstallerCustomISO/win19_cbkw.iso:/storage/custom.iso
      - /srv/qemu/InstallerAnswerfiles/win2019-eval.xml:/run/assets/win2019-eval.xml

Resulted in the following in the log file:

❯ Starting Windows for Docker v3.00...
❯ For support visit https://github.com/dockur/windows
❯ CPU: 13th Gen Intel Core TM i9 13900H | RAM: 29/31 GB | DISK: 889 GB (ext4) | HOST: 5.15.146.1-microsoft-standard-WSL2...
❯ Extracting local ISO image...
❯ Detecting Windows version from ISO image...
❯ Warning: failed to determine Windows version from string 'Microsoft� Windows� Operating System', falling back to manual installation!
❯ Building ISO image...
❯ Creating a 64G growable disk image in raw format...
❯ Booting Windows...
3h3h3hBdsDxe: failed to load Boot0002 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0xA,0x0)/Scsi(0x0,0x0): Not Found
BdsDxe: loading Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x5,0x0)/Scsi(0x0,0x0)
BdsDxe: starting Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x5,0x0)/Scsi(0x0,0x0)
❯ Windows started succesfully, visit http://localhost:8006/ to view the screen...

As you can see, the xml file was not picked up. Manual installation was selected. How would you recommend solving this issue? I suppose maybe you will say that the rest of the detectImage() function should be finding the name of the image, and then getVersion should be selecting '2019'. This would be very nice if it was working, and if that is the goal than I agree with you that this PR is a bad solution... Is there something I need to do to my install.wim or my custom.iso to allow the detectImage() and/or getVersion() to properly choose the .xml?

For transparency I built the custom windows image myself using this KB:
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/deploy-a-custom-image?view=windows-11.

Very much appreciate your time. This package is incredible!

EDIT: Also let me know if there is anything I need to provide to you to allow you and I to come to the best possible solution. ( I can modify the script to add additional logging, whatever you need )

[kroese]

Yes the goal is to have the detectImage() function work in every situation. I have tested it on maybe 25+ official images and it always works there.

It calls wimlib-imagex info -xml to get a XML about the ISO. And it reads the Windows version via the DISPLAYNAME in the XML. But in your ISO it says: Microsoft� Windows� Operating System where normally it should say Windows 7 Home Premium for example.

Without seeing that XML I cannot say if it could be fixed easily, so you could add an echo "$result" there to dump the XML to the log. Because I would rather have a pull-request that fixes the underlying issue instead of working around the symptoms.

I will accept this pull-request anyway, because I did not realize there were cases where the detection could fail. And I agree its very useful in those cases. But I will remove the addition to the readme, because its not for normal usage.

[lly-c232733]

I did grab the XML here it is :

��<WIM><TOTALBYTES>5888548057</TOTALBYTES><IMAGE INDEX="1"><DIRCOUNT>32672</DIRCOUNT><FILECOUNT>170638</FILECOUNT><TOTALBYTES>17116351717</TOTALBYTES><HARDLINKBYTES>6027849923</HARDLINKBYTES><CREATIONTIME><HIGHPART>0x01DA9B3C</HIGHPART><LOWPART>0x83699E16</LOWPART></CREATIONTIME><LASTMODIFICATIONTIME><HIGHPART>0x01DA9B3C</HIGHPART><LOWPART>0x841ED25F</LOWPART></LASTMODIFICATIONTIME><WIMBOOT>0</WIMBOOT><WINDOWS><ARCH>9</ARCH><PRODUCTNAME>Microsoft� Windows� Operating System</PRODUCTNAME><EDITIONID>ServerStandardEval</EDITIONID><INSTALLATIONTYPE>Server</INSTALLATIONTYPE><SERVICINGDATA><GDRDUREVISION>0</GDRDUREVISION><PKEYCONFIGVERSION>10.0.17763.2989;2016-01-01T00:00:00Z</PKEYCONFIGVERSION><IMAGESTATE>IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE</IMAGESTATE></SERVICINGDATA><HAL>acpiapic</HAL><PRODUCTTYPE>ServerNT</PRODUCTTYPE><PRODUCTSUITE>Terminal Server</PRODUCTSUITE><LANGUAGES><LANGUAGE>en-US</LANGUAGE><DEFAULT>en-US</DEFAULT></LANGUAGES><VERSION><MAJOR>10</MAJOR><MINOR>0</MINOR><BUILD>17763</BUILD><SPBUILD>3650</SPBUILD><SPLEVEL>0</SPLEVEL><BRANCH>rs5_release</BRANCH></VERSION><SYSTEMROOT>WINDOWS</SYSTEMROOT></WINDOWS><NAME>19CB</NAME><DESCRIPTION>Win2019 with KW and CB</DESCRIPTION></IMAGE></WIM>

I will say that when I created the .wim file I did specify a 'name' and 'description' per the KB I linked above and those strings do appear in the XML:

<NAME>19CB</NAME><DESCRIPTION>Win2019 with KW and CB</DESCRIPTION>

I wonder if there is a 'ProductName' option when I create the .wim. I will look into that.

EDIT: there is no CLI option for 'ProductName' in dism /CaptureImage, but there are 'name' and 'description'. Maybe the true solution is to name / describe isos correctly when using dsim, and updating the bash script here to fall back to 'name' and 'description'

[kroese]

For example, this an output XML that is good:

<WIM>
   <TOTALBYTES>2478299194</TOTALBYTES>
   <IMAGE INDEX="1">
      <NAME>Windows Vista BUSINESSN</NAME>
      <DESCRIPTION>Windows Vista BUSINESSN</DESCRIPTION>
      <FLAGS>BUSINESSN</FLAGS>
      <WINDOWS>
         <ARCH>9</ARCH>
         <PRODUCTNAME>Microsoft� Windows� Operating System</PRODUCTNAME>
         <HAL>acpiapic</HAL>
         <PRODUCTTYPE>WinNT</PRODUCTTYPE>
         <PRODUCTSUITE>Terminal Server</PRODUCTSUITE>
         <LANGUAGES>
            <LANGUAGE>en-US</LANGUAGE>
            <DEFAULT>en-US</DEFAULT>
         </LANGUAGES>
         <VERSION>
            <MAJOR>6</MAJOR>
            <MINOR>0</MINOR>
            <BUILD>6001</BUILD>
            <SPBUILD>18000</SPBUILD>
         </VERSION>
         <SYSTEMROOT>WINDOWS</SYSTEMROOT>
      </WINDOWS>
      <DIRCOUNT>12651</DIRCOUNT>
      <FILECOUNT>64521</FILECOUNT>
      <TOTALBYTES>11304788246</TOTALBYTES>
      <CREATIONTIME>
         <HIGHPART>0x01C85BEA</HIGHPART>
         <LOWPART>0x20131AD3</LOWPART>
      </CREATIONTIME>
      <LASTMODIFICATIONTIME>
         <HIGHPART>0x01C85C00</HIGHPART>
         <LOWPART>0x9E9F8C6A</LOWPART>
      </LASTMODIFICATIONTIME>
      <DISPLAYNAME>Windows Vista Business N</DISPLAYNAME>
      <DISPLAYDESCRIPTION>Windows Vista Business N</DISPLAYDESCRIPTION>
   </IMAGE>
</WIM>

It first reads the <DISPLAYNAME> which is Windows Vista Business N. But if that field is empty then it falls back to <PRODUCTNAME> (because in rare case that also contains the Windows version).

But ISO's with the field NAME and DESCRIPTION I never saw before. And it would not have helped if I added support for it, because I cannot easily tell from custom strings like19CB or Win2019 with KW and CB what Windows version + Edition it is.

Maybe we had a misunderstanding about what a "custom iso" is. For me, it means an iso that you downloaded yourself from the Microsoft servers. And its custom, because it was never tested unlike the automatic ISOs. But in most cases they will work. But for you a custom ISO is one that you manually modified, which will be even harder to support.

[lly-c232733]

Would you consider a pull request to add fallback of 'name' and 'description' tags?

EDIT: It does look like your example also includes 'name' and 'description'

[kroese]

Ow yes, I see that now. But Im not sure what to do with them, because for every ISO that Microsoft ever has released there is a DISPLAYNAME. And for ISOs that people created themselves, the NAME and DESCRIPTION are basicly free text fields. So they will in most cases not contain anything that I need, like Windows 7 Ultimate, but more likely some made-up names like CB19. So reading that fields would not solve the problem Im afraid?

[kroese]

I reverted the PR because there were two situations where it did not work. First was for older Windows versions like 7 and below (it needs a valid DETECTED value to recognize them and alter the boot process). And secondly for ISO's that are not custom.

The solution was very simple, to alter only the XML variable and leave the DETECTED as it was. I also modified the location of custom.xml to /storage instead of /run/assets so that it also can work by placing a file in that directory.

I also realized there was a much easier solution for your initial problem, it would have been solved just by setting:

    environment:
      DETECTED: "win2019-eval"

This overrides the detection, and it would not have been necessary to modify the name in your ISO or use a custom.xml.

In any case, I will commit the reworked code tomorrow (which now correctly reads the NAME tag and supports custom.xml in a better way).