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 <hans@stare.cz>:
> On Mar 24 04:34:42, my25mb@aol.com 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.
No comments:
Post a Comment