Load failure [3] unsupported

[LillyWho]

I'm trying to boot a Windows Server 2022 stick made with Rufus 3.18, and the following happens:

Now, it has to be said that the UEFI implementation on this seems to be really quite wonky and even a Windows Server 2008 R2, basically the target OS, had constant bootloader issues spewing error codes and then booting on second attempt, until I started chainloading with reFind. But this here fails every time, regardless of whether I'm using reFind or booting directly from the firmware boot manager. Is there anything worth debugging, or is this a writeoff?

[pbatard]

Well, the issue is that your UEFI firmware does include a native NTFS driver ([WARN] An NTFS driver service is already loaded), so, because it is not possible for UEFI:NTFS to override or even supersede the operations of the NTFS driver that's provided by your manufacturer, the loading of the efi\boot\bootx64.efi has to be done by that driver... and the resulting failure is also because of that driver.

So you may want to contact that manufacturer and let them know that their NTFS driver is unable to function as a proper UEFI file system driver as, if it was, it should have no trouble loading efi\boot\bootx64.efi from the NTFS partition. Or, if you feel inclined to tamper with your UEFI firmware (with all the risks that entails) you may want to edit the UEFI firmware to replace that native NTFS driver with one that actually works, or delete it altogether, so that the UEFI:NTFS one can be loaded.

It may also help to shame that manufacturer by providing their name as well as the model of the computer/motherboard you are trying to boot, so that people can get an idea of who's been providing half-assed NTFS drivers out there...

[pbatard]

Well, I guess from your report, the manufacturer is Dell and the model is PowerEdge R710. Not entirely surprised there, because Dell have been a regular source of issue with UEFI:NTFS (#18)...

[LillyWho]

That wanring was actually due to me nicking the driver from the rufus efi directory and dropping it into reFind's driver folder, so it was already present at the time of trying to boot.

I don't think that's the issue however, as I just plugged the same stick into my main PC and got the very same error. This time I ran it right from the BIOS boot menu and it still failed, without a warning about a driver already being present. This firmware is an AMI, Asrock Z77 Pro3, and otherwise a pretty stable one.

[LillyWho]

Well, I guess from your report, the manufacturer is Dell and the model is PowerEdge R710. Not entirely surprised there, because Dell have been a regular source of issue with UEFI:NTFS (#18)...

It's a proper rack server from about ten years ago. I suspect UEFI wasn't that widely figured out yet, as in that era a lot of machines still booted with a regular BIOS and even this thing defaults to leaving UEFI disabled.

[pbatard]

as I just plugged the same stick into my main PC and got the very same error.

Please post the full output from UEFI:NTFS then. Considering that you have been interfering with the standard boot process by adding rEFInd and drivers into the mix, I do want to see the full output rather than "I got the same error".

[LillyWho]

Well considering the same thing occurred even on a different machine without refind at play, I think it could be ruled out. I've also found out that the ISO I created from was most likely corrupted, so I'm retrying with a fresh copy. The installer won't start even on a Windows 11 installation, complaining about corrupt dll's, and the install.wim is garbage according to dism, so it might not even be down to uefi:ntfs at all. But just for future reference, where does it log to? That picture was all of the output I ever got.

[pbatard]

I was asking for the same picture as the one you posted earlier, but for the test where you say you didn't get the warning. That's the output I am talking about and what I'd like to see, even if you think it's unnecessary. Considering that I am not the one sitting in front of the screen, I don't want to take any risks into "guessing" what you are actually seeing, and whether there might be something that you think is irrelevant, but that could be crucial to troubleshooting.

Also, yes, if you still get the error without the warning then chances are that your NTFS partition is corrupted, and that your efi\boot\bootx64.efi was not extracted properly. I'll also warn you, since I've seen that happen a lot, about picking a bootloader at random, and trying to shoehorn it into a efi\boot\ folder, on account that the boot process complained that it was missing. Especially, if you picked a bootloader that was for a different arch (and be mindful that in the UEFI world, and very much unlike what is the case for BIOS, 32-bit x86 is INCOMPATIBLE with 64-bit x86), you would typically get the error you reported...

[LillyWho]

All I was starting was the boot-x64.efi that rufus put into the boot partition, with no roundabouts at all. It's most likely really just the image that rufus copied from being garbage, as I couldn't start the installer even from the ISO directly under Windows 11.

[LillyWho]

[pbatard]

Thanks. It would be interesting to feed the efi/boot/bootx64.efi file from the NTFS partition (not the one from the UEFI:NTFS partition) into a PE analyser such as PEStudio to see what it reports, especially for the arch and EFI properties.

Again, you would typically get Unsupported if you are trying to run a UEFI executable for the wrong CPU arch.

[LillyWho]

Again, you would typically get Unsupported if you are trying to run a UEFI executable for the wrong CPU arch

I don't know how efi binaries work in detail, but maybe at least a header or some such got garbled so it reads as incompatible. I won't analyse the files because it's just not practical for me, I just have to get on wifi again and get a new ISO, but if you like I can make a zip of all the boot files before erasing the drive for a new attempt.

[pbatard]

I wouldn't mind looking at the efi/boot/bootx64.efi that doesn't seem to be loading, but that file is most likely copyrighted by Microsoft, so you can't legally share it. On the other hand, if you provide something like its SHA-256 and indicate the exact name of the Windows Server 2022 ISO you downloaded (which I guess came from https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2022/ and should be something like 20348.169.210806-2348.fe_release_svc_refresh_SERVER_EVAL_x64FRE_en-us.iso), I can look into it further.

[LillyWho]

That's the one, yes. And I had run the iso through 7-zip and it just about declared every file faulty. Apparently halting and resuming didn't do it any favours. This time I did a continuous download, after one other failed attempt on the go, stayed in subway stations to get good wifi, the second attempt staying put at station with the fastest wifi yielded results! Here's hoping it works when I get home! Running a cli version of 7-zip right on my phone, and it passed the check.

[LillyWho]

So turns out since my sdcard is formatted as fat32, and probably since Android does some serious mount-fu with abstraction layers for permission management and such, wget didn't get the memo, if it even can, that the maximum file size had been exceeded. It was basically writing over the file as soon as it reached the limit, or the file system just ditched the difference.

[Masamune3210]

Stuff like this is why it's recommended to run a sanity check on downloaded images before installation, saves headaches in the long run

[pbatard]

Well, since this is unrelated to UEFI:NTFS then, I will close this issue.

[LillyWho]

Stuff like this is why it's recommended to run a sanity check on downloaded images before installation, saves headaches in the long run

That's the kicker, right after downloading 7z said all OK

[Masamune3210]

7z just does a sanity check on being able to extract the archive, its not on the file itself. It can say OK after extracting a corrupt file if the data part of the archive is damaged just enough to still extract but be corrupted