Clover General discussion

[Max.1974]

18 hours ago, MakAsrock said:

I only replaced CLOVERX64.efi with a new one, just to test it. The rest is from the previous copy. Only I have a newer build.I haven't used the installer for several years.

 

 

dmesglog.txt.zip 13.8 kB · 0 downloads

 

@MakAsrock Hi my dear, yes I don’t use the pkg installer either, but it’s just a sample, I also only replace the essentials.

I would recommend replacing the EFI drivers, the tools folder, and the two boot files — they are actually the same, but if you replace only one, it won’t be fully recognized.

[Max.1974]

This tool capture last build and update direct in your EFI 

 

https://github.com/hnanoto/Update_Clover 

 

😉 

[MakAsrock]

20 hours ago, Max.1974 said:

This tool capture last build and update direct in your EFI 

 

https://github.com/hnanoto/Update_Clover 

 

😉

It's a great utility, but the update source is hopelessly behind the times. I try to keep my own repository up to date and don't see the point in relying on Slice's branch. 😉

[Max.1974]

6 hours ago, MakAsrock said:

It's a great utility, but the update source is hopelessly behind the times. I try to keep my own repository up to date and don't see the point in relying on Slice's branch. 😉

 

 

I understand, but I can guarantee you that Clover doesn’t need to be so up-to-date — it just needs to be functional. It’s the best of the bootloaders because it doesn’t require so many updates. This app fetches the latest version from GitHub Actions and installs it directly. The tools from GitHub are better than ours, and they only come out from there if they’re 100% ready.

Edited September 19, 2025 by Max.1974

[MakAsrock]

4 hours ago, Max.1974 said:

 

Here’s a natural translation for your text into English:

I understand, but I can guarantee you that Clover doesn’t need to be so up-to-date — it just needs to be functional. It’s the best of the bootloaders because it doesn’t require so many updates. This app fetches the latest version from GitHub Actions and installs it directly. The tools from GitHub are better than ours, and they only come out from there if they’re 100% ready.

I understand. Thank you!

[MakAsrock]

Question for the community:
For packaging the build on macOS, we can either:

1. Keep the old method (no 7z).

2. Use 7z for packaging (7zz will be downloaded automatically or installed via Homebrew).

Which option do you prefer?
Nostalgic Theme (Norton-style)
This theme gives the terminal/build window a classic Norton Commander look.
You can disable it at any time by commenting out the relevant line with # in the window behavior settings.

Edited September 20, 2025 by MakAsrock

[naiclub]

17 minutes ago, MakAsrock said:

Question for the community:
For packaging the build on macOS, we can either:

1. Keep the old method (no 7z).

2. Use 7z for packaging (7zz will be downloaded automatically or installed via Homebrew).

Which option do you prefer?
Nostalgic Theme (Norton-style)
This theme gives the terminal/build window a classic Norton Commander look.
You can disable it at any time by commenting out the relevant line with # in the window behavior settings.

Looks good, my friend.

[MakAsrock]

So I went ahead and made the background in the buildme window transparent. In the active window, it will not be transparent, as before.

 

Edited September 22, 2025 by MakAsrock

[Alpha22]

@MakAsrock filled out, all ok

 

Spoiler

 

[Matgen84]

@Slice Is a new toolchain for XCODE26 planned for the near future?

[MakAsrock]

4 hours ago, Matgen84 said:

@Slice Is a new toolchain for XCODE26 planned for the near future?

Not likely anytime soon. But you can use my buildme. It compiles with the one that is there.

[Slice]

On 9/22/2025 at 3:52 PM, Matgen84 said:

@Slice Is a new toolchain for XCODE26 planned for the near future?

A new toolchain appeared when old toolchain has a problem with current codes.

[Matgen84]

12 hours ago, Slice said:

A new toolchain appeared when old toolchain has a problem with current codes.

 

Sorry, I don't understand what you means because of my poor English. I'm talking about XCODE26, to know if is it possible to build Clover under macOS Tahe with XCODE26.

[Alpha22]

28 minutes ago, Matgen84 said:

 

Sorry, I don't understand what you means because of my poor English. I'm talking about XCODE26, to know if is it possible to build Clover under macOS Tahe with XCODE26.

Xcode version 26 can compile Clover

Spoiler

 

[MakAsrock]

2 hours ago, Matgen84 said:

 

Sorry, I don't understand what you means because of my poor English. I'm talking about XCODE26, to know if is it possible to build Clover under macOS Tahe with XCODE26.

Yes, Xcode version 26 can compile Clover. But you need to clone mine branch, not Slice's or put pressure for him so that he can fix what doesn't work.

mpkg.log.zip

Edited September 29, 2025 by MakAsrock

[chris1111]

The Build is fixed ✌️
Clover take 20 min for building in first use.

I Restore buildme at this state ⬇︎

See Actiond build ⬇︎ Look the beautiful little green hook 

Edited October 1, 2025 by chris1111

[Matgen84]

Hello @chris1111 Thanks for the job, dear friend.

 

 

EDIT: On Sequoia (Xcode 16.4), the release is completed but Menu loops after Make (XCODE) with this message: Please enter your choice: /Users/mathieu/src/CloverBootloader/buildme: line 906: read error: 0: Resource temporarily unavailable

I do not try make command with gcc151 toolchain.

Edited October 1, 2025 by Matgen84

[chris1111]

3 hours ago, Matgen84 said:

Hello @chris1111 Thanks for the job, dear friend.

 

 

EDIT: On Sequoia (Xcode 16.4), the release is completed but Menu loops after Make (XCODE) with this message: Please enter your choice: /Users/mathieu/src/CloverBootloader/buildme: line 906: read error: 0: Resource temporarily unavailable

I do not try make command with gcc151 toolchain.

Hi @Matgen84 thank you 

I’ve not mod Buildme I restore at this point, I only ad Log fix for the pkg 

[chris1111]

2 hours ago, Max.1974 said:

 

Hi @chris1111 thanks a lot for your time with Clover !! 

Here is fine and good compilation 

 

 

 

 

Thank you my good frend😎

appreciate!

[Matgen84]

21 hours ago, chris1111 said:

Hi @Matgen84 thank you 

I’ve not mod Buildme I restore at this point, I only ad Log fix for the pkg 

 

Hi @chris1111  Thanks for you reply. I will git clone repo from scratch perhaps the menu loops will disappear 🥲 

 

EDIT: copy paste buildme from github to local: issue solved 😊

Edited October 2, 2025 by Matgen84

[Slice]

On 10/1/2025 at 2:21 PM, Matgen84 said:

Hello @chris1111 Thanks for the job, dear friend.

 

 

EDIT: On Sequoia (Xcode 16.4), the release is completed but Menu loops after Make (XCODE) with this message: Please enter your choice: /Users/mathieu/src/CloverBootloader/buildme: line 906: read error: 0: Resource temporarily unavailable

I do not try make command with gcc151 toolchain.

Menu loops appears because of extra spaces inside strings. I can’t correct at this moment because I’m far from home now.

[chris1111]

@Slice read your PM

[MakAsrock]

@chris1111, I finally found the reason the buildme was broken. An empty definition was escaping a needed argument. I didn't check these lines because I was confident that renowned authors wouldn't make mistakes in such things, but here it is.

Here is the first corrected fragment:

echo "[BUILD CLOVER RELEASE WITH XCODE]"
  local xrel="$(defaults read /Applications/Xcode.app/Contents/version.plist CFBundleShortVersionString | cut -d. -f1)"
  if [[ "$xrel" < "14" ]]; then
	  ./ebuild.sh -fr -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8
	  ./ebuild.sh -fr -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE8
  elif [[ "$xrel" == "14" ]]; then
	  ./ebuild.sh -fr -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE14
	  ./ebuild.sh -fr -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE14
  elif [[ "$xrel" == "15" ]]; then
	  ./ebuild.sh -fr -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE15
	  ./ebuild.sh -fr -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE15
  elif [[ "$xrel" == "16" ]]; then
	  ./ebuild.sh -fr -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE16
	  ./ebuild.sh -fr -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE16
  elif [[ "$xrel" > "16" ]]; then
      ./ebuild.sh -fr -mc --no-usb -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE16
      ./ebuild.sh -fr -D NO_GRUB_DRIVERS_EMBEDDED -t XCODE16
  fi
  # Run a post build script if exist (${DIR_TOOLS}/CloverScripts/postbuild.sh)
  if [[ -x "${DIR_TOOLS}/CloverScripts/postbuild.sh" ]]; then
  chmod +x "${DIR_TOOLS}/CloverScripts/postbuild.sh"
  echo "Running Clover postbuild script"
  "${DIR_TOOLS}/CloverScripts/postbuild.sh" "${CLOVERROOT}" $MYTOOLCHAIN
  fi
}

And this is the second one:

echo "[BUILD CLOVER WITH XCODE]"
if [[ -x "${DIR_TOOLS}/Scripts/build.sh" ]]; then
  echo "Running custom build script"
  "${DIR_TOOLS}/Scripts/build.sh" "${CLOVERROOT}" $MYTOOLCHAIN
else
  local xrel="$(defaults read /Applications/Xcode.app/Contents/version.plist CFBundleShortVersionString | cut -d. -f1)"
    if [[ "$xrel" < "14" ]]; then
  	  ./ebuild.sh -fr -D NO_GRUB_DRIVERS_EMBEDDED -D USE_APPLE_HFSPLUS_DRIVER -t XCODE8
    elif [[ "$xrel" == "14" ]]; then
  	  ./ebuild.sh -fr -D NO_GRUB_DRIVERS_EMBEDDED -D USE_APPLE_HFSPLUS_DRIVER -t XCODE14
    elif [[ "$xrel" == "15" ]]; then
  	  ./ebuild.sh -fr -D NO_GRUB_DRIVERS_EMBEDDED -D USE_APPLE_HFSPLUS_DRIVER -t XCODE15
    elif [[ "$xrel" == "16" ]]; then
  	  ./ebuild.sh -fr -D NO_GRUB_DRIVERS_EMBEDDED -D USE_APPLE_HFSPLUS_DRIVER -t XCODE16
    elif [[ "$xrel" > "16" ]]; then
      ./ebuild.sh -fr -D NO_GRUB_DRIVERS_EMBEDDED -D USE_APPLE_HFSPLUS_DRIVER -t XCODE16
    fi
  fi

All that remains is to align everything and remove any extra spaces.

[chris1111]

@MakAsrock Ive not see any issue with buildme

 

@Max.1974 

This message only appears in Tahoe 26

 

Dont know why? In Sequoia and bellow thats not appear

[MakAsrock]

1 hour ago, chris1111 said:

@MakAsrock Ive not see any issue with buildme

 

@Max.1974 

This message only appears in Tahoe 26

 

Dont know why? In Sequoia and bellow thats not appear

I encountered the same error with the original makeiso, makepkg, and makeV2 on Sequoia, so I rewrote all three files, slightly changing the algorithms.
This line is to blame:
revision=$(git describe --tags $(git rev-list --tags --max-count=1))

There's an invisible character (ZERO WIDTH SPACE or similar Unicode garbage) in there. Git interprets it as part of the argument, and instead of --max-count=1 , it actually gets something like --max-count=1<invisible_character> . As a result, the strange argument "1…" is substituted, and Git complains that it's not a number.

The old script is "like the original" and only works in the "correct" environment (called from Make, macOS, with a configured PATH, in a tagged Git repository).
My new script is more self-contained and robust:
it automatically finds the repo and toolchain;
it doesn't crash without tags;
it also works on Linux;
it monitors errors more accurately.
I could have limited myself to cleaning the old scripts of invisible characters, but I decided that the new algorithms were more reliable.
Slice shouldn't be harassing me. I've been programming since the days of punch cards. It's just that with age, I've lost my concentration in large volumes of program lines. If I don't write everything at once, as I used to, I rarely make mistakes.

Edited October 3, 2025 by MakAsrock