BOOTC-USR-OVERLAY(8)

πŸ’– BOOTC-USR-OVERLAY πŸ’–

okay bestie, welcome to the bootc-usr-overlay(8) page, straight out of your System Manager's Manual 🫢 this is the one that yeets a whole temp overlay onto /usr and then forgets it ever happened.


✨ NAME ✨

bootc-usr-overlay β€” drops a transient overlayfs on /usr that gets thrown away the moment you reboot πŸ¦‹


✨ SYNOPSIS ✨

bootc usr-overlay [OPTIONS...]

✨ DESCRIPTION ✨

So what this does is slap a transient overlayfs on top of /usr, and no cap, it's getting discarded on reboot. Gone. Poof. πŸ’…

And it's read/write by default, just so you know.


🌸 USE CASES 🌸

the classic move here? you wanna run tracing/debugging tools β€” think strace β€” and they're just... not in the base image 😭. Not a vibe.

That's where a system package manager like apt or dnf comes in: it can apply changes into this transient overlay, and everything it does gets discarded on reboot. main character energy for your debugging session, zero permanent consequences ✨


🧚 STORAGE AND MEMORY REQUIREMENTS 🧚

okay this part is important so pay attention bestie πŸ‘‘

the transient overlay is backed by a tmpfs</> filesystem, which means every single thing you write into the overlay (yes, including all those packages you installed) is living in system memory (RAM), not on persistent disk. it's giving "temporary" fr fr.

By default the kernel sizes this tmpfs at 50% of physical RAM.

So on systems with limited memory, installing big packages into the overlay can straight up exhaust your available RAM and hit you with ENOSPC β€” that's "No space left on device" πŸ’€. And here's the tea: there is currently no pre-flight space check and no early warning before the tmpfs is full. it just fills up and then it's over.

Keep this in mind when you're doing transient overlays in memory-constrained environments like CI runners or tiny virtual machines πŸ™ˆ. And if the combined size of the packages you're installing is approaching half of the system's RAM? consider increasing the VM's memory allocation instead. like, actually. do that.


🌈 /ETC AND /VAR 🌈

so here's the plot twist 😭 β€” this command has no effect on /etc and /var. changes written there will persist. and it's super common for package installations to modify these directories. so yeah. those ones stay. no take-backs.


πŸ’œ UNMOUNTING πŸ’œ

almost always, some system process is gonna be holding a reference to that open mount point, so it just won't let go 😀.

You can however invoke:

umount -l /usr

to perform a "lazy unmount". iconic workaround honestly.


πŸ’… OPTIONS πŸ’…

  • --read-only β€” mount the overlayfs as read-only. and a read-only overlayfs is genuinely useful, because it may be remounted as read/write in a private mount namespace and written to while the mount point stays read-only to the rest of the system. sneaky? yes. useful? also yes. πŸŽ€

⭐ VERSION ⭐

v1.17.1


and that's the whole page, bestie πŸ’– you now know everything this manual page knows, no gatekeeping.

this has been bootc-usr-overlay(8) from the System Manager's Manual, version v1.17.1 β€” go forth and overlay responsibly, mwah 🫢✨

πŸ“¦ where this page comes from
  • fedora 43: bootc 1.17.1-1.fc43 Β· Apache-2.0 AND BSD-3-Clause AND MIT AND (Apache-2.0 OR BSL-1.0) AND (Apache-2.0 OR MIT) AND (Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT) AND (Unlicense OR MIT)
  • fedora 44: bootc 1.17.1-1.fc44 Β· Apache-2.0 AND BSD-3-Clause AND MIT AND (Apache-2.0 OR BSL-1.0) AND (Apache-2.0 OR MIT) AND (Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT) AND (Unlicense OR MIT)
  • πŸ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms