Creating a bootable Windows 10 UEFI Installer usb-stick fails with Rufus 3.10, but suceeds with 3.9
Chatplosion opened this issue · 10 comments
Issue description
Creating a bootable Windows 10 UEFI Installer usb-stick fails with Rufus 3.10, but suceeds with 3.9.
The Windows Image is a official Windows 10 Education Image called "SW_DVD9_Win_Pro_10_1909.3_64BIT_German_Pro_Ent_EDU_N_MLF_X22-27463.ISO".
The full creation process suceeds, but created with 3.10 it doesn't start due to UEFI:NTFS driver faliure. With 3.9 it does excatly what it should do.
Target PC is Dell Optiplex 390 with UEFI-BIOS Rev. A14 (it is up-to-date version). There is no "Secure Boot" to activate or deactivate.
The harddrive is replaced with SSD. The usb stick must be manually added to uefi boot devices for each try.
The stick created with 3.10 doesn't start the installation. The stick created with 3.9 runs fine.
So I believe that there are some changes in the NTFS driver.
I hope that my feedback helps you in development of future versions.
So I believe that there are some changes in the NTFS driver.
yes there are. This is tracked in #1213 (which you might have found if you had followed the check list, especially as this issue is still open).
I will need to see the exact error you get from UEFI:NTFS, which is the ctritical part. Can you please provide that? I'm afraid UEFI:NTFS driver faliure doesn't give me nearly enough data. What is the actual error message and error code?
The Display shows following text:
*** UEFI:NTFS (x64) ***
[INFO] Disconnecting potentially blocking drivers
[INFO] Searching for target partition on boot disk:
[INFO] PciRoot(0)/Pci(0x1D,0x0)/VenHw(AA7BA38A-DAFB-40C3-8D18-B55B39609EF7)
[INFO] Found NTFS target partition:
[INFO] PciRoot(0)/Pci(0x1D,0x0)/VenHw(AA7BA38A-DAFB-40C3-8D18-B55B39609EF7)/HD(1,GPT,956232A8-5A86-467F-88...)
[INFO] Checking if target portition needs the NTFS service
[INFO] Stating NTFS partition service:
[INFO] EfiFs NTFS driver v1.5 (GRUB 2.0)
[INFO] Opening target NTFS partition:
[FAIL] Could not open partition: [3] Unsupported
[WARN] Waiting 3 seconds before retrying...
[FAIL] Could not open partition: [3] Unsupported
Press any key to exit.
The NTFS target partition is PciRoot(0)/Pci(0x1D,0x0)/VenHw(AA7BA38A-DAFB-40C3-8D18-B55B39609EF7)/HD(1,GPT,956232A8-5A86-467F-88...), but should be instead PciRoot(0)/Pci(0x1D,0x0)/VenHw(AA7BA38A-DAFB-40C3-8D18-B55B39609EF7)/HD(1,GPT,956232A8-5A86-467F-8824-0FCB98D244AD if the GUID is used to open the partition.
Thanks. This is the same error as the one that's currently being tracked in #1213.
The NTFS target partition is (...) but should be instead (...) if the GUID is used to open the partition.
Can you please post the log output from Rufus with the drive you just created plugged in (no need to create a drive, just make sure you have the drive plugged and post the log data).
I don't really see how the driver being compiled with EDK2 or gnu-efi could have any incidence on the partition GUID lookup, because this is performed long before we even load the driver (and the driver is the only element that has changed between 3.9 and 3.10), so, logically, I have to assert that you are mistaken in the GUID that is to be used here, especially as we obtain them by querying the system (which is best placed to report the exact GUID we need to use) rather than through computation.
The Rufus log output with the drive plugged should confirm this, provided you didn't recreate the drive you got the above UEFI:NTFS output from.
Here comes the log.
Rufus x86 v3.10.1647
Windows version: Windows 10 64-bit (Build 17763.1158)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.04
System locale ID: 0x0407 (de-DE)
Will use default UI locale 0x0407
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'de-DE'
Found USB 2.0 device 'ADATA USB Flash Drive USB Device' (125F:312B)
NOTE: This device is a USB 3.0 device operating at lower speed...
Found non-USB removable device 'ADATA SSD S599 55GB' => Eliminated
1 device found
Disk type: Removable, Disk size: 32 GB, Sector size: 512 bytes
Cylinders: 3773, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 2
Disk GUID: {9C131ED4-F244-4152-A568-175E9CAE860F}
Max parts: 128, Start Offset: 17408, Usable = 31037815296 bytes
Partition 1:
Type: Microsoft Basic Data Partition
Name: 'Main Data Partition'
ID: {956232A8-5A86-467F-8824-0FCB98D244AD}
Size: 28.9 GB (31035691008 bytes)
Start Sector: 2048, Attributes: 0x0000000000000000
Partition 2 (UEFI:NTFS):
Type: Microsoft Basic Data Partition
Name: 'UEFI:NTFS'
ID: {8CC1F6A1-EA8F-49E9-97F4-F4C1705C1934}
Size: 512 KB (524288 bytes)
Start Sector: 60618632, Attributes: 0x0000000000000000
Thanks. I thought you had simply failed to copy the full GUID when you pasted the output from UEFI:NTFS, hence why I replaced your HD(1,GPT,956232A8-5A86-467F-88 with HD(1,GPT,956232A8-5A86-467F-88...) when I edited the formatting.
So I think you've been assuming that UEFI:NTFS had been truncating the GUID, when it's just your environment that did that. The GUID that's part of the device path is something that we obtain from the UEFI system, and not a string we construct, and again, it is obtained long before the NTFS driver is loaded, so there's simply no logical possibility that there is internal truncation of the device path, unless you were to also get an error with 3.9, which you don't.
In other words, even if you may see them truncated on screen, the GUIDs being used internally by UEFI:NTFS are correct and the cause of the issue is something that, as the other issue details, has to do with whether the NTFS driver was compiled using EDK2 or gnu-efi.
Considering all this, I will close this issue, as this is a duplicate of #1213.
If you do have a chance however, would it be possible for you to run the test described here, and post the result in the #1213 thread?
I don't know if I have the time to run all test. At least for now using 3.9 is a functional workaround. I will try to do this tests in future, if my employer will let me do this.
That's fine. You don't have to do this at all if it's troublesome or if you feel you've already spent enough time.
You've already been great help in confirming that you had the same error as the one reported in the other issue. And you also confirmed that this appears to be a problem with Dell UEFI firmwares, which means I'll be trying to see if I can get my hands on one of these problematic Dell platforms, as I would very much like to try understanding why this issue is occurring in the first place, as well as have the means to test it on my own, instead of simply falling back to using the gnu-efi version of the driver while not being any wiser...
I have a same pb with a laptop Asus K53SD. I try to pass with the V 3.9. Thanks
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.