Yes, I've observed the same. I plan to fix this up soon, just haven't yet had the time to. There is some work being done on #82 to this effect too.

@timsutton I've tried the prepare_iso/prepare_vdi.sh script @jonanh wrote and it worked. I use Parallels Desktop, so I had to convert the resulting vdi into the Parallels' format (hdd). After that I was able to boot a VM from that hdd and build with the packer's parallels-pvm builder.

The prepare_vdi.sh script uses a different approach -- install OS into a disk image by means of installer -pkg InstallInfo.plist -- as described in #82. @jonanh converts the resulting vdi image into ovf and then uses virtualbox-ovf packer builder. Neither Parallels Desktop supports ovf, nor packer has other builders but parallels-iso and parallels-pvm. So I had to convert the vdi image to Parallels' hdd format with their prl_convert tool, which comes with Parallels Desktop. Then, I created a diskless macos VM and attached the converted image to it, both using prlctl. Finally, I passed that VM to packer's parallels-pvm builder and built my box without issues:

    {
      "type": "parallels-pvm",
      "source_path": "{{ user `vm` }}",
      "parallels_tools_flavor": "mac",
      "ssh_username": "vagrant",
      "ssh_password": "vagrant",
      "shutdown_command": "echo 'vagrant'| sudo -S shutdown -h now"
    }

The question is: Does macOS 10.13 support unattended installation by OSInstall.collection at all? Is it possible to make an image compatible with parallels-iso and/or virtualbox-iso packer builders?

A note for those failing to run prepare_vdi.sh: You must upgrade your host to macOS 10.13 to make installer -pkg InstallInfo.plist ... work.

@timsutton I've implemented what I suggested above in atikhono@44ffc75. This is Parallels Desktop support for AutoDMG-like macOS installation and image. The implementation is based on the branch from #82.

@atikhono Apple added a security restriction to the 10.12.4+ installers making impossible to include non-Apple packages [1][2]. Also they restricted the target of startosinstall. So it became very hard to automate the whole installation. :-(
I just read that in 10.13+ they have added a new parameter to startosinstall to install additional packages which it is quite interesting [3], but startosinstall can only be used for updating an installation AFAIK.

You are right, unfortunately we can only make AutoDMG-like installs if we are installing the same guest OS as the host. Also the process of creating the vdi/vmdk, creating a OVA/OVF package and then importing it into packer is quite un-optimal.

Probably we can improve it further. I wonder if we could create a minimal bootable OS system using the BaseSystem.dmg and how much we could customise it. But I wonder if it would be possible to copy the full installer and from a boot script (like the rc.cdrom.local service) start the install using startosinstall.

But what we could improve easily is the packer current pipeline removing the need of exporting the OVF and reimporting it back into packer. I would suggest doing the whole process using VirtualBox since it is free, to reduce the number of scripts and templates to maintain, and make a separate script to convert the generated virtualbox packer box into a parallel packer box o vmware packer box. Also we could research more options to export the fresh install volume (the DMG) to a vdi/vmdk, unfortunately VirtualBox doesn't like the DMG that AutoDMG is producing which is why I ended doing the script instead of using AutoDMG+vFuse.

[1] https://derflounder.wordpress.com/2017/03/29/third-party-installer-packages-may-not-be-installable-by-the-macos-10-12-4-os-installer/
[2] https://github.com/munki/createOSXinstallPkg
[3] https://derflounder.wordpress.com/2017/09/26/using-the-macos-high-sierra-os-installers-startosinstall-tool-to-install-additional-packages-as-post-upgrade-tasks/

About how long should it take for installer -verboseR -dumplog -pkg '/Applications/Install macOS High Sierra.app/Contents/SharedSupport/InstallInfo.plist' -target /Volumes/macos-build? I tried this overnight, expecting maybe 30 to 90 minutes, but the command was still running in the morning :/

My mistake, if the sparseimage is misnamed and so fails to hdiutil attach, then the installer continues to launch against a nonexistent mount point, show a few log messages, and just sit there dumb forever. When I fix the sparseimage name, then the installer begins working.

Yeah, on a fast machine this should take ~10 minutes, maybe closer to 20-25 in a VM depending on the hypervisor and disk.

You could check /var/log/install.log to see if there's anything obvious as to how the command would be still running. Maybe something else is "hogging" the installer engine (only one client can be driving an install at a time), or the VM actually halted due to lack of disk space, etc.?

Just reporting success with prepare_vdi.sh method with High Sierra 10.13.3 into virtualbox. Thanks very much for your support!

Is there a plan to update prepare_iso.sh to support High Sierra?
I just found this and am running into this issue:

Tzeejay5k:osx-vm-templates-master cj$ sudo prepare_iso/prepare_iso.sh -u cj -p pa1nt "/Applications/Install macOS High Sierra.app" $HOME/
-- Attaching input OS X installer image with shadow file..
Die erwartete CRC32-Prüfsumme ist $1D0A7164
/dev/disk3          	GUID_partition_scheme          	
/dev/disk3s1        	EFI                            	
/dev/disk3s2        	Apple_HFS                      	/private/tmp/veewee-osx-esd.So9C
-- Mounting BaseSystem..
-- Could not find BaseSystem.dmg in /private/tmp/veewee-osx-esd.So9C

Has anyone ever seen this?

@tzeejay not sure on @timsutton's thoughts on this, but I just opened a PR #97 for this. The biggest thing with this is that box creation on High Sierra as it currently stands is currently impossible due to the third-party package signing restrictions implemented by Apple after 10.12.3. However, I still think supporting High Sierra could be useful for future updates or changes to provisioning techniques.