Gayhitler

The safety thing is 100% true but only part of the picture.

E-bikes don’t need maximum energy density because they’re not gonna be used for long trips and are significantly lighter than cars and trucks.

China has many, many more electric vehicles than any other country and a ton of electricity production to run them. At some point it’s gonna become important to save the lithium batteries for the stuff that needs that high density power.

Maybe these better chemistries that will replace lithium are just around the corner. I certainly don’t count unhatched chickens.

There are some possibly inaccurate and definitely confusing statements in the reply you got, but the first part, that agm is a physical structure of the lead acid battery that can be tipped over without making a giant mess and that deep cycle is another function of design as opposed to a function of the lead acid chemistry is correct.

What’s left unsaid is that lead acid batteries which are damaged and not working right anymore have a much safer and lower tech recycling process than lithium ones do and that’s saying something because one of the parts is lead!

Hexbear was right about downvotes.

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”.

Someone already linked to journalctl, but if you just quickly want to look, the command journalctl and the flag —since 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…