Sep 2026 Solo build: detection, fixes, packaging

Parrot OS on a Touch Bar MacBook Pro

A Python command-line tool that gets Parrot OS 7 working on 2016-2017 Touch Bar MacBook Pros: it reads the hardware, offers only the fixes that Mac needs, and can undo every one of them.

Python Linux Parrot OS systemd Debian packaging

Source

parrot-mbp2017 — sudo ./parrot-mbp2017 status

sudo ./parrot-mbp2017 status

mbp2017/fixes/

done
not set up
blocked

Click a fix to run remove on it, then click again to install it back.

sudo ./parrot-mbp2017

parrot-mbp2017 is a command-line tool I built to make Parrot OS 7 usable on 2016-2017 Touch Bar MacBook Pros. On these Macs a fresh install leaves Wi-Fi dropping, the 15-inch models waking to a black screen, the speakers silent, and the Touch Bar, Touch ID, camera and light sensor dead, because a separate T1 chip runs all four. The tool reads the hardware, shows which of nine fixes this Mac needs and where each one stands, applies only the ones selected, and records every change so each fix can be undone on its own. It is Python with the standard library only, and it packages the upstream projects that already solved the hard driver work instead of rewriting them.

Fixes

Models

6 supported · 1 tested

Tests

159

Dependencies

Python stdlib only

Stack

Python 3 unittest systemd udev NetworkManager DKMS libinput PAM Docker GitHub Actions ShellCheck

A laptop that half works

Parrot OS 7 installs on a 2016 or 2017 Touch Bar MacBook Pro, but a lot of the machine does not work properly afterwards. Wi-Fi drops and sometimes never reconnects, the 15-inch models come back from sleep to a black screen, the internal speakers are silent, a resting palm moves the cursor while typing, and the Touch Bar, Touch ID, FaceTime camera and ambient light sensor do nothing at all.

The fixes exist, but they are spread across upstream projects, kernel bug reports and community hardware research, and each one changes something different. I wanted one tool that applies them in the right order, says what each step does and why before it runs it, and can take any of them back out.

Core problem

Every fix touches something a working system depends on: kernel drivers, sleep modes, package holds, and the PAM stack that decides who can log in. On a laptop someone relies on, each change had to be explained before it ran and reversible after.

Detect the hardware, not the model name

The tool first reads the DMI vendor and product name and refuses to change anything unless the machine is an Apple Mac on its six-model list, with --force as the deliberate override. After that, no fix looks at the model name again. Each one is gated on the hardware it actually needs, so a two-port 13-inch Mac with no T1 simply gets fewer fixes offered.

The T1 check reads more than presence. USB product ID 8600 means the chip is running and 1281 means it is stuck in recovery with no firmware, and the USB configuration value tells t1bridge mode apart from the legacy Touch Bar mode. When the EFI partition cannot be read without root, the T1 data shows as unknown rather than missing.

Model gate: DMI sys_vendor and product_name; anything off the list needs --force
Per-fix gates: PCI IDs for the AMD GPU and Broadcom BCM43602, the ALSA codec ID for the Cirrus Logic CS8409, input names for the SPI keyboard, USB IDs for the T1
Read-only commands: status and detect work without root and have a --json form for bug reports

Every change recorded, every fix undoable

All filesystem access and every command go through one System class. It resolves paths under a root directory and runs commands through an injectable runner, which keeps --dry-run honest and lets the tests run against a fake Mac built in a temporary folder.

Every file a fix writes is recorded per fix in a manifest under /var/lib/parrot-mbp2017. If a file already existed with different content, its original bytes and mode are backed up before it is replaced, and remove puts them back. Edits to shared files, like the libinput quirks file, go in marked blocks so the rest of the file is left alone. Writes are atomic, and a damaged manifest stops all changes instead of throwing away the record of what was changed.

Removal runs in reverse order, so the fixes that depend on t1bridge come out before it does. A failed fix does not stop the independent ones after it, and Ctrl-C leaves everything done so far recorded.

Security decision

Two things are kept on purpose: remove t1-backup never deletes a T1 backup, it only says where the backups are, and remove t1bridge keeps the fingerprint enrollment data. Backups hold the Mac’s T1 identity, so they are written with private permissions. Touch ID for sudo is the one fix that is off by default, since it changes how an administrator signs in, and the password stays as a fallback.

Packaging what upstream already solved

The T1 stack comes from t1bridge, which talks to the chip for the Touch Bar, Touch ID, camera and light sensor but only ships Arch Linux packages. The repository builds five Debian packages from a pinned upstream tag and commit, in Docker when it is available and natively otherwise, then holds the matched fingerprint packages so a routine update cannot split them.

The speaker driver is cloned at a pinned commit, checked with git rev-parse before anything is built, and installed through DKMS so it rebuilds for new kernels. Online T1 firmware recovery through t1-revive is pinned the same way, and runs under systemd-inhibit so a lid close cannot interrupt it.

Tested on real hardware, honest about the rest

Everything was developed and checked on a 15-inch 2017 MacBookPro14,3 running Parrot OS 7.3 with KDE Plasma 6.3 on Wayland. The tool ran setup there, status reported every fix done, a second run changed nothing, and remove input followed by install input switched palm rejection off and back on.

Several fixes came out of failures found on that Mac. After one resume, the Wi-Fi chip made every later suspend fail, so the wifi fix now unloads its driver before sleep and loads it again after; with that in place, a 46-second timed sleep and a two-hour idle sleep both completed and Wi-Fi reconnected in about five seconds. The Touch Bar stayed blank after waking because t1bridge’s display driver parks the panel before sleep and nothing turns it back on, so t1-wake switches it back on and restarts the Touch ID key service within about a second of each wake.

Locking Wi-Fi to 2.4 GHz was tried and reverted, because routers that steer clients onto 5 GHz rejected it and NetworkManager then stopped trying. The docs also list what has not run on hardware through the tool yet, including the other five models, restore-t1 and fingerprint-login.

Result

On the tested Mac, Wi-Fi, s2idle sleep, the speakers, palm rejection, the Touch Bar, Touch ID, the FaceTime camera and the ambient light sensor all work. 159 tests run offline and unprivileged in CI on Python 3.11 and 3.13, with ShellCheck on the packaging and installed shell scripts.

The nine fixes

Applied in this order, and each one undone on its own with remove:

01 · t1-backup: Archives the T1 firmware and Touch ID data from the EFI partition, with SHA-256 checksums
02 · wifi: Keeps the BCM43602 on brcmfmac, turns off power saving, retries forever, and reloads the driver around sleep
03 · sleep: Switches 15-inch models to s2idle, keeps PCI devices out of D3cold, and stops the T1 waking the Mac
04 · audio: Builds the out-of-tree CS8409 speaker driver through DKMS from a pinned commit
05 · input: Turns on palm rejection for the SPI keyboard and stops the Touch Bar acting as a second trackpad
06 · t1bridge: Installs the Debian-built T1 drivers and services for the Touch Bar, Touch ID, camera and light sensor
07 · t1-wake: Relights the Touch Bar and restarts the Touch ID key service straight after waking
08 · desktop: Wires Touch Bar volume, media and brightness into KDE Plasma and lets a fingerprint unlock the lock screen
09 · fingerprint-login: Opt-in Touch ID for sudo and other password prompts, with the password kept as a fallback

Back to all work