New
#30
It's in the known issues. There is no fix.
Hi, I repeated the update from a restored image of 18932 and it always failed the 1st time withError 0xc1900101, then I tried the update from a USB media created from the 18936 iso and the second attempt worked.
I'm now up with 18936, but I'll repeat the process when MS comes out with a fix.
Updated in first try and in 40 minutes. All i right except graphics, both 2D and 3D slowed to a crawl, Updated GPU and chipest drivers but still slow to borderline usability. Will try clean install of drivers later on but drivers are same as in non-Skippy installation.
My machine updated on first go this time. I had to go out for several hours. It had got to waiting for the restart before I went out, but I didn't reboot till I had returned. A couple of oddities, It restarted at 30% as usual, but didn't switch the display to my 3rd monitor this time (the one driven by the onboard graphics.) Then it did the usual reboot at 75%, advanced to 80 something %. It rebooted again, and progressed from 75% to completion. (Primary dispaly is set in the UEFI BIOS as PCIe, not onboard, as well as in Windows Settings.)
I always reboot the system again immediately after a successful update, as there have been instances where some drivers (or whatever) have not installed at the first boot after updating. The "Restarting" screen always has a blue background, not the usual green background, at this additional restart after updating.
Just an idea: You could try Macrium viBoot.
This is a storage driver issue, according to release notes. If you boot your last Macrium image in Hyper-V using viBoot, the host system storage drivers will be dormant, as VM is using Hyper-V drivers-
To be sure WU is disabled on VM, in tutorial step 2.6 select no virtual switch, boot VM without network connection:
This also prevents any NetBIOS related conflicts, which might abort upgrade because the VM and host have the same GUID and PC name.
When VM has booted, delete everything in SoftwarDistribution\Downloads folder to assure remnants from failed upgrades are not affecting upgrade. Now attach the 18936 ISO to VM and upgrade it. If it works, save the VM in new image, and restore to host.
Theoretically thinking, this could work.
Kari
Hi folks
Using UUPDUMP it has worked perfectly for me on 2 physical laptops - one an old SONY VAIO with Pentium IV processor (the heat that thing chucks out would probably heat a whole village !!!) and an HP envy laptop with Intel i7 processor. It also works on a VM running VMWare on a Linux host running on an AMD machine
My only issue with the build is that every time in these Fast / skippy releases they seem to hose up the language settings even when they say it's fixed-- frustrating when in the current 19H1 build(s) it works correctly !!!!!
While people might want to test the standard WU update - OK then that's fine reorting the issues - but for those other folk who just want to install and use the build UUPDUMP seems to work (at least in my case) every time and also if you want to upgrade more than one machine it saves a load of multiple downloads too.
What I really want from these builds though is a "persistent sandbox" - the current one isn't much use if you need to test soft/hardware that requires re-boot after install or other software which benefit after a re-boot when making parameter / setting changes.
The WSL seems to be going in the right direction -- it's quite fun getting some GUI programs to run --you need to install an X-Server on the Windows machine -- you can't yet (or I haven't been able to --so not necessarily the same thing) get a full windowed GUI desktop on the WSL -- if someone has managed it please post !!!!!!!
I'd also like a better file system (journaled preferably) to replace the aging NTFS system and some sort of sensible software RAID --standard Windows "Storage spaces" and mirroring / striping is hideous and breaks very easily - and not recoverable if it does break.
Cheers
jimbo