MACHINE-ID(5)

๐Ÿ’– MACHINE-ID(5) ๐Ÿ’–

okay bestie, sit down, hydrate, because we're about to talk about the <hotpink>machine-id</hotpink> page from section 5 of the manual โ€” yes, the local machine ID configuration file. it's giving โœจ foundational โœจ and honestly? you need to know her.


๐ŸŒธ NAME ๐ŸŒธ

machine-id โ€” the local machine ID configuration file. that's it, that's the girl. ๐Ÿ’…


โœจ SYNOPSIS โœจ

/etc/machine-id

just one file. one single file. living her best life. ๐ŸŽ€


๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

so. the /etc/machine-id file contains the unique machine ID of the local system that gets set during installation or boot. it's literally that girl's social security number but for computers.

the machine ID is a single newline-terminated, hexadecimal, 32-character, lowercase ID. when you decode it from hexadecimal, that corresponds to a 16-byte/128-bit value. and no, this ID may not be all zeros โ€” that's not a vibe, don't do that. ๐Ÿ™ˆ

the machine ID is usually generated from a random source during system installation or first boot, and then it stays constant for all subsequent boots. periodt. but optionally, for stateless systems, it gets generated during runtime during early boot if necessary. flexible queen. ๐Ÿ’…

the machine ID may be set โ€” for example when network booting โ€” with the systemd.machine_id= kernel command line parameter, or by passing the option --machine-id= to systemd. an ID specified this way has higher priority and will be used instead of the ID stored in /etc/machine-id. so like, the override eats. ๐Ÿ”ฅ

the machine ID does not change based on local or network configuration, or when hardware is replaced. because of this, and because it's longer, it's a way more useful replacement for the gethostid(3) call that POSIX specifies. upgrade era. โญ

this machine ID adheres to the same format and logic as the D-Bus machine ID. they're twinning. ๐Ÿ‘ฏ

this ID uniquely identifies the host. it should be considered "confidential", and it must not be exposed in untrusted environments, in particular on the network. okay so if some application needs a stable unique identifier tied to the machine, the machine ID or any part of it must not be used directly. instead, the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. that way the ID will be properly unique, and derived in a constant way from the machine ID โ€” but there'll be no way to retrieve the original machine ID from the application-specific one. privacy queen behavior honestly. ๐Ÿซถ

the sd_id128_get_machine_app_specific(3) API provides an implementation of such an algorithm. use it, bestie. ๐Ÿ˜Œ


๐ŸŒˆ INITIALIZATION ๐ŸŒˆ

each machine should have a non-empty ID in normal operation. and each machine's ID should be unique. to achieve those objectives, /etc/machine-id can be initialized in a few different ways. choose your fighter. ๐ŸŽ€

  • for normal operating system installations, where a custom image is created for a specific machine, /etc/machine-id should be populated during installation.
  • systemd-machine-id-setup(1) may be used by installer tools to initialize the machine ID at install time โ€” but /etc/machine-id may also be written using any other means. no gatekeeping. โœจ
  • for operating system images which are created once and used on multiple machines โ€” for example for containers or in the cloud โ€” /etc/machine-id should be either missing or an empty file in the generic file system image. (the difference between those two options is described under "First Boot Semantics" below, so keep scrolling, babe.) an ID will be generated during boot and saved to this file if possible. having an empty file in place is recommended because it allows a temporary file to be bind-mounted over the real file, in case the image is used read-only and when /etc is mounted read-only in the early boot. also see Safely Building Images[1]. ๐Ÿ’–
  • systemd-firstboot(1) may be used to initialize /etc/machine-id on mounted (but not booted) system images.

so when a machine is booted with systemd(1), the ID of the machine will be established. here's the whole priority list, and it's giving โœจ main character energy โœจ:

  1. if systemd.machine_id= or --machine-id= options (see first section, you know the one) are specified, this value will be used.
  2. otherwise, the value in /etc/machine-id will be used.
  3. if this file is empty or missing, systemd will attempt to use:
    • the D-Bus machine ID from /var/lib/dbus/machine-id,
    • the value of the kernel command line option container_uuid,
    • the KVM DMI product_uuid or the devicetree vm,uuid (on KVM systems),
    • the Xen hypervisor uuid,
    • and finally a randomly generated UUID.

systemd.machine_id=firmware can be set to generate the machine ID from the firmware. cute. ๐Ÿงš

after the machine ID is established, systemd(1) will attempt to save it to /etc/machine-id. if this fails, it will attempt to bind-mount a temporary file over /etc/machine-id. and it is an error if the file system is read-only and does not contain a (possibly empty) /etc/machine-id file. so like... don't do that. ๐Ÿ˜ญ

systemd-machine-id-commit.service(8) will attempt to write the machine ID to the file system if /etc/machine-id or /etc/ are read-only during early boot but become writable later on. she waits, she commits, she slays. ๐Ÿ‘‘


๐ŸŽ€ FIRST BOOT SEMANTICS ๐ŸŽ€

/etc/machine-id is used to decide whether a boot is the first one. the rules are as follows, no cap:

  1. the kernel command argument systemd.condition_first_boot= may be used to override the autodetection logic, see kernel-command-line(7).
  2. otherwise, if /etc/machine-id does not exist, this is a first boot. during early boot, systemd will write "uninitialized\n" to this file and overmount a temporary file which contains the actual machine ID. later (after first-boot-complete.target has been reached), the real machine ID will be written to disk. glow up moment. โœจ
  3. if /etc/machine-id contains the string "uninitialized", a boot is also considered the first boot. the same mechanism as above applies.
  4. if /etc/machine-id exists and is empty, a boot is not considered the first boot. systemd will still bind-mount a file containing the actual machine-id over it and later try to commit it to disk (if /etc/ is writable). lowkey sneaky but valid. ๐Ÿ’…
  5. if /etc/machine-id already contains a valid machine-id, this is not a first boot. she's already been through it, she's established. ๐Ÿ’–

if according to the above rules a first boot is detected, units with ConditionFirstBoot=yes will be run, and systemd will perform additional initialization steps โ€” in particular, presetting units. ๐Ÿฆ‹


๐Ÿ’œ RELATION TO OSF UUIDS ๐Ÿ’œ

okay so real talk: the machine ID historically is not an OSF UUID as defined by RFC 4122[2], nor a Microsoft GUID. BUT โ€” starting with systemd v30, newly generated machine IDs do qualify as Variant 1 Version 4 UUIDs, as per RFC 4122. she evolved, bestie. โœจ

in order to maintain compatibility with existing installations, an application requiring a strictly RFC 4122 compliant UUID should decode the machine ID, and then (non-reversibly) apply the following operations to turn it into a valid RFC 4122 Variant 1 Version 4 UUID. with "id" being an unsigned character array:

/* Set UUID version to 4 --- truly random generation */
id[6] = (id[6] & 0x0F) | 0x40;
/* Set the UUID variant to DCE */
id[8] = (id[8] & 0x3F) | 0x80;

(this code is inspired by "generate_random_uuid()" of drivers/char/random.c from the Linux kernel sources. shoutout. ๐Ÿซก)


๐ŸŒŸ HISTORY ๐ŸŒŸ

the simple configuration file format of /etc/machine-id originates in the /var/lib/dbus/machine-id file introduced by D-Bus. in fact โ€” plot twist โ€” this latter file might be a symlink to /etc/machine-id. it's giving shared custody. ๐Ÿ˜ญ๐Ÿ’–


๐Ÿ”ฅ SEE ALSO ๐Ÿ”ฅ

go read them all, you're welcome. ๐Ÿ’…


๐Ÿ“Ž NOTES ๐Ÿ“Ž

  1. Safely Building Images https://systemd.io/BUILDING_IMAGES
  2. RFC 4122 https://tools.ietf.org/html/rfc4122

and that's the whole page, bestie!! ๐ŸŽ‰ this was systemd 262.1, page MACHINE-ID(5) โ€” no cap, she ate and left no crumbs. go forth and keep your machine ID confidential, hash responsibly, and never expose her to untrusted networks. mwah. ๐Ÿ’‹๐Ÿ’–๐ŸŽ€๐Ÿฆ‹โœจ

๐Ÿ“ฆ where this page comes from
  • arch rolling: systemd 262.1-1 ยท LGPL-2.1-or-later AND CC0-1.0 AND GPL-2.0-or-later AND MIT-0
  • ๐Ÿ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms