Hi there - I tried to boot an IncusOS ISO downloaded from the customizer in Hyper-V but got the following error (twice, I downloaded the same config)
'IncusOS_202511070055_.iso (Lun 1)' failed to open because of error:
'The file or directory is corrupted and unreadable.'.
Once I get diffoscope to stop using more memory than the entire VM it’s on I will try to work out what’s wrong - although the ISO doesn’t quite look like the right format at a cursory glance.
It could be that HyperV is trying to be too clever for its own good here.
The ISO isn’t really an ISO, it’s a 2048 bytes aligned version of the RAW image (as ISOs need to be), but it’s not formatted as isofs, it’s instead using the same GPT structure as the raw image (multiple partitions).
When that happens, then the raw image should be used instead, effectively simulating a USB stick being used to install the system.
Ah, no Hyper-V needs an ISO9660 or UDF filesystem, I think.
I can probably use qemu-img to convert an image to VHDX and get it going that way.
FWIW I’d expect a file like that to have a .img extension or something. That explains why my hex editor’s format parser wasn’t seeing an ISO9660 structure!
The problem is that it would be invalid as a raw image (.img) given that such an image should be using 512 bytes or 4096 bytes alignment.
ISOs are unusual primarily because of the 2048 bytes alignment, then after that the vast majority of physical and virtual systems don’t care about the actual content when booting and will happily boot a complex image with GPT partitions.
Most systems (virtual machines from effectively everyone except HyperV as well as all physical servers we’ve tried) will happily boot a 2048 bytes aligned GPT formatted image if told it’s an ISO, so effectively attaching that to a SCSI CD-ROM device on the system.
They will however refuse to boot if the same image is attached as a USB stick or if the raw image is attached as a virtual CD-ROM device.
So far the one other case I’ve seen of a system checking for ISO9660 is the Asus server BMC on their 10th gen platform which effectively has a header check at the time of attaching the virtual media from the remote console. However attaching the same ISO through the separate persistent virtual media instance (not tied to the remote console) works as expected, so it’s basically just a spurious header check in the javascript client…
I created Include Microsoft HyperV install instructions · Issue #499 · lxc/incus-os · GitHub to track the documentation for HyperV. I need to see if I can easily get HyperV going inside of my Windows 2025 test VM here as I don’t have (or want) any physical Windows systems around 
Happy to help test as I’m on Windows for a little bit longer at least.
So I managed to convert the image easily enough using the converter from StarWind.
But then I had two problems:
The first point is an absolute deal breaker. I can’t be 100% sure that “disabling” Secure Boot doesn’t actually mean that it’s running in Setup Mode, but so far all indications are that no, it’s fully off.
I’ve still sent a PR to sort out the second point on the off chance that I’m wrong and that there is in fact a way to bring up Secure Boot:
Secure Boot is non-negotiable in our case. We’re looking at relaxing the TPM 2.0 requirement through the use of a virtual TPM device, but we don’t have any similar workaround we can do here for Secure Boot itself.
It’s also very weird when Hyper-V clearly does support Secure Boot and even comes with multiple config templates that it doesn’t have the option to define your own template or to boot in Setup Mode… Maybe I’m missing something, I’d love to be proven wrong on this one.
The only non-Windows “Secure Boot Template” leads me to this extremely weird feature that obviously hasn’t been touched for a while.
Yeah, I went down that path a bit too before giving up
Thanks for all your work on this.
Unfortunately the only “supported” way to boot a Hyper-V guest with Secure boot seems to be something like the Red Hat boot shim.