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
When 'systemctl daemon-reload' is run, systemd will clean out
/run/systemd/generator and re-run all the generators.
So it is important that the generators always create the required
files.
rootfs-generator.sh currently does *not* create the desired files
if $hookdir/initqueue/finished/devexists-${_name}.sh
exists.
This is not removed by "systectl daemon-reload" so the first time this
generator is run it will do the right thing. Subsequent times it
won't.
This results in incorrect timeouts after "daemon-reload" is run.
So let the existence of each file only guard the creation that file.
Signed-off-by: NeilBrown <neilb@suse.de>
A number of timeout scripts can be registered. If any one of them
makes progress - e.g. assembles a degraded md array - then
the main loop should wait a bit longer rather than pressing forward.
This is particularly important is resume-from-hibernate requires a
degraded md array. Both the script to forcibly assemble the md array
and the script to abort hibernation if the device doesn't appear
are 'timeout' scripts. There needs to be a reasonable delay between
these running.
So: if any script has indicated that progress was made, break of out
the loop and go back to normal waiting.
Signed-off-by: NeilBrown <neilb@suse.de>
mdraid_start is a number of scripts which run after a timeout.
If it makes progress, it should tell the main loop so that it
knows that it is worth waiting a bit longer.
So in that case, create the initqueue/work file which the main loop
checks for.
Signed-off-by: NeilBrown <neilb@suse.de>
When current dracut receives an ip with netmask of 255.255.255.255 via DHCP,
setting the also supplied default gateway fails (because it is obviously not
within the netmask).
The setup with a netmask of /32 is quite common in colocation datacenters
where you don't want the machines of two different customers to directly talk
to each other. At least two of the biggest colocation providers in Germany
(1&1 and Strato) do it that way. NetworkManager supports this kind of setup
and the dhclient-scripts of several distributions too.
In this patch I have implemented a simple approach very similar to what is
found in Debian. The dhclient-script from Fedora uses a more sophisticated
approach, but that relies on the ipcalc utility which would introduce a
dependency on Fedora-initscripts for dracut.
Signed-off-by: Gerd von Egidy <gerd.von.egidy@intra2net.com>
When the 'loop' kernel module isn't loaded in a running system, it gets
excluded from the hostonly initrd. Given that the crypt-loop dracut
module has to be loaded explicitly anyway, it makes sense to always
include the requisite loop kernel module.
When booting with 'rd.info', the 'info' statements in the crypt-loop
module's 'loop_decrypt' function are output to stdout along with the key
that gets piped into the 'cryptsetup' command, which causes the crypt
device unlocking to fail.
There are two possible simple solutions to this problem:
1. Redirect the info messages to stderr (just add '>&2' at the end of
the info statements).
or
2. Remove the info statements altogether.
I have tested both and they both work, but this commit implements #2.
The existing info messages are long (they overflow 80 characters
easily) and redundant (the password prompt clearly indicates what is
happening), and just generally not useful. Given that no one has
reported or fixed this bug in the three years that this module has
existed, no one will miss these info messages.
The commit also changes an error message in the same function to be more
descriptive.
With an EFI stub, the kernel, the initramfs and a kernel cmdline can be
glued together to a single UEFI executable, which can be booted by a
UEFI BIOS.
Harald Hoyer