Onni Rautanen

> @oizone Maybe you should change the title? The arm64 image is in fact not arm64 as it contains x86_64 binaries that are required for the software to function. "ARM64...

I just noticed that the arm64 build doesn't work without rosetta. When opening an stl, it hangs at 75%. This is in the error log: `2024-02-04T10:52:41.588Z - error uncaughtException: spawn...

Yes, I've configured following redfish properties in BIOS through ansible: PxeDev1EnDis: "Disabled" PxeDev2EnDis: "Disabled" PxeDev3EnDis: "Disabled" PxeDev4EnDis: "Disabled" HttpDev1EnDis: "Enabled" HttpDev2EnDis: "Disabled" HttpDev3EnDis: "Disabled" HttpDev4EnDis: "Disabled" HttpDev1VlanEnDis: "Enabled" HttpDev1DnsDhcpEnDis: "Disabled"...

So, is this an issue in the firmware or in mboot.efi? Meaning that does Dell need to fix this? Does this work on HPE for example?

If this is a by design limitation of UEFI HTTP boot, find it strange but let's assume it for a minute, then I assume it would be possible to pass...

And as info, I've opened severity 2 support request on VMware support on this, id 21206887703. I'll open a Dell support request also, if needed.

Hmm, thought I had different behaviour in some of my tests when I didn't rename the bootloader to mboot.efi but used the original name bootx64.efi. But must have but something...

Using the ISO method would of course fix the boot itself, but since the point is in automated installation where each host requires it's own kickstart file, it would get...