Should the same hostid (0x00bab10c) be used on all zfsbootmenu systems?

[Eeemil]

I'm not entirely sure in which circumstances the hostid is used, either in Linux in general or zfsbootmenu specifically. But the installation docs seems to suggest to always set it to 0x00bab10c. From what I can understand 0x00bab10c is a magic number for a ZFS Uberblock, but the hostid is something entirely different, right?
From what I've read on hostid in general it ought to be unique to each host, which makes me curious to why zfsbootmenu would want to use the same ID for every host. And from what I've read on zfsbootmenu, I think that the hostid is used to identify systems and possibly that 0x00bab10c is a default value - not that every system is required to have the same value.

But to be honest, I don't know enough about hostid or zfsbootmenu to know what is correct. So my question is, would it be fine to just run dd if=/dev/urandom of=/etc/hostid bs=4 count=1 to generate a hostid?

[zdykstra]

For most (read desktop/laptop) usages of ZFS, there's no compelling argument to use a unique hostid per host. A unique value is useful in the event of multipathed SAS enclosures with two discrete head units attached to them. In that case, a unique hostid value helps protect against two systems trying to import the same pool concurrently.

We use 0x00bab10c as a default value internally in ZFSBootMenu and in our documentation so that when you see that value, you know it's the hostid. You can use any value that you like - though if you stick with our pre-built EFI images, it will require ZFSBootMenu to discover the hostid every boot so that it can cleanly import the pool. There's no problem with this, but it does add maybe 250ms to each boot if you care about that sort of thing. If you generate your own images, your local /etc/hostid value will be automatically added to it.

[Eeemil]

Thanks for the quick answer and clarification. Could the hostid not be used by the system in contexts other than zfsbootmenu though where using the same ID across multiple systems possible could cause unintended side effects? I'm thinking DRM stuff, fingerprinting etc.

[ahesford]

I'm not aware of much use for the host identifier beyond ZFS, and its use in OpenZFS has unequivocally been a burden for the majority of users. Countlessly many people have sought help in r/zfs and elsewhere because a pool senselessly failed to import when a host identifier didn't match what was recorded in a pool. If nobody remembers me for anything more consequential, at least let me be remembered for my contributions to the ZFSBootMenu import loop that eliminates this madness whenever possible.

In glibc, the host identifier is, when not explicitly specified in /etc/hostid, derived from the IPv4 address that is obtained by resolving the machine's hostname. This is far from globally unique and, as the manual page notes, can never be guaranteed to be unique. The original goal of being "unique among all UNIX systems in existence" has since been watered down to "unique among all UNIX systems you control, if you care". The musl C library doesn't even support host identifiers, returning zero for every call to gethostid.

If anything is fingerprinting your machine based on the host identifier, you'd probably do well to use a single global value rather than something that might identify you more specifically. As for DRM: the ease with which the host identifier can be customized means it almost certainly is not a part of any scheme to lock content to one machine.