search

pbatard / uefi-ntfs

UEFI:NTFS - Boot NTFS or exFAT partitions from UEFI
GNU General Public License v2.0
779 stars 133 forks source link

Don't allow Windows to assign a drive letter to the UEFI_NTFS (FAT) partition #25

Closed Lucero7919 closed 3 years ago

Lucero7919 commented 3 years ago

When running an auto unattended deployment from USB, some script aspects determine the USB drive letter assuming the USB in use for deploying is the only one plugged in. However, during build, Windows assigns a drive letter to the UEFI_NTFS (FAT) partition therefore causing deployment scripts to see two drives letters for USB devices, unable to determine the one to use, so the scripts fail.

Arguable, the scripts could handle the logic better, but experience shows this is not straight forward. Perhaps the UEFI_NTFS (FAT) partition could simply be hidden beyond WinPE (or removed).

pbatard commented 3 years ago

Most UEFI systems will not enumerate or boot hidden partitions, so I don't think hiding the partition will do. Removing it is also not an option, especially if the justification for ditching UEFI:NTFS is "because some scripts are too poorly written".

In Rufus, we are already placing the UEFI:NTFS partition at the end of the drive, so that properly written scripts should always be able to rely on the first assigned letter for the drive being the one assigned to the main NTFS partition.

Also, two more things:

  1. The "hidden" attribute for a "Basic data" partition is a Microsoft specific thing, not a GPT one
  2. Any attribute is assigned at the drive level (i.e. in the driver's GPT table) and not at the partition level, so I cannot alter UEFI:NTFS to magically "disappear" the UEFI:NTFS partition after boot.

However, there appears to be one bit in the Partition attributes for Microsoft Basic Data Partition (which is the type we create for UEFI:NTFS, at least when used with Rufus) called No drive letter, which is supposed to prevent Windows from automounting the partition.

Thus, one thing I can do, if you are actually using UEFI:NTFS drives that were created by Rufus, and not just UEFI:NTFS in a custom manner, is set that bit when creating the partition in Rufus, which may prevent Windows from assigning a letter to the UEFI:NTFS partition.

But really, you should fix your scripts, rather than expect other applications to spend time adding workarounds, so that you don't have to do that. Your scripts are broken, and need to be fixed.

Lucero7919 commented 3 years ago

Thank you for your response, and your openness to provide a work around. In short, it's no so much that the scripts are poorly written, more the limitations of PoSH or WMI classes that prohibit the scripts from doing anything funky given the limitations of PoSH cmdlets OOTB. And, although such scripts write WiFi profiles when deploying, which would allow other modules to be installed, the literal first thing the scripts do is validate a usb device is attached and ready. So yes, some logic could be written in, as at the moment, PoSH is having to return the valid drive letter based on mounted volume name, which is having to be hard coded in the scripts, rather than the scripts just saying, take the letter of the USB drive, because there's two, not one. I would imagine that not many people create USB flash drives with multiple partitions and assigned drive letters. Additionally, I wonder how MS manage this with their media creation tool for wims over 4Gb, as there is only one partition listed when the creation of usb drives completes?...