add parameter continue_on_fail

PATCH In review Baoquan He 3 participants 7 messages Feb 18, 2013 – Feb 28, 2013 3 messages not in the archive

lore

Share & tools

lore

Baoquan He

author

2013-02-18 06:21 UTC #0 lore raw

v2 cover add parameter continue_on_fail

v1->v2:
Discard previous implementation, take a direct and simpler method.

By adding pamameter 'continue_on_fail=initqueue|mount_root', user can decide if continue after these points timeout. And can extend to other delay or loop point later if needed.

Baoquan He (2):
Add parameter continue_on_fail to make dracut continue after
initqueue timeout
Continue when mount rootfs failed by specifing
'continue_on_fail=mount_root'

 dracut.cmdline.7.asc                    |    3 +++
 modules.d/98systemd/dracut-initqueue.sh |   10 ++++++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

Baoquan He

author

2013-02-18 06:21 UTC #2 lore raw

PATCH v2 1/2 Add parameter continue_on_fail to make dracut continue after initqueue timeout

In reply to a message not in the archive

In kdump, When the dump device was removed, dracut will drop to shell during second kernel boot. That means kdump isn't even started. But in this case, if the target isn't presented, we should dump to a rootfs device as a default action.

In this patch, add a new parameter continue_on_fail. After initqueue timeout, detect whether this parameter is specified. If yes,continue. If not, enter into emergency_shell.

For later extending, user need give timeout point. E.g, use this parameter like below:
continue_on_fail=initqueue

dracut.cmdline.7.asc: add the relevant description

Signed-off-by Baoquan He <[email protected]>

---
 dracut.cmdline.7.asc                    |    3 +++
 modules.d/98systemd/dracut-initqueue.sh |    5 ++++-
 2 files changed, 7 insertions(+), 1 deletions(-)

dracut.cmdline.7.asc +3 -0

index 62372a5..31d2d84 100644
@@ -121,6 +121,9 @@ Misc
    specify the controlling terminal for the console.
    This is useful, if you have multiple "console=" arguments.
 
+**continue_on_fail=**_{initqueue}_::
+    continue after initqueue timeout by specify the timeout point 'initqueue'
+
 [[dracutkerneldebug]]
 Debug
 ~~~~~

modules.d/98systemd/dracut-initqueue.sh +4 -1

index 7de89e9..f889d20 100755
@@ -61,7 +61,10 @@ while :; do
     fi
 
     main_loop=$(($main_loop+1))
-    [ $main_loop -gt $RDRETRY ] && emergency_shell "Could not boot."
+    if [ $main_loop -gt $RDRETRY ]; then
+        getarg 'continue_on_fail=initqueue' && break
+        emergency_shell "Could not boot."
+    fi
 done
 
 unset job

Signature · 1 line

1.7.1

Baoquan He

author

2013-02-18 06:21 UTC #3 lore raw

PATCH v2 2/2 Continue when mount rootfs failed by specifing 'continue_on_fail=mount_root'

In reply to a message not in the archive

Dracut will drop into shell in case anything wrong with rootfs mounting, but for kdump it does not depends on rootfs for non-rootfs dump and kdump will handle the default fail action based on user configuration in /etc/kdump.conf.

In this patch, add support to make dracut continue after mount rootfs timeout by specifing parameter 'continue_on_fail=mount_root'.

dracut.cmdline.7.asc: change descrption related to 'continue_on_fail'

Signed-off-by Baoquan He <[email protected]>

---
 dracut.cmdline.7.asc                    |    4 ++--
 modules.d/98systemd/dracut-initqueue.sh |    5 ++++-
 2 files changed, 6 insertions(+), 3 deletions(-)

dracut.cmdline.7.asc +2 -2

index 31d2d84..756e734 100644
@@ -121,8 +121,8 @@ Misc
    specify the controlling terminal for the console.
    This is useful, if you have multiple "console=" arguments.
 
-**continue_on_fail=**_{initqueue}_::
-    continue after initqueue timeout by specify the timeout point 'initqueue'
+**continue_on_fail=**_{initqueue|mount_root}_::
+    continue after timeout if specify the relevant timeout point
 
 [[dracutkerneldebug]]
 Debug

modules.d/98systemd/dracut-initqueue.sh +4 -1

index f889d20..4fc72ad 100755
@@ -99,7 +99,10 @@ while :; do
     done
 
     i=$(($i+1))
-    [ $i -gt 20 ] && emergency_shell "Can't mount root filesystem"
+    if [ $i -gt 20 ]; then
+        getarg 'continue_on_fail=mount_root' && break
+        emergency_shell "Can't mount root filesystem"
+    fi
 done
 
 {

Signature · 1 line

1.7.1

Harald Hoyer

2013-02-18 10:29 UTC #4 lore raw

In reply to a message not in the archive

Am 18.02.2013 07:21, schrieb Baoquan He:

Quoted 14 lines

v1->v2:
Discard previous implementation, take a direct and simpler method.
By adding pamameter 'continue_on_fail=initqueue|mount_root', user can decide if continue after these points timeout. And can extend to other delay or loop point later if needed.
Baoquan He (2):
Add parameter continue_on_fail to make dracut continue after
initqueue timeout
Continue when mount rootfs failed by specifing
'continue_on_fail=mount_root'

Quoted 9 lines

 dracut.cmdline.7.asc                    |    3 +++
 modules.d/98systemd/dracut-initqueue.sh |   10 ++++++++--
 2 files changed, 11 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Why don't you just remove all "finished" scripts and install your own "finished" checking scripts, when your kdump device is ready?

Baoquan

author

2013-02-19 05:03 UTC #6 lore raw

In reply to a message not in the archive

Quoted 19 lines · Harald Hoyer

Am 18.02.2013 07:21, schrieb Baoquan He:
Quoted 18 lines
v1->v2:
Discard previous implementation, take a direct and simpler method.
By adding pamameter 'continue_on_fail=initqueue|mount_root', user can decide if continue after these points timeout. And can extend to other delay or loop point later if needed.
Baoquan He (2):
Add parameter continue_on_fail to make dracut continue after
initqueue timeout
Continue when mount rootfs failed by specifing
'continue_on_fail=mount_root'
 dracut.cmdline.7.asc                    |    3 +++
 modules.d/98systemd/dracut-initqueue.sh |   10 ++++++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

Quoted 8 lines

Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Why don't you just remove all "finished" scripts and install your own "finished" checking scripts, when your kdump device is ready?

Hi Harald,

Thanks for your comment.

Even though use "finished" scripts method, a parameter as switch to user is necessary. There are various kdump targets, sometime maybe it's unnecessary to continue on fail, because kdump target may not be started in initqueue.

In initqueue, adding parameter and change are because when a specific device failed to setup, later rootfs can be tried.

E.g For kdump, there can be 2 dump target, one is remote target through network with higher priority, the other is local rootfs with lower priority. So in initqueue, even though the network device failed to setup, we need go ahead to try local rootfs dumping, but not entering into emergency shell.

Baoquan
Thanks a lot!

Dave Young

2013-02-19 08:02 UTC #8 lore raw

In reply to a message not in the archive

Quoted 21 lines · Baoquan

Quoted 19 lines · Harald Hoyer
Am 18.02.2013 07:21, schrieb Baoquan He:
Quoted 18 lines
v1->v2:
Discard previous implementation, take a direct and simpler method.
By adding pamameter 'continue_on_fail=initqueue|mount_root', user can decide if continue after these points timeout. And can extend to other delay or loop point later if needed.
Baoquan He (2):
Add parameter continue_on_fail to make dracut continue after
initqueue timeout
Continue when mount rootfs failed by specifing
'continue_on_fail=mount_root'
 dracut.cmdline.7.asc                    |    3 +++
 modules.d/98systemd/dracut-initqueue.sh |   10 ++++++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

Quoted 8 lines

Quoted 8 lines
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Why don't you just remove all "finished" scripts and install your own "finished" checking scripts, when your kdump device is ready?

Even if none of kdump devices are ready, kdump still need ignore previous failure of dracut, so kdump can handle it according to kdump config options user specified. ie. some customized scripts..

Quoted 22 lines

Hi Harald,
Thanks for your comment.
Even though use "finished" scripts method, a parameter as switch to user is necessary. There are various kdump targets, sometime maybe it's unnecessary to continue on fail, because kdump target may not be started in initqueue.
In initqueue, adding parameter and change are because when a specific device failed to setup, later rootfs can be tried.
E.g For kdump, there can be 2 dump target, one is remote target through network with higher priority, the other is local rootfs with lower priority. So in initqueue, even though the network device failed to setup, we need go ahead to try local rootfs dumping, but not entering into emergency shell.
Baoquan
Thanks a lot!

Signature · 2 lines

Thanks
Dave

Dave Young

2013-02-28 03:38 UTC #9 lore raw

In reply to a message not in the archive

Quoted 19 lines · Harald Hoyer

Am 18.02.2013 07:21, schrieb Baoquan He:
Quoted 18 lines
v1->v2:
Discard previous implementation, take a direct and simpler method.
By adding pamameter 'continue_on_fail=initqueue|mount_root', user can decide if continue after these points timeout. And can extend to other delay or loop point later if needed.
Baoquan He (2):
Add parameter continue_on_fail to make dracut continue after
initqueue timeout
Continue when mount rootfs failed by specifing
'continue_on_fail=mount_root'
 dracut.cmdline.7.asc                    |    3 +++
 modules.d/98systemd/dracut-initqueue.sh |   10 ++++++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

Quoted 8 lines

Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Why don't you just remove all "finished" scripts and install your own "finished" checking scripts, when your kdump device is ready?

Grep emergency_shell usages, I find there's other points which will break out, like fsck, selinux policy loading etc. It's not only limited to initqueue...

Baoquan, looks like you only handled initqueue in the patches.

I thought to add a wrapper function like below, then replace all emergency_shell caller to call failaction instead:
failaction()

{
    if rd.failaction=continue;
        return
    fi

    emergency_shell ...

}

I think no need to add "continue_on_fail=initqueue|mount_root", one global switch is enough, nobody will want this except kdump..

Harald, do you have better solution? If I'm wrong here please correct me.

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 2 lines

Thanks
Dave