On Fri, May 30, 2014 at 11:40:02PM +0530, Hari Bathini wrote:
[..]
>- 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 of fadump,
default initrd is always there. So we should either rebuild initrd
with fadump support
all the time or have a check mechanism to minimize the number of
times we rebuild.
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 functional impact.
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.
How about using "lsinitrd" and check whether relevant files are present
or not. We could check for module "kdumpbase" is present or not? We could
also create a new option to lsinitrd so that it lists only modules and
nothing else.
>- 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.
>
True. There is no need in restoring initrd when kdump service stops.
>>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?
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.
I think I am fine with saving backup of existing initramfs. I have
the main problem with restoration part. You never know who has mucked
with stored backup in the mean time.
Thanks
Vivek