Allow overriding the systemctl command for sysroot with $SYSTEMCTL
Modified every modules' module-setup.sh to use the envvar instead
of the hardcoded command name.
Signed-off-by: Zoltán Böszörményi <zboszor@pr.hu>
dracutinstall picks up interpreters and includes bash despite
the users' wishes or expectations, as modules should not require
bashisms at runtime.
Fixes#951
This is a plain and simple hack around dependency issues between dracut
and systemd.
When using Tang-pinned LUKS root devices, we want to rely on
`systemd-cryptsetup@.service` to unlock it. However, that service only
runs `After=remote-fs-pre.target`, while `dracut-initqueue.service` has
`Before=remote-fs-pre.target` (which makes sense because we don't want
to attempt networked root devices before networking is up).
However, the rootfs-generator here wants to make sure that the root
device exists *before* exiting the initqueue via an initqueue/finished
"devexists" hook. This will never work though because by design
`systemd-cryptsetup@.service`, which unlocks the root device, won't run
until after we exit.
So we have a dependency cycle:
initqueue -> devexists hook -> root device ->
systemd-cryptsetup@.service -> remote-fs-pre.target -> initqueue
There's no clean way to break this. The root issue is that there's no
way right now to split sequencing of systemd services across the
initqueue/online and initqueue/finished events because it's all bundled
in a single service. (The deeper root issue of course is that we have
two init systems. :) ).
Here we do a tactical fix: if there's a `systemd-cryptsetup@.service`
instance, let's assume it's for the root device and skip waiting for it
to show up if it depends on `remote-fs-pre.target`.
Currently when initqueue timeout, it span the console with
"dracut-initqueue timeout - starting timeout scripts", which isn't very
helpful as we still don't know what actually happened. Try to improve
this by print what is actually being waited.
Besides, only print "starting timeout scripts" when there are
actual timeout scripts to use.
Signed-off-by: Kairui Song <kasong@redhat.com>
In commit 49c4172 all shell based memory tracing functions are removed,
there are some left over. Remove them as well.
Signed-off-by: Kairui Song <kasong@redhat.com>
This feature could be off loaded to memstrack, which have better
accurecy, better performance, and have more detailed tracing features.
Also simplify make_trace_mem a bit.
And currently rd.memdebug=4 is unstable, fails from time to time.
- allow emergency login on every console
specified in the kernel cmdline
- require password for hostonly images
- emergency mode: Manually multiplex emergency infos
This will bring all vital information to all ttys specified
as console devices, regardless of wether they hold the C flag.
Reference: FATE#325386
Reference: #449
This is what happened before this patch (edited for brevity):
dracut-cmdline-ask.service in modules.d/98dracut-systemd, which invokes
dracut-cmdline-ask.sh. This script and systemd-vconsole-setup are
started in parallel for the same console (tty1).
Then dracut-cmdline-ask quits immediately without doing anything (unless
rd.cmdline=ask is given). As this is a bash script and it gets tty as
stdin as specified in its *.service, this triggers the hangup of tty1 at
its exit.
Meanwhile systemd-vconsole-setup continues and tries some ioctls after
that, but they fail because of the hung up tty1.
The usual culprit for starting systemd-vconsole-setup early on is
plymouth-start.service, even if plymouth.enable=0 is set.
A popular (and annoying) symptom of this as reported by users was
the inability use their configured keyboard layout in plymouth when
unlocking their crypted block devices.
Reference: boo#1055834
Allow filesystem modules to install a fs-specific text file with
instructions on what to do when mount fails. This is printed when we go into
an emergency shell.
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
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.
This used to work only when specified via the command line
or if systemd was not being used. However, the exisistence of
20_force_driver.conf also requires dracut-pre-udev.service
to be run.
Reference: bsc#986216
Extend "rd.memdebug" to "4", and "make_trace_mem" to "4+:komem".
Add new "cleanup_trace_mem" to cleanup the trace if active.
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Harald Hoyer