When systemd's crypttab generator parsed crypttab, it tells
systemd about several devices which may not appear until later
in the boot sequence, and which are not needed while dract is running.
This can particularly happen when an md array is encrypted,
and the array is newly degraded so that it doesn't appear until
dracut runs mdraid_start.sh.
This can result in systemd printing warning messages which are
inappropriate.
So tell systemd that the timeout for each of these is zero.
This is involves splitting some functionality out of wait_for_dev()
That function does two things:
- creates 'finished' hooks so that dracut will wait for the device,
and
- sets the systemd timeout for the device to zero, so systemd doesn't
wait.
We only want the second of these for most encrypted devices.
So split that out into a new function set_systemd_timeout_for_dev(),
and call it from parse-crypt.sh
Signed-off-by: NeilBrown <neilb@suse.de>
--
This version fixes the missing redirect from /etc/crypttab
NeilBrown
dracut: Make host only mode more resilient to missing swaps.
This patch set allows swap devices to disappear without cocking up a
host-only initramfs boot.
There is a bug that kdump-initrd contains entry requesting nfs dump
filesystem to get filesystemchecked. And there is an erro message said
that nfs need be checked. But there's no fsck for nfs utility, e.g
fsck.nfs like other file system. Whatever fs_passno 0 or 2 are passed,
no fsck is executed at all for nfs mount.But in dracut, set it to be 2
always, so the erro message appear and it should be set to 0.
In the fstab,the sixth variable fs_passno stands for that the device need
checked or not,and dracut set it to "2".To fix this issue, it should
be "0" when the device is nfs.The third variable stands for the type of
the filesystem and we can use it to judge whether the device is nfs.
So when the third variable of fstab contains "nfs", the sixth variable
fs_passno should be set to "0".
Signed-off-by: Chao Fan <cfan@redhat.com>
Although various bits are in place to cancel waiting for the /dev/resume
device (actually a symlink), we don't actually ever wait for it.
Also as the udev rule may create the symlink, silence any errors from
our manual ln -s call from the settled job.
The only reason we add swap devices to host-only mode (added in
dd5875499e) is to allow us to process
resume= arguments passed on the kernel command line when the swap
partition lives on something slightly more complex than a normal
partion (e.g. in an LVM or RAID setup).
By adding the device to host_devs, the necessary LVM and RAID hooks
are added and thus the underlying storage will be initialised OK, and
the 95resume module handles the waiting for the device (via udev rules
creating the /dev/resume symlink).
So ultimately, we do not need to hard-code the waiting for the swap
devices into the initramfs at build time as the waiting part can be
dynamic.
This makes things more resiliant to swap partitions disappearing and
being reformatted etc.
Inspired by a patch by Martin Whitaker on Mageia bug:
https://bugs.mageia.org/show_bug.cgi?id=12305
If crypt-lib.sh is sourced from any #!/bin/sh script, a POSIX shell
quirk is in effect that causes variable assignments to "special
builtins" (such as "shift") to leak to their context. So the buggy
code works even despite the missing semicolons.
But if it is sourced by "bash acting under its own name", i.e. from
any #!/bin/bash script, the quirk is disabled, tty_cmd/tty_prompt are
undefined, and ask_for_password doesn't do anything if plymouth is not
present.
AMD's HSA Linux kernel driver (amdkfd) has been merged into the mainline
kernel since kernel 3.19.
However, for the driver to work, it needs to be included in the default
initramfs image, together with the amd_iommu_v2 driver.
The radeon driver (AMD's kernel graphic driver) calls amdkfd during its
initialization and probing stages. Because radeon is included in the
initramfs image, it tries to initialize amdkfd during the early boot
stages. However, as amdkfd is not present there, it fails.
That doesn't harm radeon operation. However, it disables the HSA
abilities in the machine.
Because of the current design, if you later try to "modprobe amdkfd",
you won't be able to run HSA applications, even though the driver will
be loaded.
https://bugzilla.redhat.com/show_bug.cgi?id=1205222
Jan Synacek