There's no reason for it to run, it can't notify anyone. But disabling
the service, or masking it, doesn't work so remove the service files
from the rootfs.
Resolves: rhbz#1888730
mk-s390-cdboot has stopped working because the kernel outgrew the
hard-coded offset it used when creating cdboot.img. IBM now has a script
in s390utils that can do the same thing so use the upstream script
instead.
This drops mk-s390-cdboot script, switches the s390 templates to use
mk-s390image from s390utils.
It adds @ROOT@ to cdboot.prm, and sets inst.stage2 so that the installer
image will be found when booting the iso.
Resolves: rhbz#1891778
Some of the options have been removed, others are now the default.
MOTD still needs to be printed, the boot environment doesn't include the
pam motd module.
Resolves: rhbz#1872892
Because of the way that compress pipes things between processes it would
leave open file descriptors, and running processes around for a bit.
This waits for them to exit and closes the fds before returning.
Python will eventually close open files, but it is recommended to
explicitly close them instead of waiting for the gc or program exit.
This fixes all the uses of open...read/write in the codebase, mostly in
tests.
I removed the example blueprints, and this is now going to run against
osbuild-composer which doesn't have default blueprints installed. So
embed them into the test and push them as the first test.
Also note that osbuild-composer diff currently has a bug, you cannot
specify a commit hash, so mark the final diff test failure as expected
for now.
Previously this symlinked them to /dev/null, which didn't really
accomplish anything since they get recreated. So just remove them so
python can decide whether or not to recreate them.
When we stopped caring about ppc and ppc64, we changed several
instances of three-item tuples:
("ppc", "ppc64", "ppc64le")
into...this:
("ppc64le")
which is not a single item tuple, but just the string "ppc64le"
in some extraneous braces. It so happens that the right thing
still happened in all relevant cases , we think, but it's wrong.
There's no need to be using an iterator at all for a single
item, so just change them all to == "ppc64le" or != "ppc64le" as
appropriate.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
I based this on the output of a recent installer image build:
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-33-20200904.n.0/logs/x86_64/buildinstall-Everything-logs/pylorax.log
I looked at every runtime-cleanup related error there and tried
to make appropriate changes. In many cases this means just
removing a line that isn't needed any more because the package
in question just went away or is no longer pulled into the
installer environment. In other cases packages changed name or
files moved around, and I tried to make appropriate updates. In
a few cases files moved to another package but I wasn't sure
enough it would still be safe to remove them so I just left them
in place. Most of the changes here I'm pretty sure should be
safe, though there *could* be unforeseen fallout from e.g. fixing
the removals from procps to be removals from procps-ng - it's
been years since that package was renamed, so something *could*
have started using those binaries in the meantime. I did at least
check that anaconda itself does not.
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
