The recently upstreamed virtualbox video driver (vboxvideo) is shipped
in the staging directory. We need to probe it before Xorg is loaded to
avoid a corrupted X.
In general it is a good practice to look also in the staging directory
for DRM drivers.
Signed-off-by: Carlo Caione <carlo@endlessm.com>
This was removed from systemd almost two years ago in
c550f7a9b89d017215af084288bc44f736f774fe, so dracut should drop support
as well.
Reference: bsc#1067279
The caller of "for_each_host_xx func" needs to tell three cases:
func success/ fail / not be called.
E.g, in kdump case, host_devs can be empty, and we want to know it.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Although no device uses multipath, the module checks
for presence of the multipath binary first, printing a
warning if not present. This patch fixes the wrong ordering.
Fix issue #279 supercede PR #299
Fix bug https://issues.openmandriva.org/show_bug.cgi?id=2219
Replace Bashisms in the boot message for a missing overlay.
Verify presence of plymouth before calling it.
(Rework of commit f1b65e92af5e3f9df79f99e55d5aa936c9bca940.)
Previously, dracut would only copy the first one found. However,
with legacy maps for some locales around, there is a chance we
pick the wrong one. Pick all matching keymaps instead
Reference: boo#1065058
If no iscsi session information can be retrieved from the firmware
then skip the iscsi attachment and allow the boot process to continue.
Ensure the timeout scripts don't hit their timeout waiting for
/tmp/iscsistarted-firmware to be created.
This will allow a common image to be used for servers with both a
local and iscsi root with rd.iscsi.firmware set.
Some of the more complex devices now need rpmsg and hwspinlock in the early boot
process to start, and these to the initrd, and pull in usb/misc because
apparently non standard usb hubs are a thing.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Type=oneshot, as currently set in dracut's emergency service file,
causes an awkward situation if emergency mode is entered e.g. because
of a root device timeout, and the root device appears later because it
just has taken longer than the timeout. In that situation, my
expectation (backed by past positive experience) is that the user should
be able to simply exit the emergency shell and resume normal boot.
:/# systemctl status sysroot.mount
● sysroot.mount - /sysroot
Loaded: loaded (/proc/cmdline; bad; vendor preset: enabled)
Active: active (mounted) since Mon 2017-10-09 14:32:15 CEST; 16s ago
Where: /sysroot
What: /dev/mapper/3600601600a30200024fbbaf3f500e411-part5
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 1873 ExecMount=/usr/bin/mount /dev/disk/by-uuid/63751805-6abc-46a3-a66f-427920dece4d /sysroot -o ro (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 512)
:/# systemctl list-jobs
JOB UNIT TYPE STATE
56 emergency.target start waiting
57 emergency.service start running
2 jobs listed.
:/# exit
logout
Failed to start default.target: Transaction is destructive.
(system keeps idling from this point on, user has no chance to
do anything).
This results from the combination of two effects:
1) initrd-root-fs.target sets "OnFailureJobMode=replace-irreversibly",
2) emergency.service's Type=oneshot causes the start jobs for both
emergency.service and emergency.target to persist while the user is in
the emergency shell.
When the shell is exited, systemd tries to isolate "initrd.target"
again, but this fails with "the transaction is destructive" error
because of the still pending jobs.
This patch fixes this by changing the Type of "emergency.service" from
"oneshot" to "idle".
JobRunningTimeoutSec now affects how long can start jobs for device
units stay in the "running" state. Disabling default job timeout via
JobTimeoutSec=0 doesn't disable running state timeout. We need to set
running state timeout as well.
Note that doing this the other way around has effect on generic timeout,
i.e. disabling running state timeout disables generic timeout. But doing
it this way we would create implicit dependency on fairly new
systemd-234. However, by setting both options we don't create dependency
on specific systemd version.
A LUKS root volume with a detached header on a device without partitioning will not have a UUID and will not have an attribute ENV{ID_FS_TYPE}=="crypto_LUKS".
Therefore, several areas need to be addressed: identification of the LUKS device, inclusion of entries within crypttab, and provision of the detached header file.
- Added support for an option (4th column: "force") in /etc/crypttab to force the inclusion of the entry in the initramfs version (avoiding the fs type test).
- Added support for an option (4th column: "header=/path/to/file") in /etc/crypttab to provide a path to a detached header file embedded within the initramfs.
- Added ID and PARTUUID support to the device (2nd column) in /etc/crypttab (complementing the existing UUID functionality).
- Added cmdline support to indicate LUKS device ("rd.luks.serial=") that refers to the attribute ENV{ID_SERIAL_SHORT}.
Tested successfully on Void Linux (x86_64 musl) (no systemd) with a LUKS root volume accessed with a keyfile and using a detached header.
Not tested on systemd, or on a LUKS root volume with a passphrase rather than a keyfile.
Some Combined Network Adapters(CNAs) implement DCB protocol
in firmware, it is recommended that do not run software-based
DCB or LLDP on CNAs that implement DCB, but we have to start
the lldpad service anyway(there might be other software DCB).
If the network interface provides hardware DCB/DCBX capabilities,
the field DCB_REQUIRED in "/etc/fcoe/cfg-xxx" is expected to
be set to "no".
We met an issue on "QLogic BCM57810" with DCB firmware support,
and found dracut still generated "fcoe=<mac>:dcb" which caused
kdump boot failure when using that fcoe dump target.
This patch parses /etc/fcoe/cfg-xxx to detect DCB_REQUIRED="no",
and force "nodcb" if it is the case.
Also improved some coding style in passing.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
The MTU is only being set on the slave devices and the MTU of the
bonding master is not being updated. This updates the bonding master and
also changes the MTU on the slaves as expected.
Signed-Off-By: Robert LeBlanc <robert@leblancnet.us>
kerneldirlen is used to modify absolute path returned by
kmod_module_get_path() while it is calculated on user-supplied
--kerneldir argument which can be a relative path.
Use kmod_get_dirname() to convert user-supplied path to the same format
as used by kmod_module_get_path().
This also allows to get rid of now useless strcmp checks that seem to
imply that /lib and /usr/lib are linked which is not always true.
Harald Hoyer