On 09/14/16 at 02:02pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 01:22 PM, Dave Young wrote:
> Hi, Hari
>
> On 09/14/16 at 12:57pm, Hari Bathini wrote:
> >
> > On Monday 12 September 2016 10:18 PM, Hari Bathini wrote:
> > >
> > > On Monday 12 September 2016 10:08 PM, Hari Bathini wrote:
> > > > Hi Dave,
> > > >
> > > >
> > > > On Monday 12 September 2016 07:35 AM, Dave Young wrote:
> > > > > Hi, Hari
> > > > >
> > > > > Thanks for sending the patches.
> > > > >
> > > > > The issue will not happen if we restore default initrd in patch
2/2,
> > > > > right? So patch 1/2 is not necessary?
> > > > Actually, the first reboot after switching over from fadump to kdump
> > > > still holds the interface name with "kdump-" prefix as we
haven't
> > > > restored
> > > > the default initrd yet. This patch intents to cover that and also,
> > > > to restore
> > > > the original interface name for subsequent reboots..
> > > >
> > Hi Dave,
> >
> > Another possible case is rebuild may not happen on switching from fadump to
> > kdump,
> > if config files are not changed. I could restore as part of start_dump() but
> > that doesn't
> > sound right to me. Posted v2 with this patch intact. Please review..
> I got the problem, do you have any method to know the fadump mode
> changing? Ideally we should check and rebuild when the mode changes.
If /sys/kernel/fadump_registered node is not available and default initrd is
built with kdump module, it signifies that we switched from fadump to
kdump. That is after a reboot though where we already have the ifname
with "kdump-" prefix..
Hari, if so how about fix it to let check_rebuild to detect the mode
change so that we can use patch 2 to restore original initramfs?
I worry about avoiding multi kdump- prefix cause issues though in real
life usually maybe nobody will name a nic as kdump-eth*
Thanks
Hari
> Thanks
> Dave
>
Thanks
Dave