On Tuesday, 21 April 2020 2:01:45 PM AEST Russell Coker wrote: > After the reboot I could not reproduce it on saved snapshots of the VM in > question dating back to when I had previously had problems. I conclude that > rebooting the hardware solved the problem. > > The problem was either an issue of failing hardware (I am running memtest86+ > right now) or hostile action. When testing for issues with libsepol I got Memtest86+ has proven that the system in question had a damaged motherboard, any time when any DIMM socket other than socket 1 was in use Memtest86+ would lock up solid in less than 7 seconds (for reference a complete Memtest86+ run was successful at the time the system was deployed). The system is on the e- waste pile and I don't expect to see such semodule problems again. How the system in question managed to boot Linux and run multiple VMs while Memtest86+ crashed so soon remains a mystery to me. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
