BonzaiDuck
Lifer
I built my system as a dual-boot Win7/Win10 configuration -- the Skylake in my sig.
I was still tweaking and perfecting it last year, when Creator Update 1703 arrived.
It borked my dual-boot menu. It took me as much as a week or more to sort things out, and complicating this was my PrimoCache configuration. The Primo was really a minor difficulty, and Macrium Reflect helped me get my dual-boot menu back.
So when Build 1709 was announced, I decided to defer it as long as possible. I have too much serious stuff ongoing with this system. It's too perfect.
However . . .
Somehow, Win 10 over-rode my choice to defer the new 1709 build for a full year. This morning, the Update took over my machine!
Since I have a good imaging backup system, I just crossed my fingers and let it all ride -- through several reboots.
I'm impressed.
The dual-boot configuration remained intact, tip-top, totally functional and undamaged.
PrimoCache didn't interfere with anything, but I discovered the two caching tasks I'd defined were blank -- without any assignment of source disks to be cached. At first, I thought I'd simply delete the caching tasks and redefine them. This would mean deleting the L2 SSD cache using a Sammy 960 EVO 250 GB NVME drive, and recreating the caching volume, which would then be reformatted by Primo as a non-standard volume.
But . . . wait. I thought I'd try simply ADDING the original source disk to be cached to the caching task. This would mean the content of the pre-1709 caching volume would remain intact. And since it didn't contain the operating system, one would think there would be no problem with that.
And -- there wasn't any!
I turned off the feature of the caching task for my boot-system C: drive which restored the cache at boot-time. This caching task was purely a RAM cache. Then, I rebooted. Now I can re-enable the same feature, and there should be no problem at all.
Voila! All is wonderful!
As much as I despise the commercialization of Windows, the herding of users to create a Microsoft account as opposed to managing the system as a workplace computer with a local password, the prods and pop-ups, this was a creators update build that seemed to install flawlessly without borking my chosen, custom configuration.
And I have to mention my use of Classic Shell. Classic Shell reconfigured itself automatically to the new build without a hitch, and continued to work just tip-top and fine.
I guess I have to say that I'm happier than a pig in shit.
And as much as a lot of us have been disgruntled at the disruption of our habitual computing, functionality and appearance with Windows 10, I can't complain about one . . . damn . . . thing with this new build.
Hoo-Wah!!
I was still tweaking and perfecting it last year, when Creator Update 1703 arrived.
It borked my dual-boot menu. It took me as much as a week or more to sort things out, and complicating this was my PrimoCache configuration. The Primo was really a minor difficulty, and Macrium Reflect helped me get my dual-boot menu back.
So when Build 1709 was announced, I decided to defer it as long as possible. I have too much serious stuff ongoing with this system. It's too perfect.
However . . .
Somehow, Win 10 over-rode my choice to defer the new 1709 build for a full year. This morning, the Update took over my machine!
Since I have a good imaging backup system, I just crossed my fingers and let it all ride -- through several reboots.
I'm impressed.
The dual-boot configuration remained intact, tip-top, totally functional and undamaged.
PrimoCache didn't interfere with anything, but I discovered the two caching tasks I'd defined were blank -- without any assignment of source disks to be cached. At first, I thought I'd simply delete the caching tasks and redefine them. This would mean deleting the L2 SSD cache using a Sammy 960 EVO 250 GB NVME drive, and recreating the caching volume, which would then be reformatted by Primo as a non-standard volume.
But . . . wait. I thought I'd try simply ADDING the original source disk to be cached to the caching task. This would mean the content of the pre-1709 caching volume would remain intact. And since it didn't contain the operating system, one would think there would be no problem with that.
And -- there wasn't any!
I turned off the feature of the caching task for my boot-system C: drive which restored the cache at boot-time. This caching task was purely a RAM cache. Then, I rebooted. Now I can re-enable the same feature, and there should be no problem at all.
Voila! All is wonderful!
As much as I despise the commercialization of Windows, the herding of users to create a Microsoft account as opposed to managing the system as a workplace computer with a local password, the prods and pop-ups, this was a creators update build that seemed to install flawlessly without borking my chosen, custom configuration.
And I have to mention my use of Classic Shell. Classic Shell reconfigured itself automatically to the new build without a hitch, and continued to work just tip-top and fine.
I guess I have to say that I'm happier than a pig in shit.
And as much as a lot of us have been disgruntled at the disruption of our habitual computing, functionality and appearance with Windows 10, I can't complain about one . . . damn . . . thing with this new build.
Hoo-Wah!!
