Jump to content

Clover problems report & features request

ErmaC

By ErmaC,
in Clover

 Share
953 posts in this topic

Recommended Posts

Badruzeus
Badruzeus
Posted
Posted
2 minutes ago, STLVNUB said:

I'm using build_clover

Have sucessfully built BaseTools

but have this error 


build.py...
/home/stlvnub/src/edk2/MdePkg/Library/BaseLib/BaseLib.inf(-1): error 3000: PCD [gEfiMdePkgTokenSpaceGuid.PcdControlFlowEnforcementPropertyMask] in [/home/stlvnub/src/edk2/MdePkg/Library/BaseLib/BaseLib.inf] is not found in dependent packages:
		/home/stlvnub/src/edk2/MdePkg/MdePkg.dec

- Failed -
Build end time: 21:28:46, Mar.10 2019
Build total time: 00:00:01

Will fix tomorrow, need some sleep.

 

Even after changing this line? 

1637	EDK2_REV="${EDK2_REV:-28976}"

 

  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
Posted

Patches_for_EDK2 is synced up to git tag edk2-stable201903/svn r28976 which will remain stable for at least 3 months.

 

Patches_for_UDK2018 works with git tag vUDK2018, and I believe also with branch UDK2018, although there's a commit there adding a file Lfence.nasm (7648fe3) that I have not synced to Clover so as not to break compatibility with vUDK2018.

  • Like 3
Link to comment
Share on other sites
STLVNUB
STLVNUB
Posted
Posted

fixed svn revision now this error 

[SLINK] GrubEXFAT
/home/stlvnub/src/edk2/Clover/FileSystems/GrubFS/grub/grub-core/fs/hfsplus.c: In function 'list_nodes':
/home/stlvnub/src/edk2/Clover/FileSystems/GrubFS/grub/grub-core/fs/hfsplus.c:714:57: error: taking address of packed member of 'struct grub_hfsplus_catkey' may result in an unaligned pointer value [-Werror=address-of-packed-member]
  714 |   *grub_utf16_to_utf8 ((grub_uint8_t *) filename, catkey->name,
      |                                                   ~~~~~~^~~~~~
/home/stlvnub/src/edk2/Clover/FileSystems/GrubFS/grub/grub-core/fs/hfsplus.c: In function 'grub_hfsplus_label':
/home/stlvnub/src/edk2/Clover/FileSystems/GrubFS/grub/grub-core/fs/hfsplus.c:996:57: error: taking address of packed member of 'struct grub_hfsplus_catkey' may result in an unaligned pointer value [-Werror=address-of-packed-member]
  996 |   *grub_utf16_to_utf8 ((grub_uint8_t *) (*label), catkey->name,
      |                                                   ~~~~~~^~~~~~
cc1: all warnings being treated as errors
make: *** [GNUmakefile:833: /home/stlvnub/src/edk2/Build/Clover/RELEASE_GCC53/X64/Clover/FileSystems/GrubFS/src/HFSPLUS/OUTPUT/grub/grub-core/fs/hfsplus.obj] Error 1


build.py...
 : error 7000: Failed to execute command
	make tbuild [/home/stlvnub/src/edk2/Build/Clover/RELEASE_GCC53/X64/Clover/FileSystems/GrubFS/src/HFSPLUS]


build.py...
 : error F002: Failed to build module
	/home/stlvnub/src/edk2/Clover/FileSystems/GrubFS/src/HFSPLUS.inf [X64, GCC53, RELEASE]

- Failed -
Build end time: 15:25:48, Mar.11 2019
Build total time: 00:00:53


o_Ops, ./ebuild.sh exited with error(s), aborting..

 

Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted
1 minute ago, STLVNUB said:

Sorry, building on Linux using GCC9.0.1 Experimental, probably why the error, maybe 

Yeah, those should be warnings but gcc9 marked as errors. You may try adding this line? 

-Wno-address-of-packed-member

as well with ../VBoxFsDxe/fsw_hfs.c

 

 

Wno-address-of-packed-member.png

Link to comment
Share on other sites
apianti
apianti
Posted
Posted

It's basically saying that it won't be able optimize the code properly because the address is not on a boundary of the type for which it wants an address. You can remove this error by using the macro provided by edk2 to get the address offset of a member. It's just a lot of work to do just to not get a warning (since the macro is just the forcing unoptimization) when you can disable the warning. I thought that the warning is disabled though, maybe it was renamed in the newest gcc?

  • Thanks 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
On 3/11/2019 at 8:25 AM, Badruzeus said:

Yeah, those should be warnings but gcc9 marked as errors. You may try adding this line? 


-Wno-address-of-packed-member

as well with ../VBoxFsDxe/fsw_hfs.c

 

 

Wno-address-of-packed-member.png

This warning should be cured by using function ReadUnaligned() else you get wrong result.

Don't do no-warning or no-error if you don't want unpredictable result.

  • Thanks 1
Link to comment
Share on other sites
STLVNUB
STLVNUB
Posted
Posted
On 3/11/2019 at 12:33 AM, Zenith432 said:

Patches_for_EDK2 is synced up to git tag edk2-stable201903/svn r28976 which will remain stable for at least 3 months.

 

Patches_for_UDK2018 works with git tag vUDK2018, and I believe also with branch UDK2018, although there's a commit there adding a file Lfence.nasm (7648fe3) that I have not synced to Clover so as not to break compatibility with vUDK2018.

Wouldn't it be a lot easier and cleaner to adapt Clovers source code to EDK2/UDK2918 standards, this is like a dog chasing its tail.

Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted
4 hours ago, STLVNUB said:

Wouldn't it be a lot easier and cleaner to adapt Clovers source code to EDK2/UDK2918 standards, this is like a dog chasing its tail.

Just updated to newer GCC 9.0.1 (20190311) on Ubuntu 19.04. The issue is still persist, nevermind. 

sudo apt-get update && sudo apt-get full-upgrade

 

gcc9-20190311.png

Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted

Well, I'm just bit curious: Using a same compiler why building Clover with Secure Boot produces more than twice binaries size? Anyway, which one is the right defined macros: -DENABLE_SECURE_BOOT or -D ENABLE_SECURE_BOOT (?) Thanks.

Link to comment
Share on other sites
STLVNUB
STLVNUB
Posted
Posted

I would use -DENABLE_SECURE_BOOT, reason being it is one parameter where -D ENABLE_SECURE_BOOT is two if calling from terminal

You could put "-D ENABLE_SECURE_BOOT" which is one as well, they both do some thing of course

  • Thanks 1
Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted (edited)
28 minutes ago, STLVNUB said:

I would use -DENABLE_SECURE_BOOT, reason being it is one parameter where -D ENABLE_SECURE_BOOT is two if calling from terminal

You could put "-D ENABLE_SECURE_BOOT" which is one as well, they both do some thing of course

OK, using -D ENABLE_SECURE_BOOT :: this is what I got: 

0:100  0:000  Starting Clover revision: 4898 on American Megatrends EFI
0:100  0:000  Build with: [Args: --ext-co -D ENABLE_SECURE_BOOT | -D ENABLE_SECURE_BOOT -D USE_LOW_EBDA -D HAVE_LEGACY_EMURUNTIMEDXE -a X64 -b RELEASE -t GCC53 -n 2 | OS: Ubuntu 19.04]

#EDIT: Wait @STLVNUB; it seems I'm unable using -DENABLE_SECURE_BOOT option.

-DENABLE_SECURE_BOOT.png

Edited by Badruzeus
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

It shouldn't matter, all three ways @STLVNUB gave should work, they are all valid arguments forms for edk build. However, the problem is probably the clover build script since it parses the command line and reforms the arguments to pass to edk build, so it may not check correctly for them. Just stick with whichever one works, it will build the secure boot support. You need to sign your binaries in order for them to work in secure boot, it's not automated... Or you can attempt to change the security policy to ask add the hash of the binaries to the whitelist when they are loaded the first time. The files are larger because they need secure boot support which means openssl support, which is huge.

Link to comment
Share on other sites
  • 2 weeks later...
Power Mac
Power Mac
Posted
Posted (edited)

Hi, I believe both No and Detect options for Inject Kexts are, once again, broken in Clover. While trying to improve my boot time, I took a look at my debug.log; I found out that, despite the fact that I've always used Detect (given that I place any extra kexts in Library/Extensions), Clover keeps loading kexts from the Other folder too. I then tried No instead of Detect, but the result is the same (with the exception that Clover skips kext injection... only to inject them just a line later).

I can't track back the version that re-introduced the bug, but it's been the case for at least the current release and the previous one, and I'm sure there's nothing wrong with my configuration (my config.plist is quite spartan and I checked it out for possible conflicts). Besides, even if there were severe issues related to my kext cache (that Clover should read in order to detect FakeSMC), Inject Kexts=No should do its work in any given condition. Last but not least, RehabMan already found out such a bug in an older Clover version, that's why I believe the feature still needs some refinement.

 

Here's a sample. To try and narrow down the issue, for this debug boot I deleted every kext in Other and set "No" for Inject Kexts. But as you can see, Clover keeps trying to inject kexts. When I actually leave some kexts in Other, they end up loading just fine (redundantly and pointlessly). 

skipping kext injection (not requested)
10:358  0:010  Use origin smbios table type 1 guid.
10:374  0:015  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\Other
10:380  0:006  Extra kext: EFI\CLOVER\kexts\Other\WhateverGreen.kext (v.1.2.6)
10:389  0:008  Failed to load extra kext (Info.plist not found): EFI\CLOVER\kexts\Other\WhateverGreen.kext

I hope this'll be useful.

P.S. I haven't tried the current beta iteration yet (Clover 4901) because I prefer waiting for stable releases for the sake of safeness. 

Edited by Power Mac
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

It seems to break often. It's not a big deal, the extra ones are actually discarded if the kext identifier is already in the cache, there is no way to tell from the log if they were actually injected though as that just means they were prepared to be injected. Injection happens much later and can't be printed to the log only the screen. However, Lilu+Whatevergreen kexts should always be injected. You should actually inject kexts that are required to boot, and install other kexts that are only needed for extra functionality. Detection only disables injection if FakeSMC is in the cache, this is what you'd want as you want to not inject kexts already in the cache because you also installed them but you need to install FakeSMC for it to work.

Link to comment
Share on other sites
Power Mac
Power Mac
Posted
Posted
1 hour ago, apianti said:

It seems to break often. It's not a big deal, the extra ones are actually discarded if the kext identifier is already in the cache, there is no way to tell from the log if they were actually injected though as that just means they were prepared to be injected. Injection happens much later and can't be printed to the log only the screen. However, Lilu+Whatevergreen kexts should always be injected. You should actually inject kexts that are required to boot, and install other kexts that are only needed for extra functionality. Detection only disables injection if FakeSMC is in the cache, this is what you'd want as you want to not inject kexts already in the cache because you also installed them but you need to install FakeSMC for it to work.

 

No, it's not a killer bug by any means, but I'd rather avoid injecting the same kexts twice and always having to make sure both locations are up-to-date. I didn't know that the log can't actually tell you whether the kext was injected or not: I assumed that was the case, given that with Detect it says something like "successfully loaded" for each kext, so thanks for the tip.

I do not agree with your advice on injection, though (sorry if I misinterpreted your words): as stated by many, there's no reason not to install every kext in /L/E, given that injected kexts live outside of the protected MacOS memory space (and some kexts do not even work correctly when injected). For this reason, I keep as few kexts as possible in Other (the ones strictly needed to run the installer). I hope the bug can be fixed soon.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted

First, I did not say inject all of your kexts, I said inject the ones that are required for you to boot. If an extension doesn't work when injected its because it needs another kext that is not loaded, you can try to force loading those kexts. I don't know who told you the nonsense of the protected macOS memory space, that is not even a thing. The kexts are injected through a mechanism that is present in the kernel to load extensions from the boot loader, all kernel extensions are loaded into the kernel memory space or they couldn't work... There is reason to inject some kexts, as I said Lilu+Whatevergreen need to be injected to ensure they are initialized before any of the kexts they patch.

  • Like 1
Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted
9 hours ago, Power Mac said:

Hi, I believe both No and Detect options for Inject Kexts are, once again, broken in Clover. While trying to improve my boot time, I took a look at my debug.log; I found out that, despite the fact that I've always used Detect (given that I place any extra kexts in Library/Extensions), Clover keeps loading kexts from the Other folder too. I then tried No instead of Detect, but the result is the same (with the exception that Clover skips kext injection... only to inject them just a line later).

I can't track back the version that re-introduced the bug, but it's been the case for at least the current release and the previous one, and I'm sure there's nothing wrong with my configuration (my config.plist is quite spartan and I checked it out for possible conflicts). Besides, even if there were severe issues related to my kext cache (that Clover should read in order to detect FakeSMC), Inject Kexts=No should do its work in any given condition. Last but not least, RehabMan already found out such a bug in an older Clover version, that's why I believe the feature still needs some refinement.

 

Here's a sample. To try and narrow down the issue, for this debug boot I deleted every kext in Other and set "No" for Inject Kexts. But as you can see, Clover keeps trying to inject kexts. When I actually leave some kexts in Other, they end up loading just fine (redundantly and pointlessly). 


skipping kext injection (not requested)
10:358  0:010  Use origin smbios table type 1 guid.
10:374  0:015  Preparing kexts injection for arch=x86_64 from EFI\CLOVER\kexts\Other
10:380  0:006  Extra kext: EFI\CLOVER\kexts\Other\WhateverGreen.kext (v.1.2.6)
10:389  0:008  Failed to load extra kext (Info.plist not found): EFI\CLOVER\kexts\Other\WhateverGreen.kext

I hope this'll be useful.

P.S. I haven't tried the current beta iteration yet (Clover 4901) because I prefer waiting for stable releases for the sake of safeness. 

Check the contents of your WhateverGreen.kext kext to see if it's like it should be

286813662_Capturedcranle2019-03-2315_32_34.png.1b2ab4df5d9553965934adee444167d5.png

Link to comment
Share on other sites
Power Mac
Power Mac
Posted
Posted (edited)
14 hours ago, chris1111 said:

Check the contents of your WhateverGreen.kext kext to see if it's like it should be

286813662_Capturedcranle2019-03-2315_32_34.png.1b2ab4df5d9553965934adee444167d5.png

 

Thank you for the suggestion but that's not the issue there: the log returns that error because I emptied my Other folder for that test (that is, WhateverGreen wasn't physically there anymore); it loads just fine, with the other ones, if I leave them in Other.

 

14 hours ago, apianti said:

First, I did not say inject all of your kexts, I said inject the ones that are required for you to boot. If an extension doesn't work when injected its because it needs another kext that is not loaded, you can try to force loading those kexts. I don't know who told you the nonsense of the protected macOS memory space, that is not even a thing. The kexts are injected through a mechanism that is present in the kernel to load extensions from the boot loader, all kernel extensions are loaded into the kernel memory space or they couldn't work... There is reason to inject some kexts, as I said Lilu+Whatevergreen need to be injected to ensure they are initialized before any of the kexts they patch.

 

Well, the "one" who told me, corroborated by a couple other devs, is a guide on the site of the one who shall not be named (but is active in the developers' corner): can't link anything because I don't want a ban, but I trust him deeply, and most of the times his guides and advice are a step ahead of everyone else's.
 

Anyway, adding what Slice said to the mix, if I were in your shoes I'd either remove the functionality or fix it: it's going to be confusing for new users who won't be able to wrap their head around it, and old ones like me will keep believing it's a forgotten bug. Besides, if what has been said about injecting kexts is true, is there a master list of kexts that need injection and kext who do not? Because GitHub pages never mention anything of the sort.

Edited by Power Mac
Link to comment
Share on other sites
apianti
apianti
Posted
Posted

Literally every single one of them is wrong then. There is no possible other place for the extensions to be loaded except into the kernel memory space. Especially since there is only kernel and user memory spaces, kernel extensions don't really make much sense outside of the kernel.... Inject kexts that you need to boot successfully, any kext that needs to be initialized first before another kext and perform some action on that kext, needs to be injected since boot loader kernel extensions are initialized first. I don't really have time to deal with any issues currently and if slice says it's working right then, idk.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...