DuetPkg fails to boot on certain Compaq systems starting with OC 0.9.5

[Lost-Entrepreneur439]

Starting with OpenCore 0.9.5, DuetPkg fails to boot on the Compaq Presario SR5310F. It just hangs on a solid white line, with no disk activity. No OpenCore logs are created on the EFI partition, so something is failing very early in the boot process. DuetPkg from OpenCore 0.9.4 works fine, even with the rest of OpenCore being 1.0.2. Since no logs are being created, I don't know what could be causing DuetPkg to fail booting.

While I can only test on the SR5310F, I'd imagine this affects a number of Compaq systems from this era, it may affect some HP systems too as around this time, most Compaq systems were HP rebrands.

System specs: CPU: Intel(R) Pentium(R) Dual CPU E2140 @ 1.60GHz GPU: ATI Radeon HD 2400 PRO Chipset: Intel Lakeport-G i945GX Touchpad: N/A (desktop) Audio Codec: Realtek ALC888 @ Intel 82801GB ICH7 - High Definition Audio Controller [A-1] Network Controller: Realtek RTL8139/ 810x Fast Ethernet Adapter Drive Model: WDC WD5000AACS-61M6B2 ATA Device EFI.zip

[mikebeaton]

Hi, Thanks for the report.

Please bisect to identify the specific commit which causes this. You can download builds of OpenCore at each commit here: https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true. Since you know the problem happened in 0.9.4, you might want to start by double checking the last commit of 0.9.3 and the last commit of 0.9.4, to confirm that they are working and not working respectively, as expected. Then pick the commit in the middle, and test that. Depending on whether that is working or not, it becomes the new last known good commit, or new first known bad commit. Then pick the commit in the middle again, between the last known good and first known bad commit, and keep doing that till you find the commit which introduces the problem. Since there are 50 commits, by the power of binary you only need to check 5 or 6 more commits to finish this procedure.

[Lost-Entrepreneur439]

bb44e89 is the commit that introduced this issue.

[vit9696]

Given that we have no such hardware ourselves and the commit in question is rather big and has no obvious bugs we will need your assistance to tackle the issue down. Are you ok to test a few builds as we get closer to what might have caused this?

If so, I have just pushed a change reverting some suspicious part of this: https://github.com/acidanthera/OpenCorePkg/commit/894376b56db07568475bf258fe9173e71cd82315

Could you please report whether using the duet from it results in any behaviour change? The CI will prepare the build soon, see the artifacts here: https://github.com/acidanthera/OpenCorePkg/actions/runs/11534080673

Thanks!

[Lost-Entrepreneur439]

Given that we have no such hardware ourselves and the commit in question is rather big and has no obvious bugs we will need your assistance to tackle the issue down. Are you ok to test a few builds as we get closer to what might have caused this?

If so, I have just pushed a change reverting some suspicious part of this: acidanthera/OpenCorePkg@894376b

Could you please report whether using the duet from it results in any behaviour change? The CI will prepare the build soon, see the artifacts here: https://github.com/acidanthera/OpenCorePkg/actions/runs/11534080673

Thanks!

That commit has fixed the issue, OpenCore is now booting.

[vit9696]

Nice. The change I made in this commit should actually be unnecessary as the same logic should also exist in a separate driver. Yet apparently after a careful analysis it seems that this driver in question does not fully replicate it.

I built a special version of OpenDuet with the improved logic in the driver (see the referenced commit). Please test it directly: boot-d4ddd293-01306907-GCC-RELEASE.zip and report whether it works or not.

Thanks!

[Lost-Entrepreneur439]

That boot file is working as well.

[Lost-Entrepreneur439]

UPDATE: While that allows OpenCore to boot, it breaks Mac OS X. I'm running 10.5.7 on this hack as Leopard is the latest that can run on the 2400 PRO, and it caused it to panic early in the boot process. Here's a screenshot of the panic, I can provide a slo-mo of the verbose log too if wanted.