Add possibility to use disk LABEL to identify rootfs uuid for
Software RAID deployment
Change-Id: I77f36e70ddc539af0190db1c1abe0fb2c66f34b4
Story: 2008303
Task: 41188
By default, grub2-mkconfig scans everything to look for other
environments and then load those into the grub configuration.
It makes sense, but on newer versions of grub2 in distribution
images, os-prober is taking an exceptionally long time in some
cases where more than one storage device exists with other
filesystems.
As a result, of the os-prober execution by grub2-mkconfig, the
bootloader installation can completely time out and fail the
deployment. This is presently experienced with metalsmith on
centos8.
There are numerous sporatic reports of issues like this issue
where grub2-mkconfig hangs for some period of time, and this is
observable on Centos8.2 in our CI. While one report[0] mentions
this issue, Another bug [1] has the dialog that actually helps us
frame the context as to what we likely should do.
Also, fixes the unit testing so we actually test if we're running
with grub2. :\
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1744693
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1709682
Depends-On: https://review.opendev.org/#/c/748315
Change-Id: I14bf299afef3a1ddb2006fe5f182d7f0d249e734
We don't have a really working way to detect root UUID for whole
disk images at the moment, which results in an ignored traceback
every time install_bootloader is called with whole disk images in
UEFI mode. Avoid it by skipping GRUB2 if root UUID is unknown.
Change-Id: I84245538f59c664b72d1cafbca8d61be0978f489
When we added software raid support, we started calling bootloader
installation. As time went on, we ehnanced that code path for non
RAID cases in order to ensure that UEFI nvram was setup
for the instance to boot properly.
Somewhere in this process, we missed a possible failure case where
the iscsi client tgtadm may return failures. Obviously, the correct
path is to not call iscsi teardown if we don't need to.
Since it was always semi-opportunistic teardown, we can't blindly
catch any error, and if we started iSCSI and failed to tear the
connection down, we might want to still fail, so this change
moves the logic over to use a flag on the agent object which
one extension to set the flag and the other to read it and take
action based upon that.
Change-Id: Id3b1ae5e59282f4109f6246d5614d44c93aefa7c
Story: 2007937
Task: 40395
Shuffle some functions around and reduce size of _is_bootloader_loaded
moving logic out to a new function.
Change-Id: I9c10bf05186dcebb37f175d61bf4ac9ff86b6510
In order to ensure grub2 finds all files it needs, mount all
vfat partitions specified in the deployed image.
Story: #2007618
Task: #39629
Change-Id: Ie5b6e0abc3f266409562f9ecb26538126b667056
It does not return anything, so it makes no point for it to be
synchronous. Ironic always calls it with wait=True, so there is
no problem with backward compatibility either.
Change-Id: I44fec2e0cb54486328ce71263613d8592e384870
The proposed changes concern two steps:
First, when creating the RAID configuration, have a GPT partition
table type (this is not necessary, but more natural with UEFI).
Also, leave some space, either for the EFI partitions or the BIOS
boot partitions, outside the Software RAID.
Secondly, when installing the bootloader, make sure the correct
boot partitions are created or relocated.
Change-Id: Icf0a76b0de89e7a8494363ec91b2f1afda4faa3b
Story: #2006379
Task: #37635
If an md device is restarted, there is a chance, depending
on the OS, that the partition may not be found upon start
of the md device.
Instead, we should always rescan after re-assembling the raid
device.
Story: 2007275
Task: 38712
Change-Id: I92bac20812940e04381a54ef2905ef5f6e293813
Somewhat common are dual boot images that have both a MBR loader
and the contents required for a UEFI boot, as largely the pointer
to where to begin reading the rest of the boot loader occurs in
the first few hundred bytes on disk which redirects the disk to
begin reading from a known address.
This goes sideways on UEFI machines where this method of booting
is not recognized nor supported. Thus we need to return false when
we encounter this state.
Change-Id: I8c0b42bb71b9e26ed7fec8894e21ce7fc06b94a1
Story: 2007455
Task: 39133
With the fix to the uefi code path so secure boot works properly
and is not accidently stomped on, we forgot to rescan the device
and force the partition table to update, which is vital for iscsi
based deploys.
Depends-On: https://review.opendev.org/706960
Change-Id: Ic2f338be075e93a2ce8c76c706d37db9bf8792ea
Story: 2007276
Task: 38713
This patch changes the workflow for whole disk images when using uefi.
If we can identify the bootloader and it's valid we can update using
efibootmgr since grub2-install have problems specially on secure boot
mode.
We also updated the regex to search for the uefi partition on the disk,
since in some cases the parted command output can be without the FS
for the partition with esp Flag.
Change-Id: I7167e71e5d2352a045565289b200e5530d0ba11d
Story: #2006847
Task: #37435
Rather than assuming that the root fs is in the first partition
of the deployed image, use the UUID passed from the conductor.
Change-Id: Ie2299372e94386902e0a8be0597250ec52e1fec9
Story: #2006649
Task: #36887
Depends-on: https://review.opendev.org/686580
Fixes regression in commit 9f8fa2853af00045118ccd44180e7053e6d027af:
utils.execute returns unicode by default, but this data is binary.
Change-Id: I5b54c1f6cfac5fff672245c523b9fb647478edbd
Lets not do silly things and if the disk looks bootable,
and we're not trying to do UEFI, then let us assume the
proper thing will occur upon power-up.
Looks at the boot sector data and if an executable is
found in the first 218 bytes, then it bypasses loading
a boot loader.
Also adds a dependency on the "file" linux distribution
package.
Change-Id: I11bc26670a08ee13174a43d7cd0f1ab9c1bd35cf
Story: 2006474
Task: 36410
When deploying an image to a software raid array, it is currently
required that the deployed image assembles the md arrays automatically
so that the rootfs can be mounted. In order to remove this
requirement/limitation on the deployed image we can add rd.md.uuid to
the kernel command line with the raid array's uuid.
Story: 2006648
Task: 36884
Change-Id: I42cb198753ecd84b7eaef6b5aa7c2064535bfe0e
Falls back to attempt to use findfs to locate
a UUID or PARTUUID match as opposed to trying to
list and enumerate through lsblk output.
Can confirm that tinycore 8.x's findfs binary works
expected.
Story: 2006724
Task: 37141
Change-Id: I4d488e4a1ab680eb1353b158c3339cb30b056ada
The deployment on top of a software RAID goes to the first partition
of the md device. Raise an exception if that partition does not exist.
Follow-up to Ieb2c95ff130b5cc1e643fcde500066d9458ddbec
Change-Id: I2b4c835d57d3888e3325aee40e8319ef8683cd27
This patch proposes to extend the IPA to be able to deploy on
software RAID devices. The IPA needs to be able to detect an
md device, find the underlying holder disks and configure grub
on them.
Change-Id: Ieb2c95ff130b5cc1e643fcde500066d9458ddbec
Story: #2004581
Task: #29102
grub-mkconfig runs a lvs command that attempts to access /run/lvm
once for each block device, currently it times out after 10 seconds
for each device and moves on. Multiple 10 second delays become
a problem (causing IPA API timeouts) when multiple block devices
are present. Bind mounting in /run avoids the delay and the
timeouts.
Task: 30616
Story: 2005507
Change-Id: Iae8b7808a35bff121f64971aadd4bd36b5f5bb71
Installs the grub bootloader to the PreP Boot partition when the
prep_boot_partition_uuid is provided. This is required when
booting a partition image locally on ppc64* systems.
This change also passes the cpu_arch along to work_on_disk so
that the PReP partition is created when partitioning disks for
local boot on ppc64* systems,
Change-Id: I70667d43af962b357e6eeccba258f4fa5a91a09e
Depends-On: I2bc9f13ec605de7b7b96d96a1a4edebee0af76dc
Story: #1749057
Task: #22999
If mounting the root partition fails for some reason, we try to unmount
the EFI partition, which is not mounted at this point. This results in
a new exception hiding the real failure. This change fixes it.
Change-Id: I0ec636a361eda71b4149e4a7ba1538a9bbf6ec34
Closes-Bug: #1732932
there is no guarantee that 'bash' is present in a user's image,
while 'sh' as system shell must be there.
As we do not use any bash-specific syntax (just starting commands in a
subshell) when installing the bootloader from chroot-ed user image,
let's be more supportive and use 'sh' instead of 'bash' for that.
Change-Id: I1fb82068b9c55da35166d8d2ecf9f0ba41356adb
Closes-Bug: #1657096
The following files added utf-8 encoding but never used. So we can
removes them at all.
ironic_python_agent/extensions/image.py
ironic_python_agent/extensions/iscsi.py
ironic_python_agent/tests/unit/extensions/test_image.py
ironic_python_agent/tests/unit/extensions/test_iscsi.py
Change-Id: Ifc98faf025ee81f885ea58d9203037c6357ea7f2
Use hacking 0.12.0
Use the new checks that are available:
[H106] Don’t put vim configuration in source files.
[H203] Use assertIs(Not)None to check for None.
[H904] Delay string interpolations at logging calls.
Fix code so tests pass.
Change-Id: If22ad272c332f30624ce10861408d377908b152b
Depends-On: I2aa44b62f900d4dfd67701b01eadd0523fbfaf07
In systems where the nvram may have been reset, add
\EFI\BOOT\BOOTx64.EFI to the EFI system partition so that
the image continues to boot. This will be particularly useful
if the NVRAM wasn't written correctly or if the baremetal
server is be simulated on virt and the NVRAM was been reset
on start (as is the case in libvirt).
Change-Id: I5005ae02c283cdc01540ea46c341a7b0bf9d4c42
Closes-Bug: #1632637
This patch updates the _install_grub2 function in image.py
so that we use 'mount -t sysfs' instead of bind mounting
the hosts /sys into the chroot.
This resolves issues which can occur with unmounting
the chroot mounts where 'target is busy' errors
may occur when you are debugging things with a serial
console.
Change-Id: I5c9a6546d048cbf54695329d9744fda55127bd30
Closes-bug: #1503385
