Closed Macschrauber closed 2 years ago
Just as initial test, try again after uncommenting decline_nvramprotect
in the config file
same behaviour
Ok. Will look at it properly and get back.
BTW, you can just drag and drop the log file (or any other supported file type) into the field to attach it
Interesting: if I start FileVault Mojave via OpenCore (your instances as well as OCLP 0.46 chainloaded thru RP 0.13AA it hangs after entering the FileVault password.
EndUnlockCoreStorageVolumekey Start SetConsoleMode End SetConsoleMode Start OpenKernelRootVolume En OpenKernelRootVolume Start LoadKernelFronStream EndLoadKerne(FromStream Start InitBootStruct root device uuid is *23127R56-98B6-49D7-9BAF-OE6R2928C527" End InitBootStruct Start LoadRAMDisk End LoadRAMDisk Start FinalizeBootStruct, Start RandonSeed End RandomSeed
is the onscreen message before hanging.
I just struck me that I did not intend to attach 0.13.3.AA to MyBootMgr 080a and not sure about the state of the file as it was probably some test version.
Try X242 (current code) to get bearings back X242-BOOTx64.zip
X242 hangs, does not reboot with FileVault Mojave:
this is the text after the password was given:
Start ErILibNamedEventSignal for gAppleEf1Log nWindoNExitGuld EndUnlockCoreStorageVolumekey Start SetConsoleMode End SetConsolehode Start OpenkernelRootVolume End OpenKerne IRootVolume Start ReadkerneICache EndReadKerneICache Start UncompressKerne1Cache EndUncompressKerne1Cache Start CalculateAdler32 End CalculateAdler32 Start LoadKernelFronStrean EndLoadKernelFronStrean Start InitBootStruct root device uuid 1s '23127A56-98B6-49D7-9BAF-OE6A29280527 ® End InitBootStruct Start LoadRAMDisk EndLoadRAMDisk Start FinalizeBootStruct Start RandonSeed End RandonSeed
here's the log (the text before was per picture to text from ios device)
Okay. Do not boot with X242 again as the log has an odd Bad Buffer Size
item which I need to look into.
Go back to the previous file and run that with decline_uefiemulate
.
WIll pick things up tomorrow as late for me.
same with decline_uefiemulate, FileVault Mojave per RP0.13AA reboots after FileVault password was given. This is no problem for me, just want to help debugging. I can easily use 13.2AP.
Thanks. I know.
Was actually concerned about something happening to the BootROM as was not sure whether that ws a message from the NVRAM.
There is a separate (possibly connected) issue which I need to look into further:
- Type 02 ... *_ WARN _* Could Not Find Tool:- 'Toggle CSR'
- Type 03 ... *_ WARN _* Could Not Find Tool:- 'UEFI Shell'
* Normalise CSR ... Bad Buffer Size
Seems the buffer size message is related to not finding the Toggle CSR tool and not the NVRAM getting hosed in the end. Something got messed up there as is an internal tool that doesn't need finding.
Restore the config items disabled before and try X243 X243-BOOTx64.zip
Goes back towards the last release to try to catch the breaking commit. Will check in tomorrow
Waiting for feedback on X243
On these:
- Type 02 ... *_ WARN _* Could Not Find Tool:- 'Toggle CSR'
* Normalise CSR ... Bad Buffer Size
Had a quick initial look at the code and found the following:
Bad Buffer Size
is because the size of the csr-active-config
data obtained from the NVRAM was not the 4 bytes expected by RPCSR_Rotate
toolI am not at the Mac Pro 3,1 but tested 0.13.AA pre on my 5.1 almost same behaviour, FileVault Mojave hangs after password, on 3.1 it rebooted
log for 0.13AA (hangs after FV Mojave): 22j30s1059.log
X243 is working on MP5.1, boots FileVault Mojave. Tested 0.13AA on MP5.1 only to validate the test.
log for X243 (boots FV Mojave): 22j30s1909.log
Thanks. Just out of curiosity, can you share a log from 0.13.2.AP?
sure, this is 0.13.2.AP booting FV Mojave 22j30t5234.log
Thanks. Lets see with X244 X244-BOOTx64.zip
x244 hangs booting FV Mojave 22j30w2030.log
OK. Thanks. Will pick it up tomorrow.
Please test X245 when you have a min X245-BOOTx64.zip
End UnlockCoreStorageVolumekey Start DrawBootGraphics
after FV password and then it hangs 22j31j4950.log
Thanks. Please test X246 X246-BOOTx64.zip
Thanks. Confirms the breaking commit Please try X247 with an attempt at a fix X247-BOOTx64.zip
X247 works, starts FV Mojave 22j31y2130.log
but something strange happened to nvram boot-args:
nvram boot-args
boot-args -a n_optcek -no_compat_check
ariable: 7c436110-ab2a-4bbb-a880-fe41995c9f82:boot-args (Apple Boot Variable)
StartID: 55aa (Valid)
State: 7f (Normal)
Unknown8: 00
Attr: 00000007 (NON_VOLATILE, BOOT_SERVICE_ACCESS, RUNTIME_ACCESS)
NameSize: 20
DataSize: 29
DataType: looks like NULL-terminated ASCII
Data:
00000000: 2d 61 20 6e 5f 6f 70 74 63 65 6b 20 2d 6e 6f 5f -a n_optcek -no_
00000010: 63 6f 6d 70 61 74 5f 63 68 65 63 6b 00 compat_check.
--------
Variable: 7c436110-ab2a-4bbb-a880-fe41995c9f82:boot-args (Apple Boot Variable)
StartID: 55aa (Valid)
State: 7d (DELETED)
Unknown8: 00
Attr: 00000007 (NON_VOLATILE, BOOT_SERVICE_ACCESS, RUNTIME_ACCESS)
NameSize: 20
DataSize: 9
DataType: looks like NULL-terminated ASCII
Data:
00000000: 2d 6f 63 6d 61 5f 68 63 00 -ocma_hc.
Variable: 7c436110-ab2a-4bbb-a880-fe41995c9f82:boot-args (Apple Boot Variable)
StartID: 55aa (Valid)
State: 7d (DELETED)
Unknown8: 00
Attr: 00000007 (NON_VOLATILE, BOOT_SERVICE_ACCESS, RUNTIME_ACCESS)
NameSize: 20
DataSize: 22
DataType: looks like NULL-terminated ASCII
Data:
00000000: 2d 63 61 68 20 2d 6e 6f 5f 63 6f 6d 70 61 74 5f -cah -no_compat_
00000010: 63 68 65 63 6b 00 check.
also I can not read bless --getboot
sudo bless --getboot
Password:
Boot option does not match XML representation
XML representation doesn't match true boot preference
So what was happening was that an attempt was made to add partial emulation of QueryVariableInfo here: https://github.com/dakanji/RefindPlus/commit/a1e97ab7423f79e2524d2f29bbf579b9bbc8edcd but it seems FileVault did not like that or how it was done. So I have removed this altogether as it was just a nice to have thing.
On the NVRAM stuff, I don't know what that is about but there have been some oddities in your logs. The 2 byte CSR entry when the inherited code expects 4 bytes and I am informed the kernel mandates 4 bytes. I had disabled the 4 byte check in X247 and was going to go with that but on second thoughts, it is best to leave it in until this aspect is clear as it may be impacting some other stuff.
Additionally, some of your boots have been showing a funny behaviour. An OS Loader boot should be a one-way trip but sometimes, your logs show that it returns to RP and then something else that looks like a preboot loader is automatically booted. This is quite odd and I don't quite understand what is happening with that.
I think the best thing is to clear your NVRAM or better still, flash a clean version in.
X248 restores the 4 byte check and has some other clean up which may avoid the issue or at least log the area around the boot cleanly: X248-BOOTx64.zip
had already cleaned it and now have an eye on it. Just recognised it because the blessing reacted odd. I have a RX560 in the box without UGA Bootscreen. Therefore is an OpenCore CD in what I can start with the C-Key as a failback when RP hangs.
Got back to RP013..2AP for a few reboots to double check things with the nvram before I try X248.
Remember, the same problem is with the other machine, the MP3,1 (what I have no access to for a week or so).
just for the record:
nvram boot-args boot-args -no_compat_check $ sudo bless --getboot /dev/disk1s1
now with 013.2.AP
tested x248,
works, boots FV Mojave
But did something with boot-args, I checked before, it was just "-no_compat_check"
after booting with x248 it was just "-ocma_hc"
blessing in nvram was unchanged. 22k01s1145.log
set boot-args back to "-no_compat_check", read it out, was correct.
booted a second time with X248, read it out, now it was "-cah -no_compat_check"
The boot args item is a separate issue related to handling ascii strings. This has been fixed but not yet pushed. You can bypass it for now by not activating disable compat check
Hi ... can you try X249? X249-BOOTx64.zip
Includes most of the needed fixes such as the ascii string handling which needs testing.
Also found the reason for this:
An OS Loader boot should be a one-way trip but sometimes, your logs show that it returns to RP and then something else that looks like a preboot loader is automatically booted.
If no issues arise, I will clean and push the fixes later
PS: Seems the 2-byte csr-active-config
has gone with the NVRAM clean as Bad Buffer Size
did not show up although the filter was back in place.
ok, X249 booted FV Mojave
I switched disable_compat_check off
Odds:
at first start I got an extra chime and a shutdown (guess: invalid platform for Big Sur disk what my system finds on 1st position) - so still it does something with blessing bootx64.efi in nvram.
at 2nd start via the OC rescue cd it booted FV Mojave, boot-args was empty as expected.
I blessed RP, switched on disable_compat_check and booted again FV Mojave. This time boot-args was set correctly, "-no_compat_check" only, no strange 2nd string.
22k01z0548.log 22k01z0112.log 22k01z0018.log
So after all it works but it does something with blessing the bootloader. Glad I had the OC Rescue CD in the drive, if not I had to fiddle a bit to get RP blessed again.
No bootscreen GPU is in the box, this is something I need to get used to. I try to hold on not swapping the GPU as the typical user can't do it neither.
Thanks. I'll wrap things up and push later.
RefindPlus Version
Pre-Release Code Build
Device Type
Apple Mac
Problem Description
I cannot start FileVault'ed Mojave with 13.3AA pre, it goes to the login screen where I can select my username, enter password and then it reboots.
13.3AA Debug and Release, same behaviour
tested on Mac Pro 3.1, Sata SSD on Backplane
I can start my Backup Disk without FileVault with 13.3AA
when swapping to 13.2.AP it works.
Problem Point
After starting a loader or tool
Affected Items
MacOS Loader
Debug Log
DA EDIT: Attach Debug log Instead no filefault 22j28x4727.txt
Additional Context
No response