Cannot mount GUID volume #1351
Comments
|
Translation：没有更多文件。-> No more files. |
|
Indeed, same issue. |
|
Please run more tests with 3.5. Be mindful that a single test with 3.5 is not enough to determine if there was a regression. Also, did any of you enable VDS (Alt-V) by any chance? If so please disable it an try again, as this feature is very experimental. |
|
Also, I see that you are getting: This is not usual and indicates that Windows is interfering with the normal flow of operation. When that happens, you may want to cycle the USB port with Alt-C as this issue tends to indicate that Windows is trying to use an old cached partition table, instead of the actual one, and the only way I have found to force Windows to forget the old table is through port cycling (I have tried many, many API calls that Microsoft say are supposed to refresh the layout, which is actually part of the reason why there is a new VDS mode in Rufus, but none actually work)... |
|
I've tested v3.3 - 3.5, all of which worked immediately. Tried it with v3.6 multiple times (and the usual stuff such as rebooting, trying different USB ports, formating the drive in Disk Management, even deleting the partition table, low level format) but it never got past that point. Always said And no, I didn't hit ALT-V. |
|
Just tried it with hitting ALT-C before pressing "Start". Worked twice in a row. |
|
I'm experiencing what appears to be the same issue, although ALT-C doesn't fix it. My log also has the same "Timeout while waiting for logical drive" and "Logical drive was not found!" messages. Using Rufus 3.5 instead of 3.6 works. This is a SATA SSD in a Ugreen USB enclosure. Rufus is running in a Windows 10 VM on KVM using USB passthrough for the target disk. Let me know if I can help by testing in any way. |
|
I see a lot of people using VM's there... Please be mindful that I can only support real hardware, as there is no telling how virtualization can interfere with either of Rufus or Windows behaviour. For instance I strongly suspect that the reason Alt-C doesn't work on a VM is because no actual USB port reset takes place (it's probably filtered by the VM application). In that case, please try to physically unplug and replug the drive. |
|
I can understand if you reckon that the VM aspect will make this problem out of scope. I very much appreciate Rufus nonetheless. |
|
Sincerely thank everyone in this thread. It turned out that rolling back to |
|
Just wanted to add that I hit this just now and the only solution, after trying all mentioned methods above, was to revert to 3.5. Let me know if I can add any debug logs for things not yet tried. |
|
(Full) logs are ALWAYS welcome. I'm afraid a "me too" without a log doesn't tell me much. Also please indicate if you are running Rufus on real hardware or on a VM. |
|
Here's the log from my Windows To Go attempt in 3.6, running in a KVM VM with USB passthrough: |
|
Thanks! |
|
Out of curiosity I tried the same thing with a virtual USB disk in the VM, and the result was the same. I don't know if this will be useful in any way, but here's the log from that: Rufus logI also tried with MBR instead of GPT, and when I do that it seems to work. |
Running 3.6 on bare-metal(HDD) and attaching full-log with screenshot. rufus-3.6_fail.log
|
|
I can also confirm that this seem to only happen when using "GPT" partitioning for the WTG target. Selecting "MBR" allows the process to progress past the GPT fail point. |
|
Thanks for the report. Did cycling the port (Alt-C) help in any way at all? |
|
No. And I did try that _multiple_ times.
|
|
Okay. I'm going to reopen this issue since it appears to affect a lot of people. Will see what I can do to try to get this fixed for 3.7. |
|
Thank you for this wonderful software!! This happened to me on windows 10 update 1903 (no virtualization) with rufus 3.6.1551, Alt-C did not make any difference, but rolling back to rufus 3.5 fixed the problem. |
|
Yeah, the problem (which can be verified with In our case, we'll get the ESP (partition 1) and MSR (partition 2) with an effective accessible volume, but not partition 3, which is the main NTFS partition where we apply the WIM image. In other words, instead of getting the partitions enumerated like this: where the value behind the where Windows "forgets" to assign a volume GUID to the 3rd partition. This is the reason why I advise a USB port reset, as a proper reset should force Windows to rescan the partition layout and assign an ID to the 3rd partition. However, it appears that, in their great wisdom, Microsoft have neutered USB port reset in Windows 1903, because it doesn't seem to produce the usual disconnection one sees with previous versions of Windows (device refresh from reset is way too fast!). And none of the APIs I tried to force a partition layout refresh seem to help either (and, believe me, I've tried all of the ones that Microsoft makes available). So my recommendation now is to yank out the USB drive and then plug it back to see if that helps (which may or may not work, since Windows appears to do its hardest to cache a partition layout, instead of properly refreshing it when it should). Now, those with a keen eye might notice that the first longword in the GUID of each partition is incremented ( So, provided the issue is that Windows only manages to sort its volume GUIDs for the first 2 partitions, I think I might revert to what I was doing in 3.5, which is have the partitions in MSR, Data and ESP order, rather than ESP, MSR, Data as was changed in 3.6. This might make things less compatible with some poorly designed UEFI systems (that aren't specs compliant if they expect the ESP as the first partition), but hopefully it will sort things out until Microsoft really gets its shit together with regards to their ABSOLUTELY ABYSMAL handling of multiple partitions... |
|
Thanks for the insight in the root cause. Note: I am using build Windows 18362, not 1903 and yet having same problems (on a bare metal). |
|
Confirmed that moving the ESP back to being the last partition should make Rufus perform as it did in 3.5. I will push the fix shortly and it will be part of Rufus 3.7 (which I may release earlier than planned as there are now quite a few fixes that would probably be better pushed sooner rather than later). |
|
Note, for those who have been facing this issue, I have just released a BETA for the upcoming Rufus 3.7, which you can download from HERE. If you feel like testing and confirm that this fixes the issues you were experiencing with 3.6, please do so! |
|
I tested with 3.7 beta in the same environment as before (Windows 10 VM running in KVM with USB passthrough for the target disk). I can confirm that the problem appears to be fixed. |
|
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. |
Checklist
<FULL LOG>below. Yeah, please see it.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
(✓)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
Hi, all. I continuously experienced error message "cannot mount GUID volume" everytime when trying to construct a Windows To Go drive on my SSD. It appers right after status "writing MBR". I successfully made a WTG on my USB drive prior to this so I don't think the ISO is to be blame and I run a bad block check but the SSD was alright. I tried several times with the SSD repluged into another port, Windows virtual machine restarted and the error message never disappers.
Log
The text was updated successfully, but these errors were encountered: