Date: Wed, 12 Apr 2023 08:49:06 +0200 From: Ralf Mardorf <ralf-mardorf@riseup.net> To: questions@freebsd.org Subject: Re: FreeBSD 13.2-RELEASE Now Available Message-ID: <629d5b5fba97951b8b5ec3635dafb74524565bbd.camel@riseup.net> In-Reply-To: <20230412054315.05dfe374.freebsd@edvax.de> References: <20230411044832.10F73170F8@freefall.freebsd.org> <CAFYkXjnpPgDsYi-1o9zZwKsNy8OhJpOfqukYA7ez8VvaJgFsdg@mail.gmail.com> <20230412054315.05dfe374.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2023-04-12 at 05:43 +0200, Polytropon wrote: > > And the vpo(4) driver for parallel SCSI drives is also gone; > > how am I supposed to read my important business files stored > > on a parallel Zip drive now?! ;-) Hi, a few days ago I experienced that secure erasing data from older SATA3 SSDs doesn't work, since the vendor's secure erase utility for the older SSDs cannot be booted using new hardware. While SATA3 isn't an issue, maybe the old utility fails to boot due to a PKCS#7 signature issue of the Linux kernel they are using for their bootable utility. I don't know. The SSDs are just a few years old, the vendor's utility supporting those SSDs is also a few years old. The new utility doesn't support SSDs that are a few years old. It's not only tricky to get back old data, from very old hardware, it can also be hard to get rid of data on relatively modern hardware. I suspect that more users want to get rid of data on older drives, than on new drives. Regards, Ralf PS anecdote: While a new mobo's firmware might support the Compatibility Support Module, a new Intel processor graphics might not allow to enable it. I'm migrating to new hardware and it already took me several days to get a buzzer working, to always and not just randomly provide POST beep signals. To get help from support related to the power-on self-test signals, they (Gigabyte) asked me to make a screenshot of Windows software that provides system information. I asked them if I'm allowed to provide the wanted information without providing a screenshot from Windows software, especially since no operating system is involved at all during POST. No screenshot from a Windows install of a system that fails to provide always audible POST signals, no support! They didn't tell me that the firmware's slowest fast boot option (it has several levels of fast boot) is the cause for the issue. I found it out myself.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?629d5b5fba97951b8b5ec3635dafb74524565bbd.camel>