The.msu files include the Microsoft nvme drivers. They do not come separately as inf, cat, sys. That is why they are installed using add-package command. Simplix integrates them directly using the add-package command. They are .msu files. KB2990941-v3.msu KB3087873-v2.msu
Well it seems i'm unable to, so try to elaborate, because i don't have a system with an M.2 NVMe ssd to test it.
In my own words he is saying you have to manually integrate the 2 NVMe updates into boot.wim, as expected because simplix pack doesn't service boot.wim.
That I understood perfectly well, what I don't understand is: "It is a problem because the sources folder in boot.wim is not updated. It still contains 17514 files. The Installation media has been updated, so the installation media sources folder contains the 18015 files. If you run setup.exe from boot.wim, it does not recognize the installation media."
setup.exe in ISO sources folder, and setup.exe inside boot.wim\2\sources must be the exact same file otherwise you will get error and installation file is ot recognized what i understood from @CEW reply, is that /NVME switch update winre.wim, and copies updated setup files to ISO sources folder in that case setup.exe will differ from unupdated boot.wim
It can't copy files to the sources folder or change anything in boot.wim, the updatepack only works on install.wim. At least when you use it like i do, using the offline batches.
Yes we know. We are going round in circles. That is why you will not be able to use boot.wim to install if you used the /nvme switch. Therefore if you want tuse the/nvme switch, integrate the 2 MS msu into boot.wim using some other method. Those msu files are not very recent. Maybe they are not needed. Maybe it is better to only use the oem nvme drivers provided by Samsung, etc.
Unless you integrate Convenience Rollup KB3125574, both are needed they add the support for OS to recognize NVMe drivers
I'm having a problem with 18.8.20, first time ever using Simplix. I'm using it on an installed system, Windows 7 Pro x86_64. Everything appears to be OK during the installation, but after the reboot, I get the message that "all changes are being reverted" (forget the exact wording). Then another reboot and I'm back to where I started. If I run it without the /silent switch, will I get a better idea of exactly where it's failing? EDIT: Just ran a full scan with BitDefender and Malwarebytes. Also ran chkdsk and sfc/scannow. No problems in any of those areas.
What exactly is a windows 7 Pro x86_x64? Is it a x86 or a x64 install on which the updatepack is ran? Or is it a incorrectly installed dual boot install (x86 and x64 on the same partition)?
It's Windows 7 Pro 64 bit (x86_64). Only OS installed. Sorry for using terminology that's been around since 1999.
I don't understand, is the installed OS x86 or x64, a bit confusing to call it x86_64. The install will be either x86 or x64. Can you post the log file? It's supposed to be in "c:\windows".
Now this is strange. I re-installed Windows 7 from a backup image I made on 6/11/2018, then ran Simplix Update Pack 18.8.20 again. It installed 5 updates: KB2920188-v7, KB2972211, KB2978120, KB4344152, and KB4343900. No errors, no reverting, no problems. Something must have happened to Windows between 6/11 and yesterday to cause the problem, but I have no idea what it was, other than Windows behaving like Windows. LOL. The installation log of UpdatePack 7 / 2008 R2 / 18.8.20 Installation start time - 16:26:54 25.08.2018 Operating system - Windows 7 Professional SP1 x64 KB2920188-v7 - To complete the installation a reboot required KB2972211 - To complete the installation a reboot required KB2978120 - To complete the installation a reboot required KB4344152 - To complete the installation a reboot required KB4343900 - To complete the installation a reboot required Installation finish time - 16:34:45 25.08.2018 The number of installed updates - 5 Total installation time of UpdatePack - 07:51 Operation of the program has been successfully finished Once again, Macrium Reflect has saved the day.
The used terminology is correct. x86_64 - the former x86 is the processor platform (Intel x86) and the latter the architecture (or 'bitness'). x64 is used as alternative descriptor because people are lazy (or like to use strings with hardcoded length). Contrary to public belief the 64bit Intel-type processors are not fundamentally different from the legacy 32bit ones. They merely have increased register sizes and additional 64bit instruction sets to make use of them (AMD64).