Troubleshooting macOS boot on a 2025 Legion Y7000 (Part 1): from an early panic to graphical boot

Start with the limits: this is a diagnostic record

The goal is not to publish copy-and-paste installation steps. It is to show how observations, comparisons, and conclusions were separated across two similar but non-identical Lenovo laptop platforms. Harvey’s Y7000 is the primary system; Luminous’s G5000 is the supplemental system.

At the time of writing, the Y7000 can display graphical macOS boot but has not entered Recovery. The G5000 passed its original early panic after one memory-mapping setting was disabled, but still stops near ACPI initialisation. Neither result supports a claim of successful installation or a working GPU driver.

• No macOS image, keys, circumvention files, or directly reusable EFI package is provided.
• For NullMoth, 1401, and OpenCore behaviour, refer to each project’s current official documentation.
• Before publication, logs and configurations should be stripped of serial numbers, MLB, SystemUUID, ROM, MAC and IP addresses, and personal paths.

The two systems and the limits of each observation

The 2025 Y7000 has model code 83LY, an i7-14650HX, and an RTX 5060 Laptop GPU. The target environment is macOS 15 Sequoia with OpenCore. This is a laptop discrete-GPU platform, so desktop validation from the driver project cannot be assumed to apply.

The G5000 is a 2024 IRX9 with board identifier LNVNB161216, an i7-13650HX (6P + 8E, 14 cores / 20 threads), and an RTX 4060 Laptop GPU. It uses OpenCore DBG-109-2026-09-30 generated by 1401 and a USB Recovery installer. Observed BIOS settings include Secure Boot off, AHCI, discrete-GPU mode, virtualisation and Hyper-Threading on, with Atom/E-cores enabled.

Y7000: building an evidence chain from a repeatable early panic

The Y7000 initially panicked consistently during early kernel initialisation, with the same fault address across runs. That repeatability points more toward a stable configuration, mapping, or device-initialisation problem than a random fault. Registers, error codes, configuration versions, hashes, and screen photographs were preserved rather than treating the final line alone as the cause.

One critical correction was that after OpenCore hands control to macOS, its own log cannot record what the kernel does next. Identical final OpenCore log lines therefore do not imply identical macOS outcomes. The final test criteria combine screen output, configuration differences, and repeatable tests.

Fault CR2: 0x00000000ff04504c
CPU: 0
Kernel: Darwin 24.6.0
State: before system initialisation completed

Y7000: verbose mode, asynchronous output, and false stopping points

With -v retained, the screen appeared to stop near the same text. Removing -v revealed the Apple logo and progress bar, showing that the “last printed line” did not fully describe execution progress. This did not solve the fault; the graphical interface merely made overall progress visible, and the bar still stopped.

Security, ACPI, and PCI messages can also interleave on screen. The last visible line may simply belong to the stream that printed last, not the step that caused the stall. A more reliable record asks whether a new stage appeared and ties each change to one configuration variable.

Y7000: narrowing the scope with grouped comparisons

Harvey enabled and disabled third-party extensions in groups, producing several pass/panic comparisons and narrowing the scope through set differences. This identifies a candidate group, not a single proven root cause; later tests must keep every other condition fixed and remove one candidate at a time.

Further analysis suggests that 0xF0000000 may be a runtime device address window rather than an ordinary value in a static firmware table. The register offsets resemble an audio-controller initialisation sequence, so audio-related extensions are priority candidates, but the link remains an evidence-based hypothesis awaiting a single-variable test.

Luminous’s G5000 comparison: cpus=1 still stalls at the ACPI stage

Luminous first reproduced the early kernel panic on the G5000. After Booter → Quirks → DevirtualiseMmio was disabled, the original panic disappeared and the system entered ACPI and CPU initialisation, but repeated namespace-lookup and method-execution errors appeared and Recovery was never reached.

With DevirtualiseMmio still disabled, cpus=1 was added and the relevant boot argument was placed in NVRAM Delete to avoid stale values, with no meaningful improvement. CpuTopologyRebuild.kext and three forced-HT kernel patches were then disabled and ctrsmt=full removed, but boot still stopped in roughly the same ACPI-initialisation area.

Repeated screen records show AE_NOT_FOUND, namespace lookup failures, method parse/execution failures, and a final visible line involving \_SB.PMAX._STA. The last ACPI message is not necessarily the root cause, so the report does not identify PMAX or PXDC as the fault source.

ACPI Exception: AE_NOT_FOUND
ACPI Error: Namespace lookup failure
ACPI Error: Method parse/execution failed
ACPI Error: [PXDC] Namespace lookup failure
ACPI Error: Method parse/execution failed [\_SB.PMAX._STA]

Why this differs from public Issue #6

In public Issue #6, a similar i7-13650HX platform reached PCI, NVMe, APFS, and disk-image initialisation after CPU-topology and forced-HT patches were disabled and cpus=1 was used. Luminous’s G5000 remained in the earlier ACPI area after similar changes.

The difference shows only that similar hardware may not follow the same boot path. Relevant variables include BIOS version, ACPI-table content, board revision, 1401/OpenCore build version, the NVRAM values that actually took effect, and other configuration differences. No cause should be claimed before the configurations and logs are compared item by item.

• Next, provide a sanitised OpenCore configuration summary, logs, and ACPI-table inventory.
• Ask the maintainers for one minimal diagnostic change rather than changing several quirks and patches at once.
• Continue recording BIOS versions, configuration hashes, screen photographs, and whether NVMe/APFS stages appear.

Methods worth keeping from this diagnostic pass

First, editing a configuration does not prove the edit took effect; corresponding evidence must appear in a log or on screen. Second, verbose mode is useful for early messages but cannot replace graphical boot as an indicator of overall progress. Third, grouped tests only narrow a candidate set; a single root cause still requires single-variable retesting.

Fourth, similar hardware is a useful comparison, not an interchangeable environment. Putting Harvey’s and Luminous’s records side by side preserves the differences: the Y7000’s progress cannot be assigned to the G5000, and the G5000’s ACPI stall cannot be used to infer the Y7000’s root cause.

Sources, roles, and citation

Harvey performed all Y7000 hands-on operations, screen recording, and result confirmation and owns the article’s main narrative. Luminous performed the G5000 comparison and prepared it as a supplemental GitHub report for the NullMoth maintainers. WorkBuddy assisted with public-source research, log and firmware-data organisation, draft test configurations, and editing, but did not access the hardware and cannot independently verify hands-on results.

Project names and configuration fields are referenced solely to explain compatibility research. Reuse or quotation should preserve the authors, title, original link, and limits above; external projects remain subject to their own licences and trademark rules.