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>
As the 'multipath' program will be triggered directly from
udev events it will be called before the multipath service
unit has started up. Which means we cannot rely on the
service unit to load the module for us, but we rather
have to do it early before udev is started.
References: bsc#986734
Signed-off-by: Hannes Reinecke <hare@suse.com>
Instead of trying all /dev/mapper/* devices to match the maj:min, and
get the VG name with "lvm lvs", use the dm/name from /sys and dmsetup
splitname.
This should speedup execution with lots of LVs.
81cio_ignore: handle cio_ignore commandline
References: bnc#874902
Incorporates following on-top patches/fixes:
----------------------------
Subject: 81cio_ignore: skip module if cio_ignore is not active
When cio_ignore is not active we should skip the entire module
during boot; otherwise it'll lead to adverse effects.
References: bnc#882685
----------------------------
Subject: 81cio_ignore: rewrite module
Rewrite cio_ignore module to rely on the dracut commandline
parameter 'rd.cio_accept', which takes a comma-separated list
of CCW IDs. Each of those IDs are being removed from the
list of devices from cio_ignore.
The default values for rd.cio_accept are taken from
/boot/zipl/active_devices.txt.
References: bnc#882685
-----------------------------
Subject: More empty cmdline fixes
This fixes up some more modules which might print out empty
commandline files.
-----------------------------
Subject: Mark scripts as executable
All scripts need to be marked as executable, otherwise dracut
won't be running them.
References: bnc#887010
Signed-off-by: Thomas Renninger <trenn@suse.de>
According to Cathy Zhou <Cathy.Zhou@Oracle.COM>:
"iscsistart is not designed to be working together with iscsid. When an
interface gets the dhcp offer successfully, the iscsiroot script is run
which starts the iscsistart service to establish the iSCSI session. With
the existence of iscsid, the iscsistart service's attempt to setup its
own mgmt ipc fails. Instead, the request to login to the iscsi target
is handled by the mgmt ipc of iscsid. After iscsistart finishes its
login attempt, it eventually sends a stop_event_loop request to stop
the mgmt process. As the result, it terminates iscsid."
So, iscsid is kicked out again.
Additionally iscsistart-flocked is used to make sure iscsistart is not
run in parallel.
Harald Hoyer