kdump service does not start after configure/reboot

Bug #1708409 reported by bugproxy on 2017-08-03
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
The Ubuntu-power-systems project
High
Canonical Foundations Team
makedumpfile (Ubuntu)
Status tracked in Bionic
Artful
Wishlist
Unassigned
Bionic
Wishlist
Canonical Foundations Team
systemd (Ubuntu)
Status tracked in Bionic
Artful
High
Dimitri John Ledkov
Bionic
High
Canonical Foundations Team

Bug Description

== Comment: #0 - Harish Sriram <email address hidden> - 2017-08-02 01:45:01 ==
kdump service does not start after configure/reboot

--Problem Description---
kdump service does not start after configure/reboot. It has to be started/loaded manually, everytime after reboot.

# kdump-config status
current state : Not ready to kdump

---uname output---
Linux ltc-test-ci2 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:02:54 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

Machine Type/Model = Power 8/8247-22L

----Additional Info-----
# cat /proc/cmdline
root=UUID=974df602-c0e4-4e67-8853-78ad15884c59 ro console=tty0 console=ttyS0,115200 quiet splash cgroup_enable=memory swapaccount=1 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M

---Steps to Reproduce---
1. installed linux-crashdump
2. edited the kdump-tools.cfg crashkernel cmdline to above
3. update-grub
4. reboot

Expected:
kdump-config to be loaded by default after reboot

# kdump-config status
current state : Not ready to kdump

# service kdump-tools status
* kdump-tools.service - Kernel crash dump capture service
   Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor pres
   Active: inactive (dead)

...........................
https://github.com/systemd/systemd/issues/6334

systemd in artful is not properly picking up the unit files in
/etc/systemd/system/default.target.wants

bugproxy (bugproxy) wrote : sosreport

Default Comment by Bridge

tags: added: architecture-ppc64le bugnameltc-157224 severity-high targetmilestone-inin---
Changed in ubuntu:
assignee: nobody → Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
affects: ubuntu → systemd (Ubuntu)
Changed in ubuntu-power-systems:
assignee: nobody → Canonical Foundations Team (canonical-foundations)
importance: Undecided → High
Steve Langasek (vorlon) wrote :

The referenced upstream bug report shows that upstream agrees this is a regression in systemd behavior which they are planning to correct, which is reasonable.

However, I think this is also a bug in the kdump-tools package. 'default.target' is a meta-target, which no package can know whether it's appropriate to start its service under without knowing what default.target is set to. In particular, kdump-tools also declares 'Wants=network-online.target'. If default.target (either on the kernel commandline or on the filesystem) is pointed to some sort of local-only rescue target, having network-online pulled into this target via kdump-tools could break the boot.

I think kdump-tools in Debian and Ubuntu should instead be integrating with multi-user.target.

Changed in systemd (Ubuntu):
importance: Undecided → High
status: New → Triaged
Changed in makedumpfile (Ubuntu):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Changed in systemd (Ubuntu):
assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) → Canonical Foundations Team (canonical-foundations)
Changed in ubuntu-power-systems:
assignee: Canonical Foundations Team (canonical-foundations) → nobody
Changed in ubuntu-power-systems:
status: New → Triaged
Manoj Iyer (manjo) on 2017-08-23
Changed in ubuntu-power-systems:
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Manoj Iyer (manjo) on 2017-09-18
tags: added: triage-a
bugproxy (bugproxy) on 2017-09-27
tags: added: severity-medium
removed: severity-high
tags: added: id-5983be8a574a2f44b3cbc1ed

------- Comment From <email address hidden> 2017-10-03 03:07 EDT-------
Due to this issue, "fadump" on pVM does not take a dump because fadump reboot the machine first and takes a dump.

Once service is manually started after reboot, the fadump is being captured and system reboots again.

Thanks,
Harish

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in makedumpfile (Ubuntu):
status: New → Confirmed
tags: added: ppc64el-kdump

It seems this has been reverted on systemd 235. However, as this might come to bite us back again in the future (it was mentioned that dependencies should not be added to aliases), and as Steve has pointed out, it makes more sense to use multi-user.target, I am going to fix it in a future release to come soon.

Dimitri John Ledkov (xnox) wrote :

Systemd regression introduced in:
$ git describe 2d058a87ffb2d31a50422a8aebd119bbb4427244
v232-626-g2d058a8

Reverted in:
$ git describe 9e4ea9cc34fa032a47c253ddd94ac6c7afda663e
v234-72-g9e4ea9c

Thus affected releases were artful and bionic.

Bionic is now on v235 and thus is fixed-release for the systemd portion of the bug.

I fear there might be other packages that are also affected by this, thus I'm going to cherrypick the revert into artful in systemd as well.

Changed in systemd (Ubuntu Bionic):
status: Triaged → Fix Released
Changed in systemd (Ubuntu Artful):
importance: Undecided → High
status: New → Confirmed
Changed in makedumpfile (Ubuntu Bionic):
importance: Undecided → Wishlist
Changed in makedumpfile (Ubuntu Artful):
importance: Undecided → Wishlist
Changed in systemd (Ubuntu Artful):
status: Confirmed → Fix Committed
status: Fix Committed → In Progress
assignee: nobody → Dimitri John Ledkov (xnox)
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2018-01-09 09:15 EDT-------
After boot on Bionic Beaver , issue is not observed.

# uname -a
Linux ltc-wspoon12 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

# kdump-config show
DUMP_MODE: kdump
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr:
/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.13.0-17-generic
kdump initrd:
/var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.13.0-17-generic
current state: ready to kdump

kexec command:
/sbin/kexec -p --command-line="root=UUID=f009e6ec-b67d-4e08-89c9-b35b2b9e657f ro quiet splash xmon=on irqpoll noirqdistrib nr_cpus=1 nousb systemd.unit=kdump-tools.service ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

Dmesg
-----------
[ 32.866017] kdump-tools[3949]: Starting kdump-tools: Modified cmdline:root=UUID=f009e6ec-b67d-4e08-89c9-b35b2b9e657f ro quiet splash irqpoll noirqdistrib nr_cpus=1 nousb systemd.unit=kdump-tools.service ata_piix.prefer_ms_hyperv=0 elfcorehdr=157184K
[ 33.277170] kdump-tools[3949]: * loaded kdump kernel

Regards,
Harish

bugproxy (bugproxy) on 2018-01-12
tags: added: targetmilestone-inin1804
removed: targetmilestone-inin---
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments