search

acidanthera / bugtracker

Acidanthera Bugtracker
374 stars 42 forks source link

ASSERT [OpenCore] ImageLoader.c(986): ((BOOLEAN)(0==1)) #2414

Closed tijon1 closed 18 hours ago

tijon1 commented 3 days ago

It seems like there is something wrong with Mountain Lion on the recent versions of OpenCore. This is with OpenCore 1.0 DEBUG binaries all on a 16gb USB.

I am unable to boot into a Mountain Lion recovery image on a Thinkpad T530 (QM77 chipset, i5-3210M ivy bridge arch) using a USB drive. I have tried reformatting multiple times and constantly validating my config file using ocvalidate

The recovery image was obtained using macrecovery via this command python3 macrecovery.py -b Mac-7DF2A3B5E5D671ED -m 00000000000F65100 download Validation is ok and the resulting image is called RecoveryImage.dmg

Upon booting the image in OpenCore (OpenCore boots up successfully with no issues), I get this assert after a while of waiting (roughly 35-60 seconds) ASSERT [OpenCore] ImageLoader.c(986): ((BOOLEAN)(0==1))

I have tried using different SMBIOSes and Hfs drivers. (OpenHfsPlus, OpenHfsLegacy and HfsPlus) Googling this assert seems to show a thread related to a thread of this exact assert with Mountain Lion with cases which all have happened in last few months. https://www.reddit.com/r/hackintosh/comments/1cl354t/unable_to_boot_macos_x_108_mountain_lion_from/

The USB drive has been reformatted multiple times using both Rufus and Windows's in-built utility known as diskpart. NVRAM has been cleared multiple times. The result is always the same.

Top-level layout of USB drive is

Logs and my EFI NOTE: I am unable to acquire Lilu DEBUG logs because I can't even boot, related to this issue. opencore-2024-07-06-010003.txt EFI.zip

vit9696 commented 2 days ago

@mhaeuser, @mikebeaton we assert here:

  //
  // Load the image ourselves in secure boot mode.
  //
  if (SecureBootStatus == EFI_SUCCESS) {
    if ((SourceBuffer != NULL) && (OcImageLoaderCaps == NULL)) {
      Status = OcImageLoaderLoad (
                 FALSE,
                 ParentImageHandle,
                 DevicePath,
                 SourceBuffer,
                 SourceSize,
                 ImageHandle
                 );
    } else {
      //
      // We verified the image, but contained garbage, or we are trying to secure boot a Fat slice.
      // This should not happen.
      //
      ASSERT (FALSE);
      Status = EFI_UNSUPPORTED;
    }
  }
mikebeaton commented 2 days ago

@tijon1 - Can you confirm what the behaviour is with FixupAppleEfiImages set to true in config.plist?

tijon1 commented 2 days ago

@mikebeaton @vit9696 The result remains the same with FixupAppleEfiImages, not advancing anywhere past that assert

mikebeaton commented 1 day ago

@tijon1 - Can you confirm that the macOS XCODE5 Artifacts downloadable from here https://github.com/acidanthera/OpenCorePkg/actions/runs/9830476980 resolve the issue?

tijon1 commented 18 hours ago

@mikebeaton @vit9696 I can confirm that the recent PR and build has fixed my issue entirely, thank you a lot for the fast work! I recommend changing readme to also mention Lion as that's the earliest version I could get the assert on, anything past 10.8 doesn't have this issue.

mikebeaton commented 17 hours ago

@tijon1 - thanks for clear and helpful bug report