From nobody Wed Apr 12 06:49:06 2023 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PxCx56L4Jz45Nvv for ; Wed, 12 Apr 2023 06:49:13 +0000 (UTC) (envelope-from ralf-mardorf@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.riseup.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PxCx41kvWz3CYh for ; Wed, 12 Apr 2023 06:49:12 +0000 (UTC) (envelope-from ralf-mardorf@riseup.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=BkI9WVNj; spf=pass (mx1.freebsd.org: domain of ralf-mardorf@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=ralf-mardorf@riseup.net; dmarc=pass (policy=none) header.from=riseup.net Received: from fews01-sea.riseup.net (unknown [10.0.1.109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx1.riseup.net (Postfix) with ESMTPS id 4PxCx24HbyzDrrn for ; Wed, 12 Apr 2023 06:49:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1681282150; bh=H4h8zi/8h1FBEO8ffSXxhpFLIUH1Op354vlUk9RKpXY=; h=Subject:From:To:Date:In-Reply-To:References:From; b=BkI9WVNjLTDysDjnlx1HiaK9FG2TK8T+v0hl7ljTEICL1JcXKL5AoHSxNNyFwnTs6 vOxiP5jRuNXhvZ0Z6v/NKsl/BMUWClMcfIEYt+3b3A+rRvMhlMasgQPvvwy42pNmpj Btw0wPRQyQ/m8fjy2qO5/ftW1kSblF3Xql+tIUnU= X-Riseup-User-ID: 3E0F039C7B9D188DB1494E09BA467202170BCD21EF04796D6BCD266748DBA065 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4PxCx16XdBzJqVV for ; Wed, 12 Apr 2023 06:49:09 +0000 (UTC) Message-ID: <629d5b5fba97951b8b5ec3635dafb74524565bbd.camel@riseup.net> Subject: Re: FreeBSD 13.2-RELEASE Now Available From: Ralf Mardorf To: questions@freebsd.org Date: Wed, 12 Apr 2023 08:49:06 +0200 In-Reply-To: <20230412054315.05dfe374.freebsd@edvax.de> References: <20230411044832.10F73170F8@freefall.freebsd.org> <20230412054315.05dfe374.freebsd@edvax.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from]; RWL_MAILSPIKE_GOOD(-0.10)[198.252.153.129:from]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[questions@freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[riseup.net:dkim]; DKIM_TRACE(0.00)[riseup.net:+]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4PxCx41kvWz3CYh X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N 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.