Jump to content
30960 posts in this topic

Recommended Posts

24 minutes ago, SavageAUS said:

.. Does the ApfsDriverLoader work for USB installs?

On my case, my 10.14 USB installer is formatted as HFS+, not really sure if it's needed (pre-install). I just did test placing it within /drivers~ folder and it works to load macOS Mojave with APFS (post-install). Thanks.

Edited by Badruzeus

Hi guys,

 

Shouldn't Clover automatically detect if you already have HFSPlus.efi installed, and not push you to install VBoxHfs.efi in this case? I thought it should remember what you have and what you don't have from previous installations, and suggest to keep that configuration by default, when you reinstall/upgrade.

 

Well, in this case, it keeps pushing to install VBoxHfs, although I didn't have it before (it would be a new install) and I already have HFSPlus. Interestingly enough, it doesn't do the same with ApfsDriverLoader.

Is this intended?

 

207371327_Screenshot2018-06-17at00_32_48.png.8c3ee5929b4d8bbd9f2c1d3cfc1773da.png

  • Like 1

@savvamitrofanov just report your ApfsDriverLoader.efi works good here HP ProBook 6570B

Compiling the drivers with UDK2018 

Thank you

Capture.png.48bfd34f203eba4e232103181879030a.png

 

Edited by chris1111
  • Like 2
  • Thanks 1

@Slice 

 

Thanks to your latest commits regarding mtoc.NEW locations, I was able to compile Clover 4551 using UDK2018 with no errors anymore. Thank you very much! :) 


By the way, since we can build nasm with ./buildnasm.sh (which has also been fixed), I think we can remove the first steps from the instructions page and add a new line for it under Step nr 4 (Prepare sources).

 

Also, to avoid error

./edksetup.sh: line 149: return: can only `return' from a function or sourced script

when invoking that script with "./" , maybe we can update the instructions so that it will be invoked with  ". edksetup.sh" instead. This should work perfectly fine.

 

Just a few ideas, of course. :)

Edited by arsradu
3 minutes ago, arsradu said:

@Slice 

 

 

 

Also, to avoid error


./edksetup.sh: line 149: return: can only `return' from a function or sourced script

when invoking that script with ./, maybe we can update the instructions so that it will be invoked with  ". edksetup.sh" instead. This should work perfectly fine.

 

 

I don't know it. Never encounter.

2 minutes ago, Slice said:

I don't know it. Never encounter.

 

Really? :)))

 

Cause I always do...when building with UDK2018. And, even though I'm building in Mojave (Xcode 10)...I doubt this has anything to do with it.

 

192-168-0-116:UDK2018 jimmy$ ./edksetup.sh
Loading previous configuration from /Users/jimmy/src/UDK2018/Conf/BuildEnv.sh
WORKSPACE: /Users/jimmy/src/UDK2018
EDK_TOOLS_PATH: /Users/jimmy/src/UDK2018/BaseTools
CONF_PATH: /Users/jimmy/src/UDK2018/Conf
./edksetup.sh: line 149: return: can only `return' from a function or sourced script
192-168-0-116:UDK2018 jimmy$ 

 

Edited by arsradu
6 minutes ago, Slice said:

But it is not our script. Report to EDK2-devel group.

 

I think it's already been reported...here: https://patches.linaro.org/patch/79255/

 

If I got this right, they say that invoking the script with ./ is actually not ok for this case. I'm not sure why. I'm not an expert. This is just what I got from it...

Edited by arsradu

bdmesg started to report faulty version number:

3:616  0:000  Starting Clover revision: 01314556 on CLOVER EFI

Do the ebuild.sh script update the Version.h file?

Here is mine:

#define FIRMWARE_BUILDDATE "2018-06-17 15:46:09"
#define FIRMWARE_REVISION L"01314556"
#define REVISION_STR "Clover revision: 01314556"
#define BUILDINFOS_STR "Args: -n 9 -t XCODE8 --vbios-patch-cloverefi --only-sata0 --no-ext -D USE_LOW_EBDA -D NO_GRUB_DRIVERS -D NO_GRUB_DRIVERS_EMBEDDED -D EXIT_USBKB=1 --x64 | -D USE_LOW_EBDA -D NO_GRUB_DRIVERS -D NO_GRUB_DRIVERS_EMBEDDED -D EXIT_USBKB=1 -D ENABLE_VBIOS_PATCH_CLOVEREFI -D ONLY_SATA_0 -D USE_LOW_EBDA -a X64 -b RELEASE -t XCODE8 -n 9 | OS: 10.13.5 | XCODE: 9.4"

So the script should be faulty...

1 minute ago, smolderas said:

bdmesg started to report faulty version number:


3:616  0:000  Starting Clover revision: 01314556 on CLOVER EFI

Do the ebuild.sh script update the Version.h file?

Here is mine:


#define FIRMWARE_BUILDDATE "2018-06-17 15:46:09"
#define FIRMWARE_REVISION L"01314556"
#define REVISION_STR "Clover revision: 01314556"
#define BUILDINFOS_STR "Args: -n 9 -t XCODE8 --vbios-patch-cloverefi --only-sata0 --no-ext -D USE_LOW_EBDA -D NO_GRUB_DRIVERS -D NO_GRUB_DRIVERS_EMBEDDED -D EXIT_USBKB=1 --x64 | -D USE_LOW_EBDA -D NO_GRUB_DRIVERS -D NO_GRUB_DRIVERS_EMBEDDED -D EXIT_USBKB=1 -D ENABLE_VBIOS_PATCH_CLOVEREFI -D ONLY_SATA_0 -D USE_LOW_EBDA -a X64 -b RELEASE -t XCODE8 -n 9 | OS: 10.13.5 | XCODE: 9.4"

So the script should be faulty...

All OK

0:100  0:000  Now is 17.6.2018,  15:52:50 (GMT)
0:100  0:000  Starting Clover revision: 4558 on American Megatrends EFI

6 minutes ago, Ukr55 said:

All OK

0:100  0:000  Now is 17.6.2018,  15:52:50 (GMT)
0:100  0:000  Starting Clover revision: 4558 on American Megatrends EFI

I removed the file, and tried to build with ebuild.sh, same issue. Somewhere along there is an error.

9 minutes ago, Ukr55 said:

All OK

0:100  0:000  Now is 17.6.2018,  15:52:50 (GMT)
0:100  0:000  Starting Clover revision: 4558 on American Megatrends EFI

I removed the file, and tried to build with ebuild.sh, same issue. Somewhere along there is an error.

 

Edit: I found the culprit:

Change the line 614 in the ebuild.sh to 

		repoRev=$(svn info|awk '{ if ($1=="Revision:") {print $2}}')

So here is the diff:

614c614
< 		repoRev=$(svn info | grep "Revision" | tr -cd [:digit:])
---
> 		repoRev=$(svn info|awk '{ if ($1=="Revision:") {print $2}}')

 

33 minutes ago, smolderas said:

I removed the file, and tried to build with ebuild.sh, same issue. Somewhere along there is an error.

 

Edit: I found the culprit:

Change the line 614 in the ebuild.sh to 


		repoRev=$(svn info|awk '{ if ($1=="Revision:") {print $2}}')

So here is the diff:


614c614
< 		repoRev=$(svn info | grep "Revision" | tr -cd [:digit:])
---
> 		repoRev=$(svn info|awk '{ if ($1=="Revision:") {print $2}}')

 

Why ome method is better then another? What is your subversion client version?

What is full output of "svn info" in EDK2 folder? In UDK2018 folder?

I tried some hours getting iMessage to work, after updating to 10.13.5. After many testing, i found that CLOVER was to blame. Before i updated to 10.13.5, i installed CLOVER 4498 (coming from 4428).

 

Any CLOVER Version i tried prevented activating iMessage (iMessage Error in systemlog: 13)

 

I tried 4497, 4509, 4458 and 4522. Rolling back to CLOVER 4428 brought back the capability to activate iMessage. iMessage is set up correctly regarding ROM and MLB and never was a issue before.

 

 

Any ideas?

 

Hi guys,

 

Are the drivers that Clover proposes for installation documented anywhere? I know some of them are. But I couldn't find a proper description for most of them.

And the description within the installer itself is far from being...descriptive enough. :))

 

So, unless you used them before, or you somehow know what they are good for, it's very hard to choose the right ones. Rule of thumb is usually start with only a few ones. But how do you know WHICH ones? Especially since they're not grouped in any way. You don't know which ones are good for what.

 

Some of them are documented here, for as far as I could see. Some of them are in Clover Change Explanations thread...and some others probably scattered throughout the forum.

 

I can collect them in a single thread, that's not a problem (in case nobody did that already). Although, in my opinion, the first place where they should be documented, is on the Clover Wiki. After that, they should be in the actual description box of the installer itself.

 

Still, in order to do that, I would still need a good description for each one of them, in terms of what they are, and what are they good for. Also, whether or not they create conflicts with other drivers.

 

Edited by arsradu
  • Like 3
  • Thanks 1
17 hours ago, ApexDE said:

I tried some hours getting iMessage to work, after updating to 10.13.5. After many testing, i found that CLOVER was to blame. Before i updated to 10.13.5, i installed CLOVER 4498 (coming from 4428).

 

Any CLOVER Version i tried prevented activating iMessage (iMessage Error in systemlog: 13)

 

I tried 4497, 4509, 4458 and 4522. Rolling back to CLOVER 4428 brought back the capability to activate iMessage. iMessage is set up correctly regarding ROM and MLB and never was a issue before.

 

 

Any ideas?

 

I too have the same issue, I was trying to find the culprit. I'll take a look at it on the weekend.

On 6/15/2018 at 9:29 AM, Sherlocks said:

 

this is awesome driver.

OsxAptioFix2Drv-free2000

and

OsxAptioFixDrv on sandy laptop(10.6~10.13).

 

there is no problem.

thank you so much.

 

Do you use both OsxAptioFix2 together on the same laptop? I have a sandy bridge laptop and use AptioFixDrv and works but I have some glitches and sometimes the display freezes.

 

What about you? no freezes/glitches? I have 8GB of RAM.

 

I'm gonna try OsxAptioFix2Drv-free2000 alone later.

Edited by el_charlie
On 6/18/2018 at 6:30 AM, smolderas said:

I too have the same issue, I was trying to find the culprit. I'll take a look at it on the weekend.

UGH!! Right about June 6 my Messages/Facetime, which have been working for many years, just stopped working. It wouldn’t activate. I spent at least eight hours on Monday trying to figure out why. I deleted pref files, even changed my rock solid config file with new serial number, board serial, ROM, MLB, etc. I even called Apple which I know was a stupid idea.

 

So others are having this same issue? I tried to go back to version 4497 but it didn't work. I think I've screwed something up with Apple activation servers now.

1 hour ago, pkdesign said:

UGH!! Right about June 6 my Messages/Facetime, which have been working for many years, just stopped working. It wouldn’t activate. I spent at least eight hours on Monday trying to figure out why. I deleted pref files, even changed my rock solid config file with new serial number, board serial, ROM, MLB, etc. I even called Apple which I know was a stupid idea.

 

So others are having this same issue? I tried to go back to version 4497 but it didn't work. I think I've screwed something up with Apple activation servers now.

i am not alone!!! right, something like that. yesterday I tried to fix but...

Following the discussion from the separate topic (good investigation, guys!), it seems that the iMessage problem originates from the change at device-inject.c from commit 4497.

 

Before this commit, built-in property injection for LAN was being made by default.

Starting with 4497, an option to control this feature was added, with its default being set to FALSE (so built-in property is being injected only when LANInjection setting is activated).

 

And as we already confirmed in the past, iMessage activation is insisting on the built-in property to exist on some device in order to activate, even if the actual connection is from a different network device.

Perhaps we could consider setting LANInjection default to TRUE, to avoid breaking iMessage for people that are relying on this.

 

Edited by Pene
  • Like 3
  • Thanks 1
×
×
  • Create New...