Guest 5T33Z0 Posted July 18, 2021 Share Posted July 18, 2021 (edited) @ghost8282 Ah, thanks for the explanation. You values for Catalina worked, although my latest Catalina Build is 19H1217. I think I'll try setting MinDate and MinVersion to -1 for now to disable this, since I want to use the config universally on varius OSes. I think a lot of people will tumble over this setting once 072 is released. Edited July 18, 2021 by 5T33Z0 Link to comment Share on other sites More sharing options...
ghost8282 Posted July 18, 2021 Share Posted July 18, 2021 (edited) 2 hours ago, 5T33Z0 said: You values for Catalina worked, although my latest Catalina Build is 19H1217 Yes, it works because 19H1217 is after 19E287. These values are the bottom line limit, so with that you will be able to load driver versions/dates >= Catalina 19E287 If you want to check your apfs driver version you can for example go to about this mac -> system report -> Extensions Check for apfs, with my big sur it's 1677.120.9, meaning -> 1677.120.009, that translates into 1677120009000000 for the config.plist Or in my Big Sur I can read the version in /System/Library/PrivateFrameworks/APFS.framework/Versions/A/Resources/version.plist -> SourceVersion=1677120009000000 About the date (MinDate) I think that it is that of the "last modification" (or whatever it translates in english) column, in the same place of the version (mine is 01/01/20 - dd/mm/yy) <- no, it seems it's not, nor it's the release date of the os version (acidanthera reports 20210508 - yyyymmdd, 11.4 was release 20210524) About the date and also version of the driver you can use also log to file in the config.plist and in the generated log file you can see a line like this: 06:935 00:019 OCJS: APFS driver 1677120009000000/20210508 found for 0A2B8FC7-6F38-A245-8B9F-68E1C80FE16E, required >= 748077008000000/20180621, allow This log is older than the commit we are talking about, so the required values (748077008000000/20180621) were that of high sierra. That line will tell you the version/date of the apfs driver you are loading. If you don't know in advance the version/date you can temporary disable both MinDate/MinVersion, boot and log and modify config.plist accordingly. Edited July 18, 2021 by ghost8282 3 Link to comment Share on other sites More sharing options...
miliuco Posted July 18, 2021 Share Posted July 18, 2021 (edited) 1 hour ago, ghost8282 said: It's the minimal allowed APFS driver date to load. Not sure why it is set to Big Sur now (changelog says "for better security", so there's a reason, but since Catalina is still a supported os from Apple...well in theory mojave is the oldest os still supported at the time of writing). You can disable MinDate (not recommended)... Thanks a lot for the info. But where can I find these values (mindate and minversion) for different macOS? EDIT: read in your last post, thanks @ghost8282. Edited July 18, 2021 by miliuco 1 Link to comment Share on other sites More sharing options...
ghost8282 Posted July 18, 2021 Share Posted July 18, 2021 1 minute ago, miliuco said: But where can I find these values (mindate and minversion) for different macOS? Check the above message, if you have direct access to your hackintoshes, otherwise internet can be your friend in finding apfs driver versions 2 Link to comment Share on other sites More sharing options...
Guest 5T33Z0 Posted July 18, 2021 Share Posted July 18, 2021 (edited) I found a list with MinDate and MinVersion Infos on the Acidanthera Repo: https://github.com/acidanthera/OpenCorePkg/blob/master/Include/Acidanthera/Library/OcApfsLib.h Edited July 18, 2021 by 5T33Z0 Link to comment Share on other sites More sharing options...
nerox Posted July 18, 2021 Share Posted July 18, 2021 Hi Guys, I'm trying to install BigSur 11.4 on a bootable USB with OPENCORE 0.70. It works in the first step, but in the second step it crashes on this screen. (Sorry my English ) Can anybody help me? Link to comment Share on other sites More sharing options...
ghost8282 Posted July 18, 2021 Share Posted July 18, 2021 (edited) 2 hours ago, 5T33Z0 said: I think a lot of people will tumble over this setting once 072 is released. Yes, I'm sure too, but only because some users don't read the documentation. All that I wrote is not from me, but it's available in the official Acidanthera documentation (Configuration.pdf), including the link you posted pointing to OcApfsLib.h As usual, all is well documented. 26 minutes ago, nerox said: Can anybody help me? Why don't you use a debug version, log to file and attach a log instead of a screenshot (there's nothing useful in that)? Sometimes, reading the log file points you in the right direction to solve issues. Edited July 18, 2021 by ghost8282 2 Link to comment Share on other sites More sharing options...
Matgen84 Posted July 18, 2021 Share Posted July 18, 2021 2 hours ago, 5T33Z0 said: I found a list with MinDate and MinVersion Infos on the Acidanthera Repo: https://github.com/acidanthera/OpenCorePkg/blob/master/Include/Acidanthera/Library/OcApfsLib.h It would also be interesting if it automatically takes the version of the macos system. With this commit, it's Big Sur by default! if I'm not mistaken. 2 Link to comment Share on other sites More sharing options...
ghost8282 Posted July 18, 2021 Share Posted July 18, 2021 (edited) 25 minutes ago, Matgen84 said: It would also be interesting if it automatically takes the version of the macos system. With this commit, it's Big Sur by default! if I'm not mistaken. When these entries first came to opencore I remember that at first they were set at a version/date that was again changed to support the older os, high sierra. Yes, you understood well, if MinDate/MinVersion are set to 0, the apfs driver will fail to load if the os is older than big sur, because 0 is default values, i.e.: /** Default version subject to increase. **/ #define OC_APFS_VERSION_DEFAULT 1600000000000000ULL #define OC_APFS_DATE_DEFAULT 20210101U /** Use default version as a minimal. **/ #define OC_APFS_VERSION_AUTO 0 #define OC_APFS_DATE_AUTO 0 16xxxxx... is big sur, 20210101 is big sur too. Maybe the developers will change these default values again?who knows Unless there's some serious security issue in older apfs drivers, setting the min versions/dates to that of mojave makes more sense to me. Edited July 18, 2021 by ghost8282 2 Link to comment Share on other sites More sharing options...
Guest 5T33Z0 Posted July 18, 2021 Share Posted July 18, 2021 29 minutes ago, Matgen84 said: It would also be interesting if it automatically takes the version of the macos system. With this commit, it's Big Sur by default! if I'm not mistaken. If it would do that, there would be no reason to implement this feature at all, imo. Link to comment Share on other sites More sharing options...
nerox Posted July 18, 2021 Share Posted July 18, 2021 51 minutes ago, ghost8282 said: Why don't you use a debug version, log to file and attach a log instead of a screenshot (there's nothing useful in that)? Sometimes, reading the log file points you in the right direction to solve issues. Hey Ghost. Tks for the support. Plist and log is attached. opencore-2021-07-18-105723.txt config.plist Link to comment Share on other sites More sharing options...
ghost8282 Posted July 18, 2021 Share Posted July 18, 2021 (edited) 7 minutes ago, nerox said: log is attached This is not from a debug version of opencore, but release ("BuildConfiguration":"Release") Please use this: https://github.com/acidanthera/OpenCorePkg/releases/download/0.7.0/OpenCore-0.7.0-DEBUG.zip Edited July 18, 2021 by ghost8282 2 Link to comment Share on other sites More sharing options...
nerox Posted July 18, 2021 Share Posted July 18, 2021 50 minutes ago, ghost8282 said: This is not from a debug version of opencore, but release ("BuildConfiguration":"Release") Please use this: https://github.com/acidanthera/OpenCorePkg/releases/download/0.7.0/OpenCore-0.7.0-DEBUG.zip It worked. I found this on boot screen: 376:961 10:379 OC: Boot failed - Aborted 377:192 00:231 OCB: StartImage failed - Aborted Log is attached opencore-2015-07-12-130536.txt Link to comment Share on other sites More sharing options...
ghost8282 Posted July 18, 2021 Share Posted July 18, 2021 1 hour ago, nerox said: I found this on boot screen: 376:961 10:379 OC: Boot failed - Aborted 377:192 00:231 OCB: StartImage failed - Aborted Can you try with DevirtualiseMmio set to false? 1 Link to comment Share on other sites More sharing options...
HenryV Posted July 18, 2021 Share Posted July 18, 2021 5 hours ago, nerox said: Hi Guys, I'm trying to install BigSur 11.4 on a bootable USB with OPENCORE 0.70. It works in the first step, but in the second step it crashes on this screen. (Sorry my English ) Can anybody help me? Switch to Clover. 2 1 Link to comment Share on other sites More sharing options...
Guest 5T33Z0 Posted July 18, 2021 Share Posted July 18, 2021 (edited) 15 hours ago, nerox said: Hey Ghost. Tks for the support. Plist and log is attached. opencore-2021-07-18-105723.txt 256 kB · 1 download config.plist 20.73 kB · 4 downloads Set SecureBootModel to Disabled, perform NVRAM Reset and try installing macOS again. BTW, to boot into macOS you don't need any of these "Tools" usually. Edited July 19, 2021 by 5T33Z0 Link to comment Share on other sites More sharing options...
btwise Posted July 20, 2021 Share Posted July 20, 2021 @vit9696 The system I have been using is Mojave xcode11.3. It has been normal to compile OpenCore before. Since a few days ago, I found that the process of compiling OpenCore in Mojave xcode11.3 environment is normal, but the compiled bootx64.efi and OpenCore.efi can not start booting. It freezes without any screen prompts, but the files compiled in BigSur can work normally. The source files used are exactly the same. I want to know why! Compared with normal files,I have checked that the MD5 values of bootx64.efi and OpenCore.efi compiled in the Mojave system are completely different, even the size of OpenCanopy.efi is different, because I can’t find the reason, I updated my Mojave (not a new installation) After being BigSur, compile again and it works fine! What is the reason for this? Link to comment Share on other sites More sharing options...
Guest 5T33Z0 Posted July 20, 2021 Share Posted July 20, 2021 @btwise Do you use SecureBootModel? Because in OC 072, the default setting has been changed so the minimum system requirement is Big Sur now. That could be the reason why Mojave is not booting Link to comment Share on other sites More sharing options...
btwise Posted July 20, 2021 Share Posted July 20, 2021 3 minutes ago, 5T33Z0 said: @btwise Do you use SecureBootModel? Because in OC 072, the default setting has been changed so the minimum system requirement is Big Sur now. That could be the reason why Mojave is not booting no,Im not use SecureBootModel,What I mean by unable to boot means that it is completely stuck when loaded from bootx64.efi, and there is no screen prompt, so it has nothing to do with which system is booted, it is a problem of the compilation environment! 2 Link to comment Share on other sites More sharing options...
nerox Posted July 20, 2021 Share Posted July 20, 2021 On 7/18/2021 at 12:06 PM, ghost8282 said: Can you try with DevirtualiseMmio set to false? On 7/18/2021 at 3:55 PM, 5T33Z0 said: Set SecureBootModel to Disabled, perform NVRAM Reset and try installing macOS again. BTW, to boot into macOS you don't need any of these "Tools" usually. Hi Guys! Doesn't work. I updated to OC 0.7.1 + Kexts and nothing, same error. Link to comment Share on other sites More sharing options...
miliuco Posted July 20, 2021 Share Posted July 20, 2021 Hello everybody. In OpenCore debug log I see these lines in an early stage: 00: 260 00: 004 OCAE: Failed to handle GOP, discovering UGA - Unsupported 00: 264 00: 003 OCAE: Failed to get screen resolution - Unsupported Below I read: 00: 490 00: 014 OCC: Installing GOP (Unsupported) on ConsoleOutHandle ... 00: 494 00: 004 OC: Requested resolution is 0x0 @ 0 (max: 1, force: 0) from Max 00: 499 00: 004 OCC: Requesting 0x0 @ 0 (max: 1) resolution, curr 3, total 8 00: 503 00: 004 OCC: Current FB at 0x40000000 (0x300000), format 1, res 1024x768 scan 1024 00: 507 00: 004 OCC: Mode 0 - 3840x2160: 1 00: 511 00: 003 OCC: Mode 1 - 640x480: 1 00: 515 00: 003 OCC: Mode 2 - 800x600: 1 00: 519 00: 003 OCC: Mode 3 - 1024x768: 1 00: 524 00: 004 OCC: Mode 4 - 1280x1024: 1 00: 527 00: 003 OCC: Mode 5 - 1400x1050: 1 00: 531 00: 003 OCC: Mode 6 - 1600x1200: 1 00: 535 00: 003 OCC: Mode 7 - 1280x960: 1 00: 539 00: 003 OCC: Setting mode 0 with 3840x2160 resolution 00: 657 00: 117 OCC: Changed resolution mode to 0 00: 662 00: 004 OC: Changed resolution to 0x0 @ 0 (max: 1, force: 0) from Max - Success 00: 666 00: 004 OCC: Using builtin text renderer with 2 scale 00: 685 00: 018 OCC: Install console control (32C2A550 / 0/0), current - Success In config.plist I have: DirectGopRendering False GopPassThrough Disabled ProvideConsoleGop True UgaPassThrough False. Otherwise everything seems to work fine at boot. Does this mean that my UEFI does not support GOP? It is a relatively modern motherboard and is updated to the latest version. 1 Link to comment Share on other sites More sharing options...
Guest 5T33Z0 Posted July 21, 2021 Share Posted July 21, 2021 On 7/18/2021 at 4:06 PM, nerox said: It worked. I found this on boot screen: 376:961 10:379 OC: Boot failed - Aborted 377:192 00:231 OCB: StartImage failed - Aborted Log is attached opencore-2015-07-12-130536.txt 256 kB · 6 downloads 604:041 00:379 AAPL: #[EB|LOG:EXITBS:START] 2015-07-12T13:15:41 Maybe this helps: https://dortania.github.io/OpenCore-Install-Guide/troubleshooting/extended/kernel-issues.html#stuck-on-eb-log-exitbs-start Link to comment Share on other sites More sharing options...
ghost8282 Posted July 21, 2021 Share Posted July 21, 2021 (edited) 13 hours ago, miliuco said: Does this mean that my UEFI does not support GOP? It is a relatively modern motherboard and is updated to the latest version. I think you are referring to the RX580? It seems the gpu doesn't support gop/uga and probably the os is booting in uefi mode but forcing legacy bios for video: if you search in internet you will find similar issues; some solved by upgrading the vbios (there are some on techpowerup, but I would think twice before flashing, unless you are 100% sure on what you're doing). If I'm not wrong some (or all?) RX 580 have a physical switch (which should be near the power connector), to set legacy vs uefi vbios (note that the switch can be something different, like performance (overclocking), or secondary backup bios, so check your manual): if your gpu has this switch check that its function is legacy/uefi switch, and if this is the case, that it's in the uefi position. Check also the bios settings and in particular that you are not using legacy mode for video: attention: if you change the video from legacy to uefi and the card is unable to support uefi you may have an unbootable system and a bios reset will be needed to boot again (assuming the defaul bios setting for video is legacy). Be prepared to something like this (recent recovery spi flash of my network bridge, bricked because of a firmware update failure) Spoiler Edited July 21, 2021 by ghost8282 1 Link to comment Share on other sites More sharing options...
Matgen84 Posted July 21, 2021 Share Posted July 21, 2021 (edited) 13 hours ago, miliuco said: In config.plist I have: DirectGopRendering False GopPassThrough Disabled ProvideConsoleGop True UgaPassThrough False. Otherwise everything seems to work fine at boot. Does this mean that my UEFI does not support GOP? It is a relatively modern motherboard and is updated to the latest version. Hi @miliuco I've got a MSI Radeon RX580. I think if you got GOP problem, maybe there is a message for Windows like below: Spoiler On my Z390 Aorus Master, I use Windows 8.1/10 WHQL instead of Windows 8.1/10. In my Opencore config.plist, the resolution is 1920*1080 (because of my monitor, not 4K). What is your resolution setting ! Edited July 21, 2021 by Matgen84 1 Link to comment Share on other sites More sharing options...
deeveedee Posted July 21, 2021 Share Posted July 21, 2021 (edited) An OC 0.7.2 commit changes the default Apple Secure Boot Model from 'Default' to 'x86legacy' Does this mean that we should change MIsc>Security>SecureBootModel from 'Default' to 'x86legacy' in our OC config.plist for better compatibility with future macOS versions? ocvalidate accepts 'x86legacy' as a valid value in OC 0.7.1. If we are currently staying with 0C 0.7.1 as our baseline, should we change SecureBootModel to 'x86legacy' in our OC 0.7.1 config.plist? Edited July 21, 2021 by tonyx86 Link to comment Share on other sites More sharing options...
Recommended Posts