On 02/18/2013 06:29 PM, Harald Hoyer wrote: > Am 18.02.2013 07:21, schrieb Baoquan He: >> 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(-) >> >> -- >> To unsubscribe from this list: send the line "unsubscribe initramfs" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> 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! -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
