On Wed, Apr 27, 2016 at 6:10 PM, Xunlei Pang xpang@redhat.com wrote:
On 2016/04/27 at 20:10, Pratyush Anand wrote:
On Wed, Apr 27, 2016 at 4:56 PM, Xunlei Pang xpang@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.
For example, I just tested on my laptop: cat /etc/kdump.conf #raw /dev/vg/lv_kdump #ext4 /dev/vg/lv_kdump #xfs /dev/mapper/rhel-root #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937 #nfs 10.66.129.115:/export/nfs #ssh user@my.server.com #sshkey /root/.ssh/kdump_id_rsa path /var/crash
Initailly it was mounted as: /dev/mapper/rhel-swap on /var/crash type ext2 (rw,relatime,seclabel)
Then I unmounted /var/crash and changed /dev/mapper/rhel-swap to a ext4 using mkfs.ext4: /dev/mapper/rhel-swap on /var/crash type ext4 (rw,relatime,seclabel,data=ordered)
After that, I did kdumpctl restart, it didn't trigger the rebuilding.
Actually, though "/dev/mapper/rhel-swap" device mapper name was not changed, but its(dm-1's) uuid (and filesystem) has been changed.
Got It :-)
Thanks for the creating a scenario. Will send a follow-up patch to resolve it.
~Pratyush