Alternative plist as a boot extension, Possible?

[Ameeno]

Hello all,

 

As you know, clover can choose different config plist files via the clover menu at the OS selection screen.

 

Is it possible to tell clover which plist file to use at boot time via a boot parameter?

 

 

My ultimate intention is this: I Will create an alternative clover config.plist file called nowait.plist

this config file will not scan entries or other boot items, wait for any time and ALWAYS boot macOS.

 

Next I will use efivars to create a clover a no-wait clover boot entry inside my bios.

 

That way, if i have any problems, i can simply F12 to the clover normal boot loader and load default config.plist file with menu and options ect, but my default boot can be clover using the nowait.plist.

 

 

However, i do not know how to pass a parameter to clover telling it which plist to use, is that possible?

[apianti]

Yeah you can just pass it as a load option:

https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/rEFIt_UEFI/refit/main.c#l2087

[Slice]

Yes, five years ago we did this.

[Ameeno]

Great, Fantastic fantastic,

 

Could you mind giving me the syntax for a Grub Menu Item?

 

For example my Syntax for my current Grub CFG for custom entries is:

 

#menuentry "macOS - No Wait" {
#  insmod chain
#  insmod search_fs_uuid
#  search --fs-uuid --no-floppy --set=root --fs-uuid 1C30-3CD4
#  chainloader /EFI/CLOVER/CLOVERX64.efi
#  savedefault
#}

 

 

what would i change the chainloader /EFI/CLOVER/CLOVERX64.efi line to to force a speedy direct to mac load?

 

Also ideally i would turn of Drive scanning on this boot entry, & As a bonus i would manually assign the mac boot partition and set it to load automatically to save those precious seconds

 

 

please help kind people.

[apianti]

No idea, you would need to figure that out for grub... Just use your firmware, since you have grub I'm assuming you have linux, so just check out efibootmgr and make entries for it. Also, you can disable parts of the scans, like for linux and kernels, and whatever.

[Ameeno]

ok how do i choose a particuler boot config/list for efiboot mgr?

 

i still am not clear how one tells clover to load a particular config (other than config.plist) at boot time?

 

 

 

[Ameeno]

On 4/20/2019 at 8:49 AM, apianti said:

No idea, you would need to figure that out for grub... Just use your firmware, since you have grub I'm assuming you have linux, so just check out efibootmgr and make entries for it. Also, you can disable parts of the scans, like for linux and kernels, and whatever.

 

Ok Using efi bootmgr (efivars) what syntax do i use to get clover to boot nowait.plist instead of config.plist

 

?

 

Lets assume my Drvie in linux clover boot file is /dev/sda1/EFI/CLOVER/CLOVERX64.efi

 

is my efi file, how do i pass in boot options? Is it simply -u 'nowait.plist'

 

or something more specific?

 

there is no documentation for this.

[apianti]

First, not efivars, you need efibootmgr (however you need efivarfs for it to actually do anything). Second, just pass whatever you want to be the options as the last options for the command. Google efibootmgr for your distro to get examples but as far as I know the only one that actually shows you how to pass parameters is the gentoo one:

https://wiki.gentoo.org/wiki/Efibootmgr

[Slice]

Look to the structure of variable BOOT0000. It contains LOAD_OPTION as a string. Clover is able to use this string as config.plist file name. That's all that I remembered but all this are already in current Clover sources.

[Captain Flack]

I too would like to know the answer to Ameeno's question. Since Clover is related to Refind, I checked the Refind documentation and found this very clear answer:—

Quote

You can tell rEFInd to use any configuration filename by passing -c filename as an option, as in refind_x64.efi -c myrefind.conf to use myrefind.conf in rEFInd's main directory. You can specify a configuration file in another directory, but to do so, you must use backslashes as directory separators, as in -c \EFI\other\refind.conf. This feature is intended for users who want to have rEFInd appear in its own menu, with the version launched in this way behaving differently from the original—for instance, to have a secondary rEFInd that provides boot options hidden by the main one. In this scenario, the default refind.conf would have a manual boot stanza defining the new rEFInd instance, including its -c option.

 

If I knew enough C++, I would try to infer Clover's equivalent of the above from Clover's source code, as Slice suggests in his 2019-04-24 comment above, but I'm hoping someone can just tell me. An answer for OpenCore would be useful too…

 

Or perhaps I should install qemu or bhyve so that I can test various guesses for myself, without multiple reboots.

[Slice]

No, Clover is not related to Refind. Rather vice versa. And Clover has no *.conf file. It uses config.plist file.

[Captain Flack]

10 minutes ago, Slice said:

No, Clover is not related to Refind.

My apologies to their respective authors! I was assuming that both started out as forks of Refit, but perhaps I've read an oversimplified history.

 

I mentioned refind.conf for exactly the same reason that Ameeno mentioned grub.cfg — as a metaphor to clarify the question. Unfortunately, apianti misinterpreted Ameeno's question as being a question about grub (it really isn't…), so I was hoping that another metaphor would eliminate the confusion. For yet another metaphor, I guess the uefi shell would be OK, as in “How can I start cloverx64.efi from the uefi shell such that clover uses a config file specified by me?”

 

Perhaps the answer to the question is “No, cloverx64.efi does not take any command-line arguments, unlike refindx64.efi”. However, the earlier parts of this discussion strongly hint that cloverx64.efi does take arguments, so it's shame that this straightforward question is apparently so hard to understand.

[Slice]

May be you need this feature?

[Captain Flack]

Interesting, I somehow overlooked that screen, even though it's mentioned at the top of this discussion 😴. Yes, I like the idea of putting several config files in place and then testing each of them as efficiently as possible. 😀