My 2011 MacBook Air runs Fedora these days, and it has one lingering habit from its previous life: the famous Apple startup chime. Every boot, that unmistakable BONG at a volume that feels calibrated to wake the neighbours – especially when you’re booting the machine in the middle of a sleepless night. macOS had ways to turn it off, but macOS is long gone from this machine. So who’s playing the sound?
The chime isn’t coming from the OS
Here’s the first clue: the chime plays before Fedora loads. Before GRUB, even. It fires at power-on, which means the operating system never had anything to do with it. The sound is played by the Mac’s EFI firmware, and the volume it plays at is stored in NVRAM – the small chunk of non-volatile memory that survives reboots, reinstalls, and indeed complete OS transplants. That’s why wiping macOS and installing Fedora didn’t touch it: the setting doesn’t live on the disk at all.
The good news is that Linux can reach into NVRAM too, via efivarfs, mounted at /sys/firmware/efi/efivars. Every EFI variable appears there as a small file named VariableName-VendorGUID. The one we’re after is Apple’s SystemAudioVolume, under Apple’s vendor GUID 7c436110-ab2a-4bbb-a880-fe41995c9f82.
Reading the current value
Before changing anything, let’s see what’s in there:
sudo hexdump -C /sys/firmware/efi/efivars/SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82On my Air this returned five bytes: 07 00 00 00 40. The structure matters. The first four bytes are the variable’s attribute flags (0x00000007 = non-volatile, accessible at boot services and at runtime), and only the fifth byte is the actual payload: the chime volume. 0x40 is 64 in decimal – roughly half volume on a scale that runs from 0x00 to 0x7F. It certainly didn’t sound like half volume at 3am.
Note that value down. It’s your backup: if you ever want the chime back, that’s the byte to restore.
The twist: 64 is half volume, but 128 is silence
If you’ve ever silenced a Mac the old-school way, you may remember the incantation nvram SystemAudioVolume=%80 from the macOS terminal. Here’s the detail nobody tells you: 0x80 doesn’t mean “volume 128”. Bit 7 of this byte is a mute flag. The usable volume range only occupies the lower seven bits (0–127), and setting the top bit tells the firmware “muted, regardless of what the volume says”. So the classic forum advice works – but through a flag, not through some overflow trick. Two values will silence the chime: 0x00 (volume zero) and 0x80 (mute flag set). I went with 0x00.
Writing the new value
One hurdle first: the kernel marks efivars files immutable as a safety net. This dates back to an era when deleting the wrong EFI variables could genuinely brick certain laptops. Writing one well-documented Apple variable is perfectly safe, but the guard rail applies to everything, so we lift it for this one file before writing:
sudo chattr -i /sys/firmware/efi/efivars/SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82
printf '\x07\x00\x00\x00\x00' | sudo tee /sys/firmware/efi/efivars/SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82 > /dev/nullThe write must include the four attribute bytes followed by the new payload byte – that’s why we’re sending \x07\x00\x00\x00 plus \x00, not just a single zero. Run the hexdump again to confirm the fifth byte has flipped to 00, then reboot for the moment of truth.
In my case: complete, glorious silence. The backlight comes on, GRUB appears, Fedora boots – and not a peep from the speaker. No Btrfs snapshot needed beforehand either, by the way: this touches NVRAM only, not the filesystem, and it’s trivially reversible by writing your original volume byte back (in my case \x40).
Which Macs does this work on?
This recipe belongs to the Intel EFI era, roughly 2006–2017, and the variable name and GUID are consistent across the whole range. My 2011 MacBook Air and 2011 MacBook Pro are squarely in the sweet spot; anything from 2008 onwards is well-trodden territory (the very earliest 2006–2007 models predate some efivars conventions and can be crankier about writes). Outside that window, the picture changes: the 2018-onwards T2 machines ship with the chime disabled by default and re-enable it via a proper macOS toggle, so there’s nothing to fight. Apple Silicon Macs use a different variable entirely (StartupMute) with their own NVRAM handling, so this exact recipe doesn’t carry over.
If the chime comes back
On some Macs the firmware occasionally rewrites SystemAudioVolume, so a resurrected chime isn’t a sign you did anything wrong. The fix is simply running the same two lines again – or, belt and braces, dropping them into a small systemd oneshot unit that re-mutes the variable on every boot. So far my Air hasn’t needed it, and my sleepless-night boots are now as silent as the night itself.