SYSTEMD-....SERVICE(8)

💖 SYSTEMD-....SERVICE(8) — bestie edition 💖

okay so this is the manual for systemd-boot-system-token.service, straight out of the systemd-boot-system-token.service corner of your system. buckle up, we're talking EFI variables and ✨entropy✨.

---

🌸 NAME 🌸

systemd-boot-system-token.service — generate an initial boot loader system token and a random seed 🎀

---

✨ SYNOPSIS ✨

systemd-boot-system-token.service

---

🦋 DESCRIPTION 🦋

okay so systemd-boot-system-token.service is a system service, and it does two little jobs automatically, no cap:

• it generates a 'system token' and stores it in an EFI variable in the system's NVRAM 🧠
• it generates a random seed and stores that on the EFI System Partition (ESP) on disk 💾

then your boot loader can take those two randomized data fields and combine them by cryptographic hashing, and hand the result off to the OS it boots as the initialization seed for its entropy pool. iconic behavior, fr fr.

the random seed stored in the ESP gets refreshed on every reboot, which is the whole point — it ensures multiple subsequent boots will each boot with a different seed. slay. meanwhile the 'system token' is generated randomly once, and then it lives persistently in the system's EFI variable storage. it's giving "one and done." 💅

systemd-boot-system-token.service invokes the bootctl random-seed command — that's the one that updates the random seed in the ESP and initializes the 'system token' if it isn't initialized yet. and here's the thing, the service is conditionalized, so it only actually runs when all of these apply:

• a boot loader is in use that implements the Boot Loader Interface[1] — that's the thing that defines the whole 'system token' concept in the first place 🥾
• either a 'system token' was not set yet, or the boot loader has not passed the OS a random seed yet (and thus most likely has been missing the random seed file in the ESP) 😭
• the system is not running in a VM environment. this case is explicitly excluded, and bestie, there's a real reason: on VM environments the ESP backing storage and the EFI variable storage are typically not physically separated, so booting the same OS image in multiple instances would replicate both of them — which means reusing the same random seed and 'system token' among all the instances, and that completely defeats the purpose 💀

note: it's still totally possible to use boot loader random seed provisioning in this mode, but the automatic logic implemented by this service has no effect then. so instead you, the user, have to manually invoke bootctl random-seed — while acknowledging these restrictions, like a responsible main character 🫶

for further details, go check out bootctl(1), specifically regarding the command this service invokes. iykyk 👑

---

👀 SEE ALSO 👀

systemd(1), bootctl(1), systemd-boot(7)

---

📝 NOTES 📝

1. Boot Loader Interface — https://systemd.io/BOOT_LOADER_INTERFACE

---

and that's the whole vibe 💜 this page came to you courtesy of systemd 252, filed under the manual name SYSTEMD-....SERVICE(8). go forth and seed your entropy pool responsibly, bestie 🌈⭐💖