Jump to content


  • Content Count

  • Joined

  • Last visited

About griven

  • Rank
    InsanelyMac Protégé

Profile Information

  • Gender
  • Location
    Bochum, NRW, Germany

Recent Profile Visitors

4,369 profile views
  1. griven

    [pre-release] macOS Mojave 10.14.1

    Installed without any issues on my Desktop Here are the release Notes to 10.14.1 (18B45d): Overview The macOS 10.14.1 SDK provides support for developing apps for Macs running macOS Mojave. The SDK comes bundled with Xcode 10.1 beta from the Apple Developer Program download page. For information on the compatibility requirements for Xcode 10.1, see Xcode 10.1 beta Release Notes. General There are no notes or known issues for this software update. No known issues and obviously no new features except XCODE 10.1 SDK compatibility at all...
  2. griven

    Clover problems report & features request

    I'am unsure if this has reported or discussed before. If so please ignore my post... It seems as if macOS Mojave has some "special requirements" about BootVolume/InstallVolume assignments. Here is what I did: I have 2 drives in my rig, both apfs formatted, one of them holds HighSierra as my daily driver and the Clover bootloader on it's EFI partition the other one is a spare drive for testing purpose. I cloned an existing clean Mojave install onto the spare drive for testing purpose which booted quite nice with clover installed on my primary drive. Today Apple rushed out Beta3 of Mojave and so I decided to give it a try. The 1st stage of the update loaded and installed fine and the 2nd stage also started fine but quits with an error "macOS could not be installed.... Installer Sources could not be found..." I took a look at the installers log and it states that it could not find installer files on my primary drive, the one Clover starts from (called Sierra as the one which should be updated is called Mojave)... It also does not matter wether you want to update or do a clean Install onto an empty disk you'll always will end up in an error message stating "Installer Resources could not be found" if the 2nd Stage is not booted from the drive it should be installed on. Is there any way to pass the booted device UUID to macOS instead of the one the bootloader started from?
  3. @Tusskan you're right if you just use one instance of HighSierra and do not wish to add any other boot entries such like the recovery partition SystemSettings -> Startup Disk is by far the easiest way to do it and it will work nicely. If you need to add more than just this entry or like to add a more customised entry as macOS then the EFI Shell is a pretty handy tool to do it. To make it work APFS.ffs of course has to be part of your custom rom but once this is done you may proceed. Here is how I did it: The only thing you have to do is find the right the location of boot.efi inside the APFS Container. Diskutil (the terminal command) is handy for that. Open up a terminal an type diskutil list you'll get something like that as the result /dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.1 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_APFS Container disk2 499.9 GB disk0s2 /dev/disk2 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +499.9 GB disk2 Physical Store disk0s2 1: APFS Volume Sierra 325.4 GB disk2s1 2: APFS Volume Preboot 19.0 MB disk2s2 3: APFS Volume Recovery 523.3 MB disk2s3 4: APFS Volume VM 2.1 GB disk2s4 As you see there is a physical Disk (Disk0) which holds the EFI Partition as well as the APFS Container and there ist a virtual (synthesized) Disk (disk2) which represents the the content of the APFS Container located on the first physical Disk. To add a boot entry via EFI shell all you need to know is the partition UUID of your OS Partition inside the APFS Container. To get the needed Information just type diskutil info disk2s1 | grep "Partition UUID" where disk2s1 of course has to be replaced with your Identifier. The command should bring up something like that: diskutil info disk2s1 | grep "Partition UUID" Disk / Partition UUID: 3C199D35-CB13-3164-9BF0-22821813CB91 Write down the UUID or remember it since we'll need it for the next step (This can also be done for the recovery Partition as well). Now reboot your maschine into the build in Hermit Shell (or a different shell) and browse the available filesystems (use the fsX: and ls command where X has to be replaced by any number) until you find the one which holds a single folder that is named like the UUID you wrote down before. This filesystem represents the Filesystem which holds your HighSierra installation inside the APFS container (in my case it was fs3). Finally to add the boot entry type bcfg boot add 1 fs3:\3C199D35-CB13-3164-9BF0-22821813CB91\System\Library\CoreServices\boot.efi "HighSierra" where fs3 has to be replaced by your finding and that's it you're done. The created entry will last until you reset your NVRAM and of course it can be done that way for the recovery Partition as well.
  4. Sure it is Boot into the build in Shell and use the bfcg boot add command to manually add an entry for HighSierra on APFS Volumes. Just make sure you find the correct volume by browsing your volumes with the FS Command. Once the correct Volume was found remember it´s identifier and complete your bfcg command with the required information. For example if your installation is on FS1 then just type bcfg boot add 1 fs1:\System\Library\CoreServices\boot.efi "macOS" after the boot Entry has successfully been added you may trigger a reboot and your HighSierra Installation should show up in your boot menu or OZ Gui.
  5. Just compiled it and it workes Just give it a try: Lilu.kext.zip Thanks to VIT and all People involved to fix it that fast couldn't be more thankful. Nice Job done once again.
  6. griven

    Clover General discussion

    I guess vit9696 is right since Apple relies on it´s ecosystem. All the things we do on bootloader level are hackintosh specific since they take place before macOS takes over. Stuff like kext injection will most likely not work on real macs since there is no layer between the machines EFI and the oses boot.efi which could enable manipulation of the Memmap in any way. Given that there is no need to double check if extensions which are part of the prelinked kernel are signed or not since they will only find their way into it if they are signed or if the user decided to disable SIP to allow loading of unsigned Extensions.
  7. griven


    Well @Download-Fritz as you know I am no Coder (at least not as this high level) and as you also know I am a a burning OZ fan which is the main reason why I offer all the FD Files and take care about users who have trouble to use OZ. I do my very best to provide a solution for Users to start with OS-X right away and even though OZ has surely come to age and isn't suitable for modern platforms anymore I take care of all the legacy Users. OZ is still a great alternative for all Users of legacy UEFI Hardware... You suggested me to remove all the FD Files I offer and sure enough I would love to do so but only under one condition... If you're able to offer an OZ Version which is capable to boot OSX 10.6.X till recent including HighSierra and APFS support how it´s meant to be by Apple (loaded from FS rather than being part of the ROM) which capable to add boot entries for APFS Volumes on it´s own and which is able to overcome the the NVRAM Issues some boards including the QOU AOS might have (pretty annoying with nvidia cards which use webdrivers) and which adds kernextpatcher functionality as well as Support for Skylake and above and deliver a tool similar to OZMTool which offers a way for interested Users to easily add all this greatness to their ROM. @Download-Fritz and here is the deal if you and your friends(?) are able to deliver a OZ version, within a timeframe of two weeks starting now, which is capable to do all the things described above and which could be applied to at least one SkyLake, one KabyLake and the Quo AOS Board without any restrictions and of course without the usage of external flash Devices (only the regular mechanisms as QFLASH or EZFLASH are allowed) I will delete the whole OZ related section on hackintosh-forum.de if not, well... Deal?
  8. griven


    @ammoune78 sure you're right the OZ Dev's don't care about anything and that's the only sad thing at the long end... For me in person it doesn't matter at all since I luckily own a Mobo which offers enough space to insert all the needed stuff and provides writeable and persistent NVRAM as well. All I've got to do is to add a boot entry via HermitShell and i am good to go but that's not my point. OZ was released as a supplemental BIOS Upgrade for the all-mighty QUO AOS Motherboard and it's kind of ironic that especially the QUO Customers are not able to use their Boards any more since OZ in combination with HighSierra lacks to detect APFS Volumes and even fail to hold manually added boot entries (added via shell with bcfg). In Fact they are forced to use Clover as an alternative since their overpaid solution isn't capable to detect and boot apples latest OS anymore and that is a shame. Don't get me wrong it's not about Cecek this guy did everything possible to give OZ life support. He did great things when Sierra pops out (the OZ devs didn't care about it at all but claimed how well OZ was designed that a simple patch is enough to make it run *sigh*) and he did it again when HighSierra pops out and with the KernextPatcher he also added a long awaited an truly needed feature. My concerns and/or thoughts about APFS might have been disputed but nevertheless APFS is a real hurdle which needs to be taken if not by the OZ Devs themselves than hopefully by someone else...
  9. griven


    It depends on the available space. We try to integrate as much as possible first of all the core files and the APFS driver and if there is enough space left the shell, sensors and stuff like that where we have a priority on the shell. The older Z7X Roms are mostly complete newer ROMS and the B or H flavoured Chipsets may lack the Theme, Shell or both. Don't get me wrong it's not about the ability to boot HighSierra through the shell it's about persistent boot entries. One of the strongest arguments pro OZ is the ease of use which includes that there was no need to take care about boot entries and stuff like that before. Most OZ users are not advanced users they use OZ since it used to work out of the box. This kind of people don't want to mess around with stuff like shells and boot entries they are not used to it and most of them don't want to learn about it. Prior to HighSierra and APFS it doesn't really matter wether the NVRAM is persistent or not since OZ took care about it and scanned the boot entries on each and every start and added them on the fly with APFS this mechanism broke and if the NVRAM is not persistent you'll end up with no bootable Volume which kind of sucks...
  10. griven


    There is one thing which is really annoying with OZ and apfs. Since OZ won't pick up boot entries for APFS Volumes on it's own you have to manually add them via EFI Shell and bcfg which is not much of a deal except your motherboards NVRAM is not writable at all. One Example my Z77-DS-3H (F10 Firmware) has writeable NVRAM and I am able to add boot entries for HighSierra and The Recovery Partition inside The APFC Container without any issue. Once added they stay persistent until I perform a NVRAM Reset on a QOU AOS the same thing won't work. You can add boot entries as well but as soon as you restart the machine or leave the EFI Shell they are gone. Any Ideas how to solve this Issue? Or is there even any progress in a way that OZ will detect this entries on it's own?
  11. griven


    You can easily add an entry via efi shell and bcfg comand...
  12. griven


    The black screen is no OZ Issue at all. Please keep in mind that flashing a new Rom onto your board will reset all settings to factory default and in case you use a dedicated GPU you might end up with a black screen since the iGPU is reactivated and initialised as primary video output. Try to connect your screen to your iGPU instead of the dedicated one and you should be able to enter your bios setup utility and configure it properly (turn off igpu etc...) @DoGuiTTo sorry but Z87N-Wifi has not enough available space to hold all necessary files so the time being there is no way to make this ROM HighSierra compatible.
  13. griven


    Here you go. The Archive contains following Files: - OZ 1.03.167X-CPWN Release (the one patched for HighSierra) - APFS.EFI patched for reduced verbose Output and taken from the Release Version of HighSierra - FakeSMC and Sensors Rev 6.25-333 (SMC Version 2.22f16) And the rest of the OZ Files taken from the XMAS Release. Be careful with the GPU Sensors they might trigger a Kernelpanik if used with a NVIDIA Pascal based GPU. The defaults in this package identify the Maschine as an iMAC14,1. HighSierra.zip
  14. griven


    The mentioned rom contains everything needed to install and run HighSierra I asked about the implementaion of APFS because it´s not best or smartest way to just insert that heavy file into the Rom.
  15. griven


    @Aigors I guess you mean Pike´s post about APFS which he wrote on a pretty early beta stage of APFS Introduction am I right? As far as we know by now there is nothing special in Apple SSD Firmware about APFS at least not as Apple added Support for third Party NVME Vendors with HighSierra... Right it has already been discussed but it has been discussed in a clover flavoured context and I guess we have to rethink about it in terms of OZ. If Apple is able to implement kind of a JumpStart driver into their ROM Images which takes care about loading and connecting APFS.EFI I guess it should be possible to do the same with OZ. Sure I am no Coder and do not understand the underlaying mechanisms but if it works for Macs why should it not work for us?