It turns out that commit f30b74e (dracut-initqueue service runs before
remote-fs-pre.target) is partial fix for remote fs mounts. Because no
one pulls in remote-fs.target, we can never start remote fs mounts.
Now pull in remote-fs.target in dracut-pre-pivot.
Signed-off-by: WANG Chao <chaowang@redhat.com>
The rootfs-generator was installed in the wrong path
in the initrd, cause it never to be run.
References: bnc#878714
Signed-off-by: Hannes Reinecke <hare@suse.de>
With the following commit, dracut doesn't mount anything from /etc/fstab
commit e920bfb
Author: WANG Chao <chaowang@redhat.com>
Date: Tue Apr 1 15:20:49 2014 +0800
fstab: do not mount and fsck from fstab if using systemd
But systemd doesn't mount nfs at all, because no unit is pulling in
remote-fs.target.
dracut must pull in these remote fs mount and all these remote mounts
should start only after network is up (ie. after dracut-initqueue).
Signed-off-by: WANG Chao <chaowang@redhat.com>
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.
Systemd tries to load this modules very early.
Even though they are not strictly required it it is a good
thing to have them around.
[Edited-by: Harald Hoyer: moved to installkernel() ]
Currently when action_on_fail is enabled, the emergency_shell won't be called.
In kdump even though user specify the default action as emergency_shell,
dracut skip it. Now change the implementation of action_on_fail to depend
on a file which is created by kdump when making kdump initrd, then remove it
at the beginning of kdump. This can solve the explicit emergency_shell problem.
And action_on_fail won't need paramenters, remove the relevant description in
dracut man page.
Signed-off-by: Baoquan He <bhe@redhat.com>