It's possible for e.g. `kernel` to be installed as an RPM BuildRequires or equivalent,
and there's no reason to sync, and *definitely* no reason to fsfreeze.
Another case where this happens is rpm-ostree, which performs its own sync/fsfreeze
globally. See e.g. 8642ef5ab3
Convert the s390x into s390 to also include s390-specific crypto
modules, for example, aes_s390 into the initramfs.
Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Some distros have both /usr/lib/plymouth and /usr/libexec/plymouth
directorirs, so we should check the existance of plymouth-populate-initrd
script.
Fixes: 421b46f8ae
Commit 5e574046e76e ("5?-dracut*.install: Allow scripts to install
the initramfs in /boot dir") added support to generate initramfs
images in the /boot directory and copy the respective BLS files.
Unfortunately, it broke the rescue initramfs generation when it's
not installed on /boot due not checking for the correct condition.
It checks for the 0-rescue sub-dir to exist, but this is created so
instead if the parent sub-dir exists has to be checked. Also, check
if the destination directory is /boot or not, instead if it exists.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Error: SHELLCHECK_WARNING:
/usr/lib/dracut/dracut-init.sh:939:20: error: Argument to implicit -n is always true due to literal strings. [SC2157]
937| dracut_kernel_post() {
938| for _f in modules.builtin.bin modules.builtin modules.order; do
939|-> [[ $srcmods/$_f ]] && inst_simple "$srcmods/$_f" "/lib/modules/$kernel/$_f"
940| done
941|
Error: SHELLCHECK_WARNING:
/usr/lib/dracut/modules.d/98syslog/parse-syslog-opts.sh:18:12: error: This expression is constant. Did you forget a $ somewhere? [SC2078]
16| elif [ -e /sbin/syslogd ]; then
17| syslogtype="syslogd"
18|-> elif [ /sbin/syslog-ng ]; then
19| syslogtype="syslog-ng"
20| else
Error: SHELLCHECK_WARNING:
/usr/lib/dracut/modules.d/90crypt/crypt-lib.sh:15:29: error: Since you double quoted this, it will not word split, and the loop will only run once. [SC2066]
13| strstr "$d" "${luks##luks-}" && return 0
14| if [ -n "$dev" ]; then
15|-> for _dev in "$(devnames $d)"; do
16| [ "$dev" -ef "$_dev" ] && return 0
17| done
The GRUB 2 bootloaders expect the initrd to be installed in /boot instead
of /boot/$MACHINE_ID/$KERNEL_VERSION/{linux,initrd}, so if that directory
doesn't exists, install the initramfs images on the /boot directory.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
If no network related params are specific, but rd.neednet=1 is set,
the default initqueue action is to wait until one of the network
interfaces is marked as setup properly.
This also help with initqueue's race condition when the network interface
shows up late
References: bnc#866771
Signed-off-by: Hannes Reinecke <hare@suse.de>
The existence of dpkg-achitecture is not indicative of a debian
installation. It may well be installed on systems of people who
package for both distros. The previous code path did not take
that into account.
We now traverse all known plymouth directories, locking on the first
valid one, and try to work with it.
At the same time, we do not include the module if the plymouth directory
could not be found.
Previously if no symmetric key was configured for EVM, then the
initialization process was aborted. It can be a valid use case, however,
to only use EVM digital signatures. In this case only X.509 certificates
need to be loaded.
With this change EVM initialization will continue if any of the
symmetric or X.509 keys could be loaded.
This implements logic analogous to the one already implemented in
ima-keys-load.sh, only for the .evm/_evm keyrings.
If the kernel was built with CONFIG_IMA_TRUSTED_KEYRING then the kernel
initially creates and configures .ima and .evm keyrings. These keyrings
only accept x509 certificates that have been signed by a local CA which
belongs to the kernel builtin trusted keyring.
Thus if such a keyring is already present then additional evm keys
should be loaded into them. If this is not the case then the _evm
keyring needs to be created in userspace and keys will be loaded into
it instead.
Before this change dracut always created the _evm keyring and loaded
keys into it without considering an existing .evm keyring. In case of
CONFIG_IMA_TRUSTED_KEYRING being enabled, the _evm keyring will not be
used by the kernel, however, and EVM digital signatures will not work as
expected.
We initially enabled it for Haswell TSX bug (mga#16657)
Now there is also Meltdown and Spectre security issues,
and more microcode issues will most likely show up...
So the sane default for 'early_microcode' to have it enabled,
as theese changes must be done early in boot process to take
effect as intended.
Update documentation accordingly.
Reference: https://bugs.mageia.org/show_bug.cgi?id=16657
Signed-off-by: Thomas Backlund <tmb@mageia.org>
Signed-off-by: Neal Gompa <ngompa13@gmail.com>
There is currently no way to override dracut's preference for
/dev/mapper device names. But using these is problematic in
different scenarios: For example, if a user has a multipath-
enabled system but wants to disable multipath, or if the
names of multipath maps change because of configuration changes
(e.g. toggling user_friendly_names in /etc/multipath.conf).
This patch makes dracut prefer the user-specified
--persistent_policy names over /dev/mapper names.
It might be worthwhile to discuss why dracut prefers /dev/mapper
of /dev/disk/by-uuid at all. This preference was introduced
in 9037b63e with the argument "dm devices maintain /dev/mapper/* as
persistent names", but that's wrong for the scenarios mentioned
above, and is not a compelling reason for preferring /dev/mapper
over /dev/disk/by-uuid.
References: bsc#908143
Signed-off-by: Martin Wilck <mwilck@suse.de>
Harald Hoyer