Clover General discussion

[zxv]

Seems for me, like Aptio maps the wrong Memory region...

Nonworking NVRAM is a known issue on newer AptioV boards. Are you using EmuVariableUefi.efi?

[Matgen84]

Thanks for sharing.  The theme folder installer option is missing unless this was on purpose?

 

Hi

 

In my compiled version r4293, the theme folder is present. 

 

[MacBart]

@joevt,

Thanks for the reply, learning something new every day   .

At the beginning I was rather freaked out, but now I know where it came from, what and why, and how easy it is to unmount, I'm glad I know now.

[Ramalama]

Nonworking NVRAM is a known issue on newer AptioV boards. Are you using EmuVariableUefi.efi?

 

Yep, ive seen, but there are ways...

1. We can disable SMI Lock in bios (to make things easier)

2. We had same Problems on Aptio4 long time ago but i dont know how it's fixed... (On my Laptop nvram works even with SMI Lock enabled...(Aptio4 Haswell))

 

So there must be a way, there are just not enough benefits, as far as Emulated Nvram exists...

 

In my Opnion, 50% of the Aptiofix driver is useless, if nvram doesnt work.

Thats why i want to get that fixed, but no one want to spend time on this...

 

Cheers

[apianti]

Your NVRAM breaks because it is being locked by your firmware, this is normal for almost all firmware but you should not have that problem with AptioFix2. Also, you are way off on what the AptioFixes do, with out it you wouldn't even be able to boot. AptioFixes add things Apple firmware expects that UEFI doesn't do, changes ACPI memory page types so they are not moved, and then patches the kernel to properly start and fix the device tree. AptioFix creates a relocation region, loads the kernel there, then moves it to the spot it requested. AptioFix2 tries to give it the region the kernel wants to begin.

 

EDIT: Also maybe try to solve the problem yourself instead of acting like other people should do it for you. I do this because I like to, not because you feel entitled for others working for you without putting in any effort of your own. There are developers who have been doing this for a decade, I myself have for like six or seven years. Do some research, learn, figure the problem out, find the solution. Believe me, no one will do it for you unless they happen to have the same problem. Sometimes, it's the configuration and your firmware settings though, too. But most of the time you need to accept it doesn't work or continue and try to find a way to change it. And just for the record, the NVRAM issue has been known since UEFI booting macOS has been possible, it is an SMI locking problem.

[zxv]

Yep, ive seen, but there are ways...

1. We can disable SMI Lock in bios (to make things easier)

2. We had same Problems on Aptio4 long time ago but i dont know how it's fixed... (On my Laptop nvram works even with SMI Lock enabled...(Aptio4 Haswell))

 

So there must be a way, there are just not enough benefits, as far as Emulated Nvram exists...

There's a topic on this if you're so inclined.

[mhaeuser]

 

 

the NVRAM issue has been known since UEFI booting macOS has been possible, it is an SMI locking problem.

This issue is probably not SMI related, the region is not moved, iirc the SMIs trigger and yet it does not work... A5 has more checks for var names, but I didnt find out what they were supposed to do before I got bored

 

Gesendet von meinem ONEPLUS A5000 mit Tapatalk

[Ramalama]

Your NVRAM breaks because it is being locked by your firmware, this is normal for almost all firmware but you should not have that problem with AptioFix2. Also, you are way off on what the AptioFixes do, with out it you wouldn't even be able to boot. AptioFixes add things Apple firmware expects that UEFI doesn't do, changes ACPI memory page types so they are not moved, and then patches the kernel to properly start and fix the device tree. AptioFix creates a relocation region, loads the kernel there, then moves it to the spot it requested. AptioFix2 tries to give it the region the kernel wants to begin.

 

EDIT: Also maybe try to solve the problem yourself instead of acting like other people should do it for you. I do this because I like to, not because you feel entitled for others working for you without putting in any effort of your own. There are developers who have been doing this for a decade, I myself have for like six or seven years. Do some research, learn, figure the problem out, find the solution. Believe me, no one will do it for you unless they happen to have the same problem. Sometimes, it's the configuration and your firmware settings though, too. But most of the time you need to accept it doesn't work or continue and try to find a way to change it. And just for the record, the NVRAM issue has been known since UEFI booting macOS has been possible, it is an SMI locking problem.

 

I asked already in my first post, that I don't want anyone spend to much time with this, I know how the things work here apianti.

And I spend my self a lot time, long time ago with the acpi tables and support for some other users...

 

However, you are right at all points.

 

I write next time if I found more things out, I will post again.

The first step I need to do anyways is to deactivate SMI lock, that should be np.

 

And as long we have working nvram with the emulated driver, everything is ok.

 

 

There's a topic on this if you're so inclined.

 

There are exactly all infos, that I've searched, thank you very much!

 

This issue is probably not SMI related, the region is not moved, iirc the SMIs trigger and yet it does not work... A5 has more checks for var names, but I didnt find out what they were supposed to do before I got bored

 

Gesendet von meinem ONEPLUS A5000 mit Tapatalk

 

Seems like you have investigated already time into this.

I think that would be my problem too. Just deactivating SMI Locking will not fix Nvram :-)))

 

 

However, thanks very much to everyone here.

 

Just to be clear, I don't want to waste time here of anyone.

I need to fix my problems myself and I have a lot of them with x299 platform...

Everything works Perfect with x299 on the first look, but unsupported cpu with VoodooTSC and Emulated Nvram sucks.

 

Thanks to all & Cheers :-)

[romaincs]

Hello everyone,

 

I'm getting some issues with Clover rev. > 4077, with a RocketRaid 2720SGL. It hang on scanning entries.

 

If I unplug all devices from it but the boot drive, it does not hang.

 

I have made a thread there if you want to have a look : #CloverEFI BiosBlockIO rev>4077 hangs at "Scanning entries"

 

I tried to use serveral different boot7 files, with no luck.

To boot from the SAS Controller, I need to user BiosBlockIO as SATA boot does not see the SAS boot device.

 

Maybe you have an idea about this ?

 

Thanks.

[Planet X]

On latest Clover 4289 and with latest apfs.efi I always get this message at boot: 

nx_dev_init:705: Warning: superblock indicates jumpstart record but this driver was not loaded from that partition

When I put the previous version of apfs.ini into drivesr64UEFI I don't have this message. What is the reason of this jumpstart message at boot?

 

B.t.w. Do I need this driver NvmExpressDxe-64.efi with latest Clover and High Sierra for my NVMe drive? It does boot without this driver.

[Guest ricoc90]

A little late (couldn't test earlier unless I'd download the update again) but now I can confirm that r4293 indeed works as expected when updating to 10.13.2 beta 2 

[apianti]

This issue is probably not SMI related, the region is not moved, iirc the SMIs trigger and yet it does not work... A5 has more checks for var names, but I didnt find out what they were supposed to do before I got bored

 

Gesendet von meinem ONEPLUS A5000 mit Tapatalk

 

There are a few regions of runtime that are moved, mainly the system table and that region. I think the relocation of this and not fixing the pointers inside the region is what causes the issue since SMM runs in physical mode. Which since it's not relocated with AptioFix2 but with AptioFix (when the kernel is relocated, this region is linked into the kernel).

 

I asked already in my first post, that I don't want anyone spend to much time with this, I know how the things work here apianti.

And I spend my self a lot time, long time ago with the acpi tables and support for some other users...

 

However, you are right at all points.

 

I write next time if I found more things out, I will post again.

The first step I need to do anyways is to deactivate SMI lock, that should be np.

 

And as long we have working nvram with the emulated driver, everything is ok.

 

 

 

There are exactly all infos, that I've searched, thank you very much!

 

 

Seems like you have investigated already time into this.

I think that would be my problem too. Just deactivating SMI Locking will not fix Nvram :-)))

 

 

However, thanks very much to everyone here.

 

Just to be clear, I don't want to waste time here of anyone.

I need to fix my problems myself and I have a lot of them with x299 platform...

Everything works Perfect with x299 on the first look, but unsupported cpu with VoodooTSC and Emulated Nvram sucks.

 

Thanks to all & Cheers :-)

 

Nah, you're good. Just making a point about how researching yourself and bringing something to the conversation usually gets problems fixed instead of asking for help without a starting point.

[mhaeuser]

There are a few regions of runtime that are moved, mainly the system table and that region. I think the relocation of this and not fixing the pointers inside the region is what causes the issue since SMM runs in physical mode. Which since it's not relocated with AptioFix2 but with AptioFix (when the kernel is relocated, this region is linked into the kernel).

Indeed it's only the SystemTable region, all others are marked as MMIO. Doubt it's the issue as the SMM drivers have their own system table (which should in theory be marked MMIO and hence not be relocated). The changes I found between the working and non-working version did not hint at sth like that either.

[apianti]

Indeed it's only the SystemTable region, all others are marked as MMIO. Doubt it's the issue as the SMM drivers have their own system table (which should in theory be marked MMIO and hence not be relocated). The changes I found between the working and non-working version did not hint at sth like that either.

 

Well there could be additional information following the system table, if you copy the system table with just sizeof(EFI_SYSTEM_TABLE) instead of SystemTable->Hdr.HeaderSize, it will usually cause problems when used. They are rarely the same size. And what changes have you seen between them, besides non working stuff? The problem could be that there are two separate tables, the one copied into the kernel is modified and the one not is used so it causes problems. Or the one copied into the kernel contains incorrect information because it wasn't meant to be moved.... I have no idea but it's the relocation of either the entire kernel or the runtime region. I don't see what else it could be, that's basically the only difference between the drivers...

 

EDIT: You know I never noticed that this line only converts the EfiRuntimeServicesData and not EfiRuntimeServicesCode to EfiMemoryMappedIO. Shouldn't it be protecting all the runtime?

EDIT2: From the spec:

EfiRuntimeServicesCode	The memory in this range is to be preserved by the loader and OS in the working and ACPI S1–S3 states.
EfiRuntimeServicesData	The memory in this range is to be preserved by the loader and OS in the working and ACPI S1–S3 states.

EfiMemoryMappedIO	This memory is not used by the OS. All system memory-mapped IO information should come from ACPI tables.

So I wonder why not also protect the code regions? Wouldn't the SMM driver code be located in a code region?

 

EDIT3: Also, I've noticed something else, memory allocated from the default pool using edk2 libraries for an application is allocated using EfiLoaderData but it is not freed upon exiting boot services like previously thought, memory leaks can occur here as the outcome depends on how the OS decides to handle that memory type, is it indeed freed?

EfiLoaderData	The Loader and/or OS may use this memory as they see fit.

EDIT4: I have now woken up from fever dreams twice in the night to edit this, lol. So I think I had a revelation that the EfiRuntimeServicesCode regions are relocated into the kernel, but EfiRuntimeServicesData are not. If the kernel is then relocated I don't think any of those regions are fixed at all and I believe that might be the bug, since there must be physical addresses present, not virtual, as SMM runs in physical mode.

[Vinicius P. Miranda]

Hello guys. I have been having this problem since the High Sierra came out, and there are several other people with the same problem. This is due to Fusion Drive. I can not do a clean install or update the system. Already 2 updates came out after the release of High Sierra, and the two times I updated I had the same problem.

Always after I click to install the update or the system, it restarts and enters the black screen with a warning that is installing the update (or the system). Soon after doing the installation faster, again it restarts, enters the Clover and from there no more enters the system to finish the installation.

 

I'm stuck again between Clover and the system because I can not boot to finish the installation, it seems that it can not find the location where the files were placed. Can solve this in Clover? Is there a way I can get this resolved so I can log in and finish the installation?

 

Note 1: the times I managed to get around the problem, I had to do a clean installation on an old notebook hard drive, and then restore the HD image to the Fusion Drive. But now that I'm full of files and programs on Fusion Drive, I can not do the restore anymore because of space.

 

Note 2: I'm using HFS+

 

Clover after the second restart, where I can not go any further.

 

Stuck here, after choosing the boot.

[romaincs]

I'm stuck again between Clover and the system because I can not boot to finish the installation, it seems that it can not find the location where the files were placed. Can solve this in Clover? Is there a way I can get this resolved so I can log in and finish the installation?

 

I had the same issue, and it was caused by APFS.efi. Maybe your issue is the same. Try to use the one you find on your updated system disk in /usr/standalone/i386/.

[mhaeuser]

 

 

Well there could be additional information following the system table, if you copy the system table with just sizeof(EFI_SYSTEM_TABLE) instead of SystemTable->Hdr.HeaderSize, it will usually cause problems when used. They are rarely the same Loader. And what changes have you seen between them, besides non working stuff? The problem could be that there are two separate tables, the one copied into the kernel is modified and the one not is used so it causes problems. Or the one copied into the kernel contains incorrect information because it wasn't meant to be moved.... I have no idea but it's the relocation of either the entire kernel or the runtime region. I don't see what else it could be, that's basically the only difference between the drivers...

 

EDIT: You know I never noticed that this line only converts the EfiRuntimeServicesData and not EfiRuntimeServicesCode to EfiMemoryMappedIO. Shouldn't it be protecting all the runtime?

EDIT2: From the spec:

EfiRuntimeServicesCode	The memory in this range is to be preserved by the loader and OS in the working and ACPI S1–S3 states.
EfiRuntimeServicesData	The memory in this range is to be preserved by the loader and OS in the working and ACPI S1–S3 states.

EfiMemoryMappedIO	This memory is not used by the OS. All system memory-mapped IO information should come from ACPI tables.

So I wonder why not also protect the code regions? Wouldn't the SMM driver code be located in a code region?

 

EDIT3: Also, I've noticed something else, memory allocated from the default pool using edk2 libraries for an application is allocated using EfiLoaderData but it is not freed upon exiting boot services like previously thought, memory leaks can occur here as the outcome depends on how the OS decides to handle that memory type, is it indeed freed?

EfiLoaderData	The Loader and/or OS may use this memory as they see fit.

EDIT4: I have now woken up from fever dreams twice in the night to edit this, lol. So I think I had a revelation that the EfiRuntimeServicesCode regions are relocated into the kernel, but EfiRuntimeServicesData are not. If the kernel is then relocated I don't think any of those regions are fixed at all and I believe that might be the bug, since there must be physical addresses present, not virtual, as SMM runs in physical mode.

Quite sure I let someone test an AptioFix that relocates RT code too, but can't say for sure... tbh I'm done with that issue until I can reproduce it, cuz remote debugging sucks. Doubt it is the issue though... Can MMIO be executed from anyway? If not, non-SMM RT code would kill the kernel. Maybe the SMM RT code portions can be PE32-relocated?

 

Regarding loader data: imo it makes sense, just free all data before handing off (if boot.efi fails, the system might be in a bad state anyway, so reboot > handoff) or use the MemoryAllocLib for UEFI (drivers) (probably simpler)

 

Also forget about SystemTable, SMM has its own. Or you think the DXE driver might be the one causing issues?

 

Gesendet von meinem ONEPLUS A5000 mit Tapatalk

[apianti]

Quite sure I let someone test an AptioFix that relocates RT code too, but can't say for sure... tbh I'm done with that issue until I can reproduce it, cuz remote debugging sucks. Doubt it is the issue though... Can MMIO be executed from anyway? If not, non-SMM RT code would kill the kernel. Maybe the SMM RT code portions can be PE32-relocated?

 

No, currently RT code IS relocated (only RT data is not), I was talking about not relocating the code either (but unsure if you just misspoke). I haven't tried the issue on my new mobo so I'm unsure if it has this problem but my old one did, unfortunately I bricked it and couldn't find another. Even if MMIO can't be executable, which I think it can, ACPI NVS regions definitely are and shouldn't be moved. Here is output from memmap regarding MMIO:

Type Start            End              # Pages          Attributes
MMIO 00000000E00F8000-00000000E00F8FFF 0000000000000001 8000000000000001
MMIO 00000000FED1C000-00000000FED1FFFF 0000000000000004 8000000000000001
MMIO 00000000FFA00000-00000000FFFFFFFF 0000000000000600 8000000000000001

It does not have the can be protected from execution flag,

EFI_MEMORY_XP 0x0000000000004000

So I would assume that yes, it is able to execute code. Also from the spec:

Memory mapped I/O and memory mapped I/O port space allowed for virtual mode calls to UEFI run-time functions.

That's rather ambiguous but I'm pretty sure that means MMIO is at least treated like code area. Since runtime code regions won't be executable protected either, switching them to MMIO should be fine. Another thing that happens is the EFI_MEMORY_RUNTIME attribute is removed from some regions, which means they are never translated to virtual addresses.

 

 

Regarding loader data: imo it makes sense, just free all data before handing off (if boot.efi fails, the system might be in a bad state anyway, so reboot > handoff) or use the MemoryAllocLib for UEFI (drivers) (probably simpler)

 

I noticed this because I normally boot windows straight through the firmware menu, not clover. But I did a bunch of weird tests in clover allocating stuff and then booted windows from there and my system memory usage was pretty high, I even think it increased the hardware reserved size it shows in task manager. I don't think that any of it's released though because the OS thinks that it's info that is used in handoff between boot and runtime, we should maybe free allocations that aren't needed for runtime. And can't switch the default allocation type because all the boot memory types are freed when exit boot services, so there would be no memory to pass anything to the OS.

 

 

Also forget about SystemTable, SMM has its own. Or you think the DXE driver might be the one causing issues?

 

I'm unsure. It's not like SMM has it's own system table just for itself. There's two copies, one relocated into the kernel on purpose. The other could potentially be relocated into the kernel as well if it's marked as RT code, or wherever it was originally if it was RT data remarked as MMIO. There's two problems, first that these tables can be out of sync with apple changing the one it expects to be used to do some extra stuff with hooks. And the second that the one table marked as RT code is moved along with system table and SMM has previous address to table. I think that this is a memory and SMM issue.

[Vinicius P. Miranda]

I had the same issue, and it was caused by APFS.efi. Maybe your issue is the same. Try to use the one you find on your updated system disk in /usr/standalone/i386/.

I just installed the system on a notebok hard drive, and update it to version 10.13.1. I noticed that in the notebook HD, when it will install the update, that first line of the boot, where have written "Starting overrides for \ System \ Library \ CoreServices \ boot.efi" changes to another pat, but in boot with Fusion Drive, the path does not change. That may be the conflict that is happening, on Fusion Drive need to change the path too, but it is not changing.

Now the doubt, how to make change? Could only the Clover developers fix it? I was unable to note which path was correct in the notebook hd.

 

I also noticed that a boot partition was created in Clover, name: Install from HD. In Fusion Drive the new install partition was not created. This partition served to install the update, then returned the normal boot partition.

 

I deleted APFS.efi, I tried without it, I put the new one, but nothing worked.

 

I think the problem is not there, but on Fusion Drive, and this path is not changing at the time of installation.

 

A doubt; is OsxAptioFix2Drv that changes the path automatically at installation and update time? Is it the problem in him?

[apianti]

You can boot into the installer and inspect the volumes. Whenever it says that line, it means that AptioFix is overriding the start image method for that boot.efi. Your issue is either the known path to the next stage of the installer boot.efi has changed and needs added to the list of installer paths, or that the apfs container probably has moved the boot.efi from the main volume, and you need to look at the preboot or boot, or whatever it's called for the boot.efi that actually loads the kernel. You can create a custom entry to start the next stage of the installer.

[Vinicius P. Miranda]

You can boot into the installer and inspect the volumes. Whenever it says that line, it means that AptioFix is overriding the start image method for that boot.efi. Your issue is either the known path to the next stage of the installer boot.efi has changed and needs added to the list of installer paths, or that the apfs container probably has moved the boot.efi from the main volume, and you need to look at the preboot or boot, or whatever it's called for the boot.efi that actually loads the kernel. You can create a custom entry to start the next stage of the installer.

Can you tell me how to do this? This problem has bothered me since the release. If I can solve this I can still help several people who have the same problem.

Note: I'm using JHFS+

[apianti]

Can you tell me how to do this? This problem has bothered me since the release. If I can solve this I can still help several people who have the same problem.

Note: I'm using JHFS+

I just did, boot into the installer, go into the terminal and inspect the volumes. You should have the ability to use simple shell commands for unix/linux based OSes, especially if you are really using this as a learning experience and not just a way to save money by not buying a real mac, which violates TOS btw. Then create a custom entry for the volume and path to the next stage installer. You can check out the wiki for custom entries. If you absolutely need more help with the custom entry I can help you because I wrote that feature, but I want all the information about where the next stage installer is, the volume identifier, etc.... I have a feeling the entry will be easy after finding that stuff.

 

EDIT: The next stage installer may be in a directory beginning with a period so remember that it's hidden without using the correct parameters to commands, like

ls -a

EDIT2: Err... I'm not sure I was clear enough... I want the information even if you get the entry working because the installer path finder code probably needs adjusted.

EDIT3: If you don't have an installer to boot, try booting the recovery, single user mode, or recovery in single user (is that even possible? lol).

EDIT4: If you can't get anything to boot to get into terminal then you can use a linux live usb or the EFI shell, this probably helping more since you can find the identifiers of the volume easier. The boot.log would help with that too, you can generate debug.log (boot.log written to file as it is written in memory) by setting Boot/Debug=true in config.plist. You can edit config.plist in linux live cd or EFI shell with edit command.

 

@anyone,

 

On a separate note, the wiki seems to have many broken anchor links across pages, so you aren't always taken to the correct section when you click on something. For instance, this link from the Contents does not take you to Config.plist structure, but the top of the Configuration page. Is there someone who can go through and please correct the anchor links to point to the correct anchors??

 

EDIT: And maybe sync the current configuration structure, and fill out some of the sections that need finished. Some brave soul? Our eternal hero?

[apianti]

I also noticed that a boot partition was created in Clover, name: Install from HD. In Fusion Drive the new install partition was not created. This partition served to install the update, then returned the normal boot partition.

 

Wait what does this mean? Seems like you installed perfectly fine....?

[Vinicius P. Miranda]

Wait what does this mean? Seems like you installed perfectly fine....?

Well, let me try to be clearer. It's just that my English is not very good.

 

I have a flash drive with the installation of the High Sierra, and I also have an old 320GB hard drive, of notebook, with the High Sierra installed in it. This HD installs and updates perfectly because the problem is only on Fusion Drive.

The place where I want to get the installation and updates perfectly is on Fusion Drive with JHFS + partition, as I have a 250GB SSD and a 3TB HD.

This problem started happening in High Sierrra, previous versions of macOS did not have the problem.

 

I can open the High Sierra through the 500GB HD (HD-HS) and walk through the folders on Fusion Drive (Macintosh HD) as shown in the photo. I also have another HD with Windows 10, but this one is irrelevant.

Note: I do not leave the 500GB HD with the High Sierra on the computer. I only plug it in when there is a problem on Fusion Drive. It is for testing and troubleshooting purposes only.

 

Edit: I'm trying to understand how to solve the problem, but I think it's going to take a while.

[Slice]

Switch off Fusion drive then install High Sierra and then switch on Fusion drive again.