New
#1060
It might need updating but I don't believe that UUPtoISO is the culprit.
If a clean install is done from a HDD, even if the ISO was created with UUPtoISO's current version, you get the normal installation menu at startup. My suspicion is that it's all related to USB and/or VMs installations and perhaps Legacy Bios and MBR. That would explain (in mi case at least) all the failed updates since 17040.
Within FCU, I mounted the ISO, copied the files to a directory on my 2nd HDD (which is just a backup drive without any OS), then restarted FCU from the recovery menu to get to command prompt, switched to the 2nd HDD's directory and excecuted setup.exe.
That same method even worked on my obsolete 32bit Dell laptop that was stuck on 17040. I'm talking Legacy bios and MBR on both machines, the newer 64bit Lenovo was stuck on 17046 and now they're both up to date.
Both methods (USB/VM vs HDD) are basically the same but behave differently.
Basically you did the same as I suggested in this post, you just added an extra step by copying ISO content to secondary HDD.
Both methods work.
Your method is explained in this tutorial: Clean Install Windows 10 without DVD or USB Flash Drive | Windows 10 Tutorials
Kari
NoteGeeks, I have not had time to update UUPtoISO tool. I will do it before the end of the week. With these new builds (Fast & Skippy) released today February 15th (14th on the wrong side of the big pond), download latest converter from my OneDrive and use it instead of our tool: Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.
Kari
No, both your suggestion and your tutorial are not the same and I didn't read any of them beforehand, it was trial and error.
Your post describe going thru command prompt because you have to, and due to the fact that instead of the installation menu you get the repair menu. In my method, I force the repair menu by choice to get to the command prompt.
Perhaps your eagerness to disagree with me clouds the fact that I was defending your program and blaming the other methods.
You said "What it means is that it's time to update our tool". Well..., your tool might need updating but in its current version it works just fine depending on which method you use.
If you install from a mounted image, a USB stick or within a VM, the repair menu will show.
If you install from a directory on a secondary HDD, the installation menu will show as usual.
No offense, Equito, but this had already been discussed, even prior to the coding bug that excluded ARM64 ISOs from being generated by UUP2ISO.
I've linked the most appropriate post on the matter above your post.
The tool is supposed to provide the user with a bootable .ISO (which can then be transferred to any medium that the machine can boot from) in order to allow for a (re)installation, and as such, until now, has worked exactly as intended, until this wimlib issue cropped up with build 17093. As such, with the files as they appear in the tool currently, exactly what you and several others reported is what happens.
If you use the .ZIP file that Kari links to, it uses the relevant dll that fixes the issue.
But I do like your forcing of command prompt lol. That was a neat trick.
No offense taken but I'm not sure what are we discussing here anymore. Perhaps the meaning of my original post got lost in translation.
All I was trying to say is that even if the tool is at fault, it works fine under certain unusual circumstances and thanks to that and this bug, I was finally able to update my machines and that's all I care.
Take care John, cheers!
I'm out