Created attachment 514226 [details] mdadm segfaults on 4.14.13 in the initramfs I observe a segfault of mdadm at the ramfs stage. Screenshot provided in qemu (running without KVM). As an aside, it seems to be known that python 3.5 also segfaults on 4.14.13. Profile: default/linux/amd64/17.0/no-multilib/hardened Notable USE: lzma for sys-apps/kmod, required for ko.xz modules Kernel config: https://git.archlinux.org/svntogit/packages.git/plain/trunk/config?h=packages/linux&id=dc615c7e4fc98551f6b2df9d0e97743350ba94bd with FIRMWARE_IN_KERNEL=y so genkernel doesn't fail when trying to `make firmware_install` Kernel/ramfs generated with: genkernel --kernel-cc=/usr/lib/ccache/bin/gcc --kernel-config=config.seeabove --makeopts=2 all
emerge --info output and genkernel version will definitely help investigate this
Maybe hardened related as I've some machines on 4.14.13 with mdadm.
Have you tried booting with pti=off?
This might be a false alert, since it boots on the real machine, just not in QEMU. I have this in /etc/portage/make.conf: CFLAGS="-march=sandybridge -O2 -pipe" Maybe emulation doesn't support some opcodes of sandybridge (instead of say, generic x86_64) and it's just that. As requested: $ genkernel --version 3.4.52.4 Attaching output of emerge --info Trying pti=off did not change that, and it actually happens on 4.14.12 as well, which has me say sorry again, it suspciously looks to be all a fluke with QEMU on non-generic x86_64.
Created attachment 514424 [details] emerge --info
Yeah I wouldn't 100% trust qemu to pass through all those sandy-specific instructions, doubly so if you have hwvirt off.