Hi Jan, Sorry for the missing clarifications on my settings.
>> Why would another disk have the same UID and how is that obvious? I use hardware copy machines for all my storage devices, since 2012. >> Your problem is a HW failure, not a clash of names. What I mean is when I try to insert the the backup disk together with the original one OpenBSD behave like the CRC problem is of the original disk, no terminal output when I insert it, no terminal output to advise about the error, only the given message in the console when I enter X. Obviously is my first time to get into this kind of CRC situations in so many years so I can't confirm if last patches has anything to deal with it. P.S: I'm gently advising about an OpenBSD problem, I'm not here to make an utterine accordance on my settings. -- Daniele Bonini Mar 24, 2023 08:18:52 Jan Stary <[email protected]>: > On Mar 24 04:34:42, [email protected] wrote: >> sd1(umass0:1:0) Check Condition (error 0x70) on opcode 0x2a >> SENSE KEY: Aborted Command >> ASC/ASCQ: information Unit iuCRC Error Detected >> >> sd1 was the original disk which the second backup disk was copy from. >> And obviously the faulty sd3 had the same UID of sd1. > > Why would another disk have the same UID and how is that obvious? > Your problem is a HW failure, not a clash of names. > >> Apart my the physical problem of the identical bit-by-bit copy > > So how did you make that copy? > Just dd sd1c onto sd3c? Why? > >> 2) The CRC problem of sd3 is passed to sd1 > > What do you mean by that? > >> I then rebooted on the backup disk and fix the fss prb to solve my >> situation but frankly the system could be more helpful and less error >> prone in these kind of emergency situations. > > You could also make normal backups.
