On Thu, May 08, 2014 at 02:45:18PM +0530, Hari Bathini wrote:
On 05/06/2014 02:53 AM, Vivek Goyal wrote:
>On Tue, Apr 29, 2014 at 07:27:55PM +0530, Hari Bathini wrote:
>>Take a backup of original initrd when fadump is used first time or
>>when user has switched from kdump to fadump. This will allow us to
>>fall back to original initrd when kdump service fails to rebuild
>>the fadump ready default initrd. Also, if the user switches from
>>fadump to kdump, then the original initrd will be restored when
>>kdump script is run first time after the switch.
>Thinking more about it. Why should kdump worry about keeping an initrd
>backup and restoring that later.
>
>I feel this should be left to user if he needs to do so.
>
>Kdump should just build initrd separately and upon successful build
>replace the original with this one.
>
>I think it is similar to admin invoking "dracut" to rebuild initrd. dracut
>does not create a backup of original initrd.
>
>I don't think kdump should be tasked with keeping a backup of original
>initrd and restore it. That does not sound right to me. That's not kdump's
>job.
>
>Thanks
>Vivek
Vivek, in fadump case, as default initrd is the initrd image for fadump
as well, it becomes a bit tricky on when to rebuild the initrd image
with fadump support as the default initrd image could already be built
with fadump support in most cases.
That's the issue with fadump from day 1. I am not very comfortable with
the idea of regneration of *boot* initrd. Given the fact that you are
trying to take a backup and restore it, you are not comfortable either
and hence trying to create some sort of fall back mechanism.
Anyway, in this specific case I did not understand two things.
- What's wrong with regeneration of initrd even if fadump is already built
in. We do this all the time with kdump initrd?
- And if you have been successful in generating initrd once with fadump
module and it works, there is no reason that rebuilding it that way will
not work.
So I am not sure what's the concern here.
Having a backup image solves this
problem.
Also, it helps in cases where default initrd is manually created
by user for specific needs as while switching back from fadump to kdump,
If user has created an initrd manually, the need to create a backup of
it.
You know what, we probably can do something like "make install". It seems
to save old kernel and initrd with suffix .old. I think that kind of
functionality still might be somewhat resonable. As one can argue that
it is not obvious that kdump service will overwrite intrd.
But I am not conviced about restoring initrd part. That needs to be
done manually if need be by user. Anyway, restoring initrd should not
be required if kdump service stops. There will not be any /proc/vmcore
even if kernel crashes and fadump module will not do anything.
creating a new default initrd image instead of restoring the
original
initrd image may be undesirable.
You indeed are creating a new default initramfs. That can always make
your current system unbootable. If you think that this is undesirable
then we should not be doing fadump feature this way. I had warned
about this long back.
It was you who had confidence that you can reliably rebuild initrd.
And if that's the case, why are you trying to introduce a backup
and restore mechanism?
Also what if user builds a custom initrd and that's overwritten by
kdump when service stops (as it restored the original initrd).
Please share your opinion on this.
I think we can just save the old initrd with some suffix. But I really
don't like the idea of restoring from backup when kdump service stops.
Thanks
Vivek