In order to make sure we have the correct time early, e.g. by the time we create a TLS certificate, this patch proposes to force an immediate NTP update when using chronyd. While the previous approach uses the passed NTP server as well, the update may happen only after chronyd has performed measurements (which may be too late). Story: #2009058 Task: #42843 Change-Id: I6edafe8edeb8549f324959e7a1ec175c3049a515 (cherry picked from commit 5531d5cee744f90ff24231a9ef467282b254adc2)
The IPA sends heartbeats to the conductor periodically and when requested, e.g. at the end of asynchronous commands. In order to avoid to send such notifications in too quick succession, e.g. when two asynchronous commands finish at the same time or when the periodic heartbeat was just sent right before a command ended, this patch proposes to coalesce heartbeats which are close together timewise and send only one for all of them in a time interval of 5 seconds. Co-Authored-By: Arne Wiebalck <arne.wiebalck@cern.ch> Story: #2008983 Task: 42633 Change-Id: Idfbce44065e1e5a8b730b94741b2604c51f0ab14 (cherry picked from commit b605943796c24a174f0709b84170e0c6de7f4238)
Check if the ESP is already mounted before attempting to mount it for the bootloader installation. Change-Id: Ifd738b2c5663f1a211d7e13b5ba386be631d8db1 (cherry picked from commit 27568204aeb7f063bf236ad7f2f8043db627baa9)
It's not uncommon that some commands fail when collecting logs. We already log all failures in utils.execute, no need to duplicate them with a non-fatal ERROR logging. Change-Id: If151b3a3be979bd2b3ce01030e5d6242ad74eaa3 (cherry picked from commit 2fcf35e56d578d98d77ffc97b6441f83548d7704)
Adds support to identify and utilize a CSV file to signal which bootloader to utilize, and set it when the OS is running as opposed to when EFI is running. This works around EFI loader potentially crashing some vendors hardware types when entry stored in the image does not match the EFI loader record which was utilzied to boot. Grub2+shim specifically specifically needs the CSV file name and entry label to match what the system was booted with in order to prevent the machine from potentially crashing. See https://storyboard.openstack.org/#!/story/2008962 and https://bugzilla.redhat.com/show_bug.cgi?id=1966129#c37 for more information. Change-Id: Ibf1ef4fe0764c0a6f1a39cb7eebc23ecc0ee177d Story: 2008962 Task: 42598 Co-Authored-By: Bob Fournier <bfournie@redhat.com> (cherry picked from commit 2fab70c36ba40a345a9dd01aeb5019681e567aa5)
To make this function useful for purposes other than efibootmgr entries, this change moves the path manipulation to _run_efibootmgr. This change also adds boot*.efi entries to BOOTLOADERS_EFI so that it includes every entry in the UEFI Spec 2.9[1] Table 3-2 UEFI Image Types. [1] https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf Story: 2008923 Task: 42521 Change-Id: Ibe02786609aa0de65115897d8f4a9b4f36c8aed2 (cherry picked from commit 10d18c41136cc645ee99d41acfb6031b9158e1fb)
qemu-img attempts to launch multiple threads by default *and* attempts to have multiple memory allocation arenas to operate from. While multithreading can be good for performance, this pattern and the memory footprint for process launch and dependencies can turn the memory footprint for a cirros image conversion (16MB) into 1.2GB of memory being asked for by the qemu-img tool. In order to limit this impact, as the default number of arenas is governed by the number of CPUs times the number 8, it seems reasonable to lower this to a more reasonable number which also helps keep our possible memory footprint from being exceeded. NOTE: This change is largely different than the original change as an intermediate change converted write_image.sh to python. As it is unlikely for us to backport the intermediate change, it is logical for us to just modify the original script. Otherwise the release note is ultimately what is backported for release note tooling continutity. Change-Id: I71a28ec59ec31c691205eb34d9fcab63a2ccb682 Story: 2008928 Task: 42528 (cherry picked from commit 9e4c7052a2fd9aac03858db696bf1ea9487f15e6)
The _manage_uefi code has a check where it attempts to just identify the precise partition number of the device, in order for configuration to be parsed and passed. However, the same code did not handle the existence of a `p1` partition instead of just a partition #1. This is because the device naming format is different with NVMe and Software RAID. Likely, this wasn't an issue with software raid due to how complex the code interaction is, but the docs also indicate to use only whole disk images in that case. This patch was pulled down my one RH's professional services folks who has confirmed it does indeed fix the issue at hand. This is noted as a public comment on the Red Hat bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=1954096 Story: 2008881 Task: 42426 Related: rhbz#1954096 Change-Id: Ie3bd49add9a57fabbcdcbae4b73309066b620d02 (cherry picked from commit fe825fa97ed1f3c9fa8b1461b63ab133fec20b72)