UEFI:NTFS - Could not find volume: [3] Unsupported #615
Comments
|
This is with the UEFI:NTFS module, so there is no logging (because logging wouldn't bring more information than what you see on screen). It looks like this could be an UEFI firmware issue on your platform as the error indicates that the call to Can you provide more information about your target computer? What make and model is uit? Have you checked whether there was an UEFI firmware update that you could apply? How old is the latest UEFI firmware? |
|
It's an HP 9740m with the F.60 bios version (http://h20564.www2.hp.com/hpsc/swd/public/detail?sp4ts.oid=5271102&swItemId=ob_143542_1&swEnvOid=4060#tab4) - i can see a newer bios version but the release notes don't indicate anything relevant. |
|
Okay. This is a fairly recent BIOS, so it's a bit puzzling that it would fail like this. The one thing I'd also like you to clarify is this:
So you originally had a bootable USB, using NTFS as the file system. At this stage, I think I'd like to know what happens if you use an official Windows 7 ISO from Microsoft (you don't need to install the OS from it, just see if it goes past the error you are getting right now). As you can understand, the only ISOs I can support are the official ones published by Microsoft, because there's just too much that can be introduced when creating custom ISOs. So I hope you can get an official Windows 7 retail ISO. I'd encourage you to look here first to locate the image you are interested in, then click Or, if you don't want to look around, can I please ask you to download an official Windows 10 straight from Microsoft, through Microsoft's Tech Bench, and then see if it goes past your current error. Again, you don't have to install Windows 10 - this is just to see if it can boot properly on your system. Once I have that info, I should be in a better position to investigate your issue. |
|
Yes, i know it's not an official official supported official build :) i have a windows 7 ISO. I created a USB from this but this doesn't boot either. |
|
to be clear though - this one doesn't even show up in the boot options. |
That's because you used MBR for your partitioning: Can you try again, using the |
|
Doh! Am at work for the rest of the week will do it at the weekend. |
|
No problem - take your time... 😃 |
|
Any update on this? |
|
Sorry, been swamped at work but I've got a few days off now. Main points:
|
|
BTW for the sake of completeness i repeated the test with MBR for UEFI and both FAT and NTFS and got the same results. |
|
Thanks for the update.
If you used Rufus, then that's not possible (be mindful that Rufus will change your options after you select an ISO). Rufus always formats to NTFS when using Windows ISOs, and indeed, your first log reports: Oh, and Rufus also partitioned as MBR: So, what you created in your "GPT/FAT32" step is an MBR/NTFS bootable USB, which booted using BIOS compatibility rather than UEFI. Not sure why you got the error you got, but it looks like Windows may not like your BIOS/BIOS compatibility module. In this mode, UEFI:NTFS is not used (but of course, then it's not USB bootable. Note that you can use Rufus to create an empty GPT/FAT32 drive (make sure you unselect "Create bootable drive using..."), and then manually copy the ISO content (using 7-zip for instance) if you want to try UEFI boot from FAT32. But for various reasons, Rufus forces the use of NTFS for Windows installation media...
Confirmed by the log (which also confirms the use of UEFI:NTFS):
If you get the same with the official retail ISOs, and it works fine an other computers (so far you are the only report I got with this error from UEFI:NTFS), I suspect that this is an issue with the UEFI firmware from HP. Given that the UEFI:NTFS code is fairly straightforward (which of course doesn't meant that it's bug free! But it helps...) and the error you get ( ADDON: I'll still see if I can think of anything I could do in UEFI:NTFS that could help, but without a problematic HP machine to test with, that will be very difficult. |
|
I ran into a similar error a long time ago (possibly HP as well). |
|
"So, what you created in your "GPT/FAT32" step is an MBR/NTFS bootable USB" The selections in Rufus were absolutely: GPT, FAT32. I have already noticed the upside down user interface which changes options further up after you select things down below :) - but why would it let me select it if it doesn't do it? - indeed, it did format as GPT/FAT32 - the actual log starts at line 538, sorry. I should have cleared first. Is there any way to capture any more information in UEFI:NTFS? a debug build or something? |
|
I guess I'll answer both of you at once... ;) @mnbf9rca, you're right (but your log was a bit confusing). About 2 days ago, I found that I introduced a bug that enabled FAT32 for Windows starting with Rufus 2.4 (in commit 49e5490). So, unlike what was the case with Rufus 2.3 and earlier, it is indeed possible to create GPT/FAT32 with Rufus 2.4 and 2.5. At this stage, I am waiting to see how much confusion this is likely to generate with regards to Windows installation. Especially, MBR+FAT32, which is now possible, will definitely result in people installing Windows in BIOS mode when they wanted UEFI, as well as the opposite, which I don't think is ideal because it might be way too late when they realize it. So I think I will disable "MBR+FAT32 for BIOS or UEFI-CSM" for Windows in the next version. But I will probably leave "MBR+FAT32 for UEFI" (which doesn't install a BIOS bootloader, so can only be booted in pure UEFI mode) and "GPT+FAT32" if I don't receive major complaints about these modes by them. I'm still half expecting that, by inadvertently enabling FAT32 for Windows, I'm going to receive notices that something gets broken during Windows installs, but the fact that nobody has alerted me to any of that ever since 2.4 was released is encouraging...
Yup. I've been trying to find the time to work on this for quite a while (#117), but, as may not be apparent, it needs to be part of a much larger effort than "simply" moving some controls around. This means that getting a more logical order in the interface cannot happen before Rufus 3.0.
The error code report is the most information you can get, as this is being provided by the UEFI firmware, and it's not possible to get more data unless you get a debug version of your UEFI firmware to explain why it complains. I don't have additional debug builds of UEFI:NTFS because it's already as close as it gets to debug. Because there really isn't much to it, a non "debug" version of UEFI:NTFS would probably only have one line that says I may however have a solution/explanation for the
|
|
yeah, i realised i'd configured it wrong and restared, and forgot to clear the logs, sorry! i'll try with a Windows 10 DVD too. Another option is to allow the user to specify the size of the FAT32 partition - i guess i can resize it manually later and add a large NTFS partition to put my 12GB WIM file on but it might be an option. |
Are you saying you have a requirement for >4GB If not, there's really no requirement for using NTFS for a Windows installation media, as the filesystem used by the USB has absolutely no incidence on the filesystem Windows will be installed on. Also, Rufus is smart enough to detect >4GB Outside of Windows To Go, which Rufus should support just fine by creating a FAT32 partition as required (provided the media is not REMOVABLE — see below) or UEFI:NTFS (which doesn't work for you, and can't be used for much but call on the regular Windows UEFI bootloader anyway), I'm not aware of a Windows installation media that has FAT32+NTFS partitions. Not that it may be impossible to create one, but one thing to consider is that Microsoft decided that Windows could never mount 2 partitions at the same time from an USB media, if that media had the REMOVABLE attribute, which is the case for 95% of USB flash drives out there. So this can make it quite tricky to produce drives with both FAT and NTFS on them, unless of course you manage to get your hands on a flash drive that has the FIXED attribute... |
|
yes, i have a 12GB install.wim. It contains drivers for about 6 different laptop models that we use. Microsoft supports provides this example (as you say, with a USB which reports as a fixed disk): http://blogs.technet.com/b/askcore/archive/2013/04/02/microsoft-deployment-toolkit-2012-update1-media-deployment-usb-drive-for-uefi-computer.aspx |
|
Despite the extended silence, I'm still not giving up on trying to fix this issue. Looking around at other UEFI applications seem to do (e.g. rEFInd), it looks like there may be cases where one needs to wait between the time a file system driver gets loaded, and the time where the corresponding file system can actually be accessed. This got me thinking that this could very well be the problem with these HP systems: If they are slow to start the NTFS driver and identify the partitions that can be serviced by it, for one reason or another, and we try to open the NTFS volume right away, it could explain why we get an I have therefore added a 1 second delay in the latest UEFI:NTFS in the hope that this will help with this issue (coz if a system really needs more than 1 second to start being able to service a file system, you really need to get a faster CPU or get whoever designed its UEFI firmware too fix that). If you feel like trying it, I have the new UEFI:NTFS |
pbatard
changed the title
|
For anyone who experienced the If I don't receive reports after one week, I will consider the problem resolved and close this issue. |
|
I now get this: I tried with both Windows 7 64bit and Windows 10 64bit, with ISOs downloaded from MSDN: |
|
Well, somehow I like that error better than the older one, because at least it tells us that your UEFI firmware doesn't like the NTFS driver we're trying to load from the get go, rather than produce a hard to troubleshoot failure later on. Also, this is the same error that was reported in #549, with, surprise, surprise, another HP laptop... At this stage, this would look like an incompatibility with the HP UEFI firmware and the NTFS UEFI driver, so I would appreciate if you could do the following:
|
|
HI pbatard, |
|
Well, first of all, I don't support multiboot. So if you are trying to create a multiboot USB and it doesn't work, you're pretty much on your own. So, whereas you are indicating that you are using "MBR for UEFI" and playing with gru4dos, can I please ask you to test with "GPT for UEFI" (using an official Windows ISO if you have one) for the time being? Also, because I have to say I am always suspicious of people who jump on an existing issue, saying "I have the same problem", and that I'll try to help, only to find out it was a different error, can you please confirm that, the output you see from UEFI:NTFS is: If it is, then please see my last post before yours and follow the steps I indicated, and report. |
|
Any update on this? Unless someone follows the steps I posted earlier to try to get some more insight about this issue, I will have to conclude that it is no longer affecting people, and close it. |
|
Closed. |
|
Sorry - cant test that just now as on site (no equipment as such) - will do tonight. Going to try with a portable HDD as opposed to a key to see if this makes a difference |
|
Hi again. I tested the new version you put out with the instructions and here's what I got. It looks good to me at least. |
|
Great! This is exactly what I was hoping to see. In that case, can you please run another test using 2.9 TEST3 which I just uploaded and which, if it works, should be close to what I'll be using regarding UEFI:NTFS for the 2.9 release. You can either run the same steps as the last test or try a Windows ISO and see if that works. |
|
I will be trying a Windows To Go Image. Hopefully it doesn't take long to do, as I will be heading out soon. Thank you so much for the help so far! |
It's you I have to thank! Couldn't do much without someone keen on playing with these various TEST versions. Feel free to take your time for the last test - I can wait. |
|
Ok sir! 👍 |
|
My problem may be slightly different as I have not been able to boot to USB at all (sorry should have mentioned that!) - I was using 'boot to efi file' option and selected the USB which I thought would work the same. Anyway if it helps I copied the bootx64.efi to the 2.9 TEST3 and using the 'boot to efi file' option I received the "Hello from NTFS" without problem. I do not have another large pen drive to test my ISO to see what happens and need the one currently using to image 20 Dells tomorrow!! I will pick up some more drives tomorrow and see what happens but as said I think I may have other problems with these laptops. |
|
@pbatard Great news! I am able to boot the Windows To Go Drive, so I guess whatever you did worked! |
|
@Michaelvas17, awesome news! As far as I can tell, part of the issue with HP firmwares then is that they don't like drivers that are of type (a.k.a. EFI subsystem) Up until now I was compiling the NTFS driver as That was a touch nut to crack, but I'm glad that, thanks to your help, we were able to crack it! 👍 I think the |
|
@pbatard my pleasure. Any time anything needs some testing, you know who to call. |
* Should fix the long-standing HP firmware compatibility as per #615, #549 and others * See pbatard/uefi-ntfs@2237006 for details
|
OK, I'm just going to point out that there's now a TEST4 if anybody's inclined to play with it. Unless I screwed up, it should behave the same as TEST3, but it includes the finalized UEFI:NTFS changes that will make it into the 2.9 release, so it's more of a paranoia check than anything else at this stage. If anyone is planning to perform further tests (and again, I have to stress out that there's really no hurry on this), please use TEST4 from now on. Thanks! |
|
I have the same problem as Michealvas1. I'm using HP 4540s. Trying your test4 with windows 10 image. Will report here. |
|
Didn't work out for me. I must be doing something wrong. I installed an unofficial iso then got the attached error.
Then I copied bootmx64.efi to efi/boot and got the hello from ntfs. It may be interesting to note I must have to press F9 to select boot from EFI otherwise HP logo hangs forever. Secure Boot is disabled. |
|
Confirmed working! Please ignore my above post. I was using invalid iso file that did not contain valid bootmx64.efi. |
|
@sgtroswell, no worries - thanks for the test! |
|
@pbatard Chiming in here to say this worked for me also (test4). I still have to manually select the boot file but I'm then straight into my MDT environment. I'm using an HP 9470m with the latest BIOS update. I also had the same error with an HP 840 G2 and expect this to resolved (I will test and report back when I next have one across my desk) Also just to say a massive thank you. I came across your UEFI:NTFS solution when I had to image a bunch of Microsoft Surfaces & Surface books. I also wished to maintain the same USB for a variety of HP and Lenovo models. Without your hard work I would be juggling sticks and maintaining multiple copies of ISOs which always leads to problems. So again thank you so much for this project and all your work. |
|
@notverynick, I greatly appreciate the testing and report. If you still see an issue with the other HP, please let me know. |
|
@pbatard , Genius!! Test 4 working (straight from flash drive) on HP probook 6570b - sorry it took time I was so busy over BH weekend. I did quickly test on brand new HP laptop (cant remember model) and had same results (set up looked same as this 6570)- Anyway I have so many to do over the next month or 2 - I will list the models working OK here as we have had every model of HP laptop through the door over last 4 years I think!! - The dual SSD / HDD ones will be interesting I think. Thanks so much for hard work. @notverynick sounds like you are using same like me - did you turn off legacy altogether as this one just booted from usb without me having to navigate to efi? Thanks all |
|
Spoke a bit to soon - image went on OK but on restart just sits there - if I enable CMS it goes through set up ok but when boots BSD's - I am sure its nothing to do with the work here just these firmwares "bios" etc, however if anyone has any ideas? - (yes i know I need to learn more!!) - I am using MDT 2013 ud 2 - ADK for win 10 and deploying a win 7 image @pbatard - you done your bit - but any advise as to why this would fail after reboot would be helpful. Thanks J |
|
@jason99991 I did turn off legacy, boot option set to full UEFI (or whatever the HP nomenclature is) I'm also having post imaging issues with my 9470m but this has to be my image as at that point Rufus has long done it's work. A colleague is preparing me a fresh image which he believes could solve my issue but for now I'm certain that Rufus is golden. |
|
@notverynick - _
_totally agree - what ever pbatard done solved the initial imaging from USB / efi but seems these machines do not know what to do after! -If its of any use I done one as MBR and it also blue screened. I have imaged these previously on legacy settings (some time ago) so am guessing maybe something to do with the bios update and drivers. I put Win 7 on a blade once 196G Ram and 32 cores to prove a point and these laptops giving me so much grief :( |
|
So I got an updated MDT image (circa 2012 R2) with re-worked task sequences (I'm told this included 'something' for UEFI) and I'm good to go. I've only imaged one machine but it's into Windows with no deployment errors and stable. I did still have to select the boot file, but that's inconsequential for me at least. This was using: rufus-2.9_TEST4 |
|
I'm using 2013 u2 with ADK for win 10 - getting various results. A brand new model HP (don't quote me but think it was 440) went on in full uefi gpt but not happening on my Dell AIO 3240's where as 2.9 (orig) works fine?? Older model HP laptops still giving problems but have not had time to test too much as yet. What I also noticed with the Dells is that after image they will boot if turning on Legacy after but it doesn't run through set up meaning no drivers at all - tried to bump it back into set up but didn't work. Sorry I am very time poor as deploying these things daily and at present using 2-3 sets of USB and network if ness. @pbatard love the work and I understand this is nothing to do with your work and I am sure I speak for others as well in a big thank you - Problem for me is that I don't fully understand what is happening i.e. when the image applies in UEFI GPT what stops the PC booting to it - Looked using diskpart and partitions seem to be there so wandering if its MDT / windows that has the problem. Would be grateful if you could point me in right direction for information (Google brings me straight back here:) --- Thanks Jason |
|
I'm afraid that, unless you get an error message during the UEFI:GPT phase (in which case I need to do what it is), whatever error you are encountering after the UEFI bootloader from the NTFS partition has started to execute is not really my concern. As much as I'd like to, I'm far too busy to play with custom Windows images, and the only elements that I will ever investigate as far as UEFI:NTFS goes are:
Anything that's outside this scope is not something I have time to look at, sorry. I'll just say this though: As far as UEFI is concerned, there shouldn't be any difference booting from GPT/FAT32 or GPT/NTFS, as long as an UEFI driver for the file system is provided (which is natively for FAT32, or through UEFI:NTFS for NTFS). If you have a firmware that does, my first guess would be that the issue is internal with that firmware... |
|
@pbatard - no worries I understand and will try and work out what is going on. I'm not sure if my post was clear though so FYI (not to look at or anything:) - I was using the same media set for the Dells on 2.9 v1 and it was working without issue - 2.9_Test 4 imaged the machines but refused to boot after. I realise that this maybe something to do with the deployment rules etc. but thought I would let you know as there must be a difference which may have an effect on standard retail builds as well. Cheers Jason |
I'm trying to create a UEFI bootable USB for a WinPE image to install Windows 7 Enterprise. I created an ISO from an NTFS-formatted bootable USB stick provided by the image maintainer (our supplier). The USB is recognised in UEFI boot, and the NTFS driver seems to be loading, then i get the following:
How can i debug this? I can't even see how it creates logs :)
The text was updated successfully, but these errors were encountered: