Bug 2089459

Summary: kdump fails to start on s390x RHCOS node
Product: Red Hat Enterprise Linux 8 Reporter: Dusty Mabe <dustymabe>
Component: kexec-toolsAssignee: Lichen Liu <lichliu>
Status: CLOSED ERRATA QA Contact: xiaoying yan <yiyan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.5CC: coxu, dornelas, jieli, lichliu, miabbott, piliu, ruyang
Target Milestone: rcKeywords: Triaged, ZStream
Target Release: ---Flags: pm-rhel: mirror+
Hardware: s390x   
OS: Unspecified   
Whiteboard:
Fixed In Version: kexec-tools-2.0.24-6.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2150795 2174836 (view as bug list) Environment:
Last Closed: 2022-11-08 10:46:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2150795    

Description Dusty Mabe 2022-05-23 18:05:57 UTC
Description of problem:

The kdump service fails to start on s390x RHCOS nodes (based on RPM-OSTree). When starting the service we get an error like:

```
# journalctl -u kdump.service | cat
May 23 02:18:22 localhost systemd[1]: Starting kdump.service - Crash recovery kernel arming...
May 23 02:18:22 cosa-devsh kdumpctl[999]: kdump: Failed to detect kdump kernel location
May 23 02:18:22 cosa-devsh kdumpctl[999]: kdump: failed to prepare for kdump bootinfo.
May 23 02:18:22 cosa-devsh kdumpctl[999]: kdump: Starting kdump: [FAILED]
May 23 02:18:22 cosa-devsh systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
May 23 02:18:22 cosa-devsh systemd[1]: kdump.service: Failed with result 'exit-code'.
May 23 02:18:22 cosa-devsh systemd[1]: Failed to start kdump.service - Crash recovery kernel arming.
```

This is because this line of code:

```
boot_img="$(sed "s/^BOOT_IMAGE=\((\S*)\)\?\(\S*\) .*/\2/" /proc/cmdline)"
```

from https://src.fedoraproject.org/rpms/kexec-tools/blob/218d9917c03f25bc9872f076491c587815d16efb/f/kdump-lib.sh#_657

assumes that `BOOT_IMAGE=` exists on the kernel command line. For s390x it does not exist on the kernel command line:

```
$ cat /proc/cmdline 
random.trust_cpu=on ignition.platform.id=qemu $ignition_firstboot ostree=/ostree/boot.1/rhcos/a3c8e96168930378ec3234ccf941fdde591117d0f60e496ab40eb3dffd7f8611/0 ignition.firstboot
```

on a s390x system the sed command gives us:

```
$ sed "s/^BOOT_IMAGE=\((\S*)\)\?\(\S*\) .*/\2/" /proc/cmdline
random.trust_cpu=on ignition.platform.id=qemu $ignition_firstboot ostree=/ostree/boot.1/rhcos/a3c8e96168930378ec3234ccf941fdde591117d0f60e496ab40eb3dffd7f8611/0 ignition.firstboot
```

on an aarch64 system the sed command gives us:

```
$ sed "s/^BOOT_IMAGE=\((\S*)\)\?\(\S*\) .*/\2/" /proc/cmdline
/ostree/rhcos-deca8b6dc8dd5ab099ac80a3036f018f93c137eda111ae8e7d830b26ceb225b6/vmlinuz-4.18.0-348.23.1.el8_5.aarch64
```


Version-Release number of selected component (if applicable):
```
[core@cosa-devsh ~]$ rpm -q kernel kexec-tools
kernel-4.18.0-348.23.1.el8_5.s390x
kexec-tools-2.0.20-57.el8_5.1.s390x
[core@cosa-devsh ~]$
[core@cosa-devsh ~]$ rpm-ostree status 
State: idle
Deployments:
* c4371a64da476811ee0bfcc34d525e6d092b8973cf35ac9ba1e0ec2a7defc445
                   Version: 411.85.202205192005-0 (2022-05-19T20:11:15Z)
```

How reproducible:

Always

Steps to Reproduce:
1. boot RHCOS
2. sudo rpm-ostree kargs --append='crashkernel=600M'
3. reboot
4. sudo systemctl start kdump

Actual results:

Failed to start kdump.

Expected results:

Success starting kdump


Additional info:

Comment 5 Dusty Mabe 2022-07-21 18:49:14 UTC
The update in kexec-tools-2.0.24-6.el8 passes my test on s390x. Thanks!

Comment 12 errata-xmlrpc 2022-11-08 10:46:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (kexec-tools bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7705