Bug ID 1190532
Summary kdump.service fails on transactional systems after /etc/hosts modifications
Classification openSUSE
Product openSUSE Tumbleweed
Version Current
Hardware Other
OS Other
Status NEW
Severity Normal
Priority P5 - None
Component Kernel
Assignee ptesarik@suse.com
Reporter fvogt@suse.com
QA Contact qa-bugs@suse.de
CC db7532@qq.com, iforster@suse.com, kubic-bugs@opensuse.org
Found By ---
Blocker ---

How to reproduce:

1. Boot into a transactional system with read-only /
2. Change /etc/hosts or just "touch" it
3. reboot

On the next boot, kdump.service fails:

Sep 15 03:18:23.894220 localhost load.sh[1139]: Regenerating kdump initrd ...
Sep 15 03:18:23.894220 localhost load.sh[1139]: dracut: Executing:
/usr/bin/dracut --force --hostonly --omit "plymouth resume usrmount"
"--compress=xz -0 --check=crc32" --add kdump
/usr/lib/modules/5.14.1-5-default/initrd-kdump 5.14.1-5-default
Sep 15 03:18:23.894220 localhost load.sh[1139]: dracut: No permission to write
to /usr/lib/modules/5.14.1-5-default.
Sep 15 03:18:23.894900 localhost systemd[1]: kdump.service: Main process
exited, code=exited, status=1/FAILURE
Sep 15 03:18:23.895117 localhost systemd[1]: kdump.service: Failed with result
'exit-code'.
Sep 15 03:18:23.895457 localhost systemd[1]: Failed to start Load kdump kernel
and initrd.
Sep 15 03:18:23.895840 localhost systemd[1]: kdump.service: Consumed 1.607s CPU
time.

This is because the service tries to regenerate initrd-kdump if it is older
than /etc/hosts.

Initially found by openQA:
https://openqa.opensuse.org/tests/1915952#step/trup_smoke/15

The problem was masked before the "trup_smoke" test was introduced, because a
different test module called "transactional-update pkg in foo.rpm", which
triggers "transactional-update kdump" as well.

I don't think there's a single simple way to address this:
1. Leave it as an error and tell the user that "transactional-update kdump"
needs to be run explicitly?
2. Don't attempt to rebuild the kdump initrd if / is read-only, thus
effectively ignore /etc/hosts changes and rely on transactional-update calling
mkdumprd regularly?
3. Move the kdump initrd into a location where it can be written even on
read-only systems?

2 might be the best option.


You are receiving this mail because: