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
...
}
--
I will add the above code in patch 2/2 in the next version..
I think we are on the same page with this.
>> 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?
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..
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