Clover General discussion

[Jief_Machak]

In this refactoring, I had to slightly reorganize custom entries and subentries "settings" field.

So if you use custom entries, please test if you can.

 

If something is not right : DO NOT try to workaround and fix. There is suppose to have NO functional change. Just tell me. 

CLOVERX64.efi

[Slice]

On 3/18/2021 at 8:21 PM, Slice said:

One more issue. debug.log is not created at this crash.

It is very-very bad. Old method for debug.log assumed that it must be created at any crash. Not now.

In the old method file opened or created and closed at every line. In the new method it will be open once and so not saved at incidence.

 

On 3/19/2021 at 11:03 AM, Jief_Machak said:

Ah and for the log : in the config.plist in the Qemu disk image, the key was Log instead of Debug. I fixed it and it's in the zip. Delete "disk_image_gpt.img.zip" and the launch script will re-extract the zip.

I don't understand why you said that I'm not closing the log, and why you re-import old method. At the end of the new "SaveMessageToDebugLogFile", there is "closeDebugLog();"

If there is a log creation problem, tell me how to reproduce and I'll fix it.

To reproduce the problem I inserted three lines into main.c:

void LOADER_ENTRY::StartLoader()
{
  EFI_STATUS              Status;
  EFI_TEXT_STRING         ConOutOutputString = 0;
  EFI_HANDLE              ImageHandle = NULL;
  EFI_LOADED_IMAGE        *LoadedImage = NULL;
  CONST CHAR8                   *InstallerVersion;
  NSVGfont                *font; // , *nextFont;

  DbgHeader("StartLoader");
  
  DBG("Starting %ls\n", FileDevicePathToXStringW(DevicePath).wc_str());
  
  DBG("test 1\n");
  panic("test panic\n");
  DBG("test 2\n");

I expected to find debug.log ended by the line "test 1" but... quess what?

Yes, there is no such log at all. Because panic will not close the file. As well as real panic.

In the old Clover (<5000 for example) the debug.log was saved on disk every line and so I really had such short log ended at the place of crash.

Now I have no such possibility.

[Jief_Machak]

3 minutes ago, Slice said:

 

To reproduce the problem I inserted three lines into main.c:

void LOADER_ENTRY::StartLoader()
{
  EFI_STATUS              Status;
  EFI_TEXT_STRING         ConOutOutputString = 0;
  EFI_HANDLE              ImageHandle = NULL;
  EFI_LOADED_IMAGE        *LoadedImage = NULL;
  CONST CHAR8                   *InstallerVersion;
  NSVGfont                *font; // , *nextFont;

  DbgHeader("StartLoader");
  
  DBG("Starting %ls\n", FileDevicePathToXStringW(DevicePath).wc_str());
  
  DBG("test 1\n");
  panic("test panic\n");
  DBG("test 2\n");

I expected to find debug.log ended by the line "test 1" but... quess what?

Yes, there is no such log at all. Because panic will not close the file. As well as real panic.

In the old Clover (<5000 for example) the debug.log was saved on disk every line and so I really had such short log ended at the place of crash.

Now I have no such possibility.

I don’t have computer right now but the log IS closed at every line. See “closeDebugLog()”

if the log is not generated AT ALL, it might be something else ?

I’ll try your 3 lines as soon as I can.

[Slice]

PS. This is real boot on my first computer. Not QEMU.

2 minutes ago, Jief_Machak said:

I don’t have computer right now but the log IS closed at every line. See “closeDebugLog()”

if the log is not generated AT ALL, it might be something else ?

I’ll try your 3 lines as soon as I can.

But there is no call for closeDebugLog(). There is panic.

[Slice]

Or something else...

[JorgeMax]

4 hours ago, Slice said:

There are new caches in BigSur and we have to load and patch kexts new way as OpenCore does.

This way we loose an ability to patch graphics kexts. May be some others too.

About WhateverGreen I see no any problem. It was loaded and works as it can.

Open the Terminal.app program and type the command

sudo kextstat | grep -v "pple"

 

Spoiler

 

 

 

[Jief_Machak]

26 minutes ago, Slice said:

Or something else...

Here is the end of a log with your test added :

=== [ StartLoader ] =============================
Starting PciRoot(0x0)\Pci(0x11,0x0)\Pci(0x5,0x0)\Sata(0x1,0x0,0x0)\HD(2,GPT,7FEBDFFB-41C8-46CE-883D-428DCBCC4D0D,0x64028,0xEF9BFB0)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,C0A6B5932777424FAB2C99B2D1ADA6FF)\B4FF70B1-62D3-4416-BBCF-798EC8A4589A\System\Library\CoreServices\boot.efi
test 1

The closeDebugLog() is called by the DBG at the previous line, because it's called at each line, exactly as it always was.

panic doesn't call the logging mechanism. So panic message is NOT in the log.

[Jief_Machak]

On 3/18/2021 at 10:32 AM, Jief_Machak said:

I

Ok, making progress. I did that and I got the crash !

 

If I used the img you've sent me few post ago, I got stuck at :

 

I also have 

ehci: PERIODIC list base register set while periodic schedule
      is enabled and HC is enabled
ehci: ASYNC list address register set while async schedule
      is enabled and HC is enabled

in the mac console.

 

Knowing which img you use is easy. The img committed in Qemu folder has this theme :

 

Could you have a quick check by copying the img you've sent me in Qemu folder? Rename it to "disk_image_gpt.img" or modify the launch command.

 

Do you have an idea why your img display these ehci message and freeze instead of crash ?

On 3/19/2021 at 11:03 AM, Jief_Machak said:

the key was Log instead of Debug

@Slice : did you check the key in the boot section ? That could easily explain no log at all.

[Slice]

16 minutes ago, JorgeMax said:

 

  Hide contents

 

 

 

 

 

Strange. I see the message in your log

7:997  0:015  OC: Prelinked injection Kexts\Other\WhateverGreen.kext () - Invalid Parameter

check your kext integrity. Replace it by a fresh copy.

9 minutes ago, Jief_Machak said:

 

Do you have an idea why your img display these ehci message and freeze instead of crash ?

@Slice : did you check the key in the boot section ? That could easily explain no log at all.

With the same config I have debug log every boot except with panic boot.

There must be a shorter file but no.

About my qemu I should look arguments to launch.

 

[Jief_Machak]

5 minutes ago, Slice said:

With the same config I have debug log every boot except with panic boot.

There must be a shorter file but no.

Can reproduce in Qemu ?

[Slice]

14 minutes ago, Jief_Machak said:

 

Do you have an idea why your img display these ehci message and freeze instead of crash ?

 

I also have this messages and I don't know what is wrong.

4 minutes ago, Jief_Machak said:

Can reproduce in Qemu ?

[Slice]

CLOVERX64-panic.efi

It is somehow smaller then regular Clover. Becuase of LTO knows OC will not used?

[jsl2000]

5 hours ago, Jief_Machak said:

In this refactoring, I had to slightly reorganize custom entries and subentries "settings" field.

So if you use custom entries, please test if you can.

 

If something is not right : DO NOT try to workaround and fix. There is suppose to have NO functional change. Just tell me. 

CLOVERX64.efi 1.25 MB · 4 downloads

Thanks and it worked without any issue at Big Sur 11.3 beta4 in my B85M-G hackintoshs.

Edited March 20, 2021 by jsl2000

[Jief_Machak]

1 hour ago, Slice said:

I also have this messages and I don't know what is wrong.

Good, send my your img and I'll debug it.

[JorgeMax]

@Sliceit's no use, doesn't load "invalid parameter" and I'm using the latest version of kext at 1.4.8

 

I'll try an older one

 

Spoiler

Version 1.4.6 loaded

Edited March 20, 2021 by JorgeMax

[Slice]

1 hour ago, Jief_Machak said:

Good, send my your img and I'll debug it.

It is Clover/Qemu image

It is not first observation of missing debug.log. I already encountered before reporting and other users told me there are no debug.log.

See

static UINTN GetDebugLogFile()
{
  EFI_STATUS          Status;
  EFI_FILE_PROTOCOL   *LogFile;

  if ( gLogFile ) return 0;

As the log file already defined then it will be not closed.

[Jief_Machak]

51 minutes ago, Slice said:

It is Clover/Qemu image

It is not first observation of missing debug.log. I already encountered before reporting and other users told me there are no debug.log.

See

static UINTN GetDebugLogFile()
{
  EFI_STATUS          Status;
  EFI_FILE_PROTOCOL   *LogFile;

  if ( gLogFile ) return 0;

As the log file already defined then it will be not closed.

Really ???

This means that if the log is already opened, it's not reopened. "GetDebugLogFile()" never closed the log file. Its purpose is and always was to open it !!!

 

The systematic close of the log file happens at then end "SaveMessageToDebugLogFile()" like it always was.

 

If you don't have any log in the current Qemu image, it's because there is no "Debug" key in boot section. I've already written 2 times about this.

You always seem to be very reluctant to send me Qemu images.

It would be much simpler than guessing configuration...

Edited March 20, 2021 by Jief_Machak

[Slice]

https://drive.google.com/file/d/1AaxV4BACMhVxpojrs21oJlFt5FAScHpW/view?usp=sharing

[Jief_Machak]

12 hours ago, Slice said:

https://drive.google.com/file/d/1AaxV4BACMhVxpojrs21oJlFt5FAScHpW/view?usp=sharing

No access. I've requested access few hours ago. In case you didn't see it.

[Slice]

38 minutes ago, Jief_Machak said:

No access. I've requested access few hours ago. In case you didn't see it.

To whom? I see no your request.

There is some strange issue #176 telling there is no debug.log.

[Slice]

OK, I opened access to all.

[Slice]

VOID SaveMessageToDebugLogFile(IN CHAR8 *LastMessage)
{
  EFI_STATUS Status;

  UINTN lastWrittenOffset = GetDebugLogFile();

then

static UINTN GetDebugLogFile()
{
  EFI_STATUS          Status;
  EFI_FILE_PROTOCOL   *LogFile;

  if ( gLogFile ) return 0;

so lastWrittenOffset = 0;

[Slice]

One more method to reproduce the bug: press RESET while in Clover GUI.

[Jief_Machak]

3 hours ago, Slice said:

VOID SaveMessageToDebugLogFile(IN CHAR8 *LastMessage)
{
  EFI_STATUS Status;

  UINTN lastWrittenOffset = GetDebugLogFile();

then

static UINTN GetDebugLogFile()
{
  EFI_STATUS          Status;
  EFI_FILE_PROTOCOL   *LogFile;

  if ( gLogFile ) return 0;

so lastWrittenOffset = 0;

At the end of "SaveMessageToDebugLogFile()" there is "closeDebugLog()". "closeDebugLog()" will set gLogFile to NULL. So this test is never true.

 

Well it is still a bug, that's true, because if you call "GetDebugLogFile()" twice in a row, the log will restart at the beginning.

I'll update that.

 

The log wasn't generate because there was no definition of PcdDebugPrintErrorLevel (defualt seems to be 0x80000000) in Clover.dsc when DEBUG_ON_SERIAL_PORT was not defined. Which is illogical as debug to file has nothing to do with serial port. Looks like RELEASE versions don't generate logs in quite some time.

That has nothing to do with panic or not, crash or not. The log was just never generate because of 

  if ((DebugMode & GetDebugPrintErrorLevel ()) == 0) {
    return;
  }

Committed.

Edited March 21, 2021 by Jief_Machak

[Slice]

The debug log is successfully generated when no panic, when no random reboot.

I will check you new commit.