Jump to content
InsanelyMac Forum

griven

Members
  • Content count

    94
  • Joined

  • Last visited

About griven

  • Rank
    InsanelyMac Protégé
  • Birthday 05/12/1974

Profile Information

  • Gender
    Male
  • Location
    Bochum, NRW, Germany
  1. @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.
  2. 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.
  3. 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.
  4. 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.
  5. griven

    Ozmosis

    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?
  6. griven

    Ozmosis

    @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...
  7. griven

    Ozmosis

    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...
  8. griven

    Ozmosis

    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?
  9. griven

    Ozmosis

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

    Ozmosis

    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.
  11. griven

    Ozmosis

    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
  12. griven

    Ozmosis

    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.
  13. griven

    Ozmosis

    @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?
  14. griven

    Ozmosis

    Besides the translator fun has anyone found a way to implement APFS more Apple like? I browsed some of their ROM Images and found something which identifies itself as APFS Jumpstart Driver which I extracted and attached here. This file is about 12KB in weight and it´s the only reference to APFS I was able to find in Apples FD Images (sure I am a noob at all)... Further on the shortened debug output of APFS.EFI shows that the driver claims that the Metadata indicates a JumpStart Record but the APFS Driver was not started from this Volume which I think is plausible since we start it directly from the ROM rather than from the Volume it should be nested on. My best guess is that APFS.EFI is not designed to be part of the ROM in fact it seems like it is designed to rest on the effected partitions and being started during the initialisation sequence via the Jumpstart Driver which ist part of Apples Firmware. Do you think it´s possible to find a similar mechanism for our OZ Roms since APFS.EFI is pretty heavy in weight and a lot of former working ROMS will become unusable with APFS and HighSierra if we don't find a better way as simply drop APFS.EFI into rom... CFFB32F4-C2A8-48BB-A0EB-6C3CCA3FE847_apfs.ffs.zip
  15. griven

    Ozmosis

    Well, no it does not. It will load if added via EFI Shell and bcfg driver ADD but it won't connect to any device so even if the driver is loaded nothing will happen unless you connect it to a proper device (use the connect command to attach it to a given device) and that's where jumpstart comes into place. Jumpstart typically means that a driver will be started even if no devices are associated with it it will connect to suitable Devices if they are available. UEFI Drivers which are placed inside of the ROM will load if you fire up your Machine and they will load before the drives are initialised to make sure the Filesystems are recognised. Drivers which are added via bcfg depend on a fully initialised and readable Disk to load them. In Case of the APFS Driver it will be loaded but as a Filesystem driver it won't attach to anything since the drives have already been scanned and attached... If you boot into the (u)EFI Shell you might be able to attach the driver to a drive with the connect or reconnect Command both will trigger a scan of the device Tree which automatically will connect APFS but this thing has to be repeated every time you boot up your PC in order to connect APFS...
×