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
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 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
A change in glibc now requires /proc be mounted in order to run mknod
which is needed in order to run rpm from runtime-postinstall.
This drops that code from the template and moves writing the package
list into run_transaction, which already has all of the needed
information to generate the list.
Resolves: rhbz#1812895
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.
Add lohit-marathi-fonts for Marathi.
Replace kacst-*-fonts with paktype-naskh-basic-fonts for Urdu,
for Arabic, we use dejavu-sans-fonts.
Replace lklug-fonts with google-noto-sans-sinhala-vf-fonts for Sinhala.
Replace lohit-gurmukhi-fonts with google-noto-sans-gurmukhi-fonts for Gurmukhi.
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
This new setting for 'find_multipaths' tries to prevent things like
LVM from going ahead and activating LVM on the individual disks/paths
until there is reasonable certainty (via a timeout) that the device
is not a component of a multipath set.
NOTE: 'smart' is supported by device-mapper-multipath v0.7.7 and later.
xorrisofs needs to use iso-level 3 when creating images with large
files. This adds tests to all the relevant templates, just like we used
to do for udf and mkisofs.
It was substituting _ which didn't match what pungi uses for creating
the DVD. Make things consistent and use - as the replacement character.
Resolves: rhbz#1687882
In order to support iso creation on multiple arches with the templates
we need to be able to select different packages based on arch.
lorax-composer uses the arch-specific Lorax templates in order to
generate the output iso so this patch:
1. Creates a new template and type to parse it, live-install.tmpl
which contains only installpkg commands and #if clauses for arch
2. Removes bootloader related packages from the live-iso.ks
3. Remove dracut-config-rescue exclusion because it can cause problems
with some blueprints.
4. Switch logo requirement to system-logos which is satisfied by
generic-logos or fedora-logos. This prevents conflicts when a blueprint
installs fedora-release-workstation.
So in the future, if x86.tmpl, etc. need a new package to support
creating the iso it should be added to the correct section in
./share/live/live-install.tmpl
Most bootloaders used in Fedora already have BootLoaderSpec but extlinux
doesn't yet. So when using extlinux the old grubby must to be installed.
Resolves: rhbz#1649778
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
