[HOW TO] OpenCore 0.7.7 > 0.7.8 differences

[mbatrawi]

Openshell.efi at opencore boot menu then fs0: then cd efi\microsoft\boot then bootmgfw then windows will start and when windows loaded I restart then windows will appear at opencore boot menu

 

[Ben42]

Updated, macOS boots fine but lost the ability to boot windows via opencore. Windows entry is missing in the boot picker.

Edit...

My mistake...I used opencore sample.plist for this update and forgot to change the scanpolicy from default value back to 0. Changed it back and now Windows show up in the boot picker.

 

[Nodarkthings]

Hi @miliuco! I'm writing here about https://www.tonymacx86.com/threads/scanpolicy-opencore-windows-entry-disappears.308487/ as we can't comment there any more: I seem to have discovered something! I'm wondering if oli.mathieu was using OpenCore Configurator (that seems faulty for this) to set the ScanPolicy... That would explain why both of you had different results!
Take the default 17760515, for example, it should check, as mentioned at Dortania:
OC_SCAN_FILE_SYSTEM_LOCK
OC_SCAN_DEVICE_LOCK
OC_SCAN_ALLOW_FS_APFS
OC_SCAN_ALLOW_DEVICE_SATA
OC_SCAN_ALLOW_DEVICE_SASEX
OC_SCAN_ALLOW_DEVICE_SCSI
OC_SCAN_ALLOW_DEVICE_NVME
OC_SCAN_ALLOW_DEVICE_PCI
But OpenCore Configurator shows this instead (see attachment).

So, when setting a ScanPolicy by checking in OpenCore Configurator, the result is completely at odds with what you get using hexa calculation (as mentioned in https://www.tonymacx86.com/threads/x299-big-sur-support.302143/page-33#post-2170072, the best trick I've found so far).
What do you think?

 

[miliuco]

Hello @Nodarkthings
I don't know yet why @oli.mathieu has that behaviour. Btw, I've read the post of @Ellybz (not read before) and it has a very good explanation about this. Only thing is that now there are more valid values in ScanPolicy (Linux...) so the post must be uptaded.
OpenCore Configurator (if up to date) works well with ScanPolicy values. There is a website very useful too, https://oc-scanpolicy.vercel.app.
If I set ScanPolicy from OpenCore configurator up to date or from vercel site or from macOS calculator app, the result is the same.

 

[Nodarkthings]

Hello @Nodarkthings
I don't know yet why @oli.mathieu has that behaviour. Btw, I've read the post of @Ellybz (not read before) and it has a very good explanation about this. Only thing is that now there are more valid values in ScanPolicy (Linux...) so the post must be uptaded.
OpenCore Configurator (if up to date) works well with ScanPolicy values. There is a website very useful too, https://oc-scanpolicy.vercel.app.
If I set ScanPolicy from OpenCore configurator up to date or from vercel site or from macOS calculator app, the result is the same.

My screen capture is from the latest OpenCore Configurator and it's clearly different from what it's supposed to be, from Dortania's page... (and it's been like that since I first tried OCC)
I've tried different values and the checkmarks in OpenCore Configurator are always different from what I build with Hexa Calculation — and actually, the value I get from Hexa Calculation gives the expected result while if I set it via the checkmarks in OCC, it gives a different value and the result is not what's expected.
If on your side you have OCC working correctly, it's a real mystery to me.

EDIT: in case I was not clear enough, I didn't mean entering the value by typing the digits on your keyboard (that is working, of course) but clicking the checkmarks (this gives a different result).

 

[Nodarkthings]

Another example: suppose you just want ATAPI (bit 20), the hexa is 0x100000, decimal 1048576 (from Hackintool's calculator), so I type this in OCC and Here's what I get:

 

[Nodarkthings]

And if you're still not convinced, here's the same value in scanpolicy.vercel.app compared to the checkmarks in OCC:

 

[oli.mathieu]

Hi @miliuco! I'm writing here about https://www.tonymacx86.com/threads/scanpolicy-opencore-windows-entry-disappears.308487/ as we can't comment there any more: I seem to have discovered something! I'm wondering if oli.mathieu was using OpenCore Configurator (that seems faulty for this) to set the ScanPolicy... That would explain why both of you had different results!
Take the default 17760515, for example, it should check, as mentioned at Dortania:
OC_SCAN_FILE_SYSTEM_LOCK
OC_SCAN_DEVICE_LOCK
OC_SCAN_ALLOW_FS_APFS
OC_SCAN_ALLOW_DEVICE_SATA
OC_SCAN_ALLOW_DEVICE_SASEX
OC_SCAN_ALLOW_DEVICE_SCSI
OC_SCAN_ALLOW_DEVICE_NVME
OC_SCAN_ALLOW_DEVICE_PCI
But OpenCore Configurator shows this instead (see attachment).

So, when setting a ScanPolicy by checking in OpenCore Configurator, the result is completely at odds with what you get using hexa calculation (as mentioned in https://www.tonymacx86.com/threads/x299-big-sur-support.302143/page-33#post-2170072, the best trick I've found so far).
What do you think?

Yes i use OpenCore Configurator

OCC "seems" to work correctly

But in fact NO

I'll try the trick you found and report

 

[Nodarkthings]

And if you're still not convinced, here's the same value in scanpolicy.vercel.app compared to the checkmarks in OCC:

In other words: if you click the same checkmarks in scanpolicy.vercel.app and in OCC, you'll end up with different values!
For the last example I gave above, 3214083 in scanpolicy.vercel.app will give 797443 in OCC... I'd be very very surprised if this behaviour was only on some computer.

 

[oli.mathieu]

In other words: if you click the same checkmarks in scanpolicy.vercel.app and in OCC, you'll end up with different values!
For the last example I gave above, 3214083 in scanpolicy.vercel.app will give 797443 in OCC... I'd be very very surprised if this behaviour was only on some computer.

You mean that OCC has a faulty Hex to Decimal converter, don't you ?
or OCC and scanpolicy.vercel.app have also different Hex value ?