Jump to content
30960 posts in this topic

Recommended Posts

6 hours ago, Jief_Machak said:

To save time from gdb compilation, this should work gdb.zip

Thanks. But then I need an instruction what to do

iMac2017:CloverBootloader sergey$ ./Qemu/gdb_launch ./Qemu/CLOVERX64.efi
clover_debug_file=./Qemu/CLOVERX64.debug
clover_efi_file=./Qemu/CLOVERX64.efi
++ '[' Darwin = Darwin ']'
++ '[' -f ./Qemu/qemu_portable/qemu-system-x86_64 ']'
++ '[' -f /Users/sergey/src/CloverBootloader/Qemu/disk_image_gpt.img ']'
++ pgrep qemu
++ hdiutil attach /Users/sergey/src/CloverBootloader/Qemu/disk_image_gpt.img
/dev/disk3          	GUID_partition_scheme          	
/dev/disk3s1        	Microsoft Basic Data           	/Volumes/QEMU_EFI
/dev/disk3s2        	Apple_HFS                      	/Volumes/QEMU_MACOS
++ shopt -s nocasematch
+++ basename ./Qemu/CLOVERX64.debug
++ [[ CLOVERX64.debug =~ CloverX64* ]]
++ echo ditto ./Qemu/CLOVERX64.efi /Volumes/QEMU_EFI/EFI/CLOVER/CLOVERX64.efi
ditto ./Qemu/CLOVERX64.efi /Volumes/QEMU_EFI/EFI/CLOVER/CLOVERX64.efi
++ ditto ./Qemu/CLOVERX64.efi /Volumes/QEMU_EFI/EFI/CLOVER/CLOVERX64.efi
++ echo ditto ./Qemu/CLOVERX64.efi /Volumes/QEMU_EFI/EFI/BOOT/BOOTX64.efi
ditto ./Qemu/CLOVERX64.efi /Volumes/QEMU_EFI/EFI/BOOT/BOOTX64.efi
++ ditto ./Qemu/CLOVERX64.efi /Volumes/QEMU_EFI/EFI/BOOT/BOOTX64.efi
++ shopt -u nocasematch
++ diskutil eject /Volumes/QEMU_EFI
Disk /Volumes/QEMU_EFI ejected
++ sleep 1
++ set -m
++ cd /Users/sergey/src/CloverBootloader/Qemu
++ [[ 0 == 0 ]]
++ set +m
++ count=1
++ timeout=60
++ image_base_str='CloverX64 : Image base = '
++ '[' 1 -le 60 ']'
++ getImageBase
++ '[' -f /Users/sergey/src/CloverBootloader/Qemu/serial0_qemu_out.log ']'
++ grep 'CloverX64 : Image base = ' /Users/sergey/src/CloverBootloader/Qemu/serial0_qemu_out.log
++ ./qemu_portable/qemu-system-x86_64 -L qemu_portable -m 2048 -cpu Penryn -bios ./bios.bin-1.13.0 -machine q35 -device ahci,id=ahi -drive format=raw,id=hda,file=./disk_image_gpt.img -usb -device usb-mouse,bus=usb-bus.0,port=2 -device usb-kbd,bus=usb-bus.0,port=1 -serial file:./serial0_qemu_out.log -gdb tcp::9000
++ return 1
++ sleep 1
++ count=2
++ '[' 2 -le 60 ']'
++ getImageBase
++ '[' -f /Users/sergey/src/CloverBootloader/Qemu/serial0_qemu_out.log ']'
++ grep 'CloverX64 : Image base = ' /Users/sergey/src/CloverBootloader/Qemu/serial0_qemu_out.log
++ return 1
++ sleep 1
++ count=3
++ '[' 3 -le 60 ']'
++ getImageBase
++ '[' -f /Users/sergey/src/CloverBootloader/Qemu/serial0_qemu_out.log ']'
++ grep 'CloverX64 : Image base = ' /Users/sergey/src/CloverBootloader/Qemu/serial0_qemu_out.log
++ return 1
++ sleep 1
++ count=4

 

  • Like 1
23 hours ago, Slice said:

The crash happen when I type "Space" on the penguin.

executing the command

SubMenuExit = MainChosenEntry->SubScreen->RunGenericMenu(&SubMenuIndex, &TempChosenEntry);

I'll have a look. I'm sure what is " I type "Space" on the penguin", though.

 

For gdb, If you don't put any parameter, it'll get the one in Build/Clover/DEBUG_GCC53/X64 folder. Both CloverX64.debug and CloverX64.are needed.

Then, you have to wait more. Qemu is extremely slow to launch. Gdb can only start when Clover will have printed something like "CloverX64 : Image base = 0x7DC38000". It can take 30/40 seconds sometimes.

It worth having that working because locating panic (and therefore bug) happens in a matter of seconds.

Have a go and tell me if it work.

2 hours ago, Slice said:

++ '[' 2 -le 60 ']'

++ getImageBase

++ '[' -f /Users/sergey/src/CloverBootloader/Qemu/serial0_qemu_out.log ']'

++ grep 'CloverX64 : Image base = ' /Users/sergey/src/CloverBootloader/Qemu/serial0_qemu_out.log

++ return 1

++ sleep 1

++ count=3

These are just shell trace I never took the time to remove...

Ok, fixed.

Explanation :

gdb back trace shows that the crash happens at REFIT_MENU_SCREEN.cpp:1555 when "GraphicsMenuStyle()" tries to access Entries[0] without checking if there is at least one entry in the array.

762687207_Screenshot2021-03-26at00_21_25.png.6b51ef6c023ccff0bc4eb3ada457a797.png

Problem is that the menu for linux entries was empty.

 

A look at "AddDefaultMenu()" shows that there is some test about the loader type :

  if (LoaderType == OSTYPE_OSX ||
      LoaderType == OSTYPE_OSX_INSTALLER ||
      LoaderType == OSTYPE_RECOVERY) { // entries for Mac OS X
	// add some entries
  } else if (LoaderType == OSTYPE_LINEFI) {
	// add some entries
  } else if ((LoaderType == OSTYPE_WIN) || (LoaderType == OSTYPE_WINEFI)) {
	// add some entries
  }

Problem is : what happen if it's none of the above, like OSTYPE_LIN for example ?

Answer : no entry at all is added.

 

As a rule of thumb : never leave a test like this (which is equivalent to a C switch) without a default action.

I've added an else condition with one default entry.

 

In this particular case, maybe OSTYPE_LIN is wrong.

And if it's right, these probably better to do for os type OSTYPE_LIN. But I don't the linux boot process.

 

Edited by Jief_Machak
  • Like 1

Unfortuantely I'm facing another issue right now. 

I'm trying to install a Catalina 10.15.7 supplemental patch with Clover v5131 (commit sha in log name), but I can't see the Installer entry, therefore I can't boot from it. It isn't there even with "Show hidden entries".

Same with Clover v5130

 

screenshot0.thumb.png.dd75353d89f2ee65956c741a49f93790.png

 

It's okay with Clover v5128 (can't test v5129 because I can't find the .efi):

screenshot1.thumb.png.75eac7a19b9e47df47e2249723605754.png

 

attaching debug logs. 

I saw another person with this issue, he was right:

https://github.com/CloverHackyColor/CloverBootloader/issues/380

 

EDIT: also saw that a lot of Clover release zips are just gone from the Release page

2021-3-25_21-47_CloverX64-RELEASE_XCODE8-20210322154001-829fd04.efi.log preboot_v5128.log

Edited by kushwavez
  • Sad 1

@Jief_Machak this commit https://github.com/CloverHackyColor/CloverBootloader/commit/3b542ca7119c13c9c860716df62b5c6e3720b49a

 

does not start macOS, you reload the Clover GUI as when you perform the NVRAM reset, but you do not start catalina or even big sur; other OS I haven't tried 

 

 

  • Like 2
1 hour ago, iCanaro said:

@Jief_Machak this commit https://github.com/CloverHackyColor/CloverBootloader/commit/3b542ca7119c13c9c860716df62b5c6e3720b49a

 

does not start macOS, you reload the Clover GUI as when you perform the NVRAM reset, but you do not start catalina or even big sur; other OS I haven't tried 

 

 

same here also there is no options menu or help or any response 

17 hours ago, kushwavez said:

Unfortuantely I'm facing another issue right now. 

I'm trying to install a Catalina 10.15.7 supplemental patch with Clover v5131 (commit sha in log name), but I can't see the Installer entry, therefore I can't boot from it. It isn't there even with "Show hidden entries".

Same with Clover v5130

 

 

Spoiler

screenshot0.thumb.png.dd75353d89f2ee65956c741a49f93790.png

 

 

It's okay with Clover v5128 (can't test v5129 because I can't find the .efi):

 

Spoiler

screenshot1.thumb.png.75eac7a19b9e47df47e2249723605754.png

 

 

attaching debug logs. 

I saw another person with this issue, he was right:

https://github.com/CloverHackyColor/CloverBootloader/issues/380

 

EDIT: also saw that a lot of Clover release zips are just gone from the Release page

2021-3-25_21-47_CloverX64-RELEASE_XCODE8-20210322154001-829fd04.efi.log 21.49 kB · 1 download preboot_v5128.log 20.83 kB · 0 downloads

@MifJpn yes indeed, from USB installer it's working. Thanks for investigating.

But I'm trying to install OTA with Software Update (as normally should be installed) like I did every time.

On Big Sur, I did not have such problems with OTA, but I decided to downgrade to Cata (mostly because of the memory leak bugs on Big Sur). An OTA update appeared, and I thought okay, go ahead and install it. But after restart I was presented with the same version, the update isn't installed (of course because the entry isn't there). I just don't want to create a whole Installer USB because of a small update.

 

Anyways @Jief_Machak, @Slice I did found something about it:

This commit 333b6ce1ca2c02300e93a151e4be513af7414d06 (Hide dead installer prebooter.)

 

After that commit (6bc80b8486563fa3cd76adff4e0209d20aa4c195 - update list in xcode project) it isn't working

The commit before (3142593e38f50af12f7a3ff399dd8b0d64893b2d - update model data) is working

 

I won't update now, let me know if you have some .efi to test with

  • Like 1
  • Sad 1
17 hours ago, kushwavez said:

Unfortuantely I'm facing another issue right now. 

I'm trying to install a Catalina 10.15.7 supplemental patch with Clover v5131 (commit sha in log name), but I can't see the Installer entry, therefore I can't boot from it. It isn't there even with "Show hidden entries".

Same with Clover v5130

 

screenshot0.thumb.png.dd75353d89f2ee65956c741a49f93790.png

 

It's okay with Clover v5128 (can't test v5129 because I can't find the .efi):

screenshot1.thumb.png.75eac7a19b9e47df47e2249723605754.png

 

attaching debug logs. 

I saw another person with this issue, he was right:

https://github.com/CloverHackyColor/CloverBootloader/issues/380

 

EDIT: also saw that a lot of Clover release zips are just gone from the Release page

2021-3-25_21-47_CloverX64-RELEASE_XCODE8-20210322154001-829fd04.efi.log 21.49 kB · 2 downloads preboot_v5128.log 20.83 kB · 0 downloads

Could you try to replace "ApfsDriverLoader.efi" by this one, for example ?apfs-v11.1.efi

  • Like 2

Replaced, but same unfortunately. 

Attaching new debug.log if needed

I saw this in the log maybe that is the Installer? It is considered as dead

edit: but also see installer dmg boot file not found so maybe that doesn't matter

[...]
0:868  0:000      APFSTargetUUID=7ADD3B9E-901D-440E-A91A-E3BCB619F3E4
0:869  0:000        contentDetails name:macOS SSD - adatok
0:869  0:000      Dead installer entry found (installer dmg boot file not found : '\macOS Install Data\Locked Files\BaseSystem.dmg')
0:869  0:000  - [07]: 'macOS SSD - adatok'
0:869  0:000      ApfsContainerUUID=5EF86F43-A55C-4384-B7DF-E35BB7E5CD9F
0:869  0:000      ApfsFileSystemUUID=7ADD3B9E-901D-440E-A91A-E3BCB619F3E4
[...]

preboot_v5131.log

Edited by kushwavez

in preboot_v5128.log I see in the log

0:782  0:000      Loader entry created for 'PciRoot(0x0)\Pci(0x1C,0x4)\Pci(0x0,0x0)\NVMe(0x1,55-7E-62-44-68-B7-26-00)\HD(2,GPT,E2A442FB-9313-4522-AD87-63BD30A5D527,0x64028,0x1D0BB7D8)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,C7EF85D336AFBE4F8D97EC42075B2261)\7ADD3B9E-901D-440E-A91A-E3BCB619F3E4\com.apple.installer\boot.efi'
0:782  0:000  - [07]: 'macOS SSD - adatok'

I think that is the Installer.

I don't see such lines in the latest log

  • Confused 1
1 hour ago, kushwavez said:

 


[...]
0:868  0:000      APFSTargetUUID=7ADD3B9E-901D-440E-A91A-E3BCB619F3E4
0:869  0:000        contentDetails name:macOS SSD - adatok
0:869  0:000      Dead installer entry found (installer dmg boot file not found : '\macOS Install Data\Locked Files\BaseSystem.dmg')
0:869  0:000  - [07]: 'macOS SSD - adatok'
0:869  0:000      ApfsContainerUUID=5EF86F43-A55C-4384-B7DF-E35BB7E5CD9F
0:869  0:000      ApfsFileSystemUUID=7ADD3B9E-901D-440E-A91A-E3BCB619F3E4
[...]

 

hmmm the log in the latest release says "Dead installer entry found (installer dmg boot file not found: ....\BaseSystem.dmg"), so I thought that doesn't matter. But I think that should be the installer after all.

 

BaseSystem.dmg is there (and the boot.efi is also inside Boot Files dir)

kushwavez@Viktor-MBP ~ % sudo ls -la /System/Volumes/Data/macOS\ Install\ Data/Locked\ Files 
total 980008
drwx------@ 11 root  wheel        352 Már 25 22:40 .
drwxr-xr-x@  8 root  wheel        256 Már 25 22:40 ..
-rw-r--r--   1 root  wheel        893 Már 25 22:40 .disk_label
-rw-r--r--@  1 root  wheel         15 Már 25 22:40 .disk_label.contentDetails
-rw-r--r--   1 root  wheel       3557 Már 25 22:40 .disk_label_2x
-rw-r--r--   1 root  wheel        328 Feb  6 09:18 AppleDiagnostics.chunklist
-rw-r--r--@  1 root  wheel    3147481 Feb  6 08:07 AppleDiagnostics.dmg
-rw-r--r--   1 root  wheel       2020 Feb  6 09:18 BaseSystem.chunklist
-rw-r--r--@  1 root  wheel  498592939 Feb  6 08:07 BaseSystem.dmg
drwxr-xr-x  29 root  wheel        928 Már 25 22:40 Boot Files
drwx------@  3 root  wheel         96 Már 25 22:40 Product Files

 

Edited by kushwavez

@kushwavez Yes, this is the problem. Old version doesn't check if the installer preboot is "dead" or not. Obviously, Imade a bug when I tried to detect if the dmg file exists or not, or Clover can't read the volume (that's why I proposed a recent apfs.efi).

I'm interested to debug that but that means to keep your hard drive like it is now. In a few hours, I can send you a Clover efi with very details log about this dmg detection and try to find what's going on.

Let me know if you can stay with this HDD in this half installed state.

  • Like 1
  • Thanks 1

@eng_redaesm last time when I had this freeze it caused by bad Quirks settings. If I remember correctly it was "DisableLinkeditJettison". That needed to be True. 

I'm now using the Quirks from the config-sample.plist from the release.zip by the way, that's okay (only enabled XhciPortLimit and disabled DisableIoMapper)

Edited by kushwavez
29 minutes ago, kushwavez said:

@eng_redaesm last time when I had this freeze it caused by bad Quirks settings. If I remember correctly it was "DisableLinkeditJettison". That needed to be True. 

I'm now using the Quirks from the config-sample.plist from the release.zip by the way, that's okay (only enabled XhciPortLimit and disabled DisableIoMapper)

@kushwavez. it was working  and i already have Xhciportlimit enabled and disanlroMapper disabled  and i make DisableLinkeditJettison true 

but still freezing 

preboot.log

@eng_redaesm Other option : find yourself the commit that broke. All the compiled commits are here https://github.com/jief666/CloverCommits

Check first the commit corresponding to a release number. Is it working with 5131 ? 5130 ? 5129 ?

Then try commits in between...

  • Like 1
×
×
  • Create New...