** Description changed:
SRU Justification:
------------------
[Impact]
- * While installing makedumpfile the "crashkernel=" argument is not
+ * While installing makedumpfile the "crashkernel=" argument is not
properly set, hence dump is not triggered on reboot.
- * Means the triggering of dumpfiles is currently not possible using
+ * Means the triggering of dumpfiles is currently not possible using
makedumpfile.
- * Dumpfiles are obviously only needed in rare cases, but if they are
+ * Dumpfiles are obviously only needed in rare cases, but if they are
needed (e.g. in production environments) the situation is usually
critical.
- * Hence fixing this is needed to allow post-mortem analysis of a dumps.
+ * Hence fixing this is needed to allow post-mortem analysis of a dumps.
- * The provided shell code snippet provides a fixed sed statement that
+ * The provided shell code snippet provides a fixed sed statement that
makes sure that the kernel parameter is propoerly set.
[Test Case]
- * Create and boot a s390x (KVM virtual) machine
+ * Create and boot a s390x (KVM virtual) machine
- * Install kdump-tools and makedumpfile
- Select 'yes' on question 'Should kdump-tools be enabled by default?'
during installation
+ * Install kdump-tools and makedumpfile
+ Select 'yes' on question 'Should kdump-tools be enabled by default?'
during installation
- * [ Reboot system ]
+ * [ Reboot system ]
- * Look for crashkernel line in zipl boot-loader
- grep crashkernel /etc/zipl.conf
- crashkernel line is missing in case this bug still exists
- one or more lines like this should be given:
- parameters = root=UUID=5ed8f208-adce-4fad-b1a6-feb5e8732d89
crashkernel=196M
+ * Look for crashkernel line in zipl boot-loader
+ grep crashkernel /etc/zipl.conf
+ crashkernel line is missing in case this bug still exists
+ one or more lines like this should be given:
+ parameters = root=UUID=5ed8f208-adce-4fad-b1a6-feb5e8732d89
crashkernel=196M
- * One may further trigger a crash (for a full positiv test)
- sudo -s
- sysctl -w kernel.sysrq=1
- echo c > /proc/sysrq-trigger
- (in case this bug still exists the system will not come up again - check
console in parallel)
+ * One may further trigger a crash (for a full positiv test)
+ sudo -s
+ sysctl -w kernel.sysrq=1
+ echo c > /proc/sysrq-trigger
+ (in case this bug still exists the system will not come up again - check
console in parallel)
+ Finally dump files should be visible in /var/crash
[Regression Potential]
- * The regression potential is very low, since:
+ * The regression potential is very low, since:
- * it's limited to the zipl boot loader configuration file only
- and this means again it's on the s390x platform only (IBM Z)
+ * it's limited to the zipl boot loader configuration file only
+ and this means again it's on the s390x platform only (IBM Z)
- * kdump-tools and makedumpfile are not installed by default and only used in
debug situations
- hence only system where the package(s) got manually installed get updated
+ * kdump-tools and makedumpfile are not installed by default and only used in
debug situations
+ hence only system where the package(s) got manually installed get updated
- * The function is today broken anyway, hence it can actually only get
+ * The function is today broken anyway, hence it can actually only get
better
- * I successfully verified this in disco.
+ * I successfully verified this in disco.
_________________________
Trying to use crashdump especially in a KVM machine.
Installation looks fine and the reboot is triggered.
But it does not work because the kernel does not have a 'crashkernel='
parameter.
Nothing in /proc/cmdline:
$ cat /proc/cmdline
root=LABEL=cloudimg-rootfs
Issue seems to be in adding the crashkernel line in this snippet:
# Customize crashkernel= value according to architecture
ARCH="$(arch)"
DEF_PRESET="384M-:128M"
case "$ARCH" in
s390x)
HAS_CRASHKERNEL="$(grep crashkernel /etc/zipl.conf)" || true
if test -z "$HAS_CRASHKERNEL"; then
sed -i "/parameters/{s|\"$| crashkernel=${DEF_PRESET}\"|}"
/etc/zipl.conf
zipl
fi
CIO_IGNORE="$(cio_ignore -u -k)"
sed -i "s/\#KDUMP_CMDLINE_APPEND/KDUMP_CMDLINE_APPEND/" $INITCONFFILE
sed -i "/KDUMP_CMDLINE_APPEND/{s|\"$| ${CIO_IGNORE}\"|}"
$INITCONFFILE
;;
esac
(especially 1st sed stmt)
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Status: New => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1790788
Title:
Customize 'crashkernel' parameter is not properly working
Status in Ubuntu on IBM z Systems:
In Progress
Status in makedumpfile package in Ubuntu:
Fix Released
Status in makedumpfile source package in Xenial:
New
Status in makedumpfile source package in Bionic:
New
Status in makedumpfile source package in Cosmic:
In Progress
Status in makedumpfile source package in Disco:
Fix Released
Bug description:
SRU Justification:
------------------
[Impact]
* While installing makedumpfile the "crashkernel=" argument is not
properly set, hence dump is not triggered on reboot.
* Means the triggering of dumpfiles is currently not possible using
makedumpfile.
* Dumpfiles are obviously only needed in rare cases, but if they are
needed (e.g. in production environments) the situation is usually
critical.
* Hence fixing this is needed to allow post-mortem analysis of a
dumps.
* The provided shell code snippet provides a fixed sed statement that
makes sure that the kernel parameter is propoerly set.
[Test Case]
* Create and boot a s390x (KVM virtual) machine
* Install kdump-tools and makedumpfile
Select 'yes' on question 'Should kdump-tools be enabled by default?'
during installation
* [ Reboot system ]
* Look for crashkernel line in zipl boot-loader
grep crashkernel /etc/zipl.conf
crashkernel line is missing in case this bug still exists
one or more lines like this should be given:
parameters = root=UUID=5ed8f208-adce-4fad-b1a6-feb5e8732d89
crashkernel=196M
* One may further trigger a crash (for a full positiv test)
sudo -s
sysctl -w kernel.sysrq=1
echo c > /proc/sysrq-trigger
(in case this bug still exists the system will not come up again - check
console in parallel)
Finally dump files should be visible in /var/crash
[Regression Potential]
* The regression potential is very low, since:
* it's limited to the zipl boot loader configuration file only
and this means again it's on the s390x platform only (IBM Z)
* kdump-tools and makedumpfile are not installed by default and only used in
debug situations
hence only system where the package(s) got manually installed get updated
* The function is today broken anyway, hence it can actually only get
better
* I successfully verified this in disco.
_________________________
Trying to use crashdump especially in a KVM machine.
Installation looks fine and the reboot is triggered.
But it does not work because the kernel does not have a 'crashkernel='
parameter.
Nothing in /proc/cmdline:
$ cat /proc/cmdline
root=LABEL=cloudimg-rootfs
Issue seems to be in adding the crashkernel line in this snippet:
# Customize crashkernel= value according to architecture
ARCH="$(arch)"
DEF_PRESET="384M-:128M"
case "$ARCH" in
s390x)
HAS_CRASHKERNEL="$(grep crashkernel /etc/zipl.conf)" || true
if test -z "$HAS_CRASHKERNEL"; then
sed -i "/parameters/{s|\"$| crashkernel=${DEF_PRESET}\"|}"
/etc/zipl.conf
zipl
fi
CIO_IGNORE="$(cio_ignore -u -k)"
sed -i "s/\#KDUMP_CMDLINE_APPEND/KDUMP_CMDLINE_APPEND/" $INITCONFFILE
sed -i "/KDUMP_CMDLINE_APPEND/{s|\"$| ${CIO_IGNORE}\"|}"
$INITCONFFILE
;;
esac
(especially 1st sed stmt)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1790788/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
