Mac OS Updates Fail to Complete

[MarioG-X]

RefindPlus Version

v0.13.2.AP Release

Device Type

Apple Mac

Problem Description

AP (and X233) prevents macOS updates from completing. Testing all failed the same way: iMac 27 2012 with 2 Catalina systems Mac mini 2014 with 1 Big Sur and 2 Monterey systems

I installed RP AN to determine this issue is related to AP and not macOS or firmware. I also tested by renaming the refind folder to refindx (any rename would probably work) and the updates worked.

Here is what used to happen with RP AN and previous:

1. Update any macOS from the Settings, and it would download, install, and reboot a few times.
2. Final reboot would work and RP would be deactivated by the process
3. Reinstall Refind, then RP to get back to RP booting.

Here is what happens with AP and X233:

1. Update any macOS from the Settings, and it would download, install, and reboot a few times.
2. What should be the final reboot would display the RP menu, booting into anything does not finish the install

Any tests are very time consuming because each one requires to start the update all over again, so about an hour apiece (I had 5 systems to update). And to retest after a successful update requires restoring the older manOS.

If it's too much to figure out then documentation should be provided to let people know they must deactivate RP AP+ before any maOS update.

Problem Point

Other

Affected Items

MacOS Loader

Debug Log

I attempted to get an AP log but was not successful.

Additional Context

No response

[dakanji]

Thanks for the report but without log files, for each reboot to try to track what is happening, I'm afraid this cannot be looked into and will be tagged as Incomplete unfortunately.

The RefindPlus DBG file generates logs unconditionally and always does so immediately it starts. The only time RefindPlus will not generate a log is if a DBG file is not in use (the REL file is in use), or if there is no writeable ESP.

On this:

If it's too much to figure out then documentation should be provided to let people know they must deactivate RP AP+ before any maOS update.

There isn't enough information to be definite about this conclusion at this stage.

Thanks again!

[MarioG-X]

I figured you would need a log, but I had trouble getting one, I did have the DBG. Not sure why but it's a different issue. If I can get the time to spend a couple of days on it I will restore older backups and try again. As for doc, happened on Catalina, Big Sur and Monterey and on 2 different computers with all getting the same result, but not on RP AN. Just thought some doc may help with the next person who has this issue but also creating this issue may help someone. At least I know about it so I can prepare next time. Will try to get something to you soon.

[dakanji]

I thought about it a bit regardless and the one difference in 0.13.2.AP that might be relevant is the coverage of ProtectNVRAM. If the installer tries to save a certificate to the NVRAM, this would get blocked in that version unlike the earlier versions which only blocked such on UEFI Windows. It could be that it then halts when such a certificate is not present. Basically does not bless itself for the last reboot; which could be why RP was loaded and not unset/unblessed.

So you could try with decline_nvramprotect active to see if it makes a difference. Just a stab in the dark as there is no log

[MarioG-X]

I restore non-updated macOS. This is log of 233 debug normal boot before requesting update: 22j19t3417.log

This is log of 233 debug boot after the update booting into the final boot, I had to manually select the "update" volume in the menu, normally this does not display in RP: 22j19u4202.log

Next try with decline_nvramprotect active.

[dakanji]

Sorry but X233 was only relevant for the specific test it was provided for. I believe this was before the 0.13.2.AP release in any case so don't consider it a benchmark instance.

Since you have used it so far though, you might as well run the decline_nvramprotect test with it for consistency. Only problem is that any results you get might not be a reflection of the actual code since it was modified before release.

Anyway, go ahead and let's see.

I need to find a way to make such test builds provided temporary ... maybe build in a time based kill switch to avoid such situations.

[MarioG-X]

Wish I new you didn't want 233 (I thought you would had preferred is which is why I used it), but AP had same results. BTW I prefer not to put in an expiration, I depended on one of your X2## versions for a while until an official RP was released. Don't remember which one but it was in the last several months. This is probably the only time you didn't want to use a test version so not something likely to happen again.

[dakanji]

I agree expiration will not likely not work out well. Just proceed with X233 or if not started, switch to the 0.13.2.AP for the final test.

[MarioG-X]

The test with 233 and decline_nvramprotect finally finished successfully, been running since the last test finished! It did the update but seemed to reboot macOS (not a hardware boot) several times more than before, but that could be my imagination. It did remove RP from booting as normally expected, so I need to reset that. Here is the last log: 22j19v1525.log

Since this is such a complex and long test I am not sure how often I can test this, if I do it again I need to restore the volume prior to the update. At least it looks like decline_nvramprotect did allow it to work. Back to 233 REL for now.

[dakanji]

Thanks. No need for further tests.

Will tag this as a bug and push a fix later.