Open
Description
Mac and installed build
- Mac mini (M4, 2024),
apple,j773g/apple,t8132, 10-core GPU, 10 Gb Ethernet. - Not a released Aurora tag. It's a local build of
techmore/linux-auroram4/j773g-cpufreq-sensors-v2(7af858e):integration/aurora4fdd0fc plus the J773g boot and cpufreq/sensors series.uname -r:7.2.11-14-1-aurj773g.- It's built from the
omacom/omarchy-pkgslinux-auroraconfig, with the release renamed soupdate-m1n1never picks its DTBs. Installed by hand, not through pacman.
- Distribution: GravityLinux/Omarchy install (
gravity-m47.1.13 release 20 remains the default entry). - Bootloader: m1n1-gravity 1.6.1 → U-Boot → Limine. The stage-2 DTB is the Aurora
t8132-j773g.dtbfrom that build.
Both firmware versions and provisioning
asahi,os-fw-version: 26.6.2
asahi,system-fw-version: unknown
(Read from /proc/device-tree/chosen under Gravity on 2026-11-03, m1n1-gravity 1.6.1. The same m1n1 was used for the Aurora attempt. m1n1 reports the system firmware version as unknown.)
Actions and results
| Feature / action | Result | Details |
|---|---|---|
| Gravity 7.1.13 kernel on the Aurora DTB: boot | pass ×2, then fail | Two warm boots passed every check below. The third warm reboot hung with a black screen; it recovered after a power-cycle. This looks like the same intermittent hang seen on 2026-11-01 with a different stage-2 DT change. |
| ↳ NVMe, Ethernet, Wi-Fi/BT, SMC fan/sensors, cpufreq | pass (on the 2 good boots) | |
| Aurora kernel on the Aurora DTB: boot | fail | One attempt, 2026-11-02 23:53 UTC, a warm reboot from Gravity with Aurora as the default Limine entry. The kernel was a UKI built with mkinitcpio using Gravity's hooks, with Gravity's cmdline minus quiet (loglevel=6). The Mac never answered on the network, and the display provided no usable output. Each power-cycle after that booted the same entry and failed the same way. The boot left no persistent journal entry and nothing in pstore; those absences do not establish whether the kernel started or the root filesystem mounted. Recovered from macOS by restoring the stage-2 m1n1 and the Limine config. |
| NVMe root (NVMMU window) | not tested | The Aurora kernel did not boot. |
| Ethernet (AQC113) | not tested | The Aurora kernel did not boot. |
| Wi-Fi association / Bluetooth pairing | not tested | The Aurora kernel did not boot. |
| SMC: power button, reboot, poweroff, RTC | not tested | The Aurora kernel did not boot. |
| SMC fan RPM and sensors | not tested | The Aurora kernel did not boot. |
| cpufreq E/P OPPs under load | not tested | The Aurora kernel did not boot. |
| HDMI | not tested | The Aurora kernel did not boot. This tree has no T8132 DCP, so at best it would have been the boot framebuffer only. |
| USB-C, audio, GPU, PMP | not tested | No T8132 support in this tree. |
Graphics and session details
Not reached: the Aurora kernel did not boot. Under Gravity on the Aurora DTB (the two good boots), the session was the normal Omarchy session on the Gravity stack.
Relevant logs and related reports
no console capture: no journal entry for the boot, pstore empty, no photo of the screen
Related: #125 (j616s, M4 Pro), #200 and #248 (T8132 MacBook Air). The DT for these results is the J773g boot series, now #332 (v3: rebased, plus a ramoops region, a T8132 apple,pcie binding fix and Wi-Fi port power via pwren-gpios; built and dtbs_check clean, not booted).
Untested features and limitations
- USB-C/Thunderbolt, DCP/HDMI modesetting, audio, GPU and PMP are untested: this tree has no T8132 support for them.
- Suspend was not tested.
- The intermittent hang is not root-caused; there's no serial console capture.
- The Aurora-kernel failure is not root-caused either. On this Mac the Limine menu was not visible on the attached display (only Apple's startup picker was), so the entry could not be switched at boot. The next attempt needs early output: a photo of the screen,
earlycon, or an m1n1 proxy load (chainloadorlinux.py) that changes no boot files. - The tree was
integration/aurora4fdd0fc with v2 of that series. v3 ([WIP] Apple M4 (T8132) Mac mini (J773g): boot from the SSD with Ethernet, Wi-Fi/Bluetooth and the SMC #332) is rebased onto 2a76ae3 and builds cleanly; it has not been booted yet. Retests will start the kernel by kexec from the running system, so no boot files change.
🤖 Generated with Claude Code
Metadata
Metadata
Assignees
Labels
No labels
Activity