Don's try to restart dracut-initqueue if it's already there

Resolves: bz1901024
Upstream: Fedora
Conflict: None

commit 108258139a
Author: Kairui Song <kasong@redhat.com>
Date:   Mon Apr 26 17:09:55 2021 +0800

    Don's try to restart dracut-initqueue if it's already there

    kdump's dump_to_rootfs will try to start initqueue unconditionally.
    dump_to_rootfs will run after systemd isolate to emergency
    target, so this is currently accetable.

    But there is a problem when initqueue starts the emergency action
    because of initqueue timeout. dump_to_rootfs will start initqueue and
    lead to timeout again.

    So following patch will remove the previous isolation wrapper, and
    detect the service status here. Previous isolation makes the detection
    impossible. Now this detection will be valid and helpful to prevent
    double timeout or hang.

    Signed-off-by: Kairui Song <kasong@redhat.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Kairui Song <kasong@redhat.com>
This commit is contained in:
Kairui Song 2021-04-26 17:09:55 +08:00
parent 6a8b7bf421
commit e5ccb87ef6

View File

@ -222,8 +222,11 @@ save_opalcore_fs() {
dump_to_rootfs()
{
dinfo "Trying to bring up rootfs device"
systemctl start dracut-initqueue
if [[ $(systemctl status dracut-initqueue | sed -n "s/^\s*Active: \(\S*\)\s.*$/\1/p") == "inactive" ]]; then
dinfo "Trying to bring up initqueue for rootfs mount"
systemctl start dracut-initqueue
fi
dinfo "Waiting for rootfs mount, will timeout after 90 seconds"
systemctl start sysroot.mount