On Wednesday 14 September 2016 02:02 PM, Hari Bathini wrote:
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
>>>> 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
>> 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
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..
How about something like this..
initrd_fadump_capable=`lsinitrd -m $DEFAULT_INITRD | grep
^kdumpbase$ | wc -l`
if [ !is_fadump_capable ] && [ initrd_fadump_capable ]
if [ $? -ne 0 ]
This hunk added to patch 2/2 should take care of restoring default initrd on
switch. But I am worried about the ifname that kdump gets on first reboot.
Let me know if you have any reservations with patch 1/2?
kexec mailing list