Commit graph

4 commits

Author SHA1 Message Date
Steve Baker
147641fc3e Set machine-id to uninitialized to trigger first boot
According to the systemd documentation[1], if /etc/machine-id is empty
it will be populated with a unique value, but not in a way which
triggers an actual first boot event (running units with
ConditionFirstBoot=yes set)

This change writes "uninitialized" to /etc/machine-id to ensure that
systemd-firstboot.service actually runs, and other units can use
first-boot-complete.target as a dependency to trigger on first boot.

Since /var/lib/dbus/machine-id is sometimes a symlink to
/etc/machine-id, it is truncated before writing to /etc/machine-id.

On older versions of systemd before first boot semantics were
formalised, any non-uuid value will trigger a new machine-id to be
generated, so "uninitialized" also works.

[1] https://www.freedesktop.org/software/systemd/man/machine-id.html#First%20Boot%20Semantics

Change-Id: I77c35e51a3da2e8a6b5a2c80d033a159b303c9af
2022-04-21 09:39:42 +12:00
Ian Wienand
2d47d4157c Fix BLS based bootloader installation
This reverts I2701260d54cf6bc79f1ac765b512d99d799e8c43,
Idf2a471453c5490d927979fb97aa916418172153 and part of
Iecf7f7e4c992bb23437b6461cdd04cdca96aafa6 which added special flags to
update kernels via grubby.

These changes actually ended up reverting the behaviour on Fedora 35,
which is what led me to investigate what was going on more fully.

All distros still support setting GRUB_DEVICE in /etc/default/grub;
even the BLS based ones (i.e. everything !centos7).

The implementation *is* confusing -- in earlier distros each BLS entry
would refer to the variable $kernelopts; which grub2-mkconfig would
write into /boot/grub2/grubenv.  After commit [1] this was reverted,
and the kernel options are directly written into the BLS entry.

But the real problem is this bit from [2]

 get_sorted_bls()
 {
     if ! [ -d "${blsdir}" ] || ! [ -e /etc/machine-id ]; then
        return
     fi
     ...
     files=($(for bls in ${blsdir}/${machine_id}-*.conf; do
     ...
 }

i.e., to avoid overwriting BLS entries for other OS-boots (?),
grub2-mkconfig will only update those BLS entries that match the
current machine-id.

The problem for DIB is that we are clearing the machine-id early in
finalise.d/01-clear-machine-id, but then running the bootloader update
later in finalise.d/50-bootloader.

The result is that the bootloader entry generated when we installed
the kernel (which guessed at the root= device, etc.) is *not* updated.
Even more annoyingly, the gate doesn't pick this up -- because the
gate tests run on a DIB image that was booted with
"root=LABEL=cloudimg-rootfs" the kernel initially installed with
"install-kernel" (that we never updated) is actually correct.  But
this fails when built on a production host.

Thus we don't need any of the explicit grubby updates; these are
reverted here.  This moves the machine-id clearing to after the
bootloader setup, which allows grub2-mkconfig to setup the BLS entries
correctly.

[1] 4a742183a3
[2] https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0062-Add-BLS-support-to-grub-mkconfig.patch

Depends-On: https://review.opendev.org/c/zuul/nodepool/+/818705
Change-Id: Ia0e49980eb50eae29a5377d24ef0b31e4d78d346
2021-11-25 14:26:23 +11:00
Logan V
c7e907794c Ensure machine-id is not included in images
Two bugs are addressed.

1) The sysprep element was broken in that it only truncates
   /etc/machine-id, but not /var/lib/dbus/machine-id. systemd will
   not generate a new machine-id if /var/lib/dbus/machine-id is
   present[1], it will simply copy it to /etc/machine-id.

   We observed machine-ids being packaged in /var/lib/dbus/machine-id
   on several distros: Ubuntu Bionic, Fedora 29, Debian Stretch.

   CentOS 7 and Ubuntu Xenial do not contain packaged machine-id as
   far as I can tell.

   All test builds were performed using -minimal elements.

2) A second bug existed where debian-minimal did not run the sysprep
   element at all, so a stretch image I tested contained a populated
   /etc/machine-id AND a populated /var/lib/dbus/machine-id.

[1] https://www.freedesktop.org/software/systemd/man/machine-id.html#Initialization

Change-Id: Ibb28b6e90d966a845de38a2cd5a1e8babd2604bc
2019-09-20 03:17:50 +00:00
Dave Hill
6c2b1465cc Clear /etc/machine-id to avoid duplicate machine-ids
Deploying many nodes with the generated image shouldn't have the same
/etc/machine-id so clearing it and letting systemd generate a new
id upon first boot seems to be the best way to achieve this.

Change-Id: I73d0577d31464521b3989312fd9d982a1312a268
Closes-bug: 1707526
Closes-bug: 1672461
2017-08-06 13:56:58 -04:00