On 05/13/2014 02:09 AM, Vivek Goyal wrote:
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.
>> 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
> 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?
In kdump case, when kdump initrd is missing, we create it. But in case
default initrd is always there. So we should either rebuild initrd with
all the time or have a check mechanism to minimize the number of times
I prefer the latter for the frequency of rebuilds without a check
mechanism will be
much higher although rebuilding multiple times doesn't have much of a
A simple check mechanism could be to have a "/boot/.fadump" file; if the
file is present,
we don't bother rebuilding, else we rebuild initrd with fadump support.
- And if you have been successful in generating initrd once with
module and it works, there is no reason that rebuilding it that way will
So I am not sure what's the concern here.
> Having a backup image solves this
> 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
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.
True. There is no need in restoring initrd when kdump service stops.
> creating a new default initrd image instead of restoring the
> 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?
We are indeed confident about rebuilding initrd with fadump support.
Intention in restoring was only to remove fadump support from initrd
when it is unnecessary. Since that doesn't sound like kexec-tools job,
will drop the idea of restoring when service stops. Will have the backup
though, for user's reference. Please share your views.
I will work on these changes and post the revised patches soon.
Also what if user builds a custom initrd and that's overwritten
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.
PS: Sorry about the delayed response. I was on vacation all these days.