Jump to content
30960 posts in this topic

Recommended Posts

@Matgen84 You should be able to use Open Core Legacy Patcher (OCLP). It should work fine with CLOVER.  See my proposed steps here.  Ivybridge/HD4000 is reported working with OCLP up to Ventura 13.2.1 (so far).

  • Thanks 1
40 minutes ago, deeveedee said:

@Matgen84 You should be able to use Open Core Legacy Patcher (OCLP). It should work fine with CLOVER.  See my proposed steps here.  Ivybridge/HD4000 is reported working with OCLP up to Ventura 13.2.1 (so far).

 

Thanks @deeveedee Catalina is installed on my IvyBridge (SMBIOS iMac 13,2) with a lot of software and data. I just want to upgrade to Monterey without losing anything. If I well understand, I can use the same SMBIOS, right ! 

@Matgen84  Yes.  I would recommend that you clone your current Catalina volume to a new volume that you can play with, then keep your original Catalina volume in a safe place as you experiment with the upgrade to Monterey.

  1. Leave your CLOVER EFI SMBIOS model as iMac13,2.  
  2. Use OCLP 0.6.1 to generate an OpenCore EFI for SMBIOS iMac13,2.  
  3. Copy kernel patches, kexts and boot-args (possibly other items) from the OCLP-generated EFI to your CLOVER EFI.  You'll need to experiment to determine what elements you need to copy from the OCLP-generated EFI to your CLOVER EFI.  Note that OCLP is intended for REAL MACs ONLY, so there are elements of the OCLP-generated EFI that are intended for REAL MACS.  You do NOT want to copy everything from the OCLP-generated EFI.
  4. After you create your new "hybrid" EFI (a combination of your original CLOVER EFI with the OCLP-generate EFI), use the new hybrid EFI to boot the Monterey installer and perform an in-place upgrade of Catalina to Monterey.
  5. After you upgrade to Monterey, use OCLP to apply post-install patches.  Note that your Monterey graphics performance may be V-E-R-Y S-L-O-W until you apply OCLP post-install patches and reboot.

If you have problems upgrading directly to Monterey, try Big Sur first.  With my hack, I found it easier to upgrade first to Big Sur, but I was still dealing with bugs in OCLP that have since been resolved.  You may have no trouble upgrading directly from Catalina to Monterey.

 

Edited by deeveedee
  • Like 1
  • Thanks 1

@deeveedee OCLP 0.6.1 can't generate an OpencoreEFI for SMBIOS iMac13,2 (on my Ivybridge Catalina-Clover rig) 😪 Of course I can create macOS Installer. Upgrade to BigSur first seems to be a good idea !

 

Spoiler

1522903171_Capturedcran2023-03-2108_21_31.png.5eb6e474dd6c4ae96cfcfd34bcdb32d0.png

 

 

 

 

Sorry for Off-Topic in Clover general discussion

@Matgen84 You can run OCLP on any Mac or Hack and choose the target SMBIOS in Settings.  Build and Install Open Core to a USB stick on the other Mac or Hack and use it on your iMac13,2.

 

 

EDIT: @Matgen84 If you don't have another hack or mac:

  1. run OCLP
  2. open Settings
  3. Change target SMBIOS to iMac13,1
  4. Return to main menu
  5. Build Open Core to a USB stick

 

The OCLP-generated EFI for iMac13,1 should be close enough to iMac13,2 that you can get what you need.

 

 

EDIT2: If you need more help, post your questions in this thread.

Edited by deeveedee
7 minutes ago, deeveedee said:

@Matgen84 You can run OCLP on any Mac or Hack and choose the target SMBIOS in Settings.  Build and Install Open Core to a USB stick on the other Mac or Hack and use it on your iMac13,2.

 

Thanks @deeveedee Unfortunately, I don't have another Hack 😪 to run OCLP and choose target. My old IvyBridge Desktop will stay with Catalina. Bad luck.

Hi @Slice

I can't build latest commit (Monterey 12.6.3 / XCode 14.2) Command Lines Tools installed. Any ideas ? Please.

 

Spoiler

TOOLCHAIN_DIR: /Users/mathieu/src/opt/local
MTOC_PREFIX: /Users/mathieu/src/opt/local/bin/
NASM_PREFIX: /Users/mathieu/src/opt/local/bin/
NASM_VER: 2.16.01
Initializing workspace
recreate Conf folder
WORKSPACE: /Users/mathieu/src/Cloverbootloader
EDK_TOOLS_PATH: /Users/mathieu/src/Cloverbootloader/BaseTools
CONF_PATH: /Users/mathieu/src/Cloverbootloader/Conf
Copying $EDK_TOOLS_PATH/Conf/build_rule.template
     to /Users/mathieu/src/Cloverbootloader/Conf/build_rule.txt
Copying $EDK_TOOLS_PATH/Conf/tools_def.template
     to /Users/mathieu/src/Cloverbootloader/Conf/tools_def.txt
Copying $EDK_TOOLS_PATH/Conf/target.template
     to /Users/mathieu/src/Cloverbootloader/Conf/target.txt
Build environment: macOS-12.6.3-x86_64-i386-64bit
Build start time: 09:43:05, Mar.22 2023

WORKSPACE        = /Users/mathieu/src/Cloverbootloader
EDK_TOOLS_PATH   = /Users/mathieu/src/Cloverbootloader/BaseTools
CONF_PATH        = /Users/mathieu/src/Cloverbootloader/Conf
PYTHON_COMMAND   = python3

Processing meta-data .. done!


build.py...
 : error C0DE: Unknown fatal error when processing [/Users/mathieu/src/Cloverbootloader/OpenCorePkg/Library/OcDebugLogLibOc2Clover/OcDebugLogLibOc2Clover.inf [X64, XCODE8, RELEASE]]
    
(Please send email to devel@edk2.groups.io for help, attaching following call stack trace!)

(Python 3.11.2 on darwin) Traceback (most recent call last):
  File "/Users/mathieu/src/Cloverbootloader/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 1388, in _BuildPa
    RemoveDirectory(AutoGenObject.BuildDir, True)
  File "/Users/mathieu/src/Cloverbootloader/BaseTools/Source/Python/Common/Misc.py", line 443, in RemoveDirectory
    os.rmdir(Directory)
  File "/Users/mathieu/src/Cloverbootloader/BaseTools/Source/Python/Common/LongFilePathOs.py", line 33, in rmdir
    return os.rmdir(LongFilePath(path))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 66] Directory not empty: '/Users/mathieu/src/Cloverbootloader/Build/Clover/RELEASE_XCODE8'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/mathieu/src/Cloverbootloader/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 2695, in Main
    MyBuild.Launch()
  File "/Users/mathieu/src/Cloverbootloader/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 2488, in Launch
    self._BuildPlatform()
  File "/Users/mathieu/src/Cloverbootloader/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 1823, in _BuildPlatform
    self._BuildPa(self.Target, Pa, FfsCommand=CmdListDict,PcdMaList=PcdMaList)
  File "/Users/mathieu/src/Cloverbootloader/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line 1389, in _BuildPa
    except WindowsError as X:
           ^^^^^^^^^^^^
NameError: name 'WindowsError' is not defined


- Failed -
 

 

 

I create a clean local repo: Error compiling cctools-949.0.1 mtoc ! Check the log /Users/mathieu/src/tools/logs/mtoc.make.log.txt. 
Anyway there is an update for cctools : https://opensource.apple.com/source/cctools/cctools -973.0.1/

 

Spoiler

Cloning into '/Users/mathieu/src/Cloverbootloader'...
Updating files:  29% (3016/10224)
Updating files:  30% (3068/10224)
Updating files:  31% (3170/10224)
Updating files:  32% (3272/10224)
Updating files:  33% (3374/10224)
Updating files:  34% (3477/10224)
Updating files:  35% (3579/10224)
Updating files:  36% (3681/10224)
Updating files:  37% (3783/10224)
Updating files:  38% (3886/10224)
Updating files:  39% (3988/10224)
Updating files:  40% (4090/10224)
Updating files:  41% (4192/10224)
Updating files:  42% (4295/10224)
Updating files:  43% (4397/10224)
Updating files:  44% (4499/10224)
Updating files:  45% (4601/10224)
Updating files:  46% (4704/10224)
Updating files:  47% (4806/10224)
Updating files:  48% (4908/10224)
Updating files:  49% (5010/10224)
Updating files:  50% (5112/10224)
Updating files:  51% (5215/10224)
Updating files:  52% (5317/10224)
Updating files:  53% (5419/10224)
Updating files:  54% (5521/10224)
Updating files:  55% (5624/10224)
Updating files:  56% (5726/10224)
Updating files:  57% (5828/10224)
Updating files:  58% (5930/10224)
Updating files:  59% (6033/10224)
Updating files:  60% (6135/10224)
Updating files:  61% (6237/10224)
Updating files:  62% (6339/10224)
Updating files:  63% (6442/10224)
Updating files:  64% (6544/10224)
Updating files:  65% (6646/10224)
Updating files:  66% (6748/10224)
Updating files:  67% (6851/10224)
Updating files:  67% (6887/10224)
Updating files:  68% (6953/10224)
Updating files:  69% (7055/10224)
Updating files:  70% (7157/10224)
Updating files:  71% (7260/10224)
Updating files:  72% (7362/10224)
Updating files:  73% (7464/10224)
Updating files:  74% (7566/10224)
Updating files:  75% (7668/10224)
Updating files:  76% (7771/10224)
Updating files:  77% (7873/10224)
Updating files:  78% (7975/10224)
Updating files:  79% (8077/10224)
Updating files:  80% (8180/10224)
Updating files:  81% (8282/10224)
Updating files:  82% (8384/10224)
Updating files:  83% (8486/10224)
Updating files:  84% (8589/10224)
Updating files:  85% (8691/10224)
Updating files:  86% (8793/10224)
Updating files:  87% (8895/10224)
Updating files:  88% (8998/10224)
Updating files:  88% (9070/10224)
Updating files:  89% (9100/10224)
Updating files:  90% (9202/10224)
Updating files:  91% (9304/10224)
Updating files:  92% (9407/10224)
Updating files:  93% (9509/10224)
Updating files:  94% (9611/10224)
Updating files:  95% (9713/10224)
Updating files:  96% (9816/10224)
Updating files:  97% (9918/10224)
Updating files:  98% (10020/10224)
Updating files:  99% (10122/10224)
Updating files: 100% (10224/10224)
Updating files: 100% (10224/10224), done.
Submodule 'OpenCorePkg' (https://github.com/CloverHackyColor/OpenCorePkg.git) registered for path 'OpenCorePkg'
Cloning into '/Users/mathieu/src/Cloverbootloader/OpenCorePkg'...
Submodule path 'OpenCorePkg': checked out 'ed2fb797dae4e7b67e6dfe5afc4c0f6375d0403f'

Status: gettext-0.21.1.tar.xz not found.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0 9818k    0 49152    0     0  84035      0  0:01:59 --:--:--  0:01:59 84744
100 9818k  100 9818k    0     0  7412k      0  0:00:01  0:00:01 --:--:-- 7444k
- Creating new RAM disk

Initialized /dev/rdisk5 as a 300 MB case-insensitive HFS Plus volume
-  gettext-0.21.1 extract...
-  gettext-0.21.1 configure...
-  gettext-0.21.1 make...
-  gettext-0.21.1 installing...
-  gettext-0.21.1 installed in /Users/mathieu/src/opt/local

- Ejecting RAM disk
"disk5" ejected.

Status: cctools-949.0.1.tar.gz not found.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   257  100   257    0     0   2281      0 --:--:-- --:--:-- --:--:--  2649
- Creating new RAM disk

Initialized /dev/rdisk5 as a 300 MB case-insensitive HFS Plus volume
Unrecognized file format of '/Users/mathieu/src/tools/download/cctools-949.0.1.tar.gz'
-  cctools-949.0.1 make mtoc...
Error compiling cctools-949.0.1 mtoc ! Check the log /Users/mathieu/src/tools/logs/mtoc.make.log.txt

- Ejecting RAM disk

 

 

/mtoc.make.log.txt

(make LTO= EFITOOLS=efitools -C libstuff) && (make -C efitools)
make: *** libstuff: No such file or directory.  Stop.

 

Edited by Matgen84

@Matgen84

When i tested Monterey on my mobo

all worked out pretty nice, using Clover as BL, in fact was the same I used for Big Sur, had to do nothing else then install the system and use same efi from BS.

i'm on Haswell (rig on 1st signature) so IvyBridge should work just fine even without OC or OCLP.

coming from Cata you should just pay attention to any possible changes needed by the quirks if any (now I can't seem to remember which were the differences if any, from one to another)

but what is sure is, it will work.

  • Like 1
19 minutes ago, LAbyOne said:

@Matgen84

When i tested Monterey on my mobo

all worked out pretty nice, using Clover as BL, in fact was the same I used for Big Sur, had to do nothing else then install the system and use same efi from BS.

i'm on Haswell (rig on 1st signature) so IvyBridge should work just fine even without OC or OCLP.

coming from Cata you should just pay attention to any possible changes needed by the quirks if any (now I can't seem to remember which were the differences if any, from one to another)

but what is sure is, it will work.

 

For now, I tested Monterey with SMBIOS Macpro6,. With SMBIOS  iMac13,2, I can't install this OS from USB Installer (Clover). I use OCLP only to patch Intel HD4000 and Nvidia GT640. Next week, I try SMBIOS iMac13,2 on Monterey installed.

 

Do you see my previous message: I can't build latest commit (Monterey 12.6.3 / XCode 14.2) Command Lines Tools installed. Any ideas ?

1 hour ago, Matgen84 said:

 

For now, I tested Monterey with SMBIOS Macpro6,. With SMBIOS  iMac13,2, I can't install this OS from USB Installer (Clover). I use OCLP only to patch Intel HD4000 and Nvidia GT640. Next week, I try SMBIOS iMac13,2 on Monterey installed.

 

Do you see my previous message: I can't build latest commit (Monterey 12.6.3 / XCode 14.2) Command Lines Tools installed. Any ideas ?

i used smbios 18.3 and also worked with imacpro

Edited by LAbyOne

Use Clover As My Main Loader, Was Loading Monterey And Ventura No Problems BUT Now

I Can't Install Any macOS As Clover Sees The Installer, Goes Thru The Initial Install Ok, Does The Reboot And

Installs The Second Install Ok, But On The Third Reboot The Disk Does Not Show In Clover Menu.

What Is Weirder Is That I Try To Boot An Full Install On USB Key, Still Does Not See It.

Never Struck This Before, I'm Out Of Ideas. 

So To Sum It Up, Can't Boot Any Installed macOS As Does Not Show Up

NVME Drive Or USB

Have An Idea It MAY Be APFS Loader May Be Borked. As It's The APFS Disks That Don't Show

 

EDIT:

I Have Tries Different Versions Of APFS.efi. Does Show Drives BUT Doesn't Boot Them

Knocks Head Against The Brick Wall;(

 EDIT:

Tried OC Same Deal, NO Show, I Think I Have Major Problems

 

I Should Add That Win11 Boots Ok Off Same NVME

 

Edit3:

All Good, Was Settings In Security, DOH!!

Does not explain how I could run the installer with that setting enabled

 

Edited by STLVNUB
  • Sad 1

Hi @Slice

 

Always a clean repo for Clover
Same issue when I use Buildme XCOBE8 (IvyBridge SMBIOS MacPro6,1 Monterey 12.6.3 / XCode 14.2) with Python 3.11.2. Very strange: cctools-949.0.1 don't make mtoc

 

Spoiler

------------------------------------------------------------------------------

                          🍀 Clover r5151 (SHA: 0fceb2622)

              TOOLCHAIN: XCODE8 (override example: './buildme XCODE8')

------------------- Installed Python version: Python 3.11.2 ------------------

 

 

 

 

 

 

 

 

 

1) build Clover 9) test Clover

2) update Clover 10) check status

3) build Clover with HFSPlus 11) show diff

4) make pkg 12) open CloverV2/EFI/CLOVER directory

5) make iso 13) update Clover (reset changes)

6) make app 14) clean BaseTools

7) build all 15) Utilities

make Release 16) quit

 

Please enter your choice: 1

[CHECK XCODE]

WORKSPACE: /Users/mathieu/src/cloverbootloader

EDK_TOOLS_PATH: /Users/mathieu/src/cloverbootloader/BaseTools

CONF_PATH: /Users/mathieu/src/cloverbootloader/Conf

Copying $EDK_TOOLS_PATH/Conf/build_rule.template

     to /Users/mathieu/src/cloverbootloader/Conf/build_rule.txt

Copying $EDK_TOOLS_PATH/Conf/tools_def.template

     to /Users/mathieu/src/cloverbootloader/Conf/tools_def.txt

Copying $EDK_TOOLS_PATH/Conf/target.template

     to /Users/mathieu/src/cloverbootloader/Conf/target.txt

[BUILD CLOVER]

TOOLCHAIN_DIR: /Users/mathieu/src/opt/local

 

- Creating new RAM disk

 

Initialized /dev/rdisk5 as a 300 MB case-insensitive HFS Plus volume

Unrecognized file format of '/Users/mathieu/src/cloverbootloader/toolchain/tools/download/cctools-949.0.1.tar.gz'

-  cctools-949.0.1 make mtoc...

Error compiling cctools-949.0.1 mtoc ! Check the log /Users/mathieu/src/cloverbootloader/toolchain/tools/logs/mtoc.make.log.txt

 

- Ejecting RAM disk

"disk5" ejected.

mathieu@iMac-de-Mathieu cloverbootloader %

 

Edited by Matgen84

Why 

Unrecognized file format of '/Users/mathieu/src/cloverbootloader/toolchain/tools/download/cctools-949.0.1.tar.gz

 

   case ${filetype} in # convert to lowercase
        gzip\ *)  tar_filter_option='--gzip' ;;
        bzip2\ *) tar_filter_option='--bzip2';;
        lzip\ *)  tar_filter_option='--lzip' ;;
        lzop\ *)  tar_filter_option='--lzop' ;;
        lzma\ *)  tar_filter_option='--lzma' ;;
        xz\ *)    tar_filter_option='--xz'   ;;
        *tar\ archive*) tar_filter_option='';;
        *) echo "Unrecognized file format of '$tarball'"
           exit 1
           ;;
    esac

 

  • Sad 1

This is new GitHub polity: we are not allowed to download a file from github by a script to avoid bots.

 We must go to GitHub by a browser, click on the file and it will be downloaded.

Then manually move the file from Download folder to our location

~/src/tools/download/

Manually downloaded file has a name "cctools-cctools-949.0.1.tar.gz" because a link on github is not a link to file. real file is sealed.

Don't load other version!

Rename it to normal name "cctools-949.0.1.tar.gz" and then start the script

./buildmtoc.sh

But now we loose the file from @Jief_Machak

cp: /BaseTools/Source/C/mtoc/mtoc-v921_jief.c: No such file or directory

Is there anybody has this file anywhere?

I found it. 

I modified buildmtoc.sh script to use new patch and commited this patched file into Clover repository. Anyway automatic download of the cctools is impossible. Only manually.

 

The resulted mtoc is attached.

mtoc.NEW_jief.zip

  • Thanks 1

@Slice

actually it does downloads and build directly

you just have to modify these lines

buildmtoc.sh


### into
export CCTOOLS_VERSION=${CCTOOLS_VERSION:-949.0.1}
-->
export CCTOOLS_VERSION=${CCTOOLS_VERSION:-cctools-949.0.1}


### into
DownloadSource () {

    cd "$DIR_DOWNLOADS"
    local tarball="cctools-${CCTOOLS_VERSION}.tar.gz"
    if [[ ! -f "$tarball" ]]; then
        echo "Status: $tarball not found."
        curl -f -o download.tmp --remote-name https://github.com/apple-oss-distributions/cctools/archive/refs/tags/$tarball || exit 1
        mv download.tmp $tarball		
-->	
    cd "$DIR_DOWNLOADS"
    local tarball="${CCTOOLS_VERSION}.tar.gz"
    if [[ ! -f ${DIR_DOWNLOADS}/${CCTOOLS_VERSION}.tar.gz ]]; then
        echo "Status: ${CCTOOLS_VERSION} not found."
        curl -k -f -o download.tmp --remote-name https://codeload.github.com/apple-oss-distributions/cctools/tar.gz/refs/tags/${CCTOOLS_VERSION} || exit 1
        mv download.tmp $tarball


### into
fnCompileMtoc ()

	local CCTOOLS_DIR=$(fnExtract "cctools-${CCTOOLS_VERSION}.tar.gz")
-->
	local CCTOOLS_DIR=$(fnExtract "${CCTOOLS_VERSION}.tar.gz")
	

 

or if better for you, here's the modified file

buildmtoc.sh

or i can eventually pull a request from git,

as is best for you

 

actually there's also a newer version = cctools-986,

which will surely require new patches,

unfortunately lately I don't really have much time left by my side , even to take a look.

if it can wait... i will gladly.

  • Like 1
  • Thanks 2

@Slice

ok, new cctools-986, integrated into build

added needed patches

1037693030_ScreenShot.png.35faef8aec09d49fad0619fd9e62939d.png

works just like previous, if you want to test.

 

One thing to notice is this new cctools requirements are macOS_10.15

 

PS.

just realized i could eventually add system version check with relative files to build,

to maintain retro-compatibility for those willing to install older systems.

 

Done.

 

PP.SS.

cctools-986-integrated.zip

Udated files = added buildmtoc_retro

with retro compatibility

 

let me know what you think.

Edited by LAbyOne
  • Like 1
28 minutes ago, Slice said:

10.15 is not good as I usually using 10.14 for compilation. But OK, in this case one may use retro.

I will commit this solution.

 

 

Thanks @Slice Maybe there is a typo error: buildmto_retro.sh instead of buildmtoc_retro.sh

To use the new cctools, new mtoc_Jief version: it's necessary to remove previous version in mi local repo. Right!

Edited by Matgen84
47 minutes ago, Matgen84 said:

 

Thanks @Slice Maybe there is a typo error: buildmto_retro.sh instead of buildmtoc_retro.sh

To use the new cctools, new mtoc_Jief version: it's necessary to remove previous version in mi local repo. Right!

But there is no difference. They work quite similar.

  • Like 1
4 hours ago, Matgen84 said:

 

Thanks @Slice Maybe there is a typo error: buildmto_retro.sh instead of buildmtoc_retro.sh

To use the new cctools, new mtoc_Jief version: it's necessary to remove previous version in mi local repo. Right!

Sorry, but it is simplier than that.

i posted both files to let @Slice make its decision based on what would be better to use.

buildmtoc.sh is the only name the file should havem as it has always been.

the retro version is only included for the reasons I explained

 

4 hours ago, Slice said:

But there is no difference. They work quite similar.

in fact none, just added different solutions

 

@Slice the only thing to do in this case to avoid confusion,

is to put on repo only the buildmtoc_retro.sh renamed buildmtoc.sh.

that only will take care of both cases and will build on any system, since, its the one who actually have the updated build for v-986, and the previous v-973 in it.

no need for multiple files.

Edited by LAbyOne
extended explanation
  • Like 1
×
×
  • Create New...