Hi, Hari
Sorry for late reply, I was busy on some blocker issues.
On 09/14/16 at 03:41pm, Hari Bathini wrote:
Hi Dave,
On Wednesday 14 September 2016 02:46 PM, Dave Young wrote:
> Hi, Hari
>
> On 09/14/16 at 02:29pm, Hari Bathini wrote:
> > Hi Dave,
> >
> >
> > On Wednesday 14 September 2016 02:13 PM, Dave Young wrote:
> > > 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?
> > Just mentioned the same on a previous mail..
> Sorry, I may not understand your points, you are thinking that rebuild
> sounds bad without kdump.conf changes? Actually we have added more logic
> to rebuild checking not limited to the config file only now.
I think restoring default initrd by checking if we have switched from
fadump to kdump is the right thing to do. I suggested pseudo code
for the same in a another mail. Let me paste it over here:
is_mode_switched()
{
initrd_fadump_capable=`lsinitrd -m $DEFAULT_INITRD | grep ^kdumpbase$ |
wc -l`
if [ !is_fadump_capable ] && [ initrd_fadump_capable ]
return 1
return 0
}
check_rebuid()
{
...
is_mode_switched
if [ $? -ne 0 ]
rebuild_initrd
...
}
--
Sounds good, just add a elif case in the if [ $image_time -eq 0 ] ... fi
I will add the above code in patch 2/2 in the next version..
I think we are on the same page with this.
Yes, we are :)
> > > I worry about avoiding multi kdump- prefix cause issues though in real
> > > life usually maybe nobody will name a nic as kdump-eth*
> > The hunk in this patch adds kdump- prefix only if the interface name
> > doesn't have it already. If it already has such prefix, we don't have
to
> > worry about the name as it is not default name.. So, I think it serves
> > the purpose you are mentioning?
> I see it, but one can rename it to kdump-eth0 in udev, it is a valid name, no?
True. But do we really need to change ifname to kdump-kdump-eth0 when
we already have an ifname that is not kernel assigned and is persistent?
Hmm, you may be right..
> I know it is not a usual case, but I still feel check_rebuild sounds
> better approach.
Yes. It is better but it still doesn't fix the issue completely using
kdumpctl script alone. Let me explain..
Switch from fadump to kdump means booting a kernel without
"fadump=on" parameter. kdumpctl may detect this switch and
restore default initrd but we still have the ifname with "kdump-"
prefix coming from the old initrd we just booted. So, without
patch 1/2, kdump will get an ifname of kdump-kdump-eth0 unless
we reboot again with the restored initrd! I am trying to avoid
another reboot with patch 1/2 and since it is safe to assume
that an ifname with one "kdump-" prefix is not a kernel assigned
name and is persistent, I think the patch doesn't break the
current functionality..
I got your case now, the root problem is we depend on kernel param.
I think the patch 1/2 is reasonalbe now. But add a code comment
will be better.
Alternatively, assuming a user only switches from fadump to
kdump with system-config-kdump, we can add backup/restore
logic in system-config-kdump package on select/deselect of
"firmware-assisted dump" option in GUI. This sounds limited
though.
Thanks
Hari
_______________________________________________
kexec mailing list
kexec(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks
Dave