It's a known bug, unfortunately proper fix doesn't exist, Microsoft is supposed to release cumulative update at the end of Novemeber that will fix file association issues.
Sorry for being annoying d**k, just to be sure, that the .iso's are brewed via the EVAL+SVF method. Any chance of timebombing by MS, while using such installation, or maybe some other fun stuff (like unpatched bug with file deletion from MS) included? How we can be sure?
NO Homebrew ISO's are allowed here on MDL, all SVF patches are created from original VLSC, Techbench or MVS iso's. All checksums can be verified by people with VLSC or MVS memberships and some of them list them for us in a txt file.
You should check what SVF method does . Delta patching isn't brewing at all, the resulting target ISO will always be hash identic to the respective MVS or VLSC ISO it was created from. Although SHA-1 is theorethically compromised, this was only possible with very small files not any 4 GB ISO files, so the SHA-1 still doesn't lie.
Yes. Just in case you do not know what's it all about.... MDL is known to offer original untampered ISOs only. A checksum is like a signature. It makes sure the file is original and has properly been downloaded / SVF patched.... After D/L (or patching to a desired ISO) calculate the SHA-1 sum (hash) of the ISO with a common hash tool (for instance HashCheck) and compare it to the sources... Either way patching or downloading directly leads to the absolutely same ISO.
This has been a pain for years, its nothing new. The OS does get the message eventually, its not a bug, MS want you to use their apps and make life difficult if you prefer to use an alternative.
Which version of the Enterprise LTSB is stable for use with no error? I'm still on LTSB 2016 ver.1607
Dumb questions ahead: Is build 17763 still the current build? Is this Windows 10 LTSC 2019 already? Is it possible to donload the evaluation version and change it to a standard version, like it is possible with Windows Server?
I agree, but, theoretically, the .iso file is archive, which consists of many small files, each of them can be easilly modified and the only one condition to check is the file good is it's size, not a checksum... So, theoretically, we got a big file with the same size, as a result, the same hash, but nobody can be sure it is 100% legit at the components level. There is no deal today.
The hash is made of every file contained in the iso, size is the one thing that can easily be fixed by people who tinkered with the iso. To crack the sha-1 checksum of an windows iso would take years on a supercomputer.
That's inaccurate. Sha-1 has been defeated since 2011. These days any serious bitcoin miner can be considered having a supercomputer - gpu's are perfect for this kind of job. And then there's cloud rental. The proof of concept by google for pdfs is exploiting the format (container) to collide only parts of the file - so it can be done for iso too, size is not an impediment at all - you work with couple parts of the chain, not the whole thing. Not to mention that these things evolve exponentially in time, after the first breach. Nobody should use crc / md5 / sha1 anymore - but they just go with it because it's processing cheaper. No idea why MS is not dropping it - but then again, they still use md5.. In any case, it should always be the combo of size + hash like you've mentioned.
They cracked the sha-1 of a 150kb pdf file, it took many hours, to be able to crack the sha-1 of a full iso, would take xxxxxxxxxxxxxx more time. For windows iso's the sha-1 still is sufficient.
Nope. The algorithm is broken, and it does not matter if the file is 150kb or 150GB! If it were an absolutely unique hash it would be huge - like them svf patches Sha-1 is not sufficient - that's why MS is sharing not only the sha-1, but the size, and even the older md5 that many including myself found pointless! But that's probably a compromise on processing expenses as it's trivial to compute the md5, assuming it's a lot harder to defeat 2 algorithms at the same time (md5 + sha-1) - not impossible tough. It's been too long, google is impatient and wants to see sha1 dead and buried. But it's hard to change the whole www now, with all those enormous databases of sha-1 hashes everywhere. Baby steps. That's good news, @fLOW.
Hp Microserver N40 / N54L. If you need Hyper-V on it, LTSB 2015 is the only one fully working. Anything above it (even 1511) breaks the HW acceleration (black screeen on WMP/WMC and so on). You can add an external VGA, to workaround the probem but that undermines the idea of a minimal consumption server / HTPC You can also use the LAV codecs in SW mode, but you'll get 90%of CPU usage instead of 4/5%, which in turn breaks the minimal power consumption idea as well. That's a corner case, but I guess there are other scenarios where 10240 is still required. The IT world is plenty of corners.