Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
29,866 posts in this topic

Recommended Posts

Matgen84
Matgen84
Posted
Posted
10 minutes ago, Andres ZeroCross said:

I got this problem when installing Clover r4988,,

I have run "sudo mount -uw /" and "sudo killall Finder" before install

image.png.757a7c50c24fb7bf165b834c53c442c6.png

 

It worked on me with this command   sudo mount -uw / killall Finder under Catalina

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted (edited)

I'm getting this error when building 4990: 

================= Making all in boot1-install =================
	[XCODE] boot1-install
================= Making all in partutil =================
	[XCODE] partutil
================= Making all in bdmesg =================
	[XCODE] bdmesg
================= Making all in clover-genconfig =================
	[XCODE] clover-genconfig
Error: don't call the '/Users/jimmy/src/UDK2018/Clover/CloverPackage/makeiso' script directly !
Use the 'make iso' command instead

Don't call ./makeiso script directly? How else would you call it? By mail? That might take a while. :)))

 

Joking, of course. But anyway, interesting error. What's funnier is that it seems to be building iso ok, despite that error... :)) And I'm getting the same error even if I run "make iso" as suggested instead of "./makeiso".

 

I think this was previously there. I just didn't see it, cause I don't usually build iso for myself.

Edited by arsradu
  • Like 2
  • Haha 1
Link to comment
Share on other sites
fusion71au
fusion71au
Posted
Posted (edited)
3 hours ago, arsradu said:

 

Perfect! Then I can just update and build directly from source. Awesome. Thank you!

 

@arsradu,

 

You still need to follow steps 2-4 in the post above so that the ISO contains the normal config.plist you use to boot your system and all your normal kexts (otherwise by default, only FakeSMC.kext is included in the ISO).

 

Also, if you want to exclude the Clovy theme as the cause of your red screen error, you can use this script that uses the embedded theme instead makeiso_embedded.zip:

 

1.  Copy my makeiso_embedded file above to ~/src/edk2/Clover/CloverPackage

2.  Delete ~/src/edk2/Clover/CloverPackage/CloverV2/EFI/CLOVER/config-sample.plist.  Copy your desired config.plist (which you know boots your system) to the same folder, giving it the name config-sample.plist

3.  Copy all the kexts you normally need to inject with Clover to ~/src/edk2/Clover/CloverPackage/CloverV2/ThirdParty/kexts/Other

4.  Copy the embedded theme folder from ~/src/edk2/Clover/CloverPackage/CloverV2/EFI/CLOVER/themes to ~/src/edk2/Clover/CloverPackage/CloverV2/themespkg

5.  Run my new makeiso_embedded script in terminal... 

cd ~/src/edk2/Clover/CloverPackage
chmod +x makeiso_embedded
./makeiso_embedded

The custom ISO will be created in the ~/src/edk2/Clover/CloverPackage/sym folder.

 

In addition, there might be a specific procedure for your particular brand/model of computer to boot in UEFI mode to CD/DVD-ROM eg google "boot in uefi mode to cd" might give relevant results.

 

Another possibility is that your firmware in UEFI mode cannot read the CD/DVD-ROM because it lacks the necessary built in uefi file system drivers?  Maybe try booting to an UEFI shell first, load CD drivers + HFS driver eg VBoxIso9600-64.efi, GrubUDF-64.efi and HFSPlus.efi (google procedure to load efi drivers with UEFI shell), then chain load to Clover on the CD?

 

Good Luck!

Edited by fusion71au
extra info
  • Like 2
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted (edited)
2 hours ago, Matgen84 said:

It worked on me with this command   sudo mount -uw / killall Finder under Catalina

 

  1. killall Finder does nothing for the pkg, other then close all windows even if you don't want.
  2. Installer.app parse all things (Distribution, Payloads, PakageInfos, Boms), so if Apple doesn't want Us to run a package that installs things to the System volume .... we can't. 'sudo mount -uw' worked in beta1 but not in beta3 (by put this command in a preinstall script). 
  3. Solution? Not sure. Should we try to implement a call to an external script from the command line by making a java-script function in the Distribution file, or call osascript to display a dialog. The Distribution is in use before the error appears.. 
  4. I'm not a java dev :whistle:
  5. Anyone has taken a look to the kernel if a read-write flag exist???
  6. Another "possible" solution is to modify the clover daemon, which I suppose runs as root, to receive an argument and so do the job for us. In a frensh installation we'll need to run the command by hand... later attempts will be automatic.
Edited by vector sigma
  • Like 1
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted
1 minute ago, arsradu said:

@fusion71au Thanks! I'll take a closer look tonight. And yeah, despite of the fact that now your changes are in the source, I didn't forget about the other steps. :) 

You may consider to also revert local changes by cd into Clover and: 

svn revert -R .

and keep a clean source..

  • Like 1
Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted (edited)

Implementing a java script for the clover package is not really a very difficult thing.

I made a very basic one here that works to make Catalina's disk read and write.

 

I do the video demonstration that it works with the one I did

 

 

Distribution-RW 


    <installation-check script="pm_install_check();"/>
    <script>function pm_install_check() {
  if(!(/* &gt;= */ system.compareVersions(system.version.ProductVersion, '10.6.0') &gt;= 0)) {
    my.result.title = 'Failure';
    my.result.message = 'You must have at least MacOS X 10.16 to use this program.';
    my.result.type = 'Fatal';
    return false;
  }
  if(!(system.run('~/src/tools/RW-script.sh') == true)) {
    my.result.title = 'Disk in RW';
    my.result.message = 'If you have entered your password and there has been a killall Finder is that the script is well executed. Otherwise make sure RW-script.sh script it is in /HOME/src/tools';
    my.result.type = '';
    return false;
  }
  return true;
}
</script>

RW-script.sh 

#!/bin/bash

osascript -e 'do shell script "sudo mount -uw / & killall Finder" with administrator privileges'

 

From now you can modify the java code so that the sexecute script inside Clover package Resources.

Good Hack :D

 

RW-script.sh.zip

Distribution-RW.zip

Edited by chris1111
  • Like 3
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted
1 hour ago, chris1111 said:

Implementing a java script for the clover package is not really a very difficult thing.

I made a very basic one here that works to make Catalina's disk read and write.

 

I do the video demonstration that it works with the one I did

 

 

Distribution-RW 



    <installation-check script="pm_install_check();"/>
    <script>function pm_install_check() {
  if(!(/* &gt;= */ system.compareVersions(system.version.ProductVersion, '10.6.0') &gt;= 0)) {
    my.result.title = 'Failure';
    my.result.message = 'You must have at least MacOS X 10.16 to use this program.';
    my.result.type = 'Fatal';
    return false;
  }
  if(!(system.run('~/src/tools/RW-script.sh') == true)) {
    my.result.title = 'Disk in RW';
    my.result.message = 'If you have entered your password and there has been a killall Finder is that the script is well executed. Otherwise make sure RW-script.sh script it is in /HOME/src/tools';
    my.result.type = '';
    return false;
  }
  return true;
}
</script>

RW-script.sh 


#!/bin/bash

osascript -e 'do shell script "sudo mount -uw / & killall Finder" with administrator privileges'

 

From now you can modify the java code so that the sexecute script inside Clover package Resources.

Good Hack :D

Distribution-RW.zip

RW-script.sh.zip

Exactly what I had in mind. Should be cool then to run osascript directly in the Distribution..

  • Like 2
Link to comment
Share on other sites
Ben.Cheng
Ben.Cheng
Posted
Posted (edited)

Hi All:

I got a issue when compile Clover EFI. It failure when compile gettext-0.20.1. Attach file is gettext.make.log.txt.

 

I remember it could run before. I could build Clover_v2.4k_r4980.pkg success. But after I update Clover + edk2, it became to failure.

 

macOS: 10.14.5

Xciode: Version 10.2.1 (10E1001)

 

Any idea? 

 

Undefined symbols for architecture x86_64:
  "_close_stdout", referenced from:
      _main in gettext-gettext.o
  "_error", referenced from:
      _main in gettext-gettext.o
  "_gnu_basename", referenced from:
      _main in gettext-gettext.o
  "_program_name", referenced from:
      _main in gettext-gettext.o
      _usage in gettext-gettext.o
  "_proper_name", referenced from:
      _main in gettext-gettext.o
  "_rpl_getopt_long", referenced from:
      _main in gettext-gettext.o
  "_rpl_optarg", referenced from:
      _main in gettext-gettext.o
  "_rpl_optind", referenced from:
      _main in gettext-gettext.o
  "_set_program_name", referenced from:
      _main in gettext-gettext.o
  "_xmalloc", referenced from:
      _expand_escape in gettext-gettext.o
ld: symbol(s) not found for architecture x86_64

 

-----------

 

Hi All:

I've solved this issue.

I found there are another "libtool" and "ar" file located out of /usr/bin. "ar" seem be installed with binutils which installed by Homebrew. Remove binutils will fixed this issue: 

$ brew uninstall binutils

 

 

gettext.make.log.txt

Edited by Ben.Cheng
Link to comment
Share on other sites
tluck
tluck
Posted
Posted (edited)

I was curious about the new packaging (which looks good) - but was specifically curious about the exclusion of the EXT_PACKAGES - such as the AptioMemoryFix group?

 

Are we left to figure out which one is best/works -- or what is the thought/rationale on this aspect?

thanks

 

AptioMemoryFix.efi (external)

vs

OsxAptioFix3Drv.efi

OsxAptioFixDrv.efi

OsxLowMemFixDrv.efi

Edited by tluck
Link to comment
Share on other sites
vector sigma
vector sigma
Posted
Posted
10 minutes ago, brousseau6933 said:

Not sure if I'm off topic:

 

Clover 4988 on Sourceforge: missing AptioMemoryFix-64.efi in the package.

 

I'll wait, better safe than sorry.

 

1 minute ago, tluck said:

I was curious about the new packaging (which looks good) - but was specifically curious about the exclusion of the EXT_PACKAGES - such as the AptioMemoryFix group?

 

Are we left to figure out which one is bests or what is the thought/rationale on this aspect?

thanks

 

AptioMemoryFix.efi (external)

vs

OsxAptioFix3Drv.efi

OsxAptioFixDrv.efi

OsxLowMemFixDrv.efi

EXT_PACKAGES gives errors which we cannot control and people asked here why, unless you want to import almost all the OpenCore source code Lol. If you have AptioMemoryFix installed the package will not touch it unless you decide to install one of the *AptioFix* included in Clover. Later if I have time I want to implement back all the changes they made to the original OsxAptioFix which AptioMemoryFix is based on :).

Link to comment
Share on other sites
pkdesign
pkdesign
Posted
Posted

Just updated to 4988 and am confused by install. There is a drivers64UEFI folder in clover folder.

 

1) Is this left over from my original 4972 install and was not deleted by Clover?

2) Will this be a problem when I restart?

3) Do I just put the drivers in the drivers64UEFI folder into the new drivers>UEFI folder and delete the driver64UEFI folder?

4) Why do I have a BIOS folder when I have a UEFI mobo and did not select any of those during install?

 

Thanks!

 

 

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted (edited)
23 minutes ago, pkdesign said:

Just updated to 4988 and am confused by install. There is a drivers64UEFI folder in clover folder.

 

1) Is this left over from my original 4972 install and was not deleted by Clover?

2) Will this be a problem when I restart?

3) Do I just put the drivers in the drivers64UEFI folder into the new drivers>UEFI folder and delete the driver64UEFI folder?

4) Why do I have a BIOS folder when I have a UEFI mobo and did not select any of those during install?

 

Thanks!

 

 

1) it's been decided to keep both the new folder scheme, and the old one, for retro-compatibility. But I feel like this created more confusion to the users.

2) unlikely (but just in case, make a USB drive with Clover on it and double check your drivers and drivers64UEFI folders). Make sure all your necessary drivers are in there.

3) if you're not planning on going back to an old version of Clover (which still uses drivers64 and drivers64UEFI scheme), without reinstalling that version, but by simply copy-pasting the drivers to your EFI/Clover folder, then yes, you can delete. In other words, if you want to use an older version, just use the damn installer! :)) Don't just copy-paste folders from one version to the other. Unless you rename them to match the old folder naming scheme (meaning drivers64 for BIOS and drivers64UEFI for UEFI booting).

4) Did you reselect UEFI drivers, along with the corresponding UEFI drivers? If yes...that might be a bug. Nothing to worry about. It just won't use those. But yeah, could be a bug.

Edited by arsradu
Link to comment
Share on other sites
artur_pt
artur_pt
Posted
Posted

hello Slice good night

 

something is wrong in clover .. that is only my opinion.. the value is zero

 

many people now is changing the source code .. clover is beginning slow to boot the OS, and not always boot the OS first time when u are doing a new update to the system.

what I want to say about this , u must begin to work the files in clover.. and do a cleanup in the source code .. I'm sure many lines are now deprecated.. I know is a hard job ... but I'm sure u are the right person to do this ... another point something is wrong in inject kext in Mojave and in Catalina..

 

sorry to disturb u , in all work u do for booting macOS 

 

all the best

 

  • Like 2
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...