Omarchy on MBP 2017 laptop?

[srdjanpavlovic]

I have MBP from 2017 (Intel i5, 8gb ram, 250gb ssd...)

Did someone try Omarchy on that model? I would like to use it instead of MacOS... if it is possible,
and all of MBP hardware is supported.

[iamobservable]

Unsure of that mbp version. I've tested this model, sounds similar.

MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
2.9 GHz Dual-Core Intel Core i5
8 GB 2133 MHz LPDDR3
250 GB SSD
Intel Iris Graphcis 550 1536 MB

The answer to your question is no not really. This is what is/isn't supported out of the box.

Omarchy installs just fine. You can boot into the machine with no additional issues. Omarchy automated install using the ISO overwrites and re-partitions the whole drive. This is NOT OPTIMAL, as the touchbar, videocam, and sound are only accessible via the iBridge (T1 chip device) and the iBridge reports as in recovery when you boot into Omarchy.

If you dual boot the operating system starting with macOS, then creating the necessary Linux partitions using archinstall, and finally manually installing Omarchy after arch is on the drive, it is possible to access the iBridge. Having the efi boot loader for Apple on the machine allows the hardware to be "turned on" so it can be used. Removing the Apple partitions from the drive does not allow the hardware to "turn on" correctly.

• Arch and Omarchy on the device
• Regular keyboard works via applespi kernel module driver

• Video camera does not work - drivers/configurations are available if you hunt online
• Touchbar does not work (thus no function or escape keys) - fun fact, escape is the same as " [" - drivers/configurations are available if you hunt online
• Sound does not work - drivers/configurations are available if you hunt online

You may have some luck talking with the people on the Omarchy Mac Discord. They are focused on T2 chip devices 2018+, and they have limited people using T1 chip devices 2016-2017, but you might ask around.

I'm working on a kernel module to support my device. I have the Touchbar working and am working on the sound. Stay tuned if you are interested.

[sa-dd]

Omarchy automated install using the ISO overwrites and re-partitions the whole drive. This is NOT OPTIMAL, as the touchbar, videocam, and sound are only accessible via the iBridge (T1 chip device) and the iBridge reports as in recovery when you boot into Omarchy.

Could this be the reason why the T1 chip doesn't show with lspci ?

[srdjanpavlovic]

Thank you very much for quick response. My model does not have a touch bar, it is MBP 2017 with 3 thuderbolt port version.

[iamobservable]

Sounds like a T2 variant. The discord I shared I. The last message likely will have people who can offer their experience with the device. Best of luck!

…

On Wed, Oct 15, 2025 at 07:28 Srđan Pavlović ***@***.***> wrote: Thank you very much for quick response. My model does not have a touch bar, it is MBP 2017 with 3 thuderbolt port version. — Reply to this email directly, view it on GitHub <#2457 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A5LKCLZUXLBBQH6J3I4BDPD3XY4YVAVCNFSM6AAAAACJGFNN7KVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINRYG4YDEMQ> . You are receiving this because you commented.Message ID: ***@***.***>

[srdjanpavlovic]

This MacBook Pro 2017 does not have a T2 chip — all security and SSD management are handled by the Intel platform controller instead.

[nohzafk]

Following up on this thread since it's where I started. All of it works now on a MacBookPro14,2 (13-inch 2017, Touch Bar) — Touch Bar, 5 GHz Wi-Fi, audio, webcam, suspend. Writeup and patched driver: https://github.com/nohzafk/omarchy-macbookpro-t1

@iamobservable was right that keeping macOS matters, and here is the mechanism. The T1 has no firmware in ROM. macOS writes it to the EFI System Partition at EFI/APPLE/EMBEDDEDOS/combined.memboot, and Apple's boot firmware loads it into the chip at every power-on. A full-disk install erases that partition, the T1 then comes up as 05ac:1281 (recovery) instead of 05ac:8600, and the Touch Bar, webcam, Touch ID and ambient light sensor are gone until macOS is reinstalled. That is also why those reports list the webcam as dead — it is a plain UVC device with no reason to fail, except a T1 with no firmware.

You don't need a manual archinstall for this. Omarchy's own Free space install preserves it. Shrink the APFS container from macOS first, then pick that option. It creates its own 2 GB ESP and leaves Apple's 300 MB one untouched:

nvme0n1p1   300M  vfat          <- Apple's ESP, T1 firmware, untouched
nvme0n1p2  102G   apfs          <- macOS, still bootable
nvme0n1p3    2G   vfat  /boot   <- Omarchy's own ESP
nvme0n1p4  129G   crypto_LUKS   <- Omarchy root

Touch Bar needed two driver bugs fixed (PR upstream), neither of them discussed anywhere. The second is why this looks impossible: hid-sensor-hub claims iBridge HID interface .0002 at boot, so appletb_probe() never finds a device. It fails with no error at all — the modules load, they bind, lsmod looks correct, dmesg is clean, and the strip stays dark. There is nothing to search for. Unbinding .0002 and rebinding it to apple-ibridge-hid is what lights it up.

Wi-Fi is worth a look even if you don't care about 5 GHz. brcmfmac loads no NVRAM for the BCM43602 — the tell is a 00:90:4c:* MAC, which is Broadcom's placeholder for "no board config loaded". That file also carries the TX power tables and RF calibration, so without it the adapter is not just 2.4 GHz-only, it is deaf. Supplying it took me from -74 dBm to -42 dBm at the same desk, 324 Mbit/s. Before the fix, scans saw one AP and scp kept failing; I had assumed distance.

Audio works via davidjo/snd_hda_macbookpro (DKMS), including on 14,2, which is currently marked unsupported on Dunedan's tracker.

Two corrections to Omarchy's Mac docs while I'm here:

1. The "disable Secure Boot in Startup Security Utility" step is impossible on a T1. Secure Boot arrived with the T2 — that pane does not exist. The 2017 Touch Bar models are T1 and appear in neither the T1 nor T2 list in the manual.
2. install/hardware/apple/fix-spi-keyboard.sh installs macbook12-spi-driver-dkms without linux-headers, so DKMS has no kernel build directory and silently produces nothing — empty /var/lib/dkms/, no build logs. fix-bcm43xx.sh in the same tree correctly installs headers. Nobody notices because applespi is mainline since 5.3, so the keyboard works anyway and only the Touch Bar and ALS are lost.

Also useful for anyone here: Omarchy never writes \EFI\BOOT\BOOTX64.EFI, so it never appears in Apple's Option-key boot picker even though it boots as the firmware default. Copying limine_x64.efi there fixes it. And kernel parameters need to go in /etc/limine-entry-tool.d/, not /boot/limine.conf, which is regenerated on any kernel change.

Caveat: one machine, MacBookPro14,2, kernel 7.1.8-arch1-3. Reports from other T1 models would be welcome — the fixes should apply to any MacBookPro13,* or 14,*.