Clover General discussion

[apianti]

I made some tests today. It's all about this part:

First line determines all packages with identifiers, starting with org.clover, excluding the identifiers of the filesystem drivers if anyone have them installed with custom package. Nothing unusual.

 

Now, the "for" cycle is the interesting part - for each identifier in the list, got by the first line, the install location is being determined and the next long command finds and deletes all files, installed by the EFI drivers subpackages. That's right, the long command deletes only EFI drivers and nothing else! This part of the command,  /usr/bin/grep -iE 'EFI/CLOVER/(drivers\w+)/, is used to append the path to the files, because it seems the bom files (the install receipts) for those subpackages contain only the filename they install and not the full path to it, like other subpackages like the Clover prefpane or the Clover Theme Manager. This is pretty short explanation of what this whole line does, those who a interested can check the xargs man page.

 

The last command removes the package receipts corresponding to those identifiers. And here we have a problem: it actually removes nothing, at least not in the recent macOS version. There was indeed a time when that folder (/Library/Receipts) contained the receipts, but at some point they were moved in /var/db/receipts and /Library/Receipts is not being used for this purpose anymore. So, with a receipt, still present in that folder, it's a matter of time any EFI driver (installed manually or not) do magically disappear.

 

Ok the last part is what is really causing an issue, the receipts are invalid or not there? Are the receipts not named well enough that you can figure out they are from which selection or contain any other information besides the names?

 

EDIT: I see that the first line actually tells you which selection they were from right? I don't agree that the filesystem drivers should be excluded. I may want to remove HFSPlus and go back to VBoxHFS, or don't need APFS or NTFS anymore because I don't have those filesystems. You are being forced to manually go in and remove drivers, even if you unselect them - thinking they will be removed, like the rest kinda are....

 

EDIT2: This means that the installer needs to determine the OS version to determine where the receipts are, and what version did they move?

 

All this seems to me like a bad design. The right approach would be a preinstall script in every EFI driver subpackage that will remove the old driver ONLY if the driver has been selected for installation.

 

Yeah, that's probably why it's coming up, lol. However, I think you have it backwards, if the new one is being installed then it doesn't really need removed as it will be (most likely) overwritten (otherwise you wouldn't be able to delete it anyway cause of permissions). The only things that should be removed were installed before but are now unselected or aren't part of the source of the running installer and the user was asked and decided not to keep them.

 

EDIT: I should be more clear, everything should be deleted that can be reinstalled from the running installer. Anything else from previous package, the user should be asked to remove or keep each selection.

 

EDIT2: Are these receipts removed if an option is then unselected? Or does it just stay there forever?

 

About fat-64.efi - this driver is not mandatory, ebuild.sh copies it in drivers-Off/drivers64UEFI, so it appears as a separate option in the Drivers64UEFI submenu. @Sherlocks, try to remove your ~/src/edk2 folder and also make sure you have the latest Build_Clover.command script (if you use it). Made several packages during last two days and none of them auto-installs fat-64.efi when the option is not selected. I think Micky pushed a commit about that these days...

 

No, he's saying he installed the driver, then uninstalled the driver. That worked fine. But then removed the package plist and he manually installed the driver, and after running the installer again, the driver was not checked but was removed even though the package plist was removed before running the installer.

[bronxteck]

can aptiofix also be added as a selection to clover drivers 64 folder right now i have to manually add it from a machine that uses uefi or install uefi drivers from clover package that my machine cant use because its bios only then manually transfer aptiofix then delete clover driver uefi folder

[apianti]

can aptiofix also be added as a selection to clover drivers 64 folder right now i have to manually add it from a machine that uses uefi or install uefi drivers from clover package that my machine cant use because its bios only then manually transfer aptiofix then delete clover driver uefi folder

 

No, forever no. It's not needed. It won't work. Legacy clover already sets up everything EFI appropriately for macOS.

 

EDIT: Why are you putting AptioFix on a legacy machine???

[bronxteck]

because it loads fine according to my boot log and works? all it needs added are the Rc scripts. no emu. machine in sig.

[chris1111]

can aptiofix also be added as a selection to clover drivers 64 folder right now i have to manually add it from a machine that uses uefi or install uefi drivers from clover package that my machine cant use because its bios only then manually transfer aptiofix then delete clover driver uefi folder

It can be ad, you need to put the Drivers in  /drivers-Off /drivers64 in your case for Legacy

it will be appears on package selection Drivers64

 

Edit ** But for each compilation or Update, the DriversOff are deleted and replace so you have to put it back to see it in your package

[bronxteck]

would it not be simpler to add it in the official clover installer in the first place?

 

edited

[chris1111]

would it not be simpler to add it in the installer in the first place?

its the same, Mandatory Drivers are deleted and replace for each Update

[apianti]

because it loads fine according to my boot log and works? all it needs added are the Rc scripts. no emu. machine in sig.

 

Nope, actually it's doing nothing. EmuVar is already part of the legacy firmware..... You need the RC scripts because you don't have native NVRAM because aptiofix doesn't do anything with legacy firmware....

 

It can be ad, you need to put the Drivers in  /drivers-Off /drivers64 in your case for Legacy

it will be appears on package selection Drivers64

 

Edit ** But for each compilation or Update, the DriversOff are deleted and replace so you have to put it back to see it in your package

 

This is pointless, there is absolutely NO benefit to this. DO NOT DO THIS. Do not use AptioFix with legacy firmware, period.

 

would it not be simpler to add it in the official clover installer in the first place?

 

edited

 

No, because it's not needed and using it is wasting time, and putting it in the installer to install in legacy is an even bigger waste of time.

 

its the same, Mandatory Drivers are deleted and replace for each Update

 

I think that may not always be the case, as per the discussion happening around this one....

 

EDIT: Oh, you mean when making the installer, then yes, it erases all the drivers and rebuilds them for each build.

[Philip Petev]

Ok the last part is what is really causing an issue, the receipts are invalid or not there? Are the receipts not named well enough that you can figure out they are from which selection or contain any other information besides the names?

EDIT2: Are these receipts removed if an option is then unselected? Or does it just stay there forever?

 The receipts are not being removed. Ever. There is no such practice in the macOS Install framework. The only way to remove them is to delete them manually from /var/db/receipts or /Library/Receipts. That's what this preinstall script is trying to do, but as I said, it's not a good idea and a bad practice, in such cases a preinstall script is being used for every subpackage to remove the older version of the files before deploying the new one. I think to look at this problem when I get some free time (probably this weekend).

 

EDIT: I see that the first line actually tells you which selection they were from right? I don't agree that the filesystem drivers should be excluded. I may want to remove HFSPlus and go back to VBoxHFS, or don't need APFS or NTFS anymore because I don't have those filesystems. You are being forced to manually go in and remove drivers, even if you unselect them - thinking they will be removed, like the rest kinda are....

The reason I suggested that change was the complaints from the user, losing the HFSPlus.efi driver. Because using the custom package (that includes the proprietary drivers) and using the official one (without them) leads to such consequences. Unlike the other drivers, HFSPlus.efi, NTFS.efi and apfs.efi are not part of the Clover/edk2 distribution and like @RehabMan said, it won't hurt if they stay there. You can change them manually whenever you want.

 

EDIT: I should be more clear, everything should be deleted that can be reinstalled from the running installer. Anything else from previous package, the user should be asked to remove or keep each selection.

 Such functionality may be possible through Installer plugins, but someone has to write them. Not familiar with them as never needed them, even when I maintained the HP ProBook Installer package.

 

No, he's saying he installed the driver, then uninstalled the driver. That worked fine. But then removed the package plist and he manually installed the driver, and after running the installer again, the driver was not checked but was removed even though the package plist was removed before running the installer.

Makes perfectly sense to me. The current package doesn't remove anything from /var/db/receipts and considering the fact the first install has added a receipt for it, the file is being deleted, because the Installer reads the receipt.

[apianti]

 The receipts are not being removed. Ever. There is no such practice in the macOS Install framework. The only way to remove them is to delete them manually from /var/db/receipts or /Library/Receipts. That's what this preinstall script is trying to do, but as I said, it's not a good idea and a bad practice, in such cases a preinstall script is being used for every subpackage to remove the older version of the files before deploying the new one. I think to look at this problem when I get some free time (probably this weekend).

 

So maybe all the previous receipts should be removed in postinstall? Or is that too late and the new receipts are there already? The previously installed stuff should definitely be removed, with caveats that the user needs to choose to remove stuff that doesn't exist in the running installer.

 

The reason I suggested that change was the complaints from the user, losing the HFSPlus.efi driver. Because using the custom package (that includes the proprietary drivers) and using the official one (without them) leads to such consequences. Unlike the other drivers, HFSPlus.efi, NTFS.efi and apfs.efi are not part of the Clover/edk2 distribution and like @RehabMan said, it won't hurt if they stay there. You can change them manually whenever you want.

 

I understand the change, I just suggest making a different one. Also having HFSPlus and VBoxHFS causes issues. I also think most people think that if they uncheck something it will be removed, I know I do. I expect that.

 

Such functionality may be possible through Installer plugins, but someone has to write them. Not familiar with them as never needed them, even when I maintained the HP ProBook Installer package.

 

I gave you a way to do it, check the current package for the same stuff as the receipts, if not found in the package, use osascript to generate a dialog. I have no idea if there is anyway to add options after the package is already made but that would be a much cleaner solution...

 

Makes perfectly sense to me. The current package doesn't remove anything from /var/db/receipts and considering the fact the first install has added a receipt for it, the file is being deleted, because the Installer reads the receipt.

 

Yeah, we should maybe remove them in postinstall like

pkgutil --forget @CLOVER_PACKAGE_IDENTITY@

But is that going to remove the currently installing package or the previous.... IDK.

 

EDIT: Actually we can run that at the end of the preinstall, because even if the script ends up failing after, all those files were removed so it's safe to remove the receipts.

 

EDIT2: Actually it's not safe because then the next time the installer is run the choices won't be selected, so it must be in postinstall.

 

EDIT3: Thought of something crazy, don't actually build the package. Put all the components to build into the package, then when installer is run, build a package from the components and missing stuff through receipts. Then run that installer from the current one. Ridiculously that should work.......... 

[Trung_Nguyen]

Hello,

I'm using AptioInputFix with Clover timeout=0 to FileVault 2 to work.

But the problem is that I couldn't enter Clover GUI by holding a key. Key combinations like(cmd+v/shift/cmd+s/...) also don't work.

So it kind of lock me into a scenario that no EFI Shell, no Recovery boot.

Is there any walk-around except set clover timeout to higher volume?

Thanks

[Philip Petev]

So maybe all the previous receipts should be removed in postinstall? Or is that too late and the new receipts are there already? The previously installed stuff should definitely be removed, with caveats that the user needs to choose to remove stuff that doesn't exist in the running installer.

 

 

I understand the change, I just suggest making a different one. Also having HFSPlus and VBoxHFS causes issues. I also think most people think that if they uncheck something it will be removed, I know I do. I expect that.

 

 

I gave you a way to do it, check the current package for the same stuff as the receipts, if not found in the package, use osascript to generate a dialog. I have no idea if there is anyway to add options after the package is already made but that would be a much cleaner solution...

 

 

Yeah, we should maybe remove them in postinstall like

pkgutil --forget @CLOVER_PACKAGE_IDENTITY@

But is that going to remove the currently installing package or the previous.... IDK.

 

EDIT: Actually we can run that at the end of the preinstall, because even if the script ends up failing after, all those files were removed so it's safe to remove the receipts.

 

EDIT2: Actually it's not safe because then the next time the installer is run the choices won't be selected, so it must be in postinstall.

 

EDIT3: Thought of something crazy, don't actually build the package. Put all the components to build into the package, then when installer is run, build a package from the components and missing stuff through receipts. Then run that installer from the current one. Ridiculously that should work.......... 

For now, I'm going to add /var/db/receipts in that preinstall script, so next time when you run the installer, only the packages, selected on the previous install, will be removed before the deployment of the new files. That's only a workaround until I figure out what to do next.

[Sherlocks]

For now, I'm going to add /var/db/receipts in that preinstall script, so next time when you run the installer, only the packages, selected on the previous install, will be removed before the deployment of the new files. That's only a workaround until I figure out what to do next.

 

all right. like you said, finally i got it. to cleanup clover installation option, remove Library/Preferences/com.projectosx.clover.installer.plist,  all file that name of org.clover.*  in /var/db/receipts.

 

fat-64 alive after removed all files in /var/db/receipts without checked or uncheck in package.

Because of the files in / var /db /receipts, after unchecked in the package, the file is always forced to be deleted. Also next time.

 

 

EDIT1.

seems this status is not good. i think it causes confusion and maybe user should check folder after check and uncheck process.

[apianti]

Hello,

I'm using AptioInputFix with Clover timeout=0 to FileVault 2 to work.

But the problem is that I couldn't enter Clover GUI by holding a key. Key combinations like(cmd+v/shift/cmd+s/...) also don't work.

So it kind of lock me into a scenario that no EFI Shell, no Recovery boot.

Is there any walk-around except set clover timeout to higher volume?

Thanks

 

Unfortunately, no, those keys are being consumed by the input buffer for FileVault2 for startup keys and stuff.... For now you will have to put at least Timeout=1, in the future I guess that protocol will need to be located and checked for this purpose.... I've no idea who's going to do that....

 

EDIT: I should also point out the startup combinations for mac don't work because that is part of the mac firmware and is not implemented in clover.... Yet, I guess.

[apianti]

Real quick question guys, can anyone successfully hibernate with APFS? Because the sleepimage was moved from /private/var/sleepimage to /private/var/vm/sleepimage, which is mounted from a different partition in the APFS container. This means we need to find the VM volume and strip the prefix of /private/var/vm to locate the sleepimage when using APFS.

[Sherlocks]

Real quick question guys, can anyone successfully hibernate with APFS? Because the sleepimage was moved from /private/var/sleepimage to /private/var/vm/sleepimage, which is mounted from a different partition in the APFS container. This means we need to find the VM volume and strip the prefix of /private/var/vm to locate the sleepimage when using APFS.

Now, clover can't load sleepimage in VM.

I used stricthibernate(read nvram varable without sleepimage)+hibernationfixup+hibernationfixup.kext+lilu for hibernation of HS.

Its successful for hibernate both 3 and 25.

But some user report fail case.

 

나의 LG-F800S 의 Tapatalk에서 보냄

[apianti]

Now, clover can't load sleepimage in VM.

I used stricthibernate(read nvram varable without sleepimage)+hibernationfixup+hibernationfixup.kext+lilu for hibernation of HS.

Its successful for hibernate both 3 and 25.

But some user report fail case.

 

나의 LG-F800S 의 Tapatalk에서 보냄

 

Ok, that's a lot of stuff when it just needs to locate the image in a different place, lol. There is an open ticket to just fix this by finding the VM volume and loading it from there, are you willing to make that change? I'll assign it to you, or if anyone else is willing, let me know or do it or whatever.

[Sherlocks]

Ok, that's a lot of stuff when it just needs to locate the image in a different place, lol. There is an open ticket to just fix this by finding the VM volume and loading it from there, are you willing to make that change? I'll assign it to you, or if anyone else is willing, let me know or do it or whatever.

Okay. I will check it with him

 

나의 LG-F800S 의 Tapatalk에서 보냄

 

EDIT1.

@Philip Petev

r4408 is good. thanks you

[TheRacerMaster]

EDIT: I should also point out the startup combinations for mac don't work because that is part of the mac firmware and is not implemented in clover.... Yet, I guess.

Isn't this handled by boot.efi?

[Badruzeus]

Hello,

any progress about how to fix "org.clover.target.esp" under 10.11.x or below versions?

It uses "/" Root as a target installation instead of EFI Partition since r4399.

Feb  9 10:22:22 MacBookPro installd[614]: ./preinstall: /tmp/PKInstallSandbox.tVnuG1/Scripts/org.clover.target.esp.2dw1nN/preinstall: line 16: cd: //EFIROOTDIR: No such file or directory
...  . ........ ..........
Feb  9 10:22:22 MacBookPro installd[614]: ./preinstall: EFIFolder Pre-Install Script
Feb  9 10:22:22 MacBookPro installd[614]: ./preinstall: ===============================================
Feb  9 10:22:22 MacBookPro installd[614]: ./preinstall: preinstall: Path to installer....... /Users/badruzeus/Downloads/Apps/Clover_v2.4k_r4409.pkg
Feb  9 10:22:22 MacBookPro installd[614]: ./preinstall: preinstall: Path to destination..... /EFIROOTDIR
Feb  9 10:22:22 MacBookPro installd[614]: ./preinstall: preinstall: Path to dest volume..... /
Feb  9 10:22:22 MacBookPro installd[614]: ./preinstall: preinstall: Root of system folder... /

Thanks. 

[Badruzeus]

Hi @Sherlocks, thanks for ur r4408 (Test version);

 

PhoenixOS (Android_x86 > .../icons/os_phoenix.icns) and..

EndlessOS (Debian > .../icons/os_endless.icns)

... are shown properly on Clover GUI. 

 

 

 

				<dict>
					<key>Disabled</key>
					<false/>
					<key>FullTitle</key>
					<string>PhoenixOS</string>
					<key>Ignore</key>
					<false/>
					<key>Path</key>
					<string>\EFI\PhoenixOS\boot\grubx64.efi</string>
					<key>Type</key>
					<string>Linux</string>
					<key>Volume</key>
					<string>EFIROOTDIR</string>
					<key>VolumeType</key>
					<string>Internal</string>
				</dict>
				<dict>
					<key>Disabled</key>
					<false/>
					<key>FullTitle</key>
					<string>EndlessOS</string>
					<key>Ignore</key>
					<false/>
					<key>Path</key>
					<string>\EFI\Endless\grubx64.efi</string>
					<key>Type</key>
					<string>Linux</string>
					<key>Volume</key>
					<string>EFIROOTDIR</string>
					<key>VolumeType</key>
					<string>Internal</string>
				</dict>

 

 

[Sherlocks]

Hi @Sherlocks, thanks for ur r4408 (Test version);

 

PhoenixOS (Android_x86 > .../icons/os_phoenix.icns) and..

EndlessOS (Debian > .../icons/os_endless.icns)

... are shown properly on Clover GUI.

 

 

 

				<dict>
					<key>Disabled</key>
					<false/>
					<key>FullTitle</key>
					<string>PhoenixOS</string>
					<key>Ignore</key>
					<false/>
					<key>Path</key>
					<string>\EFI\PhoenixOS\boot\grubx64.efi</string>
					<key>Type</key>
					<string>Linux</string>
					<key>Volume</key>
					<string>EFIROOTDIR</string>
					<key>VolumeType</key>
					<string>Internal</string>
				</dict>
				<dict>
					<key>Disabled</key>
					<false/>
					<key>FullTitle</key>
					<string>EndlessOS</string>
					<key>Ignore</key>
					<false/>
					<key>Path</key>
					<string>\EFI\Endless\grubx64.efi</string>
					<key>Type</key>
					<string>Linux</string>
					<key>Volume</key>
					<string>EFIROOTDIR</string>
					<key>VolumeType</key>
					<string>Internal</string>
				</dict>

Without custom entry setting, does it working?

 

나의 LG-F800S 의 Tapatalk에서 보냄

[Badruzeus]

Without custom entry setting, does it working?

 

나의 LG-F800S 의 Tapatalk에서 보냄

Well, using GUI - Scan=true & w/o Custom Entry setting, only EndlessOS (Debian) is shown.

PhoenixOS (Android_x86) is gone on Clover GUI.

[Sherlocks]

Well, using GUI - Scan=true & w/o Custom Entry setting, only EndlessOS (Debian) is shown.

PhoenixOS (Android_x86) is gone on Clover GUI.

 

here. plz one more test

Endless and PhoenixOS test2.zip

[Badruzeus]

here. plz one more test

Test2 still doesn't detect PhoenixOS (Android_x86) yet on Clover GUI if not using Custom Entry.