Jump to content

Taruga

Retired Developers
  • Posts

    560
  • Joined

Reputation

51 Excellent

About Taruga

Profile Information

  • Gender
    Male
  • Location
    Portugal

Contact Methods

  • Website URL
    http://

Recent Profile Visitors

10,468 profile views
  1. I don't agree that Monterey needs SecureBootModel Default for updates. I have 2 computers (same hardware) where one has SecureBootModel = Disabled and the other one has SecureBootModel = Default. The difference I see, is that the one with Disabled only gets full updates, and the one with Default gets Delta updates which are much smaller
  2. You have to wait a little, it takes some time to display the ouput, around 11 seconds on my pc. Not sure if something needs to be changed on opencore config. Output example:
  3. Verbose mode doesn't give a clear picture of what is going on, I used this command to check trims duration: log show --predicate "processID == 0" | grep spaceman Look for your SSD disk id and you should see something like this: kernel: (apfs) spaceman_scan_free_blocks:3153: disk10 scan took 66.606504 s, trims took 66.510656 s And 2 or 3 days after my clean install and the boot delay is increasing (as I sort of expected), trims for the EVO took 66 seconds. The sistem was booting in 28 seconds 2 or 3 days ago, and at the moment I have a 66 second boot delay Soon I'll be with the same 250 seconds (or more) boot delay.
  4. I have different hardware, but same 970 EVO. Boot process took 4m11s after updating to Monterey. Then I've made a clean install and restored my data from time machine and the boot now takes around 28s which is a huge difference. Not sure if it will stay like this or not. Maybe there is some incompatibility of trim with the local time machine snapshots or something else, lets see if from now forward the boot time stays short or if it keeps increasing the delay. I have another PC with same hardware but with a SATA SSD instead of the 970 EVO that it's normal. My nephew also has a big boot delay with a 970 EVO PLUS
  5. Test with 999 and check if boot takes less time. But If it does, I do not recomment leaving it with 999 as I believe it disables trim. Second best option is: -1 but that will not fix your problem. More info here: https://github.com/dortania/bugtracker/issues/192
  6. I believe you need to check if it's under Nvram-Add, and if it is, it's setting that value always on boot. Delete the csr-active.config from the Nvram-Add and then whatever you set on recevery mode with csrutil will be saved and used on next boot.
  7. I've just solved my issue and I figured out what I was doing wrong. It was because I was clearing nvram with: sudo nvram -c As soon as I used the OC ClearNvram.efi from the Tools, the problem went away Now I see the correct version (also on Hackintool): ❯ nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version REL-067-2021-03-01 Thank you for your comment, It gave me the push I needed to try one more time. All the EFI files were correct, I didn't change anything.
  8. Cleared NVRAM, rebooted and I have the same result. This is weird ... Just tested updating open core on another PC to 0.6.7 and I have the same result. I don't understand what's happening.... MD5 is a match
  9. Not sure if I did something wrong, I updated Open Core from 0.6.5 to 0.6.7 but it looks like I'm still on 0.6.5 version. Hackintool also says the Current Booted Version is 0.6.5 Is there any bug with 0.67 ?! Open Core 0.6.7 ocvalidade has the following output: Completed validating /Volumes/EFI/EFI/OC/config.plist in 1 ms. No issues found. nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version REL-065-2021-01-04
  10. This should help you: https://github.com/seanzhang98/ASRock-Z390-Phantom-ITX-OpenCore-Hackintosh-BigSur/blob/main/README_en.md
  11. Regarding the problem Stuck on ramrod mentioned in the link: https://dortania.github.io/OpenCore-Desktop-Guide/extras/big-sur/#stuck-on-ramrod where the instalation restarts on a infinite loop with a line near the bottom that says: ramrod exited with status 1 - Rebooting I want to inform that I had this problem after installing it on an OCZ Vertex 2 SSD and with or without vsmcgen=1, and with FakeSMC or with VIrtualSMC I could not overcome the problem. I tested the same Open Core configuration without changing anything on a HDD and (it was painful to wait, but...) it worked without any problem. I tested it on a Vertex 3 SSD(more recent than the Vertex 2) and it also worked without any problem. My problem with "Stuck on ramrod" reboot loop was caused by some incompatibility with these old OCZ Vertex 2 and perhaps related to Apple APFS and it had nothing to do with using or not vsmcgen=1 or VirtualSMC/FakeSMC.
  12. I don't know why, but I can only boot to desktop with booter-fileset-kernel booter-fileset-basesystem nvram settings. If I try to boot using kernel collections, It boots to a black screen and a mouse pointer. I see nothing else.
  13. I've seen somewhere else something like: kmutil install --update-all kcditto Not sure if this is it or not.
  14. OpenCore Changelog ================== #### v0.6.0 - Fixed sound corruption with AudioDxe - Fixed icon choice for Apple FW update in OpenCanopy - Fixed APFS driver loading on Fusion Drive - Added Comet Lake HDA device code - Fixed audio stream position reporting on non-Intel platforms - Added `Firmware` mode to `ResetSystem` to reboot into preferences - Replaced `BlacklistAppleUpdate` with `run-efi-updater` NVRAM variable - Fixed reset value in `FadtEnableReset` ACPI quirk - Fixed freezes during boot option expansion with PXE boot entries - Updated underlying EDK II package to edk2-stable202005 - Added `ProvideMaxSlide` quirk to improve laptop stability, thx @zhen-zen - Fixed slide choice on platforms when 0 slide is unavailable, thx @zhen-zen - Fixed assertions caused by unaligned file path access in DEBUG builds - Renamed `ConfigValidity` utility to `ocvalidate` for consistency - Added `GlobalConnect` for APFS loading to workaround older firmware issues Just replace `BlacklistAppleUpdate` with `run-efi-updater` NVRAM variable
  15. I'm using an BCM4360, Vendor 0x14E4 Device: 0x43A0. Bluetooth and wifi working now as an iMac13,2. I had to disable USBInjectAll.kext which I did not had enabled when I tested as an MacPro6,1. Stupid mistake.
×
×
  • Create New...