Thanks Connor. My test configuration is a custom core system using the official core18 kernel snap on a KVM-based virtual machine. The kernel snap is installed from channel 18 (snap download --channel 18 pc-kernel) and my current revision is 240. That said, it's easy to test new kernels as long as I can convert them to a snap package. Foundations is currently preparing a kernel snap based on eoan so I can check with this newer kernel if the problems persist (it could be a first check for a bisect), but I could also boot an instrumented kernel that would give us a better insight on what could be happening.
So, to summarize: we can use either approach, but my feeling is that the debug kernel and the eoan kernel could be a good start to help us to gather more data points. Ideally I could start testing that next week after returning from Toronto. Would that work for you? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1835279 Title: 4.15.0-54.58-generic 4.15.18: oops/BUG on LUKS open Status in linux package in Ubuntu: Invalid Status in linux source package in Bionic: In Progress Bug description: This is Linux version 4.15.0-54-generic (buildd@lgw01-amd64-014) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 (Ubuntu 4.15.0-54.58-generic 4.15.18), from pc- kernel_240.snap Version signature: 4.15.0-54.58-generic 4.15.18 Issue is non-deterministic, and happens in roughly 20% of the attempts. Running on: qemu-kvm, command line: kvm \ -bios /usr/share/ovmf/OVMF.fd \ -smp 2 -m 512 -netdev user,id=mynet0,hostfwd=tcp::8022-:22,hostfwd=tcp::8090-:80 \ -device virtio-net-pci,netdev=mynet0 \ -drive file=pc.img,format=raw Commands that caused the problem: cryptsetup -q --type luks2 --key-file <keyfile> luksFormat /dev/sda4 LD_PRELOAD=/lib/no-udev.so cryptsetup --type luks2 --key-file <keyfile> open /dev/sda4 crypt-data Notes: - See https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1589083 for more information on the no-udev workaround. - The commands are scripted. Also tried to add a 200ms and 1s interval before opening the device. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1835279/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
