Just leave versioning to @abbodi1406, so that we can get 1.5.2f, 1.5.2r and 1.5.2u versions. Or, more seriously, count up a release number whenever a change is made. 1.5.2-r1, 1.5.2-r2 and so on. Everyone having an outdated copy will notice immediately.
Updated UUP dump app to version 1.6.0 Changelog: - The "MSIT {Internal Corpnet}" channel will always have "Generate packs: NO" option - Updated genpack.php to always skip [Internal Corpnet Required] updates This should be the last major update, I couldn't find any more issues with it Thanks to @abbodi1406 for all the help p.s. "local server" has been renamed to "app" because users were confused by the previous name
After upgrading my Computer to the latest 13Gen select all options, updates, ESD, bla bla. Noticeable differences compared to my old 9700K Spoiler: Image
1.separate scripts are available in the scripts folder, all of which also work in the root uupdump directory just move "uupdump-get.cmd" and "uupdump-run.cmd" scripts to the "uupdump-x64" folder, then move "uupdump-aio.cmd" script to the scripts folder 2. edit "uupdump-get.cmd" and "uupdump-run.cmd" scripts and change default options
Is there any way to do the same thing in Linux as the script for downloading packages? My server is running. I have PHP 8 on it, and I'm just wondering how to initiate a content update (download packages). Thanks for help...
Does UUP dump app have the same restrictions as the UUP dump website of converting and building Win10/11 iso files on lower host OS versions (e.g. on Win8.1)?
Dear @abbodi1406 , I wonder is this restriction inherent to the host OS (e.g. Win8.1)? Is it possible to remove this restriction through shipping UUP dump app with some tools? Or by modifications of your script uup-converter?
DISM, even when updated, just fails to service the new versions correctly (integrating LCU), on the old host OS. Nothing to do with the script. AFAIK you can still create valid ISOs if you don't integrate updates. Edit: Just wondering if Wimlib has the same issue?
Upgraded to the local server version 1.6.0 and tried to build an 22621.2361 ISO. Everything went fine with the downloaded script 22621.2361_amd64_de-de_professional_cc66a258_convert.zip, but in the end the script created an ISO that is named 22621.1.220506-1250.NI_RELEASE_CLIENTPRO_OEMRET_X64FRE_DE-DE.ISO (which with approx. 4,33 GB size is also way smaller than the previous ISO for 22621.2359, which resulted in 6,70 GB with the default settings). So: wrong version (22621.1) and wrong timestamp (22-05-06 instead of 23-09-xx as would've expected). Any idea what went wrong here? Problem with the generated script/zip archive? Or already incorrect (meta)data from Microsoft (called "fileinfo" in the uupdump context I assume) or incorrect "pack" generated?
Sounds as if there was an error integrating updates. Except for the initial build (which you now got), each build is UUP set of the initial build + latest updates. The converter script is supposed to integrate these updates, the result is the final build. For making a 22621.x build, the conversion must be done on Windows 10, version 2004 or later, otherwise it won't work correctly.
send us uup-converter log and we'll see 1. run Remove_Failure_MountDir_TempDir.cmd and remove all old stuff 2. try to build it again but this time save the log from console window when it's done and yeah, host OS should be 19041+
What do you mean? If you can't get specific build then edit config.ini ("fetch_sync_current_only=true") and add any old build on the website
External updates mode can be used the Apps will be integrated into install.wim (still work for pre Win10 v1809 host os, but didn't test latest Canary builds 259xx) and updates will be added to the ISO and installed during setup Wimlib has no issue (why would it?)
I am running the new 1.60 version and I keep selecting "Detect New Builds", but the app doesn't find any. Looking for 22631 whatever is the latest.