This changes the start-ostree command to:
compose start-ostree [--size XXXX] [--parent PARENT] [--ref REF] <BLUEPRINT> <TYPE> [<IMAGE-NAME> <PROFILE.TOML>]
Both of them are optional, and if missing a "" is passed to
osbuild-composer. Also adds more tests for all the various possible
options and removes the provider and profile arguments.
osbuild-composer doesn't remove cancelled composes and even if we
wait for the cancellation to take place the UUID is still there
and `compose info` returns an exit code of 0 instead of 1
- avoids having to modify them in the first place so less changes
to the SUT
- will help with transition to osbuild-composer backend
- each test which needs a blueprint either declares it on its own
(some already do this) or may use a shared blueprints from the
tests lib dir
- alibaba - will be added later
- google - will be added later, low priority b/c
GCE doesn't fully support RHEL8
- live-iso - not supported for now
- ext4 & partitioned disk - removed from osbuild-composer
the image building functionality is now tested by the
osbuild-composer test suite. We weren't successfull at making this
test suite work with the 2 backends so decided to disabled these
scenarios instead. In the future they will likely be deleted.
Creating /proc/modules just quiets one dracut warning, it doesn't
actually effect the initrd that is created.
Now that mock is being run with netsharedpath set to exclude /proc is
causes problems for running lorax inside a mock, so just remove this to
prevent a crash when it doesn't exist.
Related: rhbz#1848201
If the original ISO contains both `efiboot.img` and `macboot.img`,
the current `xorrisofs` invocation does not configure `efiboot.img`
to be bootable, only `macboot.img`.
This fix uses `>=` to compare `efimode` against `EFIBOOT`, since
`MACBOOT` implies `EFIBOOT` as well.
This is similar to the logic for `mkisofs`.
Fixes#1046.
Generated image confirmed to work, when comparing the reports:
`xorriso -indev $PATH_TO_ISO -report_el_torito cmd`
```
❯ diff -u ~/xorriso-report-{orig,new}.log
--- /home/michel/xorriso-report-orig.log 2020-07-15 20:01:01.405289018 -0700
+++ /home/michel/xorriso-report-new.log 2020-07-15 20:01:19.183555423 -0700
@@ -1,6 +1,6 @@
--volid 'Fedora-S-dvd-x86_64-32'
--volume_date uuid '2020042219432600'
--boot_image isolinux system_area=--interval:imported_iso:0s-15s:zero_mbrpt,zero_gpt:'/home/michel/Downloads/Fedora-Server-netinst-x86_64-32-1.6.iso'
+-volid 'Fedora-32-btrfs'
+-volume_date uuid '2020071602410900'
+-boot_image isolinux system_area=--interval:imported_iso:0s-15s:zero_mbrpt,zero_gpt:'/home/michel/src/github/michel-slm/luks-kickstarts/iso/Fedora-32-WS-20200715-3.iso'
-boot_image any partition_cyl_align=on
-boot_image any partition_offset=0
-boot_image any partition_hd_cyl=64
@@ -14,12 +14,6 @@
-boot_image any load_size=2048
-boot_image any boot_info_table=on
-boot_image any next
--boot_image any efi_path='/images/efiboot.img'
--boot_image any platform_id=0xef
--boot_image any emul_type=no_emulation
--boot_image any load_size=11462656
--boot_image isolinux partition_entry=gpt_basdat
--boot_image any next
-boot_image any efi_path='/images/macboot.img'
-boot_image any platform_id=0xef
-boot_image any emul_type=no_emulation
```
```
❯ diff -u ~/xorriso-report-{orig,new5}.log
--- /home/michel/xorriso-report-orig.log 2020-07-15 20:01:01.405289018 -0700
+++ /home/michel/xorriso-report-new5.log 2020-07-15 20:30:27.571644770 -0700
@@ -1,6 +1,6 @@
--volid 'Fedora-S-dvd-x86_64-32'
--volume_date uuid '2020042219432600'
--boot_image isolinux system_area=--interval:imported_iso:0s-15s:zero_mbrpt,zero_gpt:'/home/michel/Downloads/Fedora-Server-netinst-x86_64-32-1.6.iso'
+-volid 'Fedora-32-btrfs'
+-volume_date uuid '2020071603283100'
+-boot_image isolinux system_area=--interval:imported_iso:0s-15s:zero_mbrpt,zero_gpt:'./iso/Fedora-32-WS-20200715-5.iso'
-boot_image any partition_cyl_align=on
-boot_image any partition_offset=0
-boot_image any partition_hd_cyl=64
@@ -17,7 +17,7 @@
-boot_image any efi_path='/images/efiboot.img'
-boot_image any platform_id=0xef
-boot_image any emul_type=no_emulation
--boot_image any load_size=11462656
+-boot_image any load_size=11460608
-boot_image isolinux partition_entry=gpt_basdat
-boot_image any next
-boot_image any efi_path='/images/macboot.img'
```
Signed-off-by: Michel Alexandre Salim <michel@michel-slm.name>
Fails on Fedora 32 and we are going to decommission this test
very soon, leaving only composer-cli related tests here. All image
building and verification tasks are already in the osbuild-composer
test suite!
urllib3 has a retry system that send the request again when the
connection fails, times out, is redircted, etc. This turns off retries,
which aren't very useful anyway.
This is used to start an ostree build, it is only supported on
ostree-composer, and requires the ostree ref and parent. It may also
include --size and optionally be uploaded.
osbuild-composer can support user specified image sizes, this adds an
optional argument, after start, to specify the size in MiB. eg.
composer-cli compose start --size 2048 example-http-server qcow2
This only works when the backend is not 'lorax-composer', when it is the
user will get a warning that it will be ignored.
At least in our CI, the default place to store VM runtime overlays
(testvm.get_temp_dir()) points to a tmpfs file, so that tests can put VM
overlays into RAM and are not affected by slow I/O. But that doesn't
work for composer, as it tends to produce huge overlays due to real-life
OS composed trees.
Use /var/tmp/ instead, which is meant for large files.
Also simplify the VirtMachine invocation -- if `identity_file` is None,
that's fine -- it's the default value of that argument anyway.
This reverts commit 6025da1421.
It ends up that using the install.img with qemu and PXE and fips=1 is a
common use case. Without vmlinuz in the install.img rootfs it has
nothing to run the check against.
Related: rhbz#1782737
Seems petitboot can't properly parse the live image grub config on ppc, thus
booting fails on bare-metal. Fix the problem by removing the obsolete 32-bit
entries.
The host system can run out of space while running mksquashfs, and while
this is logged to program.log it isn't detected by lorax or
livemedia-creator so it will continue running, possibly reporting
unrelated errors and causing confusion.
This adds checks for the return status when calling mksquashfs, logs it
to the log, and either exits or raises an error immediately.
