Failure to assign a drive letter to 3rd partition

[acromano]

Checklist

• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• I clicked the 'Log' button (🗒️) or pressed Ctrl-L in Rufus, or used DebugView, and copy/pasted the log into the section that says <FULL LOG> below.
• The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.
• I also tried one or more of the following:
  • Using a different USB drive.
  • Plugging the USB into a different port.
  • Running Rufus on a different computer.
• If using an image, I clicked on the (✓) button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

When creating a USB drive in Windows 11 using a Yocto .wic image, rufus creates all 3 partitions correctly but does not assign a drive letter to Partition 3. If we manually assign a drive letter to Partition 3 the image works correctly. Another engineer tried and got the same results. USB(s) used had no bad sectors.

Log

Rufus x64 v4.5.2180 (Portable)
Windows version: Windows 11 Pro x64 (Build 22631.3737)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.12
System locale ID: 0x0409 (en-US)
Will use default UI locale 0x0409
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
Found 517 officially revoked UEFI bootloaders from embedded list
Found 2351 additional revoked UEFI bootloaders from this system's SKUSiPolicy.p7b
Found USB 3.0 device ' USB  SanDisk 3.2Gen1 USB Device' (0781:5591)
1 device found
Disk type: Removable, Disk size: 128 GB, Sector size: 512 bytes
Cylinders: 14959, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 3
Disk GUID: {6BC77D74-A3E4-4B4B-A34E-C44A48DBA51D}
Max parts: 128, Start Offset: 17408, Usable = 123048262144 bytes
Partition 1:
  Type: Microsoft Basic Data Partition
  Name: 'install'
  Detected File System: FAT16
  ID: {9153206D-CA7D-449E-A80C-A48337B0EDF6}
  Size: 55.4 MB (58109952 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000004
Partition 2:
  Type: Linux Data Partition
  Name: 'image'
  Detected File System: ext4
  ID: {A339A62F-DC49-44EE-8403-F3F0898F84CB}
  Size: 913.7 MB (958048256 bytes)
  Start Sector: 116736, Attributes: 0x0000000000000000
Partition 3:
  Type: Microsoft Basic Data Partition
  Name: 'app'
  Detected File System: FAT16
  ID: {8B8148FA-8C90-4B44-AC50-8F25AE09345C}
  Size: 256 MB (268435456 bytes)
  Start Sector: 1988608, Attributes: 0x0000000000000000
Scanning image...
ISO analysis:
  'C:\Temp\emd-image-congatec-tca7-64-rt.wic' doesn't look like an ISO image
Disk image analysis:
  Image has a Zeroed Master Boot Record
  Image is a bootable disk image
Using image: emd-image-congatec-tca7-64-rt.wic (1.2 GB)

Computing hash for 'C:\Temp\emd-image-congatec-tca7-64-rt.wic'...
  MD5:    8a0103d583139c965ab83e5baba862aa
  SHA1:   8c0c5803d1384c356305ff2e95baf3d61c2eed9c
  SHA256: 4ee45e6899d1731275f2b88064506e28710659ef16da90a4f6adab388159e59d

Format operation started
Requesting disk access...
Will use 'D:' as volume mountpoint
Opened \\.\PhysicalDrive1 for exclusive write access
Requesting logical volume handle...
No logical drive found (unpartitioned?)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Opened \\.\PhysicalDrive1 for shared write access
Remounted \\?\Volume{9153206d-ca7d-449e-a80c-a48337b0edf6}\ as D:

Found USB 3.0 device ' USB  SanDisk 3.2Gen1 USB Device' (0781:5591)
1 device found
Disk type: Removable, Disk size: 128 GB, Sector size: 512 bytes
Cylinders: 14959, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 3
Disk GUID: {6BC77D74-A3E4-4B4B-A34E-C44A48DBA51D}
Max parts: 128, Start Offset: 17408, Usable = 123048262144 bytes
Partition 1:
  Type: Microsoft Basic Data Partition
  Name: 'install'
  Detected File System: FAT16
  ID: {9153206D-CA7D-449E-A80C-A48337B0EDF6}
  Size: 55.4 MB (58109952 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000004
Partition 2:
  Type: Linux Data Partition
  Name: 'image'
  Detected File System: ext4
  ID: {A339A62F-DC49-44EE-8403-F3F0898F84CB}
  Size: 913.7 MB (958048256 bytes)
  Start Sector: 116736, Attributes: 0x0000000000000000
Partition 3:
  Type: Microsoft Basic Data Partition
  Name: 'app'
  Detected File System: FAT16
  ID: {8B8148FA-8C90-4B44-AC50-8F25AE09345C}
  Size: 256 MB (268435456 bytes)
  Start Sector: 1988608, Attributes: 0x0000000000000000
Found USB 3.0 device ' USB  SanDisk 3.2Gen1 USB Device' (0781:5591)
1 device found
Disk type: Removable, Disk size: 128 GB, Sector size: 512 bytes
Cylinders: 14959, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 3
Disk GUID: {6BC77D74-A3E4-4B4B-A34E-C44A48DBA51D}
Max parts: 128, Start Offset: 17408, Usable = 123048262144 bytes
Partition 1:
  Type: Microsoft Basic Data Partition
  Name: 'install'
  Detected File System: FAT16
  ID: {9153206D-CA7D-449E-A80C-A48337B0EDF6}
  Size: 55.4 MB (58109952 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000004
Partition 2:
  Type: Linux Data Partition
  Name: 'image'
  Detected File System: ext4
  ID: {A339A62F-DC49-44EE-8403-F3F0898F84CB}
  Size: 913.7 MB (958048256 bytes)
  Start Sector: 116736, Attributes: 0x0000000000000000
Partition 3:
  Type: Microsoft Basic Data Partition
  Name: 'app'
  Detected File System: FAT16
  ID: {8B8148FA-8C90-4B44-AC50-8F25AE09345C}
  Size: 256 MB (268435456 bytes)
  Start Sector: 1988608, Attributes: 0x0000000000000000

[pbatard]

If we manually assign a drive letter to Partition 3 the image works correctly.

Please define "correctly". I'm going to assume that you are not actually creating a bootable drive but something very custom, since drive letter assignation from Windows has absolutely no bearing on bootability.

So what is "correctly" in this case?

I hope that you can appreciate is that if you want a third party custom Windows application to be able to work with your drive, that goes beyond the scope of what Rufus (and probably) other software is designed to do and that, before a (busy) developer decides to commit their spare time on something, they will need to understand the context behind it.

So, what is the software you are using that appears to need to use 2 separate partitions on Windows?

Also, please bear in mind that, for anybody using older versions of Windows 10, or any versions of Windows 8.x, Windows does not allow assigning multiple drive letters to a USB drive with the REMOVABLE drive (most USB Flash Drives), so, even if we wanted to, we wouldn't be able to accomplish what you want for all platforms due to intrinsics limitations of Windows.

Personally, I have to state that I fail to see how this is not an image issue in the first place, when you clearly could (and probably should) merge the 2 FAT partitions into a single one, so I'd also very much like you to explain what is the constraint on that...

[acromano]

We are creating a bootable USB for a Yocto image which has 3 partitions. By correctly, I mean when you assign a drive letter to the 3rd partition it is accessible by Windows and files can be copied to the 3rd partition.

From reading your response I understand that rufus needs to be backward compatible for Windows versions that do not allow assigning multiple drive letters to a USB drive.

[pbatard]

and files can be copied to the 3rd partition.

But by what application?

My point was to understand in which fashion being able to access the 3rd partition from Windows or not could be detrimental to the ability of creating a drive that, when used as bootable media, will effectively boot a computer, which is the main design goal of Rufus.

But it appears that you are using Rufus for a different purpose, and with a custom application or process that does not concern itself with using the resulting drive for booting, but instead for a specific purpose that you still have yet to disclose.

As you may understand, it is not my goal to spend time trying to support custom process or application usage with Rufus as, if I were to do that, I would essentially be providing free support for companies which I do estimate have more than enough resources to sort out these kind of custom issues, which are the result of their own design, by themselves.

Therefore, I was asking about your process or application, and the purpose of your image, to find out if there was a chance this could translate to something that the general public was likely to use and be faced with, which is the only kind of scenario that really matters to me, or to confirm that, as I am currently assuming, this requirement is part of a custom business process or application that you have, and that is unlikely to translate to a real requirement for the general public.

[acromano]

Thank you for explaining your reason for the inquiry. I will try explain.

We developed a Linux application using Visual Studio on Windows.

We have a created a Yocto(Linux) image for a custom embedded system which has a boot partition, an ext4 partition for the Yocto runtime filesystem and an additional partition for the application. After creating the bootable USB, the application files are manually copied from Windows to the 3rd partition on the USB drive.

The target is then booted with the freshly made USB drive. When booting the target, Yocto creates a bootable partition and an ext4 partition for the OS. The application files are copied from the USB to the correct location on the target. This was done to simplify and streamline the manufacturing process and product updates in the field.

[github-actions]

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.