UEFI boot issues
brookspeppin opened this issue · comments
I'm having a bunch of issues getting laptops to boot UEFI using standard Windows 10 install ISOs. It shows in the boot list, and after it is selected the system attempts to boot and then bombs out and flips back to HD. Secure boot is off. Tested on Dell XPS 13 and Dell E7470. Using Rufus 3.4.1430.
I've also tried on "removable" and "Fixed disk" usb drives as well as 1803, 1809 win10 ISOs.
I need a bit more details. When UEFI:NTFS fails, it will freeze and show you the complete output of what it's been trying to do, with a clear error message.
So I need to see that. Unless you can provide that, then I cannot help you, as you may want to understand that, as a standalone Free Software developer, I don't have the means to access any of the systems you mention for testing.
Here is how it is set in rufus:
Log attached of the formatting of USB.
rufus.log
Client tries to boot as I see the Dell logo (thus knowing its UEFI booting) and spinning icon for maybe 5 seconds. Then it reboots and goes back to HD (oobe screen as win10 has already been installed). I don't see any error messages on the system.
I have been previously successful in UEFI booting this ISO using a slightly different process than your tool but was hoping to use Rufus fully instead of my custom script.
Video: https://www.dropbox.com/s/o3p172eirq24k5o/IMG_0743.mp4?dl=0
Well, from your video, UEFI:NTFS does not run at all, so I don't understand why you logged this issue against UEFI:NTFS.
If you don't even see the UEFI:NTFS header after selecting your USB, then the problem is purely with your environment. If it was an issue with UEFI:NTFS, then at the very least you would see a message telling you that UEFI:NTFS did launch (which uses basic UEFI system calls to get printed, so if you don't see that, and your UEFI firmware is properly configured, then your UEFI firmware has a major issue).
I'm afraid that all I am seeing here points to a pure environmental problem: it's not that UEFI:NTFS fails during execution, it's that the Dell UEFI firmware fails to load and run it altogether. As such I have no choice but to close this issue and advise you to contact Dell support, as (once you get in touch with the right people), they should agree that, if their firmware is UEFI compliant and your UEFI settings are correct, then a bootloader that resides on a 512 KB FAT partition and that starts by displaying a simple message using the standard UEFI console output protocols should result in at least that message being displayed. So, if it doesn't (as per your video), then the fault does not reside with the bootloader.
For the record, here is the type of output you should see from UEFI:NTFS if your UEFI firmware was launching it properly (you can ignore the FAIL part as this is just a screenshot from a different issue):
Again, if you don't even see the first line, then it means that the issue is upstream to UEFI:NTFS and therefore not something I can do anything about.
Bummer. As far as I know Dell uses standard UEFI boot mechanisms. I can successfully UEFI boot using standard UEFI boot on USB (using fat32), but it just doesn't work with UEFI:NTFS.
I can successfully UEFI boot using standard UEFI boot on USB (using fat32)
That doesn't mean anything. Maybe they screwed up FAT16/FAT12 support, maybe they screwed up partition support (can only boot from first partition, but not last), or fail to ignore capitalization, or it could very much be a misconfiguration issue on your side. Are you absolutely certain you disabled Secure Boot? For instance, if you create a FAT32 drive and copy the UEFI Shell (or any other unsigned x64 UEFI application for that matter) onto it as \efi\boot\bootx64.efi, can you actually run that?
Yes secure boot is off, you can see in my video. I did some more testing a found out the following:
- Dell appears to have different implementations of NTFS boot support on various model and BIOS revs. I tried the same usb stick on a newer Dell E7490 and it booted UEFI:NTFS fine.
- I tried your suggestion a made a FAT32 partition with the UEFI:NTFS files and tried it again on the other non-booting system (E7470) and it did successfully boot to UEFI:NTFS this time. I also made that FAT32 partition the "First" partition on the USB key rather than the 2nd (like you do it), but not sure if that really matters.
I think it would be awesome if you could update the tool to use FAT32 formatting for UEFI:NTFS to provide a wider range of support given the differences in hardware vendors' implementation. I get that might impact other boot support (linux, etc) so perhaps when an standard windows ISO is detected, it could do the fat32 partitioning and leave standard FAT for others. Thanks for all the help and response. Love your tool.
Also, I'm not sure if you are interested, but it isn't necessary to even use the unsigned UEFI:NTFS boot files when you have a Windows 10 Setup media. You can instead put the boot files from the media on that FAT32 partition (make it around 500mb or so) and then put the sources folder (as the install.wim is often larger than 4gb) on the nfts partition. This allows you to keep secure boot on and not have to worry about unsigned NTFS bootloader. I've got this working in a batch file and it works great. Every Dell system (as well as VMs) boot to it successfully with secure boot on. I've attached the batch file in .txt format.
usbcreate-v2.txt
(I am not original author of this script, but found it and have tweaked it slightly)
Dell appears to have different implementations of NTFS boot support on various model and BIOS revs.
You do realize that if Dell implements NTFS boot then you don't need UEFI:NTFS at all. UEFI:NTFS is used to compensate for UEFI firmwares that don't have a native NTFS driver. Obviously if the firmware has native NTFS support, then you will be able to boot the NTFS partition, and can select that one instead of UEFI:NTFS.
made a FAT32 partition with the UEFI:NTFS files and tried it again on the other non-booting system (E7470) and it did successfully boot to UEFI:NTFS this time.
So this is a pure Dell firmware bug.
I think it would be awesome if you could update the tool to use FAT32 formatting for UEFI:NTFS to provide a wider range of support given the differences in hardware vendors' implementation.
Can't use FAT32 for a small partition. That's why we use FAT12. But really, if the Dell firmware was implemented properly, it shouldn't matter if FAT12 or FAT32 are used, or if the FAT partition is the first or last. Also, please understand that the reason we use FAT12 in the first place and a partition that is last on the drive is because:
- On most Windows system (and especially Windows 7), you can NOT mount 2 partitions at the same time from a removable drive. So we wouldn't be able to format one partition (NTFS one) and then the other (FAT one) without having to go through a cumbersome mount/unmout process
- Again, because you can't get 2 partitions mounted from removable drives on most Windows systems, we must have the UEFI:NTFS partition at the end, so that when user plug/replug their drive, the partition they will see is the NTFS one, with the ISO content, and not the UEFI:NTFS one, which would be useless to them.
So, to work around these limitation, we don't format the UEFI:NTFS partition at all, but instead, we simply write a pre-existing copy of this small partition, that is embedded in Rufus, at the end of the drive, which greatly simplify matters. And again, because that partition is so small (and of course we want it to be as small as possible), we can't use FAT32 for the file system but FAT12. But again, for a UEFI firmware that was designed by competent people, this should not matter, and I really have no interest adding workarounds because other people did a very poor job. So please get in touch with Dell, and tell them they need to fix their UEFI firmware.
You can instead put the boot files from the media on that FAT32 partition (make it around 500mb or so) and then put the sources folder (as the install.wim is often larger than 4gb) on the nfts partition.
I am well aware of this. However, this is wasteful in space, and also, as I explained, this can't be used by Windows 7, Windows 8 and pre 1803 Windows 10 users, because, if you try to do that on removable media, you will only ever see the first 500MB partition when you plug the media, and be unable to access the rest of the drive.
Also, I'd like nothing more than submit UEFI:NTFS for Secure Boot signing (this is not a matter of money or unwillingness on my side), but the problem is that Microsoft are abusing their power and preventing anything GPLv3 from being signed (for more on this, please see this FAQ entry). So, I really don't see why I would have to completely change a solution that should work just fine with Secure Boot, just because the people in charge of Secure Boot signing feel entitled to say "Yeah, we decided we don't like the license you use, so we're not gonna let you help people that have Secure Boot enabled, even if your solution would work just fine for that situation too".
You also need to understand that, as I explain in the FAQ, temporarily disabling Secure Boot is hardly the security liability that people seem to think it is (because surely, if it says "Secure" it shouldn't ever be disabled, right?).