Comment 1 for bug 1941844

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
the image isn't giving away much - we see something reports a Segmentation Fault but we do not know what or why. I've run similar guests on a few EPYC CPUs that are similar but not the very same. I have right now no access to the same chip you refer to, so I need to ask you to check a few more things.

More detail please:

1. What exactly crashes here ? Since we get more output after the segfault I doubt it is qemu. Is it systemd in the guest - is it a guest process at all? I see "tr" failing, is it just that or more guest processes? What else can you say about it?
2. what exactly is the configuration of the guest, could you share e.g. `virsh dumpxml <guestname>`?
3. could you attach logs as text files instead of images please. For example the guest log in /var/log/libvirt/qemu/<guestname>.log that might help as well.

Check alternatives, to see what makes a difference
Try those and let us know if it makes any difference.

1. I see you use 4.15.0-154-generic on Bionic, you could try the HWE kernel [1]
2. you could try a newer virtualization stack like server-backports [2]
3. you could upgrade your 18.04 system to 20.04 proper and give it a try
4. Vary your guest definition, if you use host-passthrough use something more
   compatible like qemu64 as cpu type (or vice versa). If you have plenty of extra
   features enabled, try disabling them.
5. You tried a 20.04 guest, could you try other guest versions and also not only the ISO,
   maybe the more commonly used cloud images [3]
6. various combinations of the above

[1]: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
[2]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports
[3]: http://cloud-images.ubuntu.com/daily/