safe boot (hold shift) WAS working fine with CPU available but limited by the fact it doesnt load everything.
I then did Justin Silvers method of removing older kexts.
Particularly previous to that i was only managing kexts under
~/Library but now i was also removing older ones from
One of the kexts i removed was PACEsupport and i also moved other Mbox2 related old kexts. These were from pre 2015.
But this didnt fix things immediately and not even after restart, but it did force the cache to rebuild itself from scratch as i watch it do so in
verbose boot mode (cmd+v).
So i went out to buy a replacement cord as i had given up on fixing the O.S and was going to try to get my old external HD to restore an old snapshot if possible, then suddenly out of the blue it released CPU resources again & now kernel is processing fine again & now i just need to find the correct way to recognise my old external HD.
At the time it released resources it seemed to be processing a lot of
QuickLookSatellite processes & i took a snapshot here.
As you can see the kernel was using all the CPU (at times up to 1300% or more) and here it falls off the cliff back to 18% seemingly randomly but i think it just finally processed all the kext cache again and maybe some of the removed kexts were no longer preventing it. But i think there were several kexts that were problematic here particularly originally the
Commander uninstall kext process was DDoSing the kernel CPU.
indeed the problem returned.
however i was able to fix it by doing the below.
After the disk decryption process finished, i still couldn't reinstall the O.S through recovery boot, because of connection to apple server problems, even after fixing datetime synchronisation problems.
I was however able to get my system functioning again by removing some startup items and daemons that i think were flooding my system CPU usage. I found these via inspecting the console (in utility folder) and by using EtreCheck tool.
Effectively a couple of older kexts were continually polling my O.S kernel (particularly one called
Commander, associated with an old WIFI dongle uninstall process and another one associate with an old program called
NoSleep that would prevent the O.S from sleeping but was designed for an older O.S).
These mustve been in conflict with kernel changes in high sierra + update. So they were effectively DDOSing my O.S and consequently kernel CPU was flooded. Stopping these and removing a bunch of unneeded kexts seems to have fixed the problem into a functional O.S again. Im unsure if it was only those two kexts or other removed kexts that ultimately fixed the problem, but at least this gives you an idea of what to do if you have the same problem.
My bootup time became faster but seemingly not yet back to pre-problem speed.
However, the O.S is now completely functional again, with idle CPU kernal usage down to minimal and user CPU usage available again.
Originally accepted answer:
strangely enough, i used my windows boot for a few days, and even did
a windows update, then i tried to boot Mac again and its working
mostly fine now, it still took a bit slower to boot (but not 20
minutes like it was doing before), and the decrypting is not even
finished now. So apart from not using the volume for a few days, i
have no idea why it is now working seemingly well again. Id suggest if
you have a similar problem to look at the links i've posted in the
question details. Perhaps just accessing the boot sector with Windows
helped fix up some files or perhaps it was the last First Aid i was
manage to do which didnt immediately fix it but mayve fixed it but
took a few boots for me to realise. its also possible the problem is
not fully fixed and will return but im offering this as the answer for