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
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.
This aligns other places piping cmdline() output to cmdline.d files
with the earlier fix for 95rootfs-block.
Signed-off-by: Thorsten Behrens <tbehrens@suse.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
--hostonly-cmdline:
Store kernel command line arguments needed in the initramfs
--no-hostonly-cmdline:
Do not store kernel command line arguments needed in the initramfs
Add new functions require_binaries() and require_any_binary() to be used
in the check() section of module-setup.sh.
These functions print a warning line telling the user, which binary is
missing for the specific dracut module.
This unifies the way of checking for binaries and makes the life of an
initramfs creator easier, if he wants to find out why a specific dracut
module is not included in the initramfs.
If a non-default device mapper name is used for an encrypted partion is
used, (i.e. not luks-$UUID) due to parsing of /etc/crypttab, then the
short-circuits put in place to prevent asking the password twice do not
work.
This would not normally be an issue as the settled job itself should be
removed after it has run and thus cannot be run again. Sadly, due to
the corresponding udev rule using ACTION="add|changed", and the fact
that trying to unlock the device (whether successful or not) seems to
trigger a changed event, it means the settled job is recreated with
each itteration thus causing the whole loop to run again.
It is this situation that the short-circuit exits would normally come
into play but sadly do not work when non-standard names are used.
By the time the /tmp/cryptroot-asked-$2 file is written near the end of
the script, the value of $2 has already been lost due to the argument
parsing code's use of 'shift'. So while on systems where the default
name is used are protected by checking /dev/mapper/xxxx, the
/tmp/cryptroot-asked-$2 file didn't help on systems where this was not
used due to this bug.
So this commit shuffles things around somewhat such that:
1. The /dev/mapper/xxxx device is checked *after* resolving $2 (which
contains the default name) to whatever /etc/crypttab specifies.
2. The cryptroot-asked-xxxx file also uses the translated name both
for the initial check and to flag when it's written.
As a separate fix, it might make sense to change the udev rule to only
act on add events rather than add|change events, but I'm not sure of the
ramifications of such a change and there may be cases where the add
event is missed and thus the change event needs to be included.
This prints the kernel command line parameters for the current disk
layout.
$ dracut --print-cmdline
rd.luks.uuid=luks-e68c8906-6542-4a26-83c4-91b4dd9f0471
rd.lvm.lv=debian/root rd.lvm.lv=debian/usr root=/dev/mapper/debian-root
rootflags=rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered
rootfstype=ext4
To eliminate a race condition that occurs when unlocking one device
depends on the result of unlocking a device before it, the crypt
module must wait for udev to settle between each unlock attempt.
Example
/etc/crypttab:
keyfile /dev/md1 none luks
sda4_crypt /dev/sda4 /dev/mapper/keyfile luks
sdb4_crypt /dev/sdb4 /dev/mapper/keyfile luks
Without this patch, sometimes /dev/sda4 fails to unlock because udev
doesn't have time to create /dev/mapper/keyfile before it's needed.
Prevents following error message:
I: *** Including module: crypt ***
/usr/lib/dracut/modules.d/90crypt/module-setup.sh: line 31: /etc/crypttab: No such file or directory
Start the systemd-cryptsetup@luks-*.service for the detected crypto_LUKS
device in the initqueue, so we block in the initqueue and wait for the
password entry.
1) strstr " $discarduuids " did not remove the optional
'luks-' prefix from the argument as the documentation says.
2) The lookup seems backwards. $luksdev ($luks in the other code copy)
is the full uuid and thus one should check whether the user-supplied
argument (short form) is contained therein, not the other way around.
Before this commit, the only way to trigger allow-discards was to
specify the full uuid without the 'luks-' prefix.
No automatic assembly is done anymore by default. You will have to
specify exactly what devices to assemble
("rd.md.uuid=" "rd.luks.uuid" ...)
or use "rd.auto=1" or "rd.auto" on the kernel command line.
For big servers with thousands of disks we don't want to assemble
everything by default (error prone, slow).
Harald Hoyer