Clover General discussion

[blackosx]

Use this pointer <- did you see the download?

[magnifico]

@ Slice and Fabio and all dev

 

Can write a guide for raid 0 software bootable with Clover mode Uefi in this topic ?

If can ..You can update your initial post?

 

I wait your news

[dmazar]

Slice, could you add some warning to Install post to use USB stick for first Clover installation and tests? I've seen cases where users are running install for the first time directly to HDD and then they mess with existing working Chameleon boot.

 

The best way to play with and test Clover (or any other booter) is to test from USB stick. Prepare MBR formatted USB stick with one FAT32 partition and then install Clover there. This stick can be used for standard BIOS Clover boot and for UEFI boot. Once Clover is set up on that stick and all is working good and you know what you are doing, then install it to HDD.

 

Plus UEFI boot post: until somebody makes a better guide, it would be good to add link to this one:

http://www.projectosx.com/forum/index.php?showtopic=2428&st=240&p=18682entry18682

[magnifico]

:wink2:

 

one of those users is me....

 

Note: I use only pen drive ..with method Damzar.... ( great friend )

[cyf]

Slice, could you add some warning to Install post to use USB stick for first Clover installation and tests? I've seen cases where users are running install for the first time directly to HDD and then they mess with existing working Chameleon boot.

 

The best way to play with and test Clover (or any other booter) is to test from USB stick. Prepare MBR formatted USB stick with one FAT32 partition and then install Clover there. This stick can be used for standard BIOS Clover boot and for UEFI boot. Once Clover is set up on that stick and all is working good and you know what you are doing, then install it to HDD.

 

Plus UEFI boot post: until somebody makes a better guide, it would be good to add link to this one:

http://www.projectos...682

 

FYI:

"That USB stick should have standard Clover installation."

was confusing, because you don't actually need the "bootx" files if you just want to boot under UEFI, right?

 

Actually, the whole set of instructions is complicated if someone just wants to boot UEFI in USB, they can just do this (assuming ML install, whether someone has Chameleon working or not):

 

1. Create USB key as fat32 (e.g., "/Volumes/MyCloverUSB").

2. Copy EFI folder to USB key (e.g., "/Volumes/MyCloverUSB/EFI").

3. The EFI folder should have the following files/directory structure:

 

/EFI
 config.plist [<-- note typo here corrected from pist to plist]
 /ACPI/patched
   DSDT.aml
 /BOOT
   BootX64.efi
   CloverX64.efi
   /fonts <-- Whole directory from Clover install.
   /themes <-- While directory from Clover install.
 /DRIVERS64UEFI
   HFSPlusX64.efi (or VBoxHfs.efi) <-- Required for system to read your OS X partition, which is in HFS.
   OsxFatBinaryDrv.efi
   OsxAptioFixDrv.efi <-- Only required for Aptio boards.
 /kexts/10.8/
   kext1.kext <-- Kexts from your /Extra folder in Chameleon
   kext2.kext <-- |
   ...
 /tools
   Shell64.efi <-- Can be either Shell64.efi or (Shell64U.efi renamed as Shell64.efi)--test one at a time by selecting "Shell" option at Clover boot selection menu.  Necessary if you want to go into EFI shell or definitely needed later if you have Aptio board and your bios does not see Clover directory on your hard drive--i.e., doesn't give you a boot option for Clover when you've copied EFI directory to your hard drive.
...

 

Was much simpler to make an image of my Clover key and helped a few people switch from Chameleon to Clover by having them:

 

1. Download my image;

2. Replace the DSDT in my image with their respective DSDT; and

3. Copy their kext in the /Extras folder to the /kexts/10.8/ folder.

 

People can manipulate OEM folder, etc. AFTER they have first system up and running. Too many options at the beginning is just confusing, IMHO.

[tonydickinson]

This message appears before boot OS.

 

My mouse also Logitech USB. But ordinary optical mouse.

 

Use this pointer <- did you see the download?

 

 

#blackosx - I have downloaded the "invisible" pointer and it works fine - thanks again.

 

Thanks for all you guys do - what would we do without you as I suggested many months ago efforts need to be put in place to protect your work from those who might seek to profit from what you do - like turning Clover into some form of hijacked beast....

[p.H]

Sorry again, but for the "device removal error", it takes something like this:

 

Method (_L0D, 0, NotSerialized)
{
Notify (\_SB.PCI0.EHC1, 0x02)
Notify (\_SB.PCI0.EHC2, 0x02)
Notify (\_SB.PWRB, 0x02)
Notify (\_SB.LID0, 0x02)
}

 

need to add the last two line, to notify to the driver that needs to eject the USB device when it happens one of those things (power button, LID (only for Laptops), or what comes to mind).

On the next reboot, there will be no error, because the device has been expelled before the sleep or power down!

 

Micky

Hi, Micky. Do you know what does clock-id do in dsdt for Device(EHC1 or some number else)?

If I add clock-id in my EHC, usb mouse or keyboard won't be able to wake up the hack. If clock-id removed, usb mouse can wake hack up. But the problem is if I plug one usb device, the hack automatically wake up even though I did nothing else. Really curious. I'm in dilemma.

[Micky1979]

Hi, Micky. Do you know what does clock-id do in dsdt for Device(EHC1 or some number else)?

If I add clock-id in my EHC, usb mouse or keyboard won't be able to wake up the hack. If clock-id removed, usb mouse can wake hack up. But the problem is if I plug one usb device, the hack automatically wake up even though I did nothing else. Really curious. I'm in dilemma.

You can post your dsdt? I want to see..

 

From DSDTSE.app:

"AAPL,clock-id", // property needed for sleep support

from old source code:

 

 

//================================================================================================

//

// CheckSleepCapability

//

//================================================================================================

//

void

AppleUSBOHCI::CheckSleepCapability(void)

{

// assume that sleep is OK

_controllerCanSleep = true;

_hasPCIPwrMgmt = false;

 

// We need to determine which OHCI controllers don't survive sleep. These fall into 2 categories:

//

// 1. CardBus cards

// 2. PCI Cards that lose power (right now because of a bug in the PCI Family, USB PCI cards do not prevent

// sleep, so even cards that don't support the PCI Power Mgmt stuff get their power removed.

//

// Additionally, the PowerBook 101 controller cannot survive across sleep (I doesn't support remote wakeup).

//

// So here, we look at all those cases and set the _unloadUIMAcrossSleep boolean to true. As it turns out,

// if a controller does not have the "AAPL,clock-id" property, then it means that it cannot survive sleep. We

// might need to refine this later once we figure how to deal with PCI cards that can go into PCI sleep mode.

// An exception is the B&W G3, that does not have this property but can sleep. Sigh...

 

// Now, look at PCI cards. Note that the onboard controller's provider is an IOPCIDevice so we cannot use that

// to distinguish between USB PCI cards and the on board controller. Instead, we use the existence of the

// "AAPL,clock-id" property in the provider. If it does not exist, then we are a OHCI controller on a USB PCI card.

//

if ( !_device->getProperty("AAPL,clock-id") && !((getPlatform()->getChipSetType() == kChipSetTypeGossamer) && getPlatform()->getMachineType() == kGossamerTypeYosemite) )

{

if (_device->getProperty("built-in"))

{

// rdar://5769508 - if we are on a built in PCI device, then assume the system supports D3cold

if (_device->hasPCIPowerManagement(kPCIPMCPMESupportFromD3Cold) && (_device->enablePCIPowerManagement(kPCIPMCSPowerStateD3) == kIOReturnSuccess))

{

_hasPCIPwrMgmt = true;

setProperty("Card Type","Built-in");

}

}

else

{

// rdar://5856545 - on older machines without the built-in property, we need to use the "default" case in the IOPCIDevice code

if (_device->hasPCIPowerManagement() && (_device->enablePCIPowerManagement() == kIOReturnSuccess))

{

_hasPCIPwrMgmt = true;

setProperty("Card Type","Built-in");

}

}

 

if (!_hasPCIPwrMgmt)

{

USBError(1, "AppleUSBOHCI[%p]::CheckSleepCapability - controller will be unloaded across sleep",this);

_controllerCanSleep = false;

setProperty("Card Type","PCI");

}

}

else

{

setProperty("Card Type","Built-in");

}

 

// if we have an ExpressCard attached (non-zero port), then we will need to disable port resume

// for that port (some cards disconnect when the ExpressCard power goes away and we would like to ignore these extra detach events.

_ExpressCardPort = ExpressCardPort(_device);

_badExpressCardAttached = false;

 

// Call registerService() so that the IOUSBController object is published and clients (like Prober) can find it

registerService();

}

 

 

this comes from real MBP 10,1:

Method (_DSM, 4, NotSerialized)
	 {
		 Store (Package (0x0B)
			 {
				 "AAPL,current-available",
				 0x0834,
				 "AAPL,current-extra",
				 0x0898,
				 "AAPL,current-extra-in-sleep",
				 0x0640,
				 "AAPL,max-port-current-in-sleep",
				 0x0834,
				 "AAPL,device-internal",
				 0x00,
				 Buffer (0x01)
				 {
						 0x00
				 }
			 }, Local0)
		 DTGP (Arg0, Arg1, Arg2, Arg3)
		 RefOf (Local0)
		 Return (Local0)
	 }

 

AAPL,device-internal is a sobstitute of AAPL,clock-id?

 

 

 

perhaps the value for current in sleep is very important:

"AAPL,current-in-sleep", // to solve a problem with sleep when stick is inserted
0x03E8,

but ... I think this is very objective (the type of motherboard)

 

0x03E8 in HEX = 1000 in decimal====>1000mA

 

0-5V 500mA normal for stick device , with peak currents up to 1000mA........ this may be different on the real MAC.

Maybe now we need to define normal + extra current in sleep mode?

We should study better.

 

Micky

[p.H]

You can post your dsdt? I want to see..

 

From DSDTSE.app:

 

from old source code:

 

 

//================================================================================================

//

// CheckSleepCapability

//

//================================================================================================

//

void

AppleUSBOHCI::CheckSleepCapability(void)

{

// assume that sleep is OK

_controllerCanSleep = true;

_hasPCIPwrMgmt = false;

 

// We need to determine which OHCI controllers don't survive sleep. These fall into 2 categories:

//

// 1. CardBus cards

// 2. PCI Cards that lose power (right now because of a bug in the PCI Family, USB PCI cards do not prevent

// sleep, so even cards that don't support the PCI Power Mgmt stuff get their power removed.

//

// Additionally, the PowerBook 101 controller cannot survive across sleep (I doesn't support remote wakeup).

//

// So here, we look at all those cases and set the _unloadUIMAcrossSleep boolean to true. As it turns out,

// if a controller does not have the "AAPL,clock-id" property, then it means that it cannot survive sleep. We

// might need to refine this later once we figure how to deal with PCI cards that can go into PCI sleep mode.

// An exception is the B&W G3, that does not have this property but can sleep. Sigh...

 

// Now, look at PCI cards. Note that the onboard controller's provider is an IOPCIDevice so we cannot use that

// to distinguish between USB PCI cards and the on board controller. Instead, we use the existence of the

// "AAPL,clock-id" property in the provider. If it does not exist, then we are a OHCI controller on a USB PCI card.

//

if ( !_device->getProperty("AAPL,clock-id") && !((getPlatform()->getChipSetType() == kChipSetTypeGossamer) && getPlatform()->getMachineType() == kGossamerTypeYosemite) )

{

if (_device->getProperty("built-in"))

{

// rdar://5769508 - if we are on a built in PCI device, then assume the system supports D3cold

if (_device->hasPCIPowerManagement(kPCIPMCPMESupportFromD3Cold) && (_device->enablePCIPowerManagement(kPCIPMCSPowerStateD3) == kIOReturnSuccess))

{

_hasPCIPwrMgmt = true;

setProperty("Card Type","Built-in");

}

}

else

{

// rdar://5856545 - on older machines without the built-in property, we need to use the "default" case in the IOPCIDevice code

if (_device->hasPCIPowerManagement() && (_device->enablePCIPowerManagement() == kIOReturnSuccess))

{

_hasPCIPwrMgmt = true;

setProperty("Card Type","Built-in");

}

}

 

if (!_hasPCIPwrMgmt)

{

USBError(1, "AppleUSBOHCI[%p]::CheckSleepCapability - controller will be unloaded across sleep",this);

_controllerCanSleep = false;

setProperty("Card Type","PCI");

}

}

else

{

setProperty("Card Type","Built-in");

}

 

// if we have an ExpressCard attached (non-zero port), then we will need to disable port resume

// for that port (some cards disconnect when the ExpressCard power goes away and we would like to ignore these extra detach events.

_ExpressCardPort = ExpressCardPort(_device);

_badExpressCardAttached = false;

 

// Call registerService() so that the IOUSBController object is published and clients (like Prober) can find it

registerService();

}

 

 

this comes from real MBP 10,1:

Method (_DSM, 4, NotSerialized)
        {
            Store (Package (0x0B)
                {
                    "AAPL,current-available",
                    0x0834,
                    "AAPL,current-extra",
                    0x0898,
                    "AAPL,current-extra-in-sleep",
                    0x0640,
                    "AAPL,max-port-current-in-sleep",
                    0x0834,
                    "AAPL,device-internal",
                    0x00,
                    Buffer (0x01)
                    {
                            0x00
                    }
                }, Local0)
            DTGP (Arg0, Arg1, Arg2, Arg3)
            RefOf (Local0)
            Return (Local0)
        }

 

AAPL,device-internal is a sobstitute of AAPL,clock-id?

 

 

 

perhaps the value for current in sleep is very important:

"AAPL,current-in-sleep", // to solve a problem with sleep when stick is inserted
0x03E8,

but ... I think this is very objective (the type of motherboard)

 

0x03E8 in HEX = 1000 in decimal====>1000mA

 

0-5V 500mA normal for stick device , with peak currents up to 1000mA........ this may be different on the real MAC.

Maybe now we need to define normal + extra current in sleep mode?

We should study better.

 

Micky

nice explanation. Did you remember that you just mentioned a way to solve usb device unexpectedly removed?

I tried your method to add entries L0D(somewhere I can find EHC under GPE scope). but it doesn't work.

And i am interested in how to use the spoiler button. I can't find it anyhow.

[ErmaC]

And i am interested in how to use the spoiler button. I can't find it anyhow.

 

[ spoiler ] content or text or what else to spoiler [ / spoiler ]

 

all w/o space inside the "[ ]"...

 

Fabio

[p.H]

[ spoiler ] content or text or what else to spoiler [ / spoiler ]

 

all w/o space inside the "[ ]"...

 

Fabio

So I have to do it by code ? No button available ?

 

[ErmaC]

So I have to do it by code ? No button available ?

you can write it by hand or use the button... one picture explain all..

 

 

Fabio

[p.H]

you can write it by hand or use the button... one picture explain all..

 

 

Fabio

Thanks, any idea about AAPL,clock-id ?

[cyf]

FYI:

"That USB stick should have standard Clover installation."

was confusing, because you don't actually need the "bootx" files if you just want to boot under UEFI, right?

 

Actually, the whole set of instructions is complicated if someone just wants to boot UEFI in USB, they can just do this (assuming ML install, whether someone has Chameleon working or not):

 

1. Create USB key as fat32 (e.g., "/Volumes/MyCloverUSB").

2. Copy EFI folder to USB key (e.g., "/Volumes/MyCloverUSB/EFI").

3. The EFI folder should have the following files/directory structure:

 

/EFI
config.plist [<-- note typo here corrected from pist to plist]
/ACPI/patched
DSDT.aml
/BOOT
BootX64.efi
CloverX64.efi
/fonts <-- Whole directory from Clover install.
/themes <-- While directory from Clover install.
/DRIVERS64UEFI
HFSPlusX64.efi (or VBoxHfs.efi) <-- Required for system to read your OS X partition, which is in HFS.
OsxFatBinaryDrv.efi
OsxAptioFixDrv.efi <-- Only required for Aptio boards.
/kexts/10.8/
kext1.kext <-- Kexts from your /Extra folder in Chameleon
kext2.kext <-- |
...
/tools
Shell64.efi <-- Can be either Shell64.efi or (Shell64U.efi renamed as Shell64.efi)--test one at a time by selecting "Shell" option at Clover boot selection menu. Necessary if you want to go into EFI shell or definitely needed later if you have Aptio board and your bios does not see Clover directory on your hard drive--i.e., doesn't give you a boot option for Clover when you've copied EFI directory to your hard drive.
...

 

Was much simpler to make an image of my Clover key and helped a few people switch from Chameleon to Clover by having them:

 

1. Download my image;

2. Replace the DSDT in my image with their respective DSDT; and

3. Copy their kext in the /Extras folder to the /kexts/10.8/ folder.

 

People can manipulate OEM folder, etc. AFTER they have first system up and running. Too many options at the beginning is just confusing, IMHO.

 

Edit:

kyndder beat me to it, and better assembled. What a . Just be sure you remove fakesmc.kext from /S/L/E folder as he injects it--also, if you're using HWMonitor, your kexts should be the ones included in the package compiled by Slice (I think I have rev625).

 

http://www.osx86.net/view/3439-clover_v2_uefi_only_rl896.html

[dmazar]

cyf - any guide is welcome. I hope someone will write good guide that will be more understandable to broader se of users. If you can find easier way to install it - that's cool.

 

I prefer installer, because that's how Clover is distributed. And to install Clover on USB stick, you just need start installer and click through it (ok, maybe some additional notes on what to click could help) - end you end up with USB stick with Clover that is:

- BIOS bootable

- UEFI bootable

- plus you can put your Chameleon on it

- and even XPC

 

But that's just start. Then you need to set right options to make it work and finally install it to HDD.

 

Regarding my request for BIOS Clover install first before going to UEFI boot: that was my requirement in early phase while we were testing and discovering UEFI fixes. Before debugging UEFI specifics, I wanted users to have proven Clover config/setup to be reasonably sure that any errors are UEFI specific errors and not some invalid smbios values, invalid DSDT patches, invalid Clover install or options and similar. I still think that having Clover in both ways is good.

[magnifico]

the right way is to always have a pen drive, I saved your ass on many occasions

[kyndder]

Edit:

kyndder beat me to it, and better assembled. What a . Just be sure you remove fakesmc.kext from /S/L/E folder as he injects it--also, if you're using HWMonitor, your kexts should be the ones included in the package compiled by Slice (I think I have rev625).

 

http://www.osx86.net...only_rl896.html

 

Hi cyf,

 

I thought that you was proposing that way, sorry if you had plan to make one and upload...

 

I also tried to attend dmazar's propositions here > #531

 

You will see a warning on the latest Clover downloads...

 

I don't think that the existing documentation for Clover is incomprehensible, in fact, I think that the most of

the Hackintosh users have so much hurry to make things, that forgot to read a bit more before make things...

 

I already pointed for dmazar's tip to have many boot loaders at one USB Stick, but apparently anyone saw...

[Mrengles]

When downloading just the EFI folder and moving into place you don't get any of the /etc rc scripts doesn't this mess around with saving nvram valuables?

 

I remember reading somewhere in this thread that these scripts should be installed to every Mac OS X installation that's booted/used with Clover.

 

PS. Please can a Russian who speaks,reads and writes English translate the Clover FixMask Calculator? This would be very helpful, if you don't know what the patches do it's almost as hard as editing or patching a DSDT. Even just translate to this thread and we can use as a reference when using the application instead of actually translating the localizations of the app itself.

 

Thanks

 

Mrengles

[kyndder]

When downloading just the EFI folder and moving into place you don't get any of the /etc rc scripts doesn't this mess around with saving nvram valuables

 

Yes...

 

But seems that the most of UEFI BIOS owners don't know the differences

between standard BIOS boot an UEFI boot yet...

 

So, as dmazar told, until someone

make a really good guide, maybe this is the best choice, then later after those users

start to understand how to use Clover, they can install manually those files...

[magnifico]

kynnder :wink2:

What is there to understand, everything is simple. There are people who don't read the entire procedure to be done, and here is the reason I make mistakes

 

 

I, for example, I created a bootable raid software without any error, uefi-mode.

 

 

These days I write a guide how to make bootable raid

[Mrengles]

 

Yes...

 

But seems that the most of UEFI BIOS owners don't know the differences

between standard BIOS boot an UEFI boot yet...

 

So, as dmazar told, until someone

make a really good guide, maybe this is the best choice, then later after those users

start to understand how to use Clover, they can install manually those files...

 

Will the standard installer still be released with future builds or just the ISO "EFI" folder?

 

The installer has the unpack option? I really don't think Clover is very difficult it install. Just need to read the thread, allot of new information has been released since the original first few pages. The only thing a "new" good guide will do is consolidate the information for people who are to lazy to read the entire thread. Which will help a lot of people.

 

And have having it all typed up in an "official" Clover Installation and User Guide will give some confidence to new users. Because now they start the installation with one members instructions, complete the installation with another members information, and configure with yet another members information. Who's right and who wrong? Then most likely they fix little aspects of their hackintosh with even another clover users help to fine tune and attempt to get a 100% working system.

 

A new guide is not needed, but will help a lot more people with the information just being better organized.

 

If someone really wants to go overboard a YouTube video series can me made too.

 

That's just my two cents.

 

-Mrengles

[kyndder]

Will the standard installer still be released with future builds or just the ISO "EFI" folder?

 

I'm not a Developer, so, I can't tell anything about this, but I think that Slice, dmazar, apianti, etc, may prefer a full installer...

 

The installer has the unpack option?

 

And + description on each option, it's everything 100% clear...

 

But as I told before, seems that anyone read that info...

 

I really don't think Clover is very difficult it install. Just need to read the thread, allot of new information has been released since the original first few pages. The only thing a "new" good guide will do is consolidate the information for people who are to lazy to read the entire thread. Which will help a lot of people.

 

I also think this way...

 

Chameleon is widely know and until today, we can see lots os new users having great headshakes

to configure him...

 

And have having it all typed up in an "official" Clover Installation and User Guide will give some confidence to new users. Because now they start the installation with one members instructions, complete the installation with another members information, and configure with yet another members information. Who's right and who wrong? Then most likely they fix little aspects of their hackintosh with even another clover users help to fine tune and attempt to get a 100% working system.

 

All Clover's installations are "Official"...

 

Slice's rule is "Just one Branch", so, all Clover installers that may be around should be "Official"...

 

The user to user to user thing is the natural order of things... Did you ever imagined if the Developers

waste their times helping new users??? How they will have time to make changes to his projects and make the things every time better than before???

 

A new guide is not needed, but will help a lot more people with the information just being better organized.

 

Try to make the existing documentation a bit more organised will have a better effect than

create dozens of guides...

 

just more places to "Slice" the information...

 

If someone really wants to go overboard a YouTube video series can me made too.

 

I never liked this stuff... I'm getting old... I like much more to read...

 

The better thing to watch it's a really nice movie on the theater...

[slowTerminal]

I'm getting a boot error related to the AptioFix Driver on Clover v897 (v857 works fine).

 

[tonydickinson]

I'm not a Developer, so, I can't tell anything about this, but I think that Slice, dmazar, apianti, etc, may prefer a full installer...

 

 

 

And + description on each option, it's everything 100% clear...

 

But as I told before, seems that anyone read that info...

 

 

 

I also think this way...

 

Chameleon is widely know and until today, we can see lots os new users having great headshakes

to configure him...

 

 

 

All Clover's installations are "Official"...

 

Slice's rule is "Just one Branch", so, all Clover installers that may be around should be "Official"...

 

The user to user to user thing is the natural order of things... Did you ever imagined if the Developers

waste their times helping new users??? How they will have time to make changes to his projects and make the things every time better than before???

 

 

 

Try to make the existing documentation a bit more organised will have a better effect than

create dozens of guides...

 

just more places to "Slice" the information...

 

 

 

I never liked this stuff... I'm getting old... I like much more to read...

 

The better thing to watch it's a really nice movie on the theater...

 

I do not believe that Clover is difficult to install.

 

However not being totally Noob , I found that there was too much information out there.

 

The original basic installer is relatively straight forward, but does insert drivers that are not wanted or have not been ticked, and there are unanswered questions like should a USB stick be MBR or GPT etc etc that confused me in the beginning and I have followed Clover's development way back to the iphonetom days which Slice took over and developed into something that WORKS.

 

Another issue regarding Clover BIOS and UEFI booting is how the PC BIOS is set up and particularly with Z77 and Z79 boards the UEFI setting determine what is seem at boot time, Asus for example is defaulting UEFI booting to the Windows Secure System now in their latest firmware, so knowledge is required as to how to set up your BIOS. It appears to me as well that overclocking memory and CPU can affect booting with UEFI - BIOS is more tolerant. A DSDT as well appantly working with Chameleon might not be suitable for Clover - so there are a multitude of permutations that would make a generic guide difficult to produce in respect of motherboards and graphics cards, DSDT yes or no, etc etc.

 

I believe what is being done here by ErmaC and by Kynnder at http://www.osx86.net/guides-tutorials/19291-guide-clover-efi-bootloader.html are really helping many people get to grips with the problems, and it is just knowing where to look. One also has to forget the Chameleon mentality i.e. understanding that the Config.plist file is just not a copy of org.chameleon.boot.plist and smbios.plist, and expect it to work. Clover actively works on your UEFI/EFI BIOS whereas Chameleon is mostly passive and makes cosmetic changes.

 

Clover to those who are used to using pkg files to do the job for them will have difficulties, as they just check boxes and pray that it will work then get all emotional when it does not, as they have no clue as to what they are doing. There has to be experimentation and learning, I do not believe that YouTube videos are a substitution for reading and experimenting. Also issue like USB3 and Sleep/Wake might be problematical as one strives to find and understand what is needed.

 

@Kynder I like your approach of providing a UEFI install for Clover simplifying the process considerably.

[Mrengles]

After reading all of the Clover Guide posts in this thread, I'm starting to think a good way for "all" the Cover information be moved to its own section of this forum, and from there Clover sub sections. That way us the users, can writeup/create own own Users guides specific to our hardware and software. The Developers having to create a "Users Guide" with all the different hardware and software combinations could be very difficult and time consuming. This would also make it much easier for new users to find the information they seek "How to get clover working on my hardware".

 

As a community we need to keep them "developers" working on the software, fixing bugs, creating new code the list goes one. They could write there own "User Guides" that would also be very welcome, but having a section just for Clover Bootloader User Builds will help organize the massive amounts of information, and keep from having to create a new massive Clover Guide/Instructions.

 

The Different sub sections can be moderated to keep people on task, and help keep the Clover Forum Section clean. We could have stickies for well written posts, a place to post Installer screen shots, configurations post for your hardware, Q & A section, development section this list goes on...

 

I think this would really help. More "better" information is not the answer, better organized information will help new clover users find the material they need to get started, and continue to learn about the project.