AFAICS, the devices that need these firmwares - various boards
built by NXP, https://www.nxp.com - are all aarch64. So we don't
need to carry these firmware files in the installer env for other
arches.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Mellanox Spectrum devices are switches intended for data centers.
It is I guess feasible that someone might want to install Fedora
on one, but from the product pages and data sheets, I believe
they all have management interfaces that do not require this
firmware to work, and that's what you'd use if you needed a
network connection during OS deployment. The firmware is only
needed for the actual switched interfaces, and we don't need to
make those work during installation.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These are for devices that just aren't going to be needed during
install, like video encode/decode accelerators, TV capture cards,
webcams, and some sound firmwares that should probably be in
alsa-firmware but aren't. This is a fairly conservative cut, I
will split some possibly more controversial cuts into separate
commits for ease of detachment. The linux-firmware WHENCE file is
an invaluable resource in figuring this out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
blivet-gui-runtime requires PolicyKit-authentication-agent. If
we just let dnf pick what to satisfy that requirement with, it
picks lxpolkit, which requires gtk2. Specifying polkit-gnome
instead should I think give us a smaller footprint, its deps
seem quite small.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
gnome-firmware is a GNOME app for installing firmwares, no use
here at all. sigrok-firmware is for signal analyzers, again, no
need for it here.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
libnotify dropped the requirement just a couple of months after
this line was added, but we never took it back out again.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The expectation is that all environments where an editor might be
used should ship GNU nano by default and tools should activate it
when an "editor" is requested. This change should ensure that for
the install media runtime environment.
Reference: https://fedoraproject.org/wiki/Changes/UseNanoByDefault
Resolves: rhbz#1874094
when $SKIP_IMAGE_BUILD is set the test skips 2 phases:
- start the compose again (after it has been cancelled) and
- waiting for it to finish & downloading the resulting image
This will allow to enable this test script in downstream gating
jobs.
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
