Jump to content

Clover General discussion


ErmaC
30,146 posts in this topic

Recommended Posts

Test Release r5121 build from source:

 

  • Mojave (my IvyBridge config): Hidden Entries works via GUI section config.plist. I can boot Recovery partition
  • Catalina (my Z390 config): Hidden Entries works via GUI section config.plist. I can boot Recovery partition

 

I hope that Clover will be compatible with Big Sur, soon. Thanks for developers efforts :)

 

 

Edited by Matgen84
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

@Cristina89,


Yeah, a custom entry to hide Recovery HD like below
 

Spoiler



	<key>GUI</key>
	<dict>
		<key>Custom</key>
		<dict>
			<key>Entries</key>
			<array>
				<dict>
					<key>Disabled</key>
					<false/>
					<key>FullTitle</key>
					<string>Recovery HD</string>
					<key>Hidden</key>
					<true/>
					<key>Ignore</key>
					<false/>
					<key>InjectKexts</key>
					<true/>
					<key>NoCaches</key>
					<false/>
					<key>Type</key>
					<string>OSXRecovery</string>
				</dict>
			</array>
		</dict>


 

no longer works in r5121.


Easiest work around is to remove the custom entry from your config.plist and just include "Recovery" in the "Hide" section of GUI...

 

	<key>GUI</key>
	<dict>
		<key>Hide</key>
		<array>
			<string>Recovery</string>
		</array>

 

Main GUI with hidden Recovery HD...

Spoiler

screenshot1.thumb.png.93777091fcd448c6cf7df03f7f7fea5f.png

 

Unhide Recovery HD by pressing <F3>...

Spoiler

screenshot2.thumb.png.d6ee1289578a0d8125dcc6a23348a323.png

 

  • Like 5
Link to comment
Share on other sites

6 minutes ago, Jief_Machak said:

I committed the next step in plist refactoring. I tried with my computer and with Slice config.

 

I've also committed a portable version of Qemu in Qemu folder.  It's 22 MB. If you are against that, just tell me, I'll cancel my last commit.

 

Thanks a lot. :)

I don't understand why there is a portable version of Qemu in a Qemu folder. Personally, I use both Parallels (Big Sur compatible) and VMware Fusion. In my opinion, users can download updated versions directly from Qemu.org, if they want. This is only my point of view as most of the users do not use virtualization software, especially because they are not developers or testers.

  • Like 2
Link to comment
Share on other sites

18 minutes ago, Matgen84 said:

I don't understand why there is a portable version of Qemu in a Qemu folder. Personally, I use both Parallels (Big Sur compatible) and VMware Fusion. In my opinion, users can download updated versions directly from Qemu.org, if they want. This is only my point of view as most of the users do not use virtualization software, especially because they are not developers or testers.

I also use VMWare. I do almost all my live debug with it.

If we make this easy, maybe all users will become testers !

Portable version of things are handy because it's possible to have launch script that works all the time. Sometime a user can have a different version, one that has a bug, or doesn't know how to install, or install in a different place.
It's also handy to know that I can just copy my Clover folder and have all the tools ready. I can copy my Clover folder on a friend's computer and work offline without the need to install anything and modifying his computer.

But what you said is also true : its code that can be downloaded elsewhere. I wouldn't have done that if it wasn't only 22MB. But because it's debatable, no problem to remove that commit (as long as nobody commit anything else, because to free the space, all the repository has to be reverted to the previous commit).

The first idea was to make a script to launch under Qemu and gdb, so any users can report the backtrace. Could help a lot in case of a panic. I did the script, but haven't has much success with that. And we manage to find the panic anyway.

  • Like 1
Link to comment
Share on other sites

@Jief_Machak

 


I understand the general idea with Qemu and his interest. But these are still virtual tests, while the posts on the Clover topic bring up information from real machines. Personally, I do not know and do not know how to use Qemu. It would require documentation for those who want to use it. Because that would remain optional, wouldn't it. Modestly, I think a manual is quite heavy to manage.

 

Many Clover users are eagerly awaiting compatibility with Big Sur. While they are forced to go through OC since Beta 1. I am one of those who want to continue using Clover. Obviously, this is only my opinion: although interesting, the Qemu file is not necessarily essential for the moment.

 

Sorry, It would have been interesting to ask the question to the users before making the commit.

  • Like 2
Link to comment
Share on other sites

7 hours ago, Matgen84 said:

@Jief_Machak

 

I understand the general idea with Qemu and his interest. But these are still virtual tests, while the posts on the Clover topic bring up information from real machines. Personally, I do not know and do not know how to use Qemu. It would require documentation for those who want to use it. Because that would remain optional, wouldn't it. Modestly, I think a manual is quite heavy to manage.

Instead of committing Qemu, perhaps commit some scripts or instructions to (1) download Qemu (2) build it (3) install Clover to it (4) launch Qemu (5) debug Clover in Qemu.

Or do both so we know how to make use of the Qemu commit (I haven't looked at it, maybe the info is already included?).

 

Link to comment
Share on other sites

2 hours ago, maclinuxG4 said:

boot is okay for r5121, but i lost sound, made by a patch to get it. 

(usb sound ok)

 

the patch is  made by device with a list of element.

 

 

Could you send me your config.plist ? I'l quickly find why the patch is ignored.

Link to comment
Share on other sites

On 8/23/2020 at 11:22 AM, Jief_Machak said:

Could you send me your config.plist ? I'l quickly find why the patch is ignored.

 

yes check also why clover say disable first, and apply for patch kernel

 

i use a patch in device for sound but also elements

 

Edited by maclinuxG4
bug found
Link to comment
Share on other sites

43 minutes ago, maclinuxG4 said:

why clover say disable first, and apply for patch kerne

Fixed.

 

44 minutes ago, maclinuxG4 said:

i use a patch in device for sound but also elements

Not sure what you mean by "elements". I found a difference. Property were 8 bytes instead of 4 before. Could you try to see if it makes a difference ?

Link to comment
Share on other sites

I wanted to ask you dev, if you are planning something like oc validate or oc config appears
this in order to check if the Clover config you are using is updated with respect to the sample and if it contains no errors.
I say these because several times I ran into problems that in the end were simply related to a corrupt or not compliant config, but apparently it was OK.
Just yesterday it happened to me on the Z370 while testing a new KVM switch, that I had to forcibly reset the system, but out of the blue, clover 5121 didn't even start the GUI, while with clover 5120 it started regularly. I redid my config starting from the sample, and this mysterious problem where Clover 5121 didn't start anymore, has been solved. :)

 

  • Like 2
Link to comment
Share on other sites

In my signature Clevo, with Parted Magic I first formatted and created new EFI, started by pendrive USB I installed Clover 5121, recreated from scratch the config with the sample, finally put back kexts, ssdt that I used previously.
As a memory manager, ocquirks and openruntime.
The macOS that start and work perfectly are:
win 7x64, win10Prox64, el capitan, sierra, high sierra, mojave and finally catalina

In this way I passed an empasse that prevented me from using any clover greater than 5098 and now I'm up to date with the next releases of Clover :thumbsup_anim:

  • Like 2
Link to comment
Share on other sites

×
×
  • Create New...