https://bugzilla.suse.com/show_bug.cgi?id=1188896 https://bugzilla.suse.com/show_bug.cgi?id=1188896#c59 --- Comment #59 from LTC BugProxy <bugproxy@us.ibm.com> --- ------- Comment From geraldsc@de.ibm.com 2022-02-15 09:05 EDT------- (In reply to comment #54) [...]

- You can download latest Tumbleweed iso images (not released because of this bug) from here: https://build.opensuse.org/package/binaries/openSUSE:Factory:zSystems/ 000product:openSUSE-dvd5-dvd-s390x/images

The kernel is here: https://build.opensuse.org/package/binaries/openSUSE:Factory:zSystems/kernel... default/standard

Thanks, we are getting closer. It is not the matching kernel version (5.16.8-1 instead of 5.16.4-1), and therefore not usable to open the dump in crash. But it showed me that I was wrong, and the debuginfo vmlinux is apparently not enough, and it also takes the normal vmlinux in addition (don't ask me why...). So, the following RPMs would be needed, or rather the included files which you would find on your system when installed (Of course, in the very same version as the kernel that was dumped): kernel-default-debuginfo-5.16.8-1.1.s390x.rpm: ./usr/lib/debug/usr/lib/modules/5.16.8-1-default/vmlinux.debug kernel-default-5.16.8-1.1.s390x.rpm: ./usr/lib/modules/5.16.8-1-default/vmlinux.xz

well, the dump-guest-memory method was exactly what I used to create the dump above but comment 52 says it is not usable. (method used is basically: have qemu with debuginfo installed, attach gdb to hanging vm, load the dump-guest-memory.py from the qemu git to create the dump). but for the guest VM the runing kernel is taken from the project where the build happens, so this could be any kernel and the same debuginfo is not neccessarily available or even built at all.

The dump is not necessarily unusable for analysis in crash, at least if we would also have matching vmlinux files (both with and w/o debuginfo, see above). What did not work with this dump, was "crash --log", which would not need any vmlinux files, and only extract kernel message log. That might just "work as designed", e.g. due to this special qemu dump, or maybe a bug in crash, who knows. This is not really a problem, as long as we would be able to open the dump in crash for analysis, which would require the vmlinux files. As long as we do not have any vmlinux files, nobody can say if the dump us usable or not. Of course, this specific dump, w/o panic_on_taint, will most likely not give useful insight, even if we had vmlinux files, other than maybe the kernel message log. But at least it serves as exercise on how to submit dumps and additional required files. -- You are receiving this mail because: You are the assignee for the bug.