Commit Graph

10 Commits

Author SHA1 Message Date
Julia Kreger
57149d9eb1 Check and mount boot volume for data extraction with nouuid
When building an image, say RHEL9, on a host installed with that
same image, you will be blocked from mounting the filesystems to
extract contents, as the host OS kernel will identify the duplicate
UUIDs and error accordingly.

This was previously fixed for the root filesystem, but not the boot
filesystem.

Change-Id: I63a34fba033ed1c459aeb9c201c8821fa38a36e9
2022-05-25 12:39:57 -07:00
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
Steve Baker
7de5bc6fa3 Handle btrfs root subvolume for fedora extract-image
This adds a check for the root device having filesystem type btrfs,
and when it is assume there is a subvolume called "root". This fixes
extract-image when using Fedora-Cloud-Base btrfs images.

This should be sufficient until there is another btrfs base image with
a different subvolume layout.

Change-Id: Ib18979090585ba92566e523951b521b9d902fcb7
2022-03-11 15:48:03 +13:00
Steve Baker
41c21e91db Revert "Revert "Detect boot and EFI partitions in extract-image""
This change is proposed again, avoiding lsblk features missing from
older distros:
- lsblk is avoided entirely for a whole-disk image with a single
  partition, which would be the majority of old image building jobs
- Field PARTTYPENAME not available on the lsblk in CentOS-8, instead
  rely on the GUID being correct for EFI partitions
- Argument --output-all not available on the lsblk in CentOS-7, this
  is just for logging debug, so can be removed

This reverts commit b06bac734c.

Change-Id: Ib0d4e7751fd968511fc7f672d524e58d1488ae11
2022-02-25 14:52:45 +13:00
Riccardo Pittau
b06bac734c Revert "Detect boot and EFI partitions in extract-image"
This reverts commit 0630b3cb69.

Reason for revert: breaks compatibility with CentOS Stream 8, lsblk does not have PARTTYPENAME until version 2.35 and CS8 has version 2.32.1 installed

Change-Id: I7fc0e76f0eeb8594d8a0d57629b2c67526b961ad
2022-02-24 13:42:50 +00:00
Steve Baker
0630b3cb69 Detect boot and EFI partitions in extract-image
RHEL-9 base images are whole-disk images with the /boot/efi partition
correctly set up for EFI Secure Boot. This doesn't work with
extract-image because it only mounts the root partition, leaving
/boot/efi empty even though grub2-efi & shim packages are "installed".

This change mounts discovered partitions to mnt/boot, mnt/boot/efi so
all content can be extracted from the image.

Partition detection is done by reading block device attributes and
matching on Boot Loader Specification[1] UIDs or labels as observed in
supported base images.

[1] https://systemd.io/BOOT_LOADER_SPECIFICATION/
Change-Id: I8487002a18ae6ca98609ab68d92ae9173a2b864f
2022-02-23 15:28:32 +13:00
Eduardo Santos
0f430664a2 Fix openSUSE images and bump them to 15.3
SUSE dropped OpenStack Cloud in 2019 [1], and as a result, some
OpenStack-related repositories were removed from openSUSE Download and
root filesystem images stopped being provided. This change deprecates
Leap releases before 15.3 and employs the extract-image script. It also
moves the extract-image script to the sysprep element, since now it's
also used by openSUSE-related elements.

Additionally, revert the "Remove opensuse related funtests" change [2]
so that the opensuse element is tested again and set the default Leap
release to 15.3.

[1] https://www.zdnet.com/article/suse-drops-openstacks/
[2] https://review.opendev.org/c/openstack/diskimage-builder/+/824002

Change-Id: I73d6323aa65cee69a55e54bc53ed682f096dfc89
2022-01-28 02:18:47 -03: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