This is "industrial input/output". I'm *pretty* sure we don't
need to support industrial magnetometers and humidity sensors
during installation.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
per airlied, these are mainly intended for compute (OpenCL), they
may also be used by vaapi/vdpau (video playback acceleration),
but they're definitely not used for regular graphics.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This appears to be intended for testing and should not be needed
for setting up wifi connections in the installer.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's over 1M and not really essential. We might occasionally
want to use it to analyze boot of an installer image, but we
could just spin an image that includes it when we want to do
this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
AFAICS, this dep chain (syslinux->mtools->glibc-gconv-extra) is
the only reason glibc-gconv-extra is in the installer env. It's
quite large (8M). syslinux's dep on mtools seems to be due to
(one of) its installer(s) using mtools, but I don't think we
ever run that from the installer env; we only pull syslinux into
it to set up bootloader stuff for the installer image itself,
which happens in x86.tmpl and doesn't involve actually running
a syslinux installer, just copying files around.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
As best I can tell, guile22 is only in the installer env because
we include gdb and gdb depends on the libraries from it. gdb's
dep is for guile scripting support, AIUI. I don't think any kind
of libreport or manual gdb debugging we'd do in the installer env
would need that support, and even if it does, the ccache does
seem to be a cache - docs say if the files are not present,
they'll be generated on the fly from the .scm format sources in
/usr/share/guile/2.2. So I think it should be safe to ditch this
cache, which is large (it takes up ~38M uncompressed).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This addresses most "no files matched!" and "no files to remove!"
errors in current F36/Rawhide. They mostly relate to packages
that are no longer pulled in at all, or whose layout has changed.
The entries for audit haven't been fixed for the /usr merge years
ago. In linux-firmware, all files have been xz-compressed at some
point, so the entries were not matching any more. The usbdux/
subdir contains only sources for the actual firmwares that are a
level above, and we don't include those in the package any more;
the actual firmwares are useless in the installer env, so this
removes them. util-linux was split into util-linux and
util-linux-core, so we have to add an entry for util-linux-core
and move the relevant excludes to that entry.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Prior to bc46724, we dropped several variants of DejaVu to save
space, including DejaVuSans-Oblique.ttf, to which I think this
is the equivalent. I believe the idea is that it's not worth
half a megabyte just to get tuned rendering of italics in the
installer environment (where they're rarely used anyway); AIUI
in the absence of a specific oblique/italic font face, freetype
will produce one by slanting the regular face.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The dropped google-noto packages contain fonts of scripts for
languages that the installer is not translated into. Most are
obvious, but for the record, "lao" is for the script and
language also called Lao; "thaana" is for the script Thaana,
used for the language Maldivian.
sil-abyssinica-fonts was an older set of Ethiopic fonts used for
e.g. Amharic; we now prefer google-noto-sans-ethiopic-vf-fonts,
the installer environment does not need both.
Similarly, sil-scheherazade-fonts covers a similar range to
google-noto-sans-arabic-vf-fonts and paktype-naskh-basic-fonts,
which are now preferred.
xorg-x11-fonts-misc contains bitmap fonts for some non-Latin
scripts. I'm fairly sure nothing in the installer environment
should need bitmap fonts any more.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Since we're leaving pipewire-libs in, it'll still pull in liblilv
from 0.3.41 onwards. Currently liblilv is in the same package as
some binaries which we don't need, and one actually requires the
removed libsndfile, so we need to trim it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We aim to remove all sound support from the installer root, but
this was never updated for Pipewire. This just started causing
compose failures because of a dep chain from pipewire to lilv.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Marvell Prestera firmware has been split into its own subpackage,
so instead of stripping the files from linux-firmware, exclude
the package from the globed install command.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These firmwares are for Qualcomm smartphone chipsets (SM845 and
SM8250). Don't think they're any use in network install images.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Fedora has split xorg-x11-font-utils, with bdftopcf, mkfontscale and
fonttosfnt being split out into separate packages. Remove all of those too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In f34 and beyond, the old xorg-x11-server-utils package was split up
into seperate packages for each util. This was to allow them to rev at
their own pace instead of requiring all of them to rebuild at once.
See https://bugzilla.redhat.com/show_bug.cgi?id=1932754
and
https://fedoraproject.org/wiki/Changes/XorgUtilityDeaggregation
We need to adjust lorax (in f34+) to not try and remove the
xorg-x11-server-utils package (as it no longer exists) and also to
install the 2 utils that we need from it for installs.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
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
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>
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
The kernel in /boot is not needed. Keep the .vmlinuz*hmac file so that
fips mode can check it (this requires dracut-050 or later).
Related: rhbz#1782737
Some of the files no longer exist, some of them have moved. In the case
of dracut the 98systemd directory was renamed to 98dracut-systemd, but
nobody noticed.
This updates the following:
* rename 98systemd to 98dracut-systemd so scripts are in the
install.img
* drop fedora-release removefrom, it now only has os-release
fedora-repos has the repo files, not anaconda, they are moved by
runtime-postinstall.tmpl
* Use initscripts to keep the /etc/init.d, chkconfig only has an empty
directory.
* gtk2-engines is no longer installed
* metacity doesn't include anything in /etc/
* /usr/share/X11/rgb.txt is no longer installed
* libgstbadallocators-1.0.so
The eject utility moved into util-linux and the package was dropped, but
since the runtime-cleanup template is using `removefrom util-linux
--allbut` it was never added to the boot.iso after the move.
This removes the package request for eject and adds it to the list of
binaries to keep from util-linux.
Anaconda uses zram to allow installation on low memory systems.
We used to have a custom script called "zram-stats", that can be
used to test and debug zram usage during installation.
The script no longer works & zramctl now provides much better
output than our script ever did. So we decided to decommission
the old Anaconda provided script & use zramctl instead.
So change the cleanup rule in the Lorax boot.iso template
to keep the zramctl utility.
Related: rhbz#1561773
Some files are created in non-reproducible way, including including
random data explicitly (/etc/machine-id), timestamps (fontconfig cache,
ldconfig aux-cache, certs cache), or entries in random order (groups,
systemd catalog, package list).
Fix this by either making the files reproducible, or removing them.
It looks like gnome-helper grew a dependency on it so let's not remove
it. From today's pungi run we can see this error in the verify:
```
libgstgl-1.0.so.0, needed by /usr/bin/gnome-help, not found
```
This will allow anaconda to fetch kickstarts using https when installing
with fips=1
Leave vmlinuz and .vmlinuz.hmac in /boot
dracut-fips module needs the vmlinuz.hmac file in order to boot.
