Might be helpful for those who have these problems.
After yesterday's adventures, I finally started testing. Are there any other bugs?
Thank God, everything is fine, and even the indexing of disks has been fixed compared to all previous versions of monterey (before, the time for indexing disks by the mds process after loading took about 5 minutes - now no more than a couple of minutes)
I have a lot of disks in my computer: instead of CDRom I have EFI opencore and all previous versions of opencore with different configs - cdf's, martin's, config for update, etc., macos 2tb on nvme, on sata M2 1tb I have windows, 4 sata HDD in raid10- this is a reserve of libraries, and on the PSI-e i have 4xNVME ssd evo plus 1TB each - one for working in Windows, 1TB libraries for 3D programs, and two 1TB disks in raid0 for libraries, working files and cache for twinmotion, UE5, blender. And probably the macos did not optimally indexed my disks every time
But now this mds process is completed very quickly.
Now, in order to understand what happened yesterday, I will write step by step:
for macos updates since monterey I use method 2 (before that I used method 1 and Martin's config)
Yesterday, it went wrong from the start.
When writing the config modified for the update on the efi, there was not enough free space (probably the trimforce disabled during previous updates and I have not checked its status for a long time)
in order not to think for a long time, I deleted the no_avx kext that I did not use and the config fit on the disk
but during the reboot for the MacOS update, the macos installer process did not want to end - with each reboot, the installer remained an opencore bootloader option (later I checked my config carefully - all necessary changes according the instruction for method 2 were done correctly)
then I installed Martin's opencore with changes for MacOS update, restarted the process via macos updates
12.6.7 successfully updated
when I tried to return the config to work in standard - efi again did not allow writing - I temporarily removed windows from efi in order to start the macOS work and overwrite the opencore disk
I deleted the apfs volume, reformatted the disk first as mbr by terminal, and then again reformatted as apfs with guid
now efi is free again and I recorded opencore and windows there, made trimforce enable and boot into windows.
Windows was updated and the driver for AMD 6800 was installed, but I use the driver for RadeonPRO, I had to reinstall driver. But after the necessary reboots, windows hangs on the login.
This often happens to me after windows updates - I have reported this.
Reseted smc and nvram - booted into windows - set everything up as it was before.
Further adventures from the previous post began....
This morning (when the system was working properly) I again found that the trimforce is disabled.
At first I thought, maybe the TRIM on my sata ssd conflicts with macos?
But no, I again enable trim and have been testing the work for three hours, there are no bugs
so it must have been something else
EDITED
I thought that if the procedure for updating the macOS according to the second method did not work for me, then my system ROM is not healthy
I flashed system ROM by recreated BootROM image ( made by tsialex for my cMP- he recommends doing the procedure periodically)
I work on the computer after the procedure for two weeks.
no more errors observed
