[PATCH] get_ssh_size fix for localized df output
by Dave Young
When kdump service is started, /sbin/mkdump checks if there is enough
free space on the ssh server using "df -P" command.
However, the slight difference in the first line of the "df -P" command
output for English and Japanese environment causes a problem.
-----
# LANG=en_us.utf8 df -P | head -1
Filesystem 1024-blocks Used Available Capacity Mount on
# LANG=ja_JP.utf8 df -P | head -1
ファイルシス 1024-ブロック 使用 使用可 容量 マウント位置
-----
Because the number of words is 7 in the English output and 6 in
Japanese, the subsequent awk command could not correctly locate the
free space field and results in an error.
One way to fix it is use df -P /var/crash|tail -1, but for remote restricted
shell pipe is not supported. Thus fix this by print field NF-2 in awk script.
Signed-off-by: Dave Young <dyoung(a)redhat.com>
---
mkdumprd | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- kexec-tools.orig/mkdumprd
+++ kexec-tools/mkdumprd
@@ -142,8 +142,9 @@ get_ssh_size() {
[ $? -ne 0 ] && {
perror_exit "checking remote ssh server available size failed."
}
- #ssh output removed the line break, so print $11 instead of $4
- _size=$(echo -n $_out|tail -1 | awk '{print $11}')
+
+ #ssh output removed the line break, so print field NF-2
+ _size=$(echo -n $_out| awk '{avail=NF-2; print $avail}')
echo -n $_size
}
10 years, 1 month
[PATCH] Backport vmcore-dmsg stack smashing in extreme case
by Arthur Zou
Resolves bz1071376
In exteme case vmcore-dmesg will overflow. upstream has fixed the
some problem. so simply backport it
Signed-off-by: Arthur Zou <zzou(a)redhat.com>
---
...sg-stack-smashing-happend-in-extreme-case.patch | 43 ++++++++++++++++++++++
kexec-tools.spec | 2 +
2 files changed, 45 insertions(+)
create mode 100644 kexec-tools-2.0.4-vmcore-dmesg-stack-smashing-happend-in-extreme-case.patch
diff --git a/kexec-tools-2.0.4-vmcore-dmesg-stack-smashing-happend-in-extreme-case.patch b/kexec-tools-2.0.4-vmcore-dmesg-stack-smashing-happend-in-extreme-case.patch
new file mode 100644
index 0000000..044cb61
--- /dev/null
+++ b/kexec-tools-2.0.4-vmcore-dmesg-stack-smashing-happend-in-extreme-case.patch
@@ -0,0 +1,43 @@
+From 401e037e5e9527134c594b8923342a69ff38b7cb Mon Sep 17 00:00:00 2001
+From: Arthur Zou <zzou(a)redhat.com>
+Date: Wed, 12 Mar 2014 13:05:18 +0800
+Subject: [PATCH] vmcore-dmesg stack smashing happend in extreme case
+
+Description
+in dump_dmesg_structured() the out_buf size is 4096, and if the
+length is less than 4080( 4096-16 ) it won't really write out.
+Normally, after writing one or four chars to the out_buf, it will
+check the length of out_buf. But in extreme cases, 19 chars was
+written to the out_buf before checking the length. This may cause
+the stack corruption. If the length was 4079 (won't realy write out),
+and then write 19 chars to it. the out_buf will overflow.
+
+Solution
+Change 16 to 64 thus can make sure that always have 64bytes before
+moving to next records. why using 64 is that a long long int can take
+20 bytes. so the length of timestamp can be 44 ('[','.',']',' ') in
+extreme case.
+
+Signed-off-by: Arthur Zou <zzou(a)redhat.com>
+Acked-by: Vivek Goyal <vgoyal(a)redhat.com>
+Signed-off-by: Simon Horman <horms(a)verge.net.au>
+---
+ vmcore-dmesg/vmcore-dmesg.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/vmcore-dmesg/vmcore-dmesg.c b/vmcore-dmesg/vmcore-dmesg.c
+index 0345660..e15cd91 100644
+--- a/vmcore-dmesg/vmcore-dmesg.c
++++ b/vmcore-dmesg/vmcore-dmesg.c
+@@ -674,7 +674,7 @@ static void dump_dmesg_structured(int fd)
+ else
+ out_buf[len++] = c;
+
+- if (len >= OUT_BUF_SIZE - 16) {
++ if (len >= OUT_BUF_SIZE - 64) {
+ write_to_stdout(out_buf, len);
+ len = 0;
+ }
+--
+1.8.4.2
+
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 1a8f849..ba4589c 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -97,6 +97,7 @@ Patch615: kexec-tools-2.0.4-makedumpfile-Add-non-mmap-option-to-disable-mmap-man
Patch616: kexec-tools-2.0.4-makedumpfile-Fall-back-to-read-when-mmap-fails.patch
Patch617: kexec-tools-2.0.4-vmcore-dmesg-struct_val_u64-not-casting-u64-to-u32.patch
Patch618: kexec-tools-2.0.4-makedumpfile-Improve-progress-information-for-huge-memor.patch
+Patch619: kexec-tools-2.0.4-vmcore-dmesg-stack-smashing-happend-in-extreme-case.patch
%description
kexec-tools provides /sbin/kexec binary that facilitates a new
@@ -146,6 +147,7 @@ tar -z -x -v -f %{SOURCE19}
%patch616 -p1
%patch617 -p1
%patch618 -p1
+%patch619 -p1
tar -z -x -v -f %{SOURCE13}
--
1.8.4.2
10 years, 1 month
[Patch v3 1/3] kdump-lib.sh: introduce two functions abstracted from get_block_dump_target for reuse
by Baoquan He
In function get_block_dump_target(), code block to get user configured
dump disk and get root fs device can be reused by other places. Now
abstract and wrap them into 2 new functions:
get_user_configured_dump_disk()
get_root_fs_device()
And put them into kdump-lib.sh.
Meanwhile change the get_block_dump_target() accordingly.
Signed-off-by: Baoquan He <bhe(a)redhat.com>
---
kdump-lib.sh | 24 ++++++++++++++++++++++++
mkdumprd | 7 ++-----
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/kdump-lib.sh b/kdump-lib.sh
index aac0c5f..384f7b4 100755
--- a/kdump-lib.sh
+++ b/kdump-lib.sh
@@ -37,3 +37,27 @@ is_fence_kdump()
# fence kdump not configured?
(pcs cluster cib | grep -q 'type="fence_kdump"') &> /dev/null || return 1
}
+
+get_user_configured_dump_disk()
+{
+ local _target
+
+ if is_ssh_dump_target || is_nfs_dump_target; then
+ return
+ fi
+
+ _target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw" /etc/kdump.conf 2>/dev/null |awk '{print $2}')
+ [ -n "$_target" ] && echo $_target
+
+ return
+}
+
+get_root_fs_device()
+{
+ local _target
+ _target=$(findmnt -k -f -n -o SOURCE /)
+ [ -n "$_target" ] && echo $_target
+
+ return
+}
+
diff --git a/mkdumprd b/mkdumprd
index 6797791..0b71391 100644
--- a/mkdumprd
+++ b/mkdumprd
@@ -346,15 +346,12 @@ get_block_dump_target()
{
local _target
- if is_ssh_dump_target || is_nfs_dump_target; then
- return
- fi
- _target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw" /etc/kdump.conf 2>/dev/null |awk '{print $2}')
+ _target=$(get_user_configured_dump_disk)
[ -n "$_target" ] && echo $(to_dev_name $_target) && return
#get rootfs device name
- _target=$(findmnt -k -f -n -o SOURCE /)
+ _target=$(get_root_fs_device)
[ -b "$_target" ] && echo $(to_dev_name $_target)
}
--
1.8.3.1
10 years, 1 month
[PATCH] mkdumprd: dracut omit resume module
by WANG Chao
Let's omit resume module when building kdump initramfs, because:
- kdump don't want to resume
- it would pull in the swap device dependencie
Tested on Fedora20. This change doesn't break anything.
Signed-off-by: WANG Chao <chaowang(a)redhat.com>
---
mkdumprd | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mkdumprd b/mkdumprd
index 6797791..fbea236 100644
--- a/mkdumprd
+++ b/mkdumprd
@@ -14,7 +14,7 @@ SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa"
SAVE_PATH=$(grep ^path $conf_file| cut -d' ' -f2)
[ -z "$SAVE_PATH" ] && SAVE_PATH="/var/crash"
extra_modules=""
-dracut_args=("--hostonly" "-o" "plymouth dash")
+dracut_args=("--hostonly" "-o" "plymouth dash resume")
OVERRIDE_RESETTABLE=0
perror_exit() {
--
1.8.5.3
10 years, 1 month
[PATCH] mkdumprd: use dracut --hostonly-cmdline by default
by WANG Chao
dracut has changed its default behavior to not store kernel command line
arguments in the initramfs. However kdump initramfs needs these cmdline
arguments in initramfs ($initrd/etc/cmdline.d/*.conf) to setup some
devices we need properly.
To adapt this change, we should modify mkdumprd by calling dracut
--hostonly-cmdline to restore the old behavior.
Signed-off-by: WANG Chao <chaowang(a)redhat.com>
---
mkdumprd | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mkdumprd b/mkdumprd
index 6797791..e760a0c 100644
--- a/mkdumprd
+++ b/mkdumprd
@@ -14,7 +14,7 @@ SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa"
SAVE_PATH=$(grep ^path $conf_file| cut -d' ' -f2)
[ -z "$SAVE_PATH" ] && SAVE_PATH="/var/crash"
extra_modules=""
-dracut_args=("--hostonly" "-o" "plymouth dash")
+dracut_args=("--hostonly" "--hostonly-cmdline" "-o" "plymouth dash")
OVERRIDE_RESETTABLE=0
perror_exit() {
--
1.8.5.3
10 years, 1 month
[PATCH v2] s390x: do not install /etc/adjtime
by WANG Chao
On s390x, RTC or hardware clock doesn't exist. s390 is using a more
precise clock source TOD, which is storing time in UTC format.
The problem is /etc/adjtime installed by anaconda is saying LOCAL (this
is actually a bug in anaconda), which means it's telling the userspace
that RTC is storing time in local time format. This is bug and it
confuses the init system (systemd in this case) particularly when init
is trying to setup the system time.
In a normal boot, this wrong adjtime file makes the system time wrong at
first, but the system time is corrected by NTP daemon later.
Unfortunately, in kdump case, we don't use NTP or any time synchronizing
userspace at all. The result is systemd sets the system clock wrong
(hours drifted regarding the timezone).
To avoid such problem, either /etc/adjtime should be saying UTC at its
third line or /etc/adjtime shouldn't exist.
Given the fact that anaconda has deferred the bug to the next release,
we should first fix this problem in our kdump to avoid this issue by not
installing /etc/adjtime in our kdump initramfs.
Signed-off-by: WANG Chao <chaowang(a)redhat.com>
Acked-by: Dave Young <dyoung(a)redhat.com>
---
dracut-module-setup.sh | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index bdadf7c..d5951ca 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -460,6 +460,16 @@ kdump_install_random_seed() {
bs=$poolsize count=1 2> /dev/null
}
+# /etc/adjtime is used to determine RTC time format (UTC or localtime)
+# /etc/localtime is used to set system timezone
+kdump_install_time() {
+ # RTC doesn't exist on s390
+ if [ `uname -m` != "s390x" ]; then
+ dracut_install -o /etc/adjtime
+ fi
+ dracut_install -o /etc/localtime
+}
+
install() {
kdump_install_conf
>"$initdir/lib/dracut/no-emergency-shell"
@@ -467,7 +477,7 @@ install() {
if is_ssh_dump_target; then
kdump_install_random_seed
fi
- dracut_install -o /etc/adjtime /etc/localtime
+ kdump_install_time
inst "$moddir/monitor_dd_progress" "/kdumpscripts/monitor_dd_progress"
chmod +x ${initdir}/kdumpscripts/monitor_dd_progress
inst "/bin/dd" "/bin/dd"
--
1.8.5.3
10 years, 1 month
[Patch v2] kdump fails loading if target is root fs by default while disk is mounted on save path
by Baoquan He
kdump now dumps vmcore to root partition by default in SAVE_PATCH
directory, e.g /var/crash defaultly. This is problematic when another
disk is mounted on /var or /var/crash, because the saved vmcore will
he hidden after dump in 1st kernel. This also has the potential of
blindly filling the root file system without a clue as to why.
Now fix this by failing the loading of kdump kernel if dump target
is root fs by default while different disk is mounted on save path.
Signed-off-by: Baoquan He <bhe(a)redhat.com>
---
mkdumprd | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/mkdumprd b/mkdumprd
index bc002bc..d30b34c 100644
--- a/mkdumprd
+++ b/mkdumprd
@@ -453,6 +453,34 @@ check_resettable()
return 1
}
+check_block_dump_target()
+{
+ local _target
+ local _mntpoint
+
+ if is_ssh_dump_target || is_nfs_dump_target; then
+ return
+ fi
+
+ _target=$(egrep "^ext[234]|^xfs|^btrfs|^minix|^raw" /etc/kdump.conf 2>/dev/null |awk '{print $2}')
+ [ -n "$_target" ] && return
+
+ #get rootfs device name
+ _target=$(findmnt -k -f -n -o SOURCE /)
+ if [ -b "$_target" ]; then
+ mkdir -p $SAVE_PATH
+ _mntpoint=`df $SAVE_PATH | tail -1 | awk '{print $NF}'`
+ _target=`df $SAVE_PATH | tail -1 | awk '{print $1}'`
+ if [ "$_mntpoint" != "/" ]; then
+ perror "Currently SAVE_PATH is $SAVE_PATH, $_target is mounted on $_mntpoint. While dump target is root filesystem by default."
+ perror_exit "Then vmcore will be hidden in 1st kernel after dump. Please check /etc/kdump.conf clearly to remove confusion!"
+ fi
+ fi
+
+}
+
+check_block_dump_target
+
if ! check_resettable; then
exit 1
fi
--
1.8.3.1
10 years, 1 month