Clover.app testing

[arsradu]

1 hour ago, vector sigma said:

3. keep both.

 

is native nvram = false

 

do you want to update the app?

|Yes|                     |No|

 

no just a text as EmuVariableUefiPresent is published automatically by EmuVariableUefi.efi. Will let you know Clover will use the nvram.plist or not.

 

Sure, I guess both could work, as well. :))

 

So...it's a detection based on that EmuVariableUefiPresent? What if the user has native NVRAM but is still using EmuVariableUefi.efi for some reason? Which one will it be used? I'm guessing the emulated nvram, since it probably doesn't have anther way to tell if it's native or not?

 

I was always wondering how can you tell if it's native or not... What are you looking for? Aside from "if it's not EmuVariableUefiPresent, then it must be native". :))

 

Anyway, if it's only to inform the user, and it's not a selection, I guess true/false values will be just fine.

Edited December 8, 2019 by arsradu

[vector sigma]

37 minutes ago, arsradu said:

So...it's a detection based on that EmuVariableUefiPresent? What if the user has native NVRAM but is still using EmuVariableUefi.efi for some reason?

tried? good boot failure. (native means is a memory in a dedicated chip soldered on the motherboard, emulated....  is a fake because a file contents is copied to the RAM at boot time)

 

37 minutes ago, arsradu said:

I was always wondering how can you tell if it's native or not... What are you looking for? Aside from "if it's not EmuVariableUefiPresent, then it must be native". :))

Don't tell to me, ask Sherlocks, he asked. I've just explain at the previous page that using Clover, legacy = legacy firmware = CLOVER (which cannot be the UEFI firmware name of any kind)

Edited December 8, 2019 by vector sigma

[Sherlocks]

Don't tell to me, ask Sherlocks, he asked. I've just explain at the previous page that using Clover, legacy = legacy firmware = CLOVER (which cannot be the UEFI firmware name of any kind)

How about it? Boot Type: Clover BIOS(or Legacy) or Clover UEFI- check whether UEFI or not.

NVRAM Type: Native or EmuVariable(if there is emuvariableuefi nvram key or legacy boot)

 

it is a goal for show current system type and info in clover app like "Boot Devices:".

 

나의 SM-N960N 의 Tapatalk에서 보냄

 

 

 

 

 

 

 

 

 

[arsradu]

42 minutes ago, vector sigma said:

tried? good boot failure. (native means is a memory in a dedicated chip soldered on the motherboard, emulated....  is a fake because a file contents is copied to the RAM at boot time)

 

Don't tell to me, ask Sherlocks, he asked. I've just explain at the previous page that using Clover, legacy = legacy firmware = CLOVER (which cannot be the UEFI firmware name of any kind)

 

I actually did try it a while ago (years ago), when I didn't know that I actually already had native NVRAM and didn't need to use EmuVariable. It worked fine either way. :)) But I was only curious which one was it using. And I'm guessing it was checking if there is EmuVariableUefiPresent, and if so, conclude that the system didn't have native NVRAM and use whatever was stored in nvram.plist at boot time, right? So, no matter if the system actually supported native NVRAM, it was using emulated one instead.

 

So, nothing bad happened in my case. But...yeah, I didn't need it anyway.  

 

And on systems where I did need it (Skylake for example), not using it didn't result in boot failure. I just couldn't use Nvidia drivers, for example, and iMessage, if I recall correctly.

 

Anyway, I was curious about it, because some people believe that newer motherboards might still have native nvram, it's just relocated to a different address.

Anyway, that's not really a topic for Clover app. I was only curious how can someone determine whether or not a board uses "native" NVRAM. Just an interesting topic.  

Edited December 8, 2019 by arsradu

[Slice]

19 hours ago, arsradu said:

 

I was only curious how can someone determine whether or not a board uses "native" NVRAM. Just an interesting topic.  

Very simple. Exclude EmuVariable and check if nvram test=1 will save upon reboot.

[arsradu]

20 minutes ago, Slice said:

Very simple. Exclude EmuVariable and check if nvram test=1 will save upon reboot.

 Well, yes. :)) Of course. I guess I didn't ask the question properly. Sorry about that.

 

So, the question was: how can a Clover developer know if the user's board has native nvram or not, in order to show him that text above (native NVRAM = true/false)?

 

In other words, for this particular scenario, what are you basing your assessment on? On the existence of a nvram.plist file in the root of your system partition? On the existence of EmuVariableUefiPresent ? If there's a nvram.plist file, then it's not native nvram? Something like this? What do you consider a proof of the existence or non existence of native NVRAM on a user's board? How do you look for it?

 

I guess the shorter version would be: how do you test NVRAM on Clover side, on boot, so you can display the result (native NVRAM=true/false) later on inside the app?

 

As a user, of course you can test this very easily. But in order for Clover to show "you've got native NVRAM = true/false", you can't do a nvram test=1 and reboot. :))

Edited December 9, 2019 by arsradu

[Rodion2010]

I have no native NVRAM, but  nvram test=1  works due to script executed at LogoutHook

[vector sigma]

 

On 12/8/2019 at 5:19 PM, arsradu said:

I actually did try it a while ago (years ago), when I didn't know that I actually already had native NVRAM and didn't need to use EmuVariable. It worked fine either way. :)) But I was only curious which one was it using. And I'm guessing it was checking if there is EmuVariableUefiPresent, and if so, conclude that the system didn't have native NVRAM and use whatever was stored in nvram.plist at boot time, right? So, no matter if the system actually supported native NVRAM, it was using emulated one instead.

To be honest now I'm lost. The question should not be now why someone installs the Emu runtime even if the NVRAM is working? I eventually would like to do this only after ascertain that the nvram is not persistent, as it is easy to see if your sound volume or your brithness is not restored across reboots or maybe Message and Face time aren't working etc., for example. EmuVariableUefiPresent is just a variable published to let understand the nvram is emulated  ... so the rc scripts or CloverDaemonNew will know what to do, i.e. save the nvram.plist some where.

Edited December 9, 2019 by vector sigma

[vector sigma]

On 12/8/2019 at 5:18 PM, Sherlocks said:

How about it? Boot Type: Clover BIOS(or Legacy) or Clover UEFI- check whether UEFI or not.

Did not you like something like:

 

Firmware Vendor: INSYDE Corp

vs

Firmware Vendor: CLOVER

?

On 12/8/2019 at 5:18 PM, Sherlocks said:

NVRAM Type: Native or EmuVariable(if there is emuvariableuefi nvram key or legacy boot)

EmuVariable != Legacy boot, I'm wrong?

Edited December 9, 2019 by vector sigma

[Slice]

Legacy Boot always contains EmuVariableDxe.

With UEFI boot you have three situation:

1. Native NVRAM.

2. EmuVariableUEFI for emulated NVRAM.

3. No working NVRAM services - this is a wrong way.

[arsradu]

59 minutes ago, vector sigma said:

To be honest now I'm lost. The question should not be now why someone installs the Emu runtime before to see if the NVRAM is working or not? I eventually would like to do this only after ascertain that the nvram is not persistent, as it is easy to see if your sound volume or your brithness is not restored across reboots or maybe Message and Face time aren't working etc., for example. EmuVariableUefiPresent is just a variable published to let understand the nvram is emulated  ... so the rc scripts or CloverDaemonNew will know what to do, i.e. save the nvram.plist some where.

 

Haha! :)) Well, you're assuming people know when they need EmuVariable and when they don't. Which...while is definitely nice to have, is not always the case.

 

As I said, in my early days, I had no idea what was that EmuVariable for and whether or not I needed it. I didn't know what "native NVRAM" was and whether or not I already had it! And at some point, I think Slice pointed it out to me. He was like: why are you using EmuVariable with your board? You should have hardware nvram. And I was like: "well, that's always nice to hear! I did not know I have "hardware NVRAM". Let's see if it works." And of course it did! It was all very new to me. :)))

 

But, the point I'm trying to make is that, just as it was something new for me, it will also be new for other people. And so, some of the users, especially new users, might not know when to use EmuVariable and they might decide to use it just in case. So, on Clover side, if we're basing our assumption on the presence of that EmuVariableUefiPresent, we're gonna show "native NVRAM = false" even when the board actually supports native NVRAM. But I don't know how to test it another way. This was exactly the source of my curiosity: how does, or how would (if it doesn't already) Clover do it?

Edited December 9, 2019 by arsradu

[Slice]

Clover can not know if NVRAM will work in macOS.

Example is my Z170  where native NVRAM worked at Clover time but not working in macOS time. It was fixed by vit9696 a year ago in OsxAptioFix3Drv but there is another example Z390 where native NVRAM is still not working at macOS time no matter of AptioFix version.

 

How to check.

1. Boot system without EmuVariable if possible. I know my Z170 where it is not possible.

2. If success then go to Terminal and type

sudo nvram test=1

3. Reboot.

4. Go to Terminal and type

nvram test

Did you see it stored? Or the answer is 

nvram: Error getting variable - 'test': (iokit/common) data was not found

 

The test will be successful as well with EmuVariable if rc.script/daemon was installed. There is a sense for EmuVariable and those scripts.

Two things are not possible for EmuVariable:

1. Hibernation  pointer "boot0082"

2. Variable "AAPL,panic-report" if you have KP with reboot.

[vector sigma]

On 12/9/2019 at 11:25 PM, arsradu said:

Haha! :)) Well, you're assuming people know when they need EmuVariable and when they don't. Which...while is definitely nice to have, is not always the case.

I'm just a little baffled by the fact that one necessarily want this app to make an easy test, i.e.  install or uninstall a driver, install or uninstall the rc scripts or the daemon to see if nvram variables are persistent without them. Slice told this multiple times but I'm scared of the fact that someone want the easy way when is not possible by a user space program even if "The wish" is strong. 

 

EmuVariableUefi.efi description:

Workaround for store NVRAM variables for systems without UEFI hardware.
Mostly UEFI boot uses hardware NVRAM but in some rare cases this driver is needed. Use it only if you have a problem without it

so easy that i don't expect anyone to install it if there is not need for it. This is what i assume and is the same assumption of peoples before me. 

 

On 12/10/2019 at 6:08 AM, Slice said:

1. Hibernation  pointer "boot0082"

With a permissive SIP we can let the daemon add it to the nvram.plist before sleep .. if we can build the data...

EDIT Who cares about SIP. We can do what we want with the nvram.plist Lol

Edited December 13, 2019 by vector sigma

[Rodion2010]

4 hours ago, vector sigma said:

We can do what we want with the nvram.plist Lol

we can save only keys from 7C436110-AB2A-4BBB-A880-FE41995C9F82 in the simple way nvram -xp > nvram.plist

Boot82 is 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0082 and it is more complicated to save and read it

 

https://github.com/acidanthera/OcSupportPkg/blob/master/Utilities/LogoutHook/LogoutHook.command

it works with OpenCore only, not Clover (

[D-an-W]

Installed today as this is looking really good.

 

Does it do away with "10.save_and_rotate_boot_log.local" and "20.mount_ESP.local" I use for Log creation and ESP mounting (They are in rc.boot.d)?

 

If so, can the app create and rotate the last 10 boot logs for me somewhere?

 

Also, how do I make best use of the "Sound" option please (I already have it working on boot using AudioDxe and BootChimeDxe)?

Edited December 15, 2019 by D-an-W

[Slice]

@vector sigma

I can't release Clover.app in 5101 because I am in ElCapitan now.

Please add Clover.app to 5101 release and some other files.

[d620osx]

Morning @vector sigma,

 

Thank you for the app. I have tried running both Make System File read write and Disable Sleep Proxy. Clicked on both and installed Clover Daemon, rebooted the machine twice but I still get the wake at night:

 

2019-12-24 00:29:49.774927+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:29:49.774929+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:33:44.953718+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:33:44.953720+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:41:08.944414+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

 

Have I not followed the correct procedure or is it that I am running Legacy bios that may be the issues.

 

Machine is a Dell Optiplex 790 running 10.15.1.

 

Thank you

 

 

 

 

[Sherlocks]

Morning [mention=2078499]vector sigma[/mention],
 
Thank you for the app. I have tried running both Make System File read write and Disable Sleep Proxy. Clicked on both and installed Clover Daemon, rebooted the machine twice but I still get the wake at night:
 

2019-12-24 00:29:49.774927+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:29:49.774929+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:33:44.953718+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:33:44.953720+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:41:08.944414+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

 
Have I not followed the correct procedure or is it that I am running Legacy bios that may be the issues.
 
Machine is a Dell Optiplex 790 running 10.15.1.
 
Thank you
 

 

 

 

type nvram -p
and upload clover bootlog

나의 SM-N960N 의 Tapatalk에서 보냄

[d620osx]

2 hours ago, Sherlocks said:

type nvram -p
and upload clover bootlog

나의 SM-N960N 의 Tapatalk에서 보냄
 

@Sherlocks

 

Thank you for looking at my query. I hope I have done this correctly. Log now attached.

 

 

bdmesg.log

[Sherlocks]

1 hour ago, d620osx said:

@Sherlocks

 

Thank you for looking at my query. I hope I have done this correctly. Log now attached.

 

 

bdmesg.log

 

seem you are not install rc script or newcloverdaemon of clover app.

PutNvramPlistToRtVars: nvram.plist not found

you need to check nvram.plist on ESP.

[vector sigma]

On 12/20/2019 at 11:24 PM, Slice said:

@vector sigma

I can't release Clover.app in 5101 because I am in ElCapitan now.

Please add Clover.app to 5101 release and some other files.

I'm so sorry because I lost your post, saw only now. Late, but I see you solved.

 

On 12/14/2019 at 5:15 PM, D-an-W said:

Installed today as this is looking really good.

 

Does it do away with "10.save_and_rotate_boot_log.local" and "20.mount_ESP.local" I use for Log creation and ESP mounting (They are in rc.boot.d)?

 

If so, can the app create and rotate the last 10 boot logs for me somewhere?

 

Also, how do I make best use of the "Sound" option please (I already have it working on boot using AudioDxe and BootChimeDxe)?

Sorry to you as well, but same, I didn't aware of your post, not sure why I wasn't receiving notifications from my own topic... 

 

Clover.app did not use rcscripts as they conflicts, so it must remove them. The package do just the same inverted, i.e. it remove the Daemon from this app when you install back the rc scripts.

The app actually didn't show the System log, but only show the daemon log and the bdmesg. Honestly, during the development of this app, I thought this has nothing to do with Clover. So why you did not see it. Should be easy to log some n lines, but in the event should I introduce this to Clover.app, to not use an nvram variable anymore to set how many lines to log, but instead just create always a log with a fixed size. I don't think we should mess with the nvram unless a real need exist, i.e. like a usefull functionality related to the bootloader.

For the sound, as written in the first post, it is actually doing nothing because it is under development. We discuss how to do here.

5 hours ago, d620osx said:

Morning @vector sigma,

 

Thank you for the app. I have tried running both Make System File read write and Disable Sleep Proxy. Clicked on both and installed Clover Daemon, rebooted the machine twice but I still get the wake at night:

 

2019-12-24 00:29:49.774927+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:29:49.774929+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:33:44.953718+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:33:44.953720+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

2019-12-24 00:41:08.944414+0000  localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)

 

Have I not followed the correct procedure or is it that I am running Legacy bios that may be the issues.

 

Sherlocks also asked you to type this:

nvram -p

.. in Terminal.app.

But, as in the app there is a button that says "read the daemon log", I expect you to show me at least this file .... otherwise I can't tell you if the Daemon it's doing its job or if a problem exists 

 

Edited December 24, 2019 by vector sigma

[d620osx]

Thank you both for replying. When I initially ran nvram -p in Terminal I got an error. So I rebooted and added it to the boot args in clover. I have attached the daemon log and can see Clover.DisableSleepProxyClient is not set. so looks like I am doing something wrong. 

 

Any pointers on what I am doing wrong?

 

Thank you

 

clover.daemon.log

[vector sigma]

6 minutes ago, d620osx said:

Thank you both for replying. When I initially ran nvram -p in Terminal I got an error. So I rebooted and added it to the boot args in clover. I have attached the daemon log and can see Clover.DisableSleepProxyClient is not set. so looks like I am doing something wrong. 

 

Any pointers on what I am doing wrong?

 

Thank you

 

clover.daemon.log

ok. Can you please run this in Terminal:

sudo rm -f /Library/Application\ Support/Clover/CloverDaemon-stopservice

and 

sudo defaults delete com.apple.loginwindow LoginHook

then reboot. Let me know with a new clover.daemon.log, tahnks.

Edited December 24, 2019 by vector sigma

[d620osx]

Second command gives me:

 

2019-12-24 14:42:21.165 defaults[646:6150]

Domain (com.apple.loginwindow) not found.

Defaults have not been changed.

 

Once re-booted do you need additional info?

 

Thank you

[vector sigma]

6 minutes ago, d620osx said:

Once re-booted do you need additional info?

 

Thank you

nothing else, let see. But may be better that you do two reboots to see if the daemon installed the correct logout hook as we will see that only on the second one.