When dump target is re-formatted then its UUID changes. These patches add support to recognize such changes and then force initramfs rebuild, if dracut argument has an UUID based root location.
Pratyush Anand (2): kdumpctl: force rebuild in case of dynamic system modification kdumpctl: force rebuild in case of dump target modification
kdumpctl | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+)
There could be some dynamic system modification, which may affect kdump kernel boot process. In such situation initramfs must be rebulit on the basis of changes. Since most of these checking methods will use information from TARGET_INITRD, therefore check for its existence in common code.
Signed-off-by: Pratyush Anand panand@redhat.com --- kdumpctl | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/kdumpctl b/kdumpctl index ef18a2d4f6ce..614a816e344c 100755 --- a/kdumpctl +++ b/kdumpctl @@ -327,6 +327,13 @@ setup_target_initrd() fi }
+is_system_modified() +{ + [[ -f $TARGET_INITRD ]] || return 1 + + return 0 +} + check_rebuild() { local extra_modules modified_files="" @@ -388,6 +395,11 @@ check_rebuild() fi done
+ is_system_modified + if [ $? -ne 0 ]; then + force_rebuild="1" + fi + #check if target initrd has fadump support if [ "$DEFAULT_DUMP_MODE" = "fadump" ] && [ -f "$TARGET_INITRD" ]; then initramfs_has_fadump=`lsinitrd -m $TARGET_INITRD | grep ^kdumpbase$ | wc -l`
kdump also passes persistent device mapping as --mount or --device argument of dracut. However this persistent id (UUID) is changed if dump target is re-formated. kdumpctl must have a mechanism to recognise this modification, so that its service restart is able to rebuild initramfs.
Testing: * When raw target is raid device, dracut argument is passed as --device '/dev/mapper/xxxxx', and in this case it does not force rebuild after reformatting. vmcore save was also fine. * When raw target is an ide device, dracut argument is passed as --device '/dev/disk/by-uuid/xxxxx', and in this case it does force rebuild after reformatting. * Similar test was also performed as ext4, xfs and btrfs file system target.
One of the test case's detailed illustration: a) Attach an IDE device, lets say it is /dev/sdb1 b) Format it as ext4 # mkfs.ext4 /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf" TYPE="ext4" c) Mount it into /mnt and create a var/crash directory in it. # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash d) Add following line in /etc/kdump.conf ext4 /dev/sdb1 e) Restart kdumpctl # kdumpctl restart f) crash # echo c > /proc/sysrq-trigger g) Here you will be able save vmcore with or without this patch. h) repeat step (b), (c), (e) and (f) i) Now you will be able to save vmcore only when you have this patch in your kexec-tools. Your initramfs will be rebuilt when you repeat step (e) after reformatting.
Signed-off-by: Pratyush Anand panand@redhat.com --- kdumpctl | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/kdumpctl b/kdumpctl index 614a816e344c..060eed1233c5 100755 --- a/kdumpctl +++ b/kdumpctl @@ -327,10 +327,40 @@ setup_target_initrd() fi }
+is_dump_target_modified() +{ + target=$(egrep "^ext[234]|^xfs|^btrfs|^raw" /etc/kdump.conf) + + #if dump target does not exist then do not rebuild + [ -n "$target" ] || return 0 + + dracut_args=$(lsinitrd $TARGET_INITRD | grep "Arguments:") + #if --mount or --device is not by UUID, then also do not rebuild + echo $dracut_args | grep "by-uuid" &> /dev/null + [ $? -eq 0 ] || return 0 + + target=$(echo $target | cut -d ' ' -f 2) + uuid=$(blkid $target | awk -F"UUID=" '{print $2}' | cut -d '"' -f 2) + #if target does not have uuid, then also do not rebuild + [ -n $uuid ] || return 0 + + echo $dracut_args | grep $uuid &> /dev/null + #if dracut argument and target have same uuid, then also do not rebuild + [ $? -ne 0 ] || return 0 + + return 1 +} + is_system_modified() { [[ -f $TARGET_INITRD ]] || return 1
+ is_dump_target_modified + if [ $? -ne 0 ]; then + echo "Detected change in dump target" + return 1 + fi + return 0 }
On 2016/03/30 at 15:45, Pratyush Anand wrote:
kdump also passes persistent device mapping as --mount or --device argument of dracut. However this persistent id (UUID) is changed if dump target is re-formated. kdumpctl must have a mechanism to recognise this modification, so that its service restart is able to rebuild initramfs.
Testing:
- When raw target is raid device, dracut argument is passed as --device '/dev/mapper/xxxxx', and in this case it does not force rebuild after reformatting. vmcore save was also fine.
- When raw target is an ide device, dracut argument is passed as --device '/dev/disk/by-uuid/xxxxx', and in this case it does force rebuild after reformatting.
- Similar test was also performed as ext4, xfs and btrfs file system target.
One of the test case's detailed illustration: a) Attach an IDE device, lets say it is /dev/sdb1 b) Format it as ext4 # mkfs.ext4 /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf" TYPE="ext4" c) Mount it into /mnt and create a var/crash directory in it. # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash d) Add following line in /etc/kdump.conf ext4 /dev/sdb1 e) Restart kdumpctl # kdumpctl restart
Should we make this more intelligent? i.e. open a daemon, if detecting such modification(poll or better utilize some kernel notification mechanism), then restart dump automatically without user's manual intervention.
Regards, Xunlei
f) crash # echo c > /proc/sysrq-trigger g) Here you will be able save vmcore with or without this patch. h) repeat step (b), (c), (e) and (f) i) Now you will be able to save vmcore only when you have this patch in your kexec-tools. Your initramfs will be rebuilt when you repeat step (e) after reformatting.
Signed-off-by: Pratyush Anand panand@redhat.com
kdumpctl | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/kdumpctl b/kdumpctl index 614a816e344c..060eed1233c5 100755 --- a/kdumpctl +++ b/kdumpctl @@ -327,10 +327,40 @@ setup_target_initrd() fi }
+is_dump_target_modified() +{
- target=$(egrep "^ext[234]|^xfs|^btrfs|^raw" /etc/kdump.conf)
- #if dump target does not exist then do not rebuild
- [ -n "$target" ] || return 0
- dracut_args=$(lsinitrd $TARGET_INITRD | grep "Arguments:")
- #if --mount or --device is not by UUID, then also do not rebuild
- echo $dracut_args | grep "by-uuid" &> /dev/null
- [ $? -eq 0 ] || return 0
- target=$(echo $target | cut -d ' ' -f 2)
- uuid=$(blkid $target | awk -F"UUID=" '{print $2}' | cut -d '"' -f 2)
- #if target does not have uuid, then also do not rebuild
- [ -n $uuid ] || return 0
- echo $dracut_args | grep $uuid &> /dev/null
- #if dracut argument and target have same uuid, then also do not rebuild
- [ $? -ne 0 ] || return 0
- return 1
+}
is_system_modified() { [[ -f $TARGET_INITRD ]] || return 1
- is_dump_target_modified
- if [ $? -ne 0 ]; then
echo "Detected change in dump target"return 1- fi
- return 0
}
On 2016/04/01 at 09:51, Xunlei Pang wrote:
On 2016/03/30 at 15:45, Pratyush Anand wrote:
kdump also passes persistent device mapping as --mount or --device argument of dracut. However this persistent id (UUID) is changed if dump target is re-formated. kdumpctl must have a mechanism to recognise this modification, so that its service restart is able to rebuild initramfs.
Testing:
- When raw target is raid device, dracut argument is passed as --device '/dev/mapper/xxxxx', and in this case it does not force rebuild after reformatting. vmcore save was also fine.
- When raw target is an ide device, dracut argument is passed as --device '/dev/disk/by-uuid/xxxxx', and in this case it does force rebuild after reformatting.
- Similar test was also performed as ext4, xfs and btrfs file system target.
One of the test case's detailed illustration: a) Attach an IDE device, lets say it is /dev/sdb1 b) Format it as ext4 # mkfs.ext4 /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf" TYPE="ext4" c) Mount it into /mnt and create a var/crash directory in it. # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash d) Add following line in /etc/kdump.conf ext4 /dev/sdb1 e) Restart kdumpctl # kdumpctl restart
Should we make this more intelligent? i.e. open a daemon, if detecting such modification(poll or better utilize some kernel notification mechanism), then restart dump automatically without user's manual intervention.
Some further illustration: Not just for UUID, but also for other kdump-related files, at least for files, filesystems have the mechanism to notify the changing. I think it's doable.
Regards, Xunlei
Regards, Xunlei
f) crash # echo c > /proc/sysrq-trigger g) Here you will be able save vmcore with or without this patch. h) repeat step (b), (c), (e) and (f) i) Now you will be able to save vmcore only when you have this patch in your kexec-tools. Your initramfs will be rebuilt when you repeat step (e) after reformatting.
Signed-off-by: Pratyush Anand panand@redhat.com
kdumpctl | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/kdumpctl b/kdumpctl index 614a816e344c..060eed1233c5 100755 --- a/kdumpctl +++ b/kdumpctl @@ -327,10 +327,40 @@ setup_target_initrd() fi }
+is_dump_target_modified() +{
- target=$(egrep "^ext[234]|^xfs|^btrfs|^raw" /etc/kdump.conf)
- #if dump target does not exist then do not rebuild
- [ -n "$target" ] || return 0
- dracut_args=$(lsinitrd $TARGET_INITRD | grep "Arguments:")
- #if --mount or --device is not by UUID, then also do not rebuild
- echo $dracut_args | grep "by-uuid" &> /dev/null
- [ $? -eq 0 ] || return 0
- target=$(echo $target | cut -d ' ' -f 2)
- uuid=$(blkid $target | awk -F"UUID=" '{print $2}' | cut -d '"' -f 2)
- #if target does not have uuid, then also do not rebuild
- [ -n $uuid ] || return 0
- echo $dracut_args | grep $uuid &> /dev/null
- #if dracut argument and target have same uuid, then also do not rebuild
- [ $? -ne 0 ] || return 0
- return 1
+}
is_system_modified() { [[ -f $TARGET_INITRD ]] || return 1
- is_dump_target_modified
- if [ $? -ne 0 ]; then
echo "Detected change in dump target"return 1- fi
- return 0
}
kexec mailing list kexec@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Hi Xunlei,
On 01/04/2016:10:13:38 AM, Xunlei Pang wrote:
Some further illustration: Not just for UUID, but also for other kdump-related files, at least for files, filesystems have the mechanism to notify the changing. I think it's doable.
Sorry, probably I could not understand it. Currently, kdumpctrl is already checking changes in /etc/kdump.conf. Other than that which kdump related files do we need to check?
Or may be you meant to check for /etc/kdump.conf in daemon which we intend to implement? Yes, that should be doable and a good point to take. Thanks :-)
~Pratyush
On 2016/04/01 at 11:59, Pratyush Anand wrote:
Hi Xunlei,
On 01/04/2016:10:13:38 AM, Xunlei Pang wrote:
Some further illustration: Not just for UUID, but also for other kdump-related files, at least for files, filesystems have the mechanism to notify the changing. I think it's doable.
Sorry, probably I could not understand it. Currently, kdumpctrl is already checking changes in /etc/kdump.conf. Other than that which kdump related files do we need to check?
Or may be you meant to check for /etc/kdump.conf in daemon which we intend to implement? Yes, that should be doable and a good point to take. Thanks :-)
Yes, this is what I meant.
Regards, Xunlei
~Pratyush
Hi Xunlei,
Thanks for your review.
On 01/04/2016:09:51:50 AM, Xunlei Pang wrote:
On 2016/03/30 at 15:45, Pratyush Anand wrote:
kdump also passes persistent device mapping as --mount or --device argument of dracut. However this persistent id (UUID) is changed if dump target is re-formated. kdumpctl must have a mechanism to recognise this modification, so that its service restart is able to rebuild initramfs.
Testing:
- When raw target is raid device, dracut argument is passed as --device '/dev/mapper/xxxxx', and in this case it does not force rebuild after reformatting. vmcore save was also fine.
- When raw target is an ide device, dracut argument is passed as --device '/dev/disk/by-uuid/xxxxx', and in this case it does force rebuild after reformatting.
- Similar test was also performed as ext4, xfs and btrfs file system target.
One of the test case's detailed illustration: a) Attach an IDE device, lets say it is /dev/sdb1 b) Format it as ext4 # mkfs.ext4 /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf" TYPE="ext4" c) Mount it into /mnt and create a var/crash directory in it. # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash d) Add following line in /etc/kdump.conf ext4 /dev/sdb1 e) Restart kdumpctl # kdumpctl restart
Should we make this more intelligent? i.e. open a daemon, if detecting such modification(poll or better utilize some kernel notification mechanism), then restart dump automatically without user's manual intervention.
Yes, this is on agenda and will be done after active watchdog detection patches are also upstreamed.
~Pratyush
On 2016/04/01 at 11:51, Pratyush Anand wrote:
Hi Xunlei,
Thanks for your review.
On 01/04/2016:09:51:50 AM, Xunlei Pang wrote:
On 2016/03/30 at 15:45, Pratyush Anand wrote:
kdump also passes persistent device mapping as --mount or --device argument of dracut. However this persistent id (UUID) is changed if dump target is re-formated. kdumpctl must have a mechanism to recognise this modification, so that its service restart is able to rebuild initramfs.
Testing:
- When raw target is raid device, dracut argument is passed as --device '/dev/mapper/xxxxx', and in this case it does not force rebuild after reformatting. vmcore save was also fine.
- When raw target is an ide device, dracut argument is passed as --device '/dev/disk/by-uuid/xxxxx', and in this case it does force rebuild after reformatting.
- Similar test was also performed as ext4, xfs and btrfs file system target.
One of the test case's detailed illustration: a) Attach an IDE device, lets say it is /dev/sdb1 b) Format it as ext4 # mkfs.ext4 /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf" TYPE="ext4" c) Mount it into /mnt and create a var/crash directory in it. # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash d) Add following line in /etc/kdump.conf ext4 /dev/sdb1 e) Restart kdumpctl # kdumpctl restart
Should we make this more intelligent? i.e. open a daemon, if detecting such modification(poll or better utilize some kernel notification mechanism), then restart dump automatically without user's manual intervention.
Yes, this is on agenda and will be done after active watchdog detection patches are also upstreamed.
Glad to hear that. Very cool~
Regards, Xunlei
~Pratyush
On 04/01/16 at 09:21am, Pratyush Anand wrote:
Hi Xunlei,
Thanks for your review.
On 01/04/2016:09:51:50 AM, Xunlei Pang wrote:
On 2016/03/30 at 15:45, Pratyush Anand wrote:
kdump also passes persistent device mapping as --mount or --device argument of dracut. However this persistent id (UUID) is changed if dump target is re-formated. kdumpctl must have a mechanism to recognise this modification, so that its service restart is able to rebuild initramfs.
Testing:
- When raw target is raid device, dracut argument is passed as --device '/dev/mapper/xxxxx', and in this case it does not force rebuild after reformatting. vmcore save was also fine.
- When raw target is an ide device, dracut argument is passed as --device '/dev/disk/by-uuid/xxxxx', and in this case it does force rebuild after reformatting.
- Similar test was also performed as ext4, xfs and btrfs file system target.
One of the test case's detailed illustration: a) Attach an IDE device, lets say it is /dev/sdb1 b) Format it as ext4 # mkfs.ext4 /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf" TYPE="ext4" c) Mount it into /mnt and create a var/crash directory in it. # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash d) Add following line in /etc/kdump.conf ext4 /dev/sdb1 e) Restart kdumpctl # kdumpctl restart
Should we make this more intelligent? i.e. open a daemon, if detecting such modification(poll or better utilize some kernel notification mechanism), then restart dump automatically without user's manual intervention.
Yes, this is on agenda and will be done after active watchdog detection patches are also upstreamed.
We can keep it in mind, it will even increase the kdump scripts complexity. If we automaticlly detect changes for filesystem, one will say how about detect network changes as well. There are a lot of different cases for storage and networking They will increase the complexity even more. Also we may have to add another systemd service to handle it. Most of the daemon are written in C, shell may not be a good choice, using bash we need a sleep/loop...
How about handle these case by case and maybe we can do it only when there are such reports in the future?
Thanks Dave
Hi Dave,
Thanks for your valuable feedback.
On 01/04/2016:05:03:27 PM, Dave Young wrote:
On 04/01/16 at 09:21am, Pratyush Anand wrote:
Hi Xunlei,
Thanks for your review.
On 01/04/2016:09:51:50 AM, Xunlei Pang wrote:
On 2016/03/30 at 15:45, Pratyush Anand wrote:
kdump also passes persistent device mapping as --mount or --device argument of dracut. However this persistent id (UUID) is changed if dump target is re-formated. kdumpctl must have a mechanism to recognise this modification, so that its service restart is able to rebuild initramfs.
Testing:
- When raw target is raid device, dracut argument is passed as --device '/dev/mapper/xxxxx', and in this case it does not force rebuild after reformatting. vmcore save was also fine.
- When raw target is an ide device, dracut argument is passed as --device '/dev/disk/by-uuid/xxxxx', and in this case it does force rebuild after reformatting.
- Similar test was also performed as ext4, xfs and btrfs file system target.
One of the test case's detailed illustration: a) Attach an IDE device, lets say it is /dev/sdb1 b) Format it as ext4 # mkfs.ext4 /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf" TYPE="ext4" c) Mount it into /mnt and create a var/crash directory in it. # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash d) Add following line in /etc/kdump.conf ext4 /dev/sdb1 e) Restart kdumpctl # kdumpctl restart
Should we make this more intelligent? i.e. open a daemon, if detecting such modification(poll or better utilize some kernel notification mechanism), then restart dump automatically without user's manual intervention.
Yes, this is on agenda and will be done after active watchdog detection patches are also upstreamed.
We can keep it in mind, it will even increase the kdump scripts complexity. If we automaticlly detect changes for filesystem, one will say how about detect network changes as well. There are a lot of different cases for storage and networking They will increase the complexity even more. Also we may have to add another systemd service to handle it. Most of the daemon are written in C, shell may not be a good choice, using bash we need a sleep/loop...
OK, that I can explore when will start implementing it. I would also be more comfortable in writing C code :-).
How about handle these case by case and maybe we can do it only when there are such reports in the future?
Yes, agreed.
~Pratyush
Hi, Pratyush
On 04/01/16 at 02:57pm, Pratyush Anand wrote:
Hi Dave,
Thanks for your valuable feedback.
On 01/04/2016:05:03:27 PM, Dave Young wrote:
On 04/01/16 at 09:21am, Pratyush Anand wrote:
Hi Xunlei,
Thanks for your review.
On 01/04/2016:09:51:50 AM, Xunlei Pang wrote:
On 2016/03/30 at 15:45, Pratyush Anand wrote:
kdump also passes persistent device mapping as --mount or --device argument of dracut. However this persistent id (UUID) is changed if dump target is re-formated. kdumpctl must have a mechanism to recognise this modification, so that its service restart is able to rebuild initramfs.
Testing:
- When raw target is raid device, dracut argument is passed as --device '/dev/mapper/xxxxx', and in this case it does not force rebuild after reformatting. vmcore save was also fine.
- When raw target is an ide device, dracut argument is passed as --device '/dev/disk/by-uuid/xxxxx', and in this case it does force rebuild after reformatting.
- Similar test was also performed as ext4, xfs and btrfs file system target.
One of the test case's detailed illustration: a) Attach an IDE device, lets say it is /dev/sdb1 b) Format it as ext4 # mkfs.ext4 /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf" TYPE="ext4" c) Mount it into /mnt and create a var/crash directory in it. # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash d) Add following line in /etc/kdump.conf ext4 /dev/sdb1 e) Restart kdumpctl # kdumpctl restart
Should we make this more intelligent? i.e. open a daemon, if detecting such modification(poll or better utilize some kernel notification mechanism), then restart dump automatically without user's manual intervention.
Yes, this is on agenda and will be done after active watchdog detection patches are also upstreamed.
We can keep it in mind, it will even increase the kdump scripts complexity. If we automaticlly detect changes for filesystem, one will say how about detect network changes as well. There are a lot of different cases for storage and networking They will increase the complexity even more. Also we may have to add another systemd service to handle it. Most of the daemon are written in C, shell may not be a good choice, using bash we need a sleep/loop...
OK, that I can explore when will start implementing it. I would also be more comfortable in writing C code :-).
Ok, thanks a lot! We can do it if we have strong reason to do it later.
How about handle these case by case and maybe we can do it only when there are such reports in the future?
Yes, agreed.
~Pratyush _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Hi, Pratyush
Thanks for the patches, see a few comments inline..
On 03/30/16 at 01:15pm, Pratyush Anand wrote:
kdump also passes persistent device mapping as --mount or --device argument of dracut. However this persistent id (UUID) is changed if dump target is re-formated. kdumpctl must have a mechanism to recognise this modification, so that its service restart is able to rebuild initramfs.
Testing:
- When raw target is raid device, dracut argument is passed as --device '/dev/mapper/xxxxx', and in this case it does not force rebuild after reformatting. vmcore save was also fine.
- When raw target is an ide device, dracut argument is passed as --device '/dev/disk/by-uuid/xxxxx', and in this case it does force rebuild after reformatting.
- Similar test was also performed as ext4, xfs and btrfs file system target.
One of the test case's detailed illustration: a) Attach an IDE device, lets say it is /dev/sdb1 b) Format it as ext4 # mkfs.ext4 /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf" TYPE="ext4" c) Mount it into /mnt and create a var/crash directory in it. # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash d) Add following line in /etc/kdump.conf ext4 /dev/sdb1 e) Restart kdumpctl # kdumpctl restart f) crash # echo c > /proc/sysrq-trigger g) Here you will be able save vmcore with or without this patch. h) repeat step (b), (c), (e) and (f) i) Now you will be able to save vmcore only when you have this patch in your kexec-tools. Your initramfs will be rebuilt when you repeat step (e) after reformatting.
Signed-off-by: Pratyush Anand panand@redhat.com
kdumpctl | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/kdumpctl b/kdumpctl index 614a816e344c..060eed1233c5 100755 --- a/kdumpctl +++ b/kdumpctl @@ -327,10 +327,40 @@ setup_target_initrd() fi }
+is_dump_target_modified() +{
- target=$(egrep "^ext[234]|^xfs|^btrfs|^raw" /etc/kdump.conf)
All the vars should be local in the function btw use the function below should be better: _target=$(local_fs_dump_target)
raw is not necessary because we do not care the filesystem on it.
- #if dump target does not exist then do not rebuild
- [ -n "$target" ] || return 0
- dracut_args=$(lsinitrd $TARGET_INITRD | grep "Arguments:")
grep "^Arguments:"|head -1 should be better
Is the "Arguments:" in lsinitrd output reliable? If Dracut changes the output it will fail. Maybe we can add a sanity check about dracut_args, if it is nul or something invalid (ie. without hostonly)then return 0 and give out a warning
- #if --mount or --device is not by UUID, then also do not rebuild
- echo $dracut_args | grep "by-uuid" &> /dev/null
- [ $? -eq 0 ] || return 0
- target=$(echo $target | cut -d ' ' -f 2)
it will be not necessary using $(local_fs_dump_target) in previous code..
- uuid=$(blkid $target | awk -F"UUID=" '{print $2}' | cut -d '"' -f 2)
- #if target does not have uuid, then also do not rebuild
- [ -n $uuid ] || return 0
If it does not have uuid, there must be something wrong, should warning and return 1?
- echo $dracut_args | grep $uuid &> /dev/null
- #if dracut argument and target have same uuid, then also do not rebuild
- [ $? -ne 0 ] || return 0
- return 1
+}
is_system_modified() { [[ -f $TARGET_INITRD ]] || return 1
- is_dump_target_modified
- if [ $? -ne 0 ]; then
echo "Detected change in dump target"return 1- fi
- return 0
}
-- 2.5.0 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
Thanks Dave
Hi Dave,
On 01/04/2016:04:55:39 PM, Dave Young wrote:
Hi, Pratyush
Thanks for the patches, see a few comments inline..
On 03/30/16 at 01:15pm, Pratyush Anand wrote:
kdump also passes persistent device mapping as --mount or --device argument of dracut. However this persistent id (UUID) is changed if dump target is re-formated. kdumpctl must have a mechanism to recognise this modification, so that its service restart is able to rebuild initramfs.
Testing:
- When raw target is raid device, dracut argument is passed as --device '/dev/mapper/xxxxx', and in this case it does not force rebuild after reformatting. vmcore save was also fine.
- When raw target is an ide device, dracut argument is passed as --device '/dev/disk/by-uuid/xxxxx', and in this case it does force rebuild after reformatting.
- Similar test was also performed as ext4, xfs and btrfs file system target.
One of the test case's detailed illustration: a) Attach an IDE device, lets say it is /dev/sdb1 b) Format it as ext4 # mkfs.ext4 /dev/sdb1 # blkid /dev/sdb1 /dev/sdb1: UUID="21c7baff-e35d-49c7-aa08-0fba4513f5bf" TYPE="ext4" c) Mount it into /mnt and create a var/crash directory in it. # mount /dev/sdb1 /mnt;mkdir /mnt/var;mkdir /mnt/var/crash d) Add following line in /etc/kdump.conf ext4 /dev/sdb1 e) Restart kdumpctl # kdumpctl restart f) crash # echo c > /proc/sysrq-trigger g) Here you will be able save vmcore with or without this patch. h) repeat step (b), (c), (e) and (f) i) Now you will be able to save vmcore only when you have this patch in your kexec-tools. Your initramfs will be rebuilt when you repeat step (e) after reformatting.
Signed-off-by: Pratyush Anand panand@redhat.com
kdumpctl | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
diff --git a/kdumpctl b/kdumpctl index 614a816e344c..060eed1233c5 100755 --- a/kdumpctl +++ b/kdumpctl @@ -327,10 +327,40 @@ setup_target_initrd() fi }
+is_dump_target_modified() +{
- target=$(egrep "^ext[234]|^xfs|^btrfs|^raw" /etc/kdump.conf)
All the vars should be local in the function
I thought, by default they are local. OK.Will improve in V2.
btw use the function below should be better: _target=$(local_fs_dump_target)
raw is not necessary because we do not care the filesystem on it.
I had thought of using it, but did not use as (1) We also need to take care of "raw". I agree it is filesystem independent, but UUID of a /dev/sdxn device changes after any type of formatting. So, even if /etc/kdump.conf has raw entry, it will not work if disk is re-formatted. (2) for minix, I am not sure if we need to handle it. It does not have UUID, rather it has PARTUUID field which does not change after reformatting.
[root@localhost panand]# mkfs.minix /dev/sdb1 21856 inodes 65535 blocks Firstdatazone=696 (696) Zonesize=1024 Maxsize=268966912
[root@localhost panand]# blkid /dev/sdb1 /dev/sdb1: TYPE="minix" PARTUUID="3c66e385-01" [root@localhost panand]# mkfs.minix /dev/sdb1 21856 inodes 65535 blocks Firstdatazone=696 (696) Zonesize=1024 Maxsize=268966912
[root@localhost panand]# blkid /dev/sdb1 /dev/sdb1: TYPE="minix" PARTUUID="3c66e385-01"
- #if dump target does not exist then do not rebuild
- [ -n "$target" ] || return 0
- dracut_args=$(lsinitrd $TARGET_INITRD | grep "Arguments:")
grep "^Arguments:"|head -1 should be better
OK.
Is the "Arguments:" in lsinitrd output reliable? If Dracut changes the output it will fail. Maybe we can add a sanity check about dracut_args, if it is nul or something invalid (ie. without hostonly)then return 0 and give out a warning
OK.
- #if --mount or --device is not by UUID, then also do not rebuild
- echo $dracut_args | grep "by-uuid" &> /dev/null
- [ $? -eq 0 ] || return 0
- target=$(echo $target | cut -d ' ' -f 2)
it will be not necessary using $(local_fs_dump_target) in previous code..
Yes, but $(local_fs_dump_target) might not be usable.
- uuid=$(blkid $target | awk -F"UUID=" '{print $2}' | cut -d '"' -f 2)
- #if target does not have uuid, then also do not rebuild
- [ -n $uuid ] || return 0
If it does not have uuid, there must be something wrong, should warning and return 1?
Initially I had thought of using is_dump_target_configured(), so had put this line for "minix" and "nfs", but I think now this line is not needed, or may be what you say.
- echo $dracut_args | grep $uuid &> /dev/null
- #if dracut argument and target have same uuid, then also do not rebuild
- [ $? -ne 0 ] || return 0
- return 1
+}
is_system_modified() { [[ -f $TARGET_INITRD ]] || return 1
- is_dump_target_modified
- if [ $? -ne 0 ]; then
echo "Detected change in dump target"return 1- fi
- return 0
}
-- 2.5.0 _______________________________________________ kexec mailing list kexec@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org
~Pratyush
Hi, Pratyush
+is_dump_target_modified() +{
- target=$(egrep "^ext[234]|^xfs|^btrfs|^raw" /etc/kdump.conf)
All the vars should be local in the function
I thought, by default they are local. OK.Will improve in V2.
btw use the function below should be better: _target=$(local_fs_dump_target)
raw is not necessary because we do not care the filesystem on it.
I had thought of using it, but did not use as (1) We also need to take care of "raw". I agree it is filesystem independent, but UUID of a /dev/sdxn device changes after any type of formatting. So, even if /etc/kdump.conf has raw entry, it will not work if disk is re-formatted.
It sounds odd to use "raw UUID=" in kdump.conf, but lvm volume name should be fine since it is persistent.
Hmm, does that mean even if for "raw /dev/sdb1" in kdump.conf, kdump still uses UUID in kdump initrd in case there is a filesystem on /dev/sdb1?
(2) for minix, I am not sure if we need to handle it. It does not have UUID, rather it has PARTUUID field which does not change after reformatting.
Yes, Agreed that we can ignore minix.
Thanks Dave
Hi Dave,
On 05/04/2016:02:39:13 PM, Dave Young wrote:
Hi, Pratyush
+is_dump_target_modified() +{
- target=$(egrep "^ext[234]|^xfs|^btrfs|^raw" /etc/kdump.conf)
All the vars should be local in the function
I thought, by default they are local. OK.Will improve in V2.
btw use the function below should be better: _target=$(local_fs_dump_target)
raw is not necessary because we do not care the filesystem on it.
I had thought of using it, but did not use as (1) We also need to take care of "raw". I agree it is filesystem independent, but UUID of a /dev/sdxn device changes after any type of formatting. So, even if /etc/kdump.conf has raw entry, it will not work if disk is re-formatted.
It sounds odd to use "raw UUID=" in kdump.conf, but lvm volume name should be fine since it is persistent.
Hmm, does that mean even if for "raw /dev/sdb1" in kdump.conf, kdump still uses UUID in kdump initrd in case there is a filesystem on /dev/sdb1?
Yes. This is what I observed.
~Pratyush
Hi, Pratyush
On 04/05/16 at 12:27pm, Pratyush Anand wrote:
Hi Dave,
On 05/04/2016:02:39:13 PM, Dave Young wrote:
Hi, Pratyush
+is_dump_target_modified() +{
- target=$(egrep "^ext[234]|^xfs|^btrfs|^raw" /etc/kdump.conf)
All the vars should be local in the function
I thought, by default they are local. OK.Will improve in V2.
btw use the function below should be better: _target=$(local_fs_dump_target)
raw is not necessary because we do not care the filesystem on it.
I had thought of using it, but did not use as (1) We also need to take care of "raw". I agree it is filesystem independent, but UUID of a /dev/sdxn device changes after any type of formatting. So, even if /etc/kdump.conf has raw entry, it will not work if disk is re-formatted.
It sounds odd to use "raw UUID=" in kdump.conf, but lvm volume name should be fine since it is persistent.
Hmm, does that mean even if for "raw /dev/sdb1" in kdump.conf, kdump still uses UUID in kdump initrd in case there is a filesystem on /dev/sdb1?
Yes. This is what I observed.
How about fix it to avoid "uuid" and "label" for raw devices? we can use persistent dev names other than filsystem label and uuid eg. by-id/ or by-path/
So that even if the uuid changed we do not need to rebuild kdump initrd for "raw" because raw devices do not care about the backing filesystem..
Thanks Dave
Hi Dave,
On 05/04/2016:03:34:35 PM, Dave Young wrote:
Hi, Pratyush
On 04/05/16 at 12:27pm, Pratyush Anand wrote:
Hi Dave,
On 05/04/2016:02:39:13 PM, Dave Young wrote:
Hi, Pratyush
+is_dump_target_modified() +{
- target=$(egrep "^ext[234]|^xfs|^btrfs|^raw" /etc/kdump.conf)
All the vars should be local in the function
I thought, by default they are local. OK.Will improve in V2.
btw use the function below should be better: _target=$(local_fs_dump_target)
raw is not necessary because we do not care the filesystem on it.
I had thought of using it, but did not use as (1) We also need to take care of "raw". I agree it is filesystem independent, but UUID of a /dev/sdxn device changes after any type of formatting. So, even if /etc/kdump.conf has raw entry, it will not work if disk is re-formatted.
It sounds odd to use "raw UUID=" in kdump.conf, but lvm volume name should be fine since it is persistent.
Hmm, does that mean even if for "raw /dev/sdb1" in kdump.conf, kdump still uses UUID in kdump initrd in case there is a filesystem on /dev/sdb1?
Yes. This is what I observed.
How about fix it to avoid "uuid" and "label" for raw devices? we can use persistent dev names other than filsystem label and uuid eg. by-id/ or by-path/
So that even if the uuid changed we do not need to rebuild kdump initrd for "raw" because raw devices do not care about the backing filesystem..
Seems reasonable.
OK, Will do.
Thanks for the feedback.
~Pratyush
-
Dave Young -
Pratyush Anand -
Xunlei Pang