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@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave