Hi Dave,
Thanks for reviewing this. Planning to post the next version of the patches
by early next week..
- Hari
On Friday 30 September 2016 02:12 PM, Dave Young wrote:
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