Rufus 2.10 BIOS/UEFI-CSM FAT32 will not boot on old BIOS PC #813
Assignees
Comments
|
Using Alt-E for same ISO on FAT32 - doesn't boot on BIOS PC. Log |
I hate to call bullshit on this, but I'm not aware of Microsoft ever publishing a retail 32+64 bit ISO... Also, Microsoft calls the latest Windows refresh 1607, not 1608. So, unless you renamed it, that So, while I would very much like to be proved wrong, there's already something fishy about the ISO you use, which looks like something custom... Of course, you do realize that the only Windows ISOs I can officially support are the ones that are officially released by Microsoft. At this stage, I am therefore going to assume that you are using a custom ISO, which, as I said, is unsupported. My guess is that it might have be based on WinPE 4.0, and that you are therefore running into a bug which I recently fixed that could allow people to use FAT32, where they should only have been able to use NTFS, but that only affected custom ISOs. In that case, I have a very early test version of Rufus 2.11 that addresses this issue and that I'd like you to try. Do you see the same issue there? Oh, and of course, if you have a link for where you downloaded your ISO, I'd like to have it so that I can test it myself. |
|
PS: An SHA-1 of your ISO (which is something I also ask for in the checklist, but that you chose to skip) would also provide invaluable information about the nature of your ISO. There's a reason why I ask for all these things you know — it helps validate what people report... |
|
To answer your nit-pick, it is the 1607 version, but it was downloaded in August hence 1608 (though I agree I should have named it 1607). It is not a custom ISO - it is absolutely as downloaded from Microsoft. To make the dual ISO, you use the Media Creation Tool. This allows you to download an ISO - which can be Pro/Home or just Home, and x32, x64 or both and to select a default locale too. So there are 2 x 3 x 38 locales i.e. 228 different possible ISOs. AFAIK, MS has not published the checksums for these. The checksums for my ISO are:
Please feel free to download the English (UK) version of the Pro x32/x64 ISO (only a 6GB download) and calculate your own checksums to confirm that they are the same as mine. I ran Rufus 2.10 again using NTFS and it boots fine. I will test the alpha 2.11 version tomorrow as soon as I have finished work. P.S. What exactly do the checksums above tell you about the nature of my ISO? |
|
Actually I have tested it now:
I get the following message box:
The log is empty. Is this what you intended? |
|
P.S. I noticed that the User Rufus MBR checkbox is not set by default in the test version. But checking it makes no difference. |
|
P.P.S. Happy to try more test versions if it will help. |
|
Ah OK. All signs seemed to point out to a custom All-In-One ISO (I do get a lot of requests using these), but I stand corrected. I wasn't aware the Media Creation Tool offered the 32+64 bit option, and I tend to avoid using it for creating ISOs, as Microsoft managed to create I guess I'll download one these 32+64 bit ISOs and play with it a little bit.
Yup. Rufus is meant to force NTFS for Windows ISOs whenever you create a BIOS bootable drive (only pure UEFI should allow the selection of FAT32). So FAT32 should not have been selectable, and won't be in the next version of Rufus. Now, if you pick NTFS, it should boot fine from BIOS (and hopefully from UEFI if you use Alt-E, though that's one thing I'm planning to test with the MCT ISO). |
|
It occurs to me that you may believe that this is a custom WinPE image because it doesn't have Also, happy to upload my image to a web server you can download it from if you want a copy of the exact ISO image I am using. |
|
Nah, I do believe you and I happily admit that I was wrong to assume you were using something that didn't originate from Microsoft. I tested the MCT and I confirm that it offers a 32+64 bit option. I'm downloading my own MCT ISO as we speak, which I fully expect to behave exactly as yours, so, while I appreciate the offer, you don't have to upload anything, thanks! |
|
Don't worry. In your place I would probably be highly sceptical and unsympathetic myself. I can quite imagine just how many people you get telling you that they are using a MS ISO when in fact they are using a custom one. Looking at a few bits of your code I can see that you do a lot of stuff which is dependent on the type of ISO - its obviously not as simple (as I naively thought) as creating the partition, copying the boot sector(s) from the ISO and then copying the files over in the same structure (starting with the files in the root directory before recursing - so as to put the boot files in low sectors). If it were that simple, then you might be able to support any ISO - but once you get into ISO-format-specific activities, then you can obviously only support a limited set of ISO formats that you code for and can test. Anyway, back to you. |
I am confused. I was under the impression that you cannot boot from an NTFS partition on a pure UEFI machine because UEFI only understands FAT. So if you want an image which is bootable on both BIOS and UEFI machines - doesn't it need to be FAT32 (or have a FAT32 UEFI-loader partition). If you then want to be able to read (and write) the USB partitions from Windows as well as boot from it, doesn't that raise further issues because Windows cannot handle multiple partitions on a USB stick? (I tried it once and it wouldn't allow it or couldn't see the subsequent partitions). Is there a technical reason that you can't have a FAT32 file system for joint BIOS / UEFI images? (I haven't tried the working BIOS/UEFI FAT32 image I created (using |
There are some ways to make UEFI boot NTFS... 😄
No. If I wanted to, it would be fairly easy to add it in Rufus. But I have to cater to people who have no clue whether their computer booted in BIOS or UEFI mode, and will get annoyed if they spent a couple hours installing Windows on their UEFI computer, only to discover they actually installed it in BIOS/CSM mode. If I were to allow FAT32, and keep this feature, I'd have to start removing files from the original ISO to prevent UEFI boot when only BIOS/CSM should be enabled, and one of the major design goals of Rufus is to keep the USB content as close as possible to the ISO, so that's not something I really want to do. It's much easier to force BIOS boot for Windows to only use NTFS as, if you don't install the UEFI:NTFS partition, it will (usually) not be bootable at all from UEFI. |
|
Ok - I have read your FAQ again plus the readme from your UEFI:NTFS repo, and I think I understand. And my hat off to you for creating UEFI:NTFS - which seems a very elegant solution. So, whilst there may be no theoretical reason that you can't have a FAT32 dual BIOS / UEFI solution, there is no need for it if you have UEFI:NTFS - and not allowing FAT32 in this situation means that you don't have to support it (which is a very good reason not to allow it). In which case, perhaps better to allow only NTFS for Windows NT onwards. In which case my only comment is that rather than giving the above error box when someone tries to create a FAT32 image, it would be better to grey out the option in the File System drop-down and provide a tooltip explaining why it is disabled. |
|
Oh, and another very important thing that I need to mention here, is the 4GB file limit for FAT32 system. Microsoft is know to actually have released an official ISO that contained a >4GB |
|
+1 |
Yeah, I actually thought about doing that, but greyed out options can be confusing, and more difficult to implement/maintain than a messagebox. Heck, I did manage to screw up the conditions that prompt the "use a different FS with this type of ISO" to appear, and didn't notice it for some time, so I'm not that optimistic about my ability to ensure that greyed out options stay greyed out as they should. Also, since I'm hoping that in the long run I can add some automated testing to check for breakage, message boxes are much easier to convert to a PASS/FAIL test compared to checking if a line is read-only in a dropdown. I'm still a very long way to add automated testing though... |
|
Ok - busy creating an NTFS compressed image to try (Alt-E/S/N) - and yes I know compression is unsupported. Writing this is also MUCH (an order of magnitude?) slower. And it seems to have saved only c. 3% of disk space, so hardly worth it. (In passing I note that the NTFS volume is created with the allow file contents to be indexable flag set - I have no idea whether this is right or not, but you might want to think about whether it should be off.) |
|
For the greyed out options, you might want to consider implementing a lookup table which defines what is greyed out and provides the text (or I18N key) for a tooltip explanation. This would make the code generic and easier to test, and make it much simpler to make changes to what is greyed out when. You could extend this to include the You have 3 choices for partition scheme, and four choices for file system and 8 choices for bootable disk type so the table would have 96 rows. Finally on a UI note, can I lobby to have the Alt-E cheat moved to a check box in Advanced options. |
I guess you know why compression is only available as a cheat mode. Somebody really wanted it, and it was relatively easy to add, so I did, but Microsoft really should take some lessons on compression (their VHD compression algorithms also suck)...
As far as I know, that's what the default Windows format tool does (with no option to disable it), and I try to follow what the Microsoft format tool does where possible. If it's easy to do, I'll see if I can add that feature as a cheat mode (I have now made a note for that in #799). |
|
As to adding a new item to the Advanced options, I'm not planning to do UI changes before I can get through some UI redesign (#117), that I've been trying to get started for more than a few years now, but that I may very well be the only one to understand the need for)... |
|
Actually, reflecting on the Alt-E UI comment above whilst in the shower this morning, I think it makes more sense to have two items in the Partition Scheme dropdown - one for And I can see why you are hesitant about starting on a UI rework. |
|
Okay, I played with the MCT dual 32/64 bit ISO, and I think it behaves as expected when converted to bootable USB with the upcoming Rufus 2.11, so I will close this issue. As to the suggestion of using "BIOS Compatibility", that's something I played with when I added the options, but the problem here is width. This dropdown is usually the one's that the largest in all translations (NB: it may look like there's tons of space to do it on modern Windows, but you need to consider XP), and using "BIOS Compatibility" means that I would have to expand the width of the application. Doesn't sound like a big deal, huh? Well it is when your translation framework relies on manually resizing all the elements according to the application width → doing so would be a major undertaking as I'd need to update the size 15 controls for almost every single one of the 36 translations. However, and much to my chagrin, many people seem to be oblivious to it, there are very helpful tooltips for every single of the options from that dropdown, which will tell you precisely which one you should select. Also, IMO, people need to become familiar with the CSM acronym, just as they have become familiar with UEFI or Secure Boot, especially as many UEFI firmwares will use CSM and not "BIOS Compatibility" in their options. So trying to shy away from knowing the proper terminology of the stuff you use is not a good bet, and will confuse users further. Finally, you'll be happy to hear that I've added a new cheat mode (Alt-Q) to disable file indexing on format, for the files systems that support it (NTFS, UDF and ReFS). This will be part of Rufus 2.11 |
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
<PLEASE READ THIS CAREFULLY: You MUST read and complete the checklist below, by placing an x into each [ ], BEFORE clicking on 'Submit new issue'. Failure to perform these steps, WHICH ARE ONLY THERE TO HELP YOU, will result in the issue being dismissed without warning.>
Checklist
Logbutton in Rufus and copy/pasted the log into the line that says<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
#button (at the bottom of the Rufus interface), 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
I downloaded the Win10 1608 ISO (x32/x64) from Microsoft and used Rufus to create a BIOS bootable USB image using the following settings:
When I tried to boot this on a BIOS PC and got the error message
Invalid System Disk.I then ran
bootsect /nt60 e:and the image was bootable and I was able to install Windows 10 from it.Note: I was unable to find MD5/SHA checksums for the UK English x32/x64 image to check valid download, but since I was able to install fro it in the end I do not believe that it is an issue of a bad download.
Log
I will try the Alt-E checat code and report back.
The text was updated successfully, but these errors were encountered: