Someone already linked to journalctl, but if you just quickly want to look, the command journalctl and the flag —since <your time here> will get you going.
Journalctls output can be piped, so if you know what you’re looking for you can grep it easily.
dd if=/dev/zero of=/dev/(your drive)
You can do status=progress if you want like someone else posted and if you pick a block size go with either the physical block size reported by the disk in smartcontrol or some multiple of it that coincides with a big even division of your controllers memory. The drives physical block size will be “easy” for the drive, bigger blocks are faster.
People saying physical destruction are operating in a different world than you and people saying urandom or shred are operating off old (>30 years) information. The same technology that makes ssds unrecoverable black boxes was originally developed and deployed in spinning drives to eek out speed gains because the disk itself can be expected to know better than the operating system where to put shit and makes techniques (which were postulated but never actually implemented successfully in the wild) to recover overwritten data infeasible.
Alternately just reformat it and don’t worry. No one doing drive rmas cares about your data. They’re already on the razors edge with feedback and customer trust, you think they’re gonna burn their above board bread and butter to run a harvesting operation for a few bucks on the side? That’s usually the purview of your local pc repair shop…
So go ahead and take a look at your journalctl output. The left hand side should be timestamps, so you can immediately figure out if it’s starting a million years in the past or sometime you know you had the problem.
If it is a million years in the past, use the —since flag and specify the time you want to start at as enumerated in the manual file (man journalctl).
Once you’re looking at the logs in journalctl from a day you know the problem happened, go ahead and use arrow keys and pgup/pgdn to find a reboot. You’ll know when you find a reboot because it’ll look different. The messages will be about figuring out what hardware is attached and changing runlevels and whatnot.
Once you found where the reboot is, go backwards to find something weird happening in the logs.
E: By default the parser (program used to handle text) of journalctls output is “less”. If you want to get out of it, press “q”, and if you want to know more “man less”.