On Wed, Apr 27, 2016 at 4:56 PM, Xunlei Pang <xpang(a)redhat.com> wrote:
On 2016/04/27 at 17:23, Pratyush Anand wrote:
>> Additionally, for device mappers, if they got reformatted,
because the persistent name
>> is from "/dev/mapper" not from "/dev/disk/by-uuid", will
"return 0" here, not rebuilt.
>> Should we handle this?
>>
> we do not need to rebuild in that case. Persistent name would be valid
> and so dracut will create valid root mount point.
Yes, but if a device mapper device is reformatted to be a different filesystem,
its uuid is changed(after remount, its fstype changes), then user restart kdump,
shouldn't we trigger rebuilding to update its mount fstype passed to dracut?
Yes, I agree if above could be a valid scenario then we need to
rebuild in that case. I am not sure how to generate above scenario.
If you can help with a scenario for generating above issue, I can
cook a patch to resolve. Moreever, should we also not required to
change the filesystem type in kdump.conf?
This is what my understanding is:
-- When we pass filesystem type and target device (like ext4
/dev/sdb1) in kdump.conf, then kexec-tools passes --mount as
'/dev/disk/by-uuid/...'. So, whenever we will reformat even with
different filesystem, UUID will change and there will be a rebuild.
-- If we do not pass filesystem type, but "dump path" (like
/var/crash) mounts a device other than the device which mounts root,
then also kexec-tools passes --mount as '/dev/disk/by-uuid/...'. So,
in that case as well it will rebuild after reformatting.
-- kexec-tools does not pass --mount or --device when both "dump
path" and root path mounts same device.
~Pratyush