On Mon, Apr 25, 2022 at 04:55:03PM +0800, Kairui Song wrote:
Ok, thanks for the clarification.
You are welcome!
[...]
>>
>> >Just one concern, could
there be any wired DHCP corner case? Like if
>> >the kdump kernel took a longer time to boot, eg. 5 min, and then your
>> >DHCP IP just expired during that time window, the kdump kernel will be
>> >using an expired IP and conflict with other machines. The minimal
>> >lease time of DHCP address is 1 hr, could be a rare corner case, but
>> >in-theory possible.
>
>> It seems I don't fully understand you. In the
kdump kernel, we still use
>> DHCP to have a IP so there should be conflict. kdumpip is only used to
>> create to a dumping folder named "{IP}-{DATE}" and we don't assign
>> kdumpip to a NIC.
>Oh, yes, you are right, I didn't read the patch
carefully enough.
>Since kdumpip is only used to create the dump dir, then this is fine.
>Now I'm a bit concerned that kdumpip being embedded
inside the initramfs.
>kdumpip could be dynamic, but the initramfs isn't. This is probably
>okay? since it's only used to naming the dump dir...
>IIUC, now the dump dir's ip prefix could be out-of-sync
with the
>actual IP address of the machine when the dump happens, and will be in
>out-of-sync status for a long time until the initramfs get rebuilt.
>Just not sure if this will confuse anyone...
Thanks for coming up with this scenario! I thought in the case where we
have a different IP in the kdump kernel, the original IP of the 1st
kernel can better tell us where the dump happens. But I haven't took
the above scenario into consideration. How about we using FAQN i.e.
`hostname --fqdn` and the date to name the dumping folder instead?
--
Best regards,
Coiby