Groups > alt.comp.os.windows-11 > #18245 > unrolled thread

Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE)

Started by	"Carlos E.R." <robin_listas@es.invalid>
First post	2025-04-03 22:01 +0200
Last post	2025-04-05 22:03 +0200
Articles	15 on this page of 35 — 6 participants

Back to article view | Back to alt.comp.os.windows-11

  Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-03 22:01 +0200
    Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-03 17:47 -0400
      Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 02:39 +0200
        Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-03 23:33 -0400
          Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 11:36 +0200
            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 12:16 +0200
              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-04 14:51 -0400
                Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 21:52 +0200
            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Java Jive <java@evij.com.invalid> - 2025-04-04 11:28 +0100
              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 12:47 +0200
                Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Java Jive <java@evij.com.invalid> - 2025-04-04 17:06 +0100
                  Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 19:09 +0200
                    Re: Amazon (Was: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "J.O. Aho" <user@example.net> - 2025-04-04 21:26 +0200
                      Re: Amazon (Was: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Mark Lloyd <not.email@all.invalid> - 2025-04-05 16:22 +0000
                        Re: Amazon (Was: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 21:01 +0200
      Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-06 14:44 +0200
    Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) vallor <vallor@cultnix.org> - 2025-04-04 06:30 +0000
      Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-04 03:53 -0400
        Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 12:53 +0200
          Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 13:44 +0200
          Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 23:40 +0200
            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 13:33 +0200
              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 18:23 +0200
                Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 21:04 +0200
      Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 12:15 +0200
        Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-04 16:30 -0400
          Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 22:52 +0200
            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-04 18:46 -0400
            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Java Jive <java@evij.com.invalid> - 2025-04-05 00:20 +0100
              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-04 23:05 -0400
              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 12:47 +0200
                Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Java Jive <java@evij.com.invalid> - 2025-04-05 14:14 +0100
                  Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 18:23 +0200
                    Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-06 00:13 -0400
    Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 22:03 +0200

Page 2 of 2 — ← Prev page 1 [2]

#18283

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-04 23:40 +0200
Message-ID	<i606clxumo.ln2@Telcontar.valinor>
In reply to	#18266

On 2025-04-04 12:53, Carlos E.R. wrote:
> On 2025-04-04 09:53, Paul wrote:

>>     https://ralimtek.com/posts/2021/jms578/
>>
>> The claim there, is the ROM inside the device has a boot loader,
>> so erasing the flash cannot brick it. You can keep trying to flash it.
> 
> «Additionally, you may have run into the stupid way these units power 
> down the drives after 10 minutes of inactivity forcefully. Completely 
> ignoring OS or HDD settings. This is infuriating if you want the drives 
> to do what you tell them.»
> 
> Argh. So I need a cronjob every five minutes? Or do they restart 
> automatically?
> 
> [...]
> 
> Seems to not be happening. I listed files in the terminal more than 10 
> minutes later, and it responded instantly.

Yes, it is happening.

Maybe having a terminal open at the mount point avoided the power off to happen.

I hibernated the machine, later woke it up, and access to the files was fast. But now I launched a smartctl long test, and it aborted (doesn't say the percent):

Telcontar:~ # smartctl -l selftest /dev/sde
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.4.0-150600.23.42-default] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Interrupted (host reset)      00%       614         -
# 2  Short offline       Completed without error       00%       613         -
# 3  Short offline       Completed without error       00%       606         -

So I'm trying again leaving a terminal open at the mount point. If that fails, I need a while loop to do some activity periodically while running the smart test.

I don't know how sensitive is software raid to the disk dying on it.

[...]

Well, no, leaving the terminal open is not enough, the long test is aborted. Brilliant firmware, that. I'll have to create a script with the test and a loop.

Initial script:

+++···················
#!/bin/bash

THEDISK=/dev/sde

function busyloop()
{
    while true  ; do
         DATE=`date --rfc-3339=s`
         echo -en "$DATE \t"
         smartctl -l selftest $THEDISK | grep "# 1"
         sleep 1m
    done
}

echo smartctl --test=long $THEDISK
echo
busyloop
···················++-

It has survived for 15 minutes so far. I will let the script run, and change the loop to 5 minutes.

Mmm, dunno how to stop automatically the script... Of course, the text will say so, then ctrl-C. Maybe... knowing how long it should run, kill the script with a timer. Better parse the text somehow.

2025-04-04 23:35:18+02:00 	# 1  Extended offline    Completed without error       00%       618         -
^C
Telcontar:~/tmp/disk1 #

Ok, the procedure works. Now logging off, because I have a bug that crashes the machine a bit after midnight.
Improving the script has to wait.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#18298

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 13:33 +0200
Message-ID	<i1h7clxu39.ln2@Telcontar.valinor>
In reply to	#18283

On 2025-04-04 23:40, Carlos E.R. wrote:
> On 2025-04-04 12:53, Carlos E.R. wrote:
>> On 2025-04-04 09:53, Paul wrote:


> Well, no, leaving the terminal open is not enough, the long test is 
> aborted. Brilliant firmware, that. I'll have to create a script with the 
> test and a loop.
> 
> Initial script:
> 
> +++···················
> #!/bin/bash
> 
> THEDISK=/dev/sde
> 
> function busyloop()
> {
>     while true  ; do
>          DATE=`date --rfc-3339=s`
>          echo -en "$DATE \t"
>          smartctl -l selftest $THEDISK | grep "# 1"
>          sleep 1m
>     done
> }
> 
> echo smartctl --test=long $THEDISK
> echo
> busyloop
> ···················++-

...

> Ok, the procedure works. Now logging off, because I have a bug that 
> crashes the machine a bit after midnight.
> Improving the script has to wait.

Improved script:

+++···················
#!/bin/bash


function busyloop()
{
    while true  ; do
         DATE=`date --rfc-3339=s`
         TEXT=`smartctl -l selftest $THEDISK | grep "# 1"`
         echo -en "$DATE \t $TEXT\r"
         
         TEXT2=`echo "$TEXT" | grep "Self-test routine in progress"`
         if [ -n "$TEXT2" ]; then
             sleep 1m
         fi

         TEXT2=`echo "$TEXT" | grep "Interrupted"`
         if [ -n "$TEXT2" ]; then
             echo -e "\nTest Aborted."
             break
         fi

         TEXT2=`echo "$TEXT" | grep "Completed"`
         if [ -n "$TEXT2" ]; then
             echo -e "\nTest ended."
             break
             #echo -en "\r"
         fi

    done
}

if [ $# -eq 0 ]; then
     echo "runs SMART long test on the given device, and waits it out, verbosely"
     exit
fi
THEDISK=$1


smartctl --test=long $THEDISK
echo
busyloop

#parse output.

# 2025-04-04 23:35:18+02:00     # 1  Extended offline    Completed without error       00%       618         -
# 1  Extended offline    Self-test routine in progress 10%       618         -
# 2  Extended offline    Interrupted (host reset)      00%       614         -
···················++-

It runs like this:


Telcontar:~/tmp/disk2 # YottamasterLongtest /dev/sdf
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.4.0-150600.23.42-default] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 108 minutes for test to complete.
Test will complete after Sat Apr  5 15:15:23 2025 CEST
Use smartctl -X to abort test.

2025-04-05 13:30:24+02:00 	 # 1  Extended offline    Self-test routine in progress 90%      3989         -



The last line is overwritten every minute. Or could be every 5 minutes, but I'm testing. The terminal has to be kept open.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#18304

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 18:23 +0200
Message-ID	<3128clxb1o.ln2@Telcontar.valinor>
In reply to	#18298

On 2025-04-05 13:33, Carlos E.R. wrote:
> On 2025-04-04 23:40, Carlos E.R. wrote:
>> On 2025-04-04 12:53, Carlos E.R. wrote:
>>> On 2025-04-04 09:53, Paul wrote:
> 
> 
>> Well, no, leaving the terminal open is not enough, the long test is 
>> aborted. Brilliant firmware, that. I'll have to create a script with 
>> the test and a loop.
>>
>> Initial script:
...
> 
>> Ok, the procedure works. Now logging off, because I have a bug that 
>> crashes the machine a bit after midnight.
>> Improving the script has to wait.
> 
> Improved script:

...

> The last line is overwritten every minute. Or could be every 5 minutes, 
> but I'm testing. The terminal has to be kept open.

There is an impact of the script, that queries the status of the smart test; look at the output:

Telcontar:~/tmp/disk2 # YottamasterLongtest /dev/sdf
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.4.0-150600.23.42-default] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 108 minutes for test to complete.
Test will complete after Sat Apr  5 15:15:23 2025 CEST
Use smartctl -X to abort test.

2025-04-05 16:49:57+02:00 	 # 1  Extended offline    Completed without error       00%      3992         -
Test ended.
Telcontar:~/tmp/disk2 #

Instead of finishing at 15:15:23. it did at 16:49:57. It took more than one hour longer. So I'll change the delay to 8 minutes.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#18312

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 21:04 +0200
Message-ID	<3fb8clxkbr.ln2@Telcontar.valinor>
In reply to	#18304

On 2025-04-05 18:23, Carlos E.R. wrote:
> On 2025-04-05 13:33, Carlos E.R. wrote:
>> On 2025-04-04 23:40, Carlos E.R. wrote:
>>> On 2025-04-04 12:53, Carlos E.R. wrote:
>>>> On 2025-04-04 09:53, Paul wrote:

One more find: when I hibernate the computer, the leds on the box switch 
off, so I assume it powers down the disks. However, the fan keeps 
running. The fan is very silent, I have to put my ear very close to the 
box to distinguish it.

This is possibly not important for my use case, but it is a data point.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#18263

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-04 12:15 +0200
Message-ID	<v3o4clxl55.ln2@Telcontar.valinor>
In reply to	#18259

On 2025-04-04 08:30, vallor wrote:
> On Thu, 3 Apr 2025 22:01:43 +0200, "Carlos E.R." <robin_listas@es.invalid>
> wrote in <7263clxr47.ln2@Telcontar.valinor>:

...

>> What do you think about the error?
>>
>> <1.4> 2025-04-03T20:16:01.859892+02:00 Telcontar udisksd 2769 - -  Error
>> probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sde':
>> Unexpected sense data returned:#0120000: 00 00 00 00  00 00 00 00  00 00
>> 00 00  00 00 00 00    ................#0120010: 00 00 00 00  00 00 00 00
>>   00 00 00 00  00 00 00 00    ................#012 (g-io-error-quark, 0)
>>
>>
>> Bug report?
>>
>> (openSUSE Leap 15.6)
> 
> Well, Linux seems to see the partitions...
> 
> Maybe the drives will work anyway?  Have you tested them?

I don't have yet the blank hard disks to construct the software raid I 
intended, I expect them early next week.

I have two disks with data that I connected. I launched a file copy from 
both disks simultaneously (a /usr directory) and they are running at 
speeds of 4.5M/S. No errors on log.

I can try big file write, simultaneously, with dd.

Telcontar:~/tmp/disk1 # dd if=/dev/zero of=test bs=5M count=1000 
status=progress oflag=direct
5117050880 bytes (5.1 GB, 4.8 GiB) copied, 29 s, 176 MB/s
1000+0 records in
1000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 29.5996 s, 177 MB/s
Telcontar:~/tmp/disk1 #

Telcontar:~/tmp/disk2 # dd if=/dev/zero of=test bs=5M count=1000 
status=progress oflag=direct
5153751040 bytes (5.2 GB, 4.8 GiB) copied, 30 s, 172 MB/s
1000+0 records in
1000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 30.4898 s, 172 MB/s
Telcontar:~/tmp/disk2 #


So at least plain normal usage works.



-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#18281

From	Paul <nospam@needed.invalid>
Date	2025-04-04 16:30 -0400
Message-ID	<vspfi8$ctlr$1@dont-email.me>
In reply to	#18263

On Fri, 4/4/2025 6:15 AM, Carlos E.R. wrote:
> On 2025-04-04 08:30, vallor wrote:
>> On Thu, 3 Apr 2025 22:01:43 +0200, "Carlos E.R." <robin_listas@es.invalid>
>> wrote in <7263clxr47.ln2@Telcontar.valinor>:
> 
> ...
> 
>>> What do you think about the error?
>>>
>>> <1.4> 2025-04-03T20:16:01.859892+02:00 Telcontar udisksd 2769 - -  Error
>>> probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sde':
>>> Unexpected sense data returned:#0120000: 00 00 00 00  00 00 00 00  00 00
>>> 00 00  00 00 00 00    ................#0120010: 00 00 00 00  00 00 00 00
>>>   00 00 00 00  00 00 00 00    ................#012 (g-io-error-quark, 0)
>>>
>>>
>>> Bug report?
>>>
>>> (openSUSE Leap 15.6)
>>
>> Well, Linux seems to see the partitions...
>>
>> Maybe the drives will work anyway?  Have you tested them?
> 
> I don't have yet the blank hard disks to construct the software raid I intended, I expect them early next week.
> 
> I have two disks with data that I connected. I launched a file copy from both disks simultaneously (a /usr directory) and they are running at speeds of 4.5M/S. No errors on log.
> 
> I can try big file write, simultaneously, with dd.
> 
> Telcontar:~/tmp/disk1 # dd if=/dev/zero of=test bs=5M count=1000 status=progress oflag=direct
> 5117050880 bytes (5.1 GB, 4.8 GiB) copied, 29 s, 176 MB/s
> 1000+0 records in
> 1000+0 records out
> 5242880000 bytes (5.2 GB, 4.9 GiB) copied, 29.5996 s, 177 MB/s
> Telcontar:~/tmp/disk1 #
> 
> Telcontar:~/tmp/disk2 # dd if=/dev/zero of=test bs=5M count=1000 status=progress oflag=direct
> 5153751040 bytes (5.2 GB, 4.8 GiB) copied, 30 s, 172 MB/s
> 1000+0 records in
> 1000+0 records out
> 5242880000 bytes (5.2 GB, 4.9 GiB) copied, 30.4898 s, 172 MB/s
> Telcontar:~/tmp/disk2 #
> 
> 
> So at least plain normal usage works.

When you get your practice disks *do a capacity test*.

1) Create the array.
2) Fill the array with 1GB test files until it is full.
3) Did the array corrupt at 2.2TB worth of files ?

I could find evidence that the thing was using 28-bit LBA
instead of 48-bit LBA. I don't think the SATA specs even allow
that. All of SATA, should be in 48-bit addressing mode.

You should be *very suspicious* about this product,
and use test procedures appropriate for "mystery meat".

   Paul

[toc] | [prev] | [next] | [standalone]

#18282

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-04 22:52 +0200
Message-ID	<sdt5clxhsh.ln2@Telcontar.valinor>
In reply to	#18281

On 2025-04-04 22:30, Paul wrote:
> On Fri, 4/4/2025 6:15 AM, Carlos E.R. wrote:
>> On 2025-04-04 08:30, vallor wrote:
>>> On Thu, 3 Apr 2025 22:01:43 +0200, "Carlos E.R." <robin_listas@es.invalid>
>>> wrote in <7263clxr47.ln2@Telcontar.valinor>:

...

>> So at least plain normal usage works.
> 
> When you get your practice disks *do a capacity test*.
> 
> 1) Create the array.
> 2) Fill the array with 1GB test files until it is full.
> 3) Did the array corrupt at 2.2TB worth of files ?
> 
> I could find evidence that the thing was using 28-bit LBA
> instead of 48-bit LBA. I don't think the SATA specs even allow
> that. All of SATA, should be in 48-bit addressing mode.
> 
> You should be *very suspicious* about this product,
> and use test procedures appropriate for "mystery meat".

My routine includes filling the disks to capacity with pseudo random data. I wrote some code that does this at maximum speed ;-)

Oh, this is because I intend to encrypt the disks. I suppose I should encrypt the resulting raid device, say /dev/md0, then mount /dev/dm-0.

Another hurdle, is I need to read the FARM data, because there are fake new Seagate hard disks running around⁽¹⁾. I tested this:

+++··················
Telcontar:~ # smartctl -l farm /dev/sdf
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.4.0-150600.23.42-default] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

FARM log (GP Log 0xa6) not supported

Telcontar:~ #
··················++-

I have to find out if this because the disks I am using are old and do not have the FARM log yet, or the box firmware doesn't allow reading it. This is not crucial if I can read it somewhere else.

Huh, I have an idea. If this box in the end is not valid, I could rip it out and insert usb2sata connectors on the back of each disk. Use only the power supply and the iron. It would be ugly and impose a delay on my project, and waste of money, but would work.

(1) <https://www.tomshardware.com/pc-components/hdds/seagate-hard-drive-controversy-persists-as-scammers-discover-methods-to-alter-reliability-metrics>

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#18286

From	Paul <nospam@needed.invalid>
Date	2025-04-04 18:46 -0400
Message-ID	<vspnfl$kge7$2@dont-email.me>
In reply to	#18282

On Fri, 4/4/2025 4:52 PM, Carlos E.R. wrote:

> Huh, I have an idea. If this box in the end is not valid, I could rip it out and insert usb2sata connectors on the back of each disk. Use only the power supply and the iron. It would be ugly and impose a delay on my project, and waste of money, but would work.

Now, you are talking like a real scientist [Like] :-)

   Paul

[toc] | [prev] | [next] | [standalone]

#18287

From	Java Jive <java@evij.com.invalid>
Date	2025-04-05 00:20 +0100
Message-ID	<vsppfn$n253$1@dont-email.me>
In reply to	#18282

On 2025-04-04 21:52, Carlos E.R. wrote:
> 
> Huh, I have an idea. If this box in the end is not valid, I could rip it 
> out and insert usb2sata connectors on the back of each disk. Use only 
> the power supply and the iron. It would be ugly and impose a delay on my 
> project, and waste of money, but would work.

Wouldn't it be easier to try to solve the firmware problem?  If you're 
going to destroy the innards, invalidate the warranty, and so not be 
able to return it anyway, why not try installing a fixed firmware first?

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

[toc] | [prev] | [next] | [standalone]

#18291

From	Paul <nospam@needed.invalid>
Date	2025-04-04 23:05 -0400
Message-ID	<vsq6m0$17cbt$1@dont-email.me>
In reply to	#18287

On Fri, 4/4/2025 7:20 PM, Java Jive wrote:
> On 2025-04-04 21:52, Carlos E.R. wrote:
>>
>> Huh, I have an idea. If this box in the end is not valid, I could rip it out and insert usb2sata connectors on the back of each disk. Use only the power supply and the iron. It would be ugly and impose a delay on my project, and waste of money, but would work.
> 
> Wouldn't it be easier to try to solve the firmware problem?  If you're going to destroy the innards, invalidate the warranty, and so not be able to return it anyway, why not try installing a fixed firmware first?
> 

You can't really destroy it (apparently), as the ROM
inside the 578 is not volatile, and it allows attempts
to reflash the external SPI flash chip, as you wish.

Keep a backup copy of the existing SPI image (using the flasher
tool) and then that can be put back later if desired.

I get the impression that executing the "erase flash",
followed by a "power cycle" for the 578, puts it in
"ready-to-flash" mode.

   Paul

[toc] | [prev] | [next] | [standalone]

#18297

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 12:47 +0200
Message-ID	<ebe7clx3p.ln2@Telcontar.valinor>
In reply to	#18287

On 2025-04-05 01:20, Java Jive wrote:
> On 2025-04-04 21:52, Carlos E.R. wrote:
>>
>> Huh, I have an idea. If this box in the end is not valid, I could rip 
>> it out and insert usb2sata connectors on the back of each disk. Use 
>> only the power supply and the iron. It would be ugly and impose a 
>> delay on my project, and waste of money, but would work.
> 
> Wouldn't it be easier to try to solve the firmware problem?  If you're 
> going to destroy the innards, invalidate the warranty, and so not be 
> able to return it anyway, why not try installing a fixed firmware first?

But someone has to provide the fixed software file.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#18301

From	Java Jive <java@evij.com.invalid>
Date	2025-04-05 14:14 +0100
Message-ID	<vsrac2$2b6bi$1@dont-email.me>
In reply to	#18297

On 2025-04-05 11:47, Carlos E.R. wrote:
>
> On 2025-04-05 01:20, Java Jive wrote:
>>
>> On 2025-04-04 21:52, Carlos E.R. wrote:
>>>
>>> Huh, I have an idea. If this box in the end is not valid, I could rip 
>>> it out and insert usb2sata connectors on the back of each disk. Use 
>>> only the power supply and the iron. It would be ugly and impose a 
>>> delay on my project, and waste of money, but would work.
>>
>> Wouldn't it be easier to try to solve the firmware problem?  If you're 
>> going to destroy the innards, invalidate the warranty, and so not be 
>> able to return it anyway, why not try installing a fixed firmware first?
> 
> But someone has to provide the fixed software file.

Paul gave you a big clue in his post of 2025-04-04, 04:33.  He didn't 
want to give actual links because he couldn't verify their sources, but 
you can search on the file names he gave, for example:

https://duckduckgo.com/?q=jms578fwupdater.tgz

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

[toc] | [prev] | [next] | [standalone]

#18305

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 18:23 +0200
Message-ID	<l028clxb1o.ln2@Telcontar.valinor>
In reply to	#18301

On 2025-04-05 15:14, Java Jive wrote:
> On 2025-04-05 11:47, Carlos E.R. wrote:
>>
>> On 2025-04-05 01:20, Java Jive wrote:
>>>
>>> On 2025-04-04 21:52, Carlos E.R. wrote:
>>>>
>>>> Huh, I have an idea. If this box in the end is not valid, I could 
>>>> rip it out and insert usb2sata connectors on the back of each disk. 
>>>> Use only the power supply and the iron. It would be ugly and impose 
>>>> a delay on my project, and waste of money, but would work.
>>>
>>> Wouldn't it be easier to try to solve the firmware problem?  If 
>>> you're going to destroy the innards, invalidate the warranty, and so 
>>> not be able to return it anyway, why not try installing a fixed 
>>> firmware first?
>>
>> But someone has to provide the fixed software file.
> 
> Paul gave you a big clue in his post of 2025-04-04, 04:33.  He didn't 
> want to give actual links because he couldn't verify their sources, but 
> you can search on the file names he gave, for example:
> 
> https://duckduckgo.com/?q=jms578fwupdater.tgz
> 

It has to be an update of the Yottamaster model F55 specifically, and I 
didn't see any.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#18315

From	Paul <nospam@needed.invalid>
Date	2025-04-06 00:13 -0400
Message-ID	<vssv1e$3d34$1@dont-email.me>
In reply to	#18305

On Sat, 4/5/2025 12:23 PM, Carlos E.R. wrote:
> On 2025-04-05 15:14, Java Jive wrote:
>> On 2025-04-05 11:47, Carlos E.R. wrote:
>>>
>>> On 2025-04-05 01:20, Java Jive wrote:
>>>>
>>>> On 2025-04-04 21:52, Carlos E.R. wrote:
>>>>>
>>>>> Huh, I have an idea. If this box in the end is not valid, I could rip it out and insert usb2sata connectors on the back of each disk. Use only the power supply and the iron. It would be ugly and impose a delay on my project, and waste of money, but would work.
>>>>
>>>> Wouldn't it be easier to try to solve the firmware problem?  If you're going to destroy the innards, invalidate the warranty, and so not be able to return it anyway, why not try installing a fixed firmware first?
>>>
>>> But someone has to provide the fixed software file.
>>
>> Paul gave you a big clue in his post of 2025-04-04, 04:33.  He didn't want to give actual links because he couldn't verify their sources, but you can search on the file names he gave, for example:
>>
>> https://duckduckgo.com/?q=jms578fwupdater.tgz
>>
> 
> It has to be an update of the Yottamaster model F55 specifically, and I didn't see any.
> 

I don't think there are that many firmwares out there.

The "NVRAM" whether emulated or not, there are bytes
in there that control the controller operating mode,
and the NVRAM is not protected by a checksum.

  https://helmet.kafuka.org/bboard/thread.php?id=259

And some of these discussion threads, seem to indicate
the firmware size is a lot smaller than the flasher flash file
size. the uncompressed firmware might be 4MB, but if you
do a backup of an existing firmware, it's on the order of 50668 bytes.
Which is a more reasonable or believable value. When you get your
flasher package, you may want to pop the "firmware file" into
a hex editor, and see if large portions of it are zero. The SPI
chip inside your box, may not be a matching 4MB, but could be
a lot smaller, like maybe 128KB (to hold a 50668 byte file).

When we did two controllers (having entirely different functions),
the firmware for those fit in 3KB of code. That's why I had trouble
believing a firmware needed 3MB to work. And the 50668 bytes or whatever,
is still large, but isn't too much of a multiplier over 3KB.

   Paul

[toc] | [prev] | [next] | [standalone]

#18313

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 22:03 +0200
Message-ID	<fte8clxvj8.ln2@Telcontar.valinor>
In reply to	#18245

On 2025-04-03 22:01, Carlos E.R. wrote:
> 
> Hi,
> 
> I just bought a hard disk enclosure, a Yottamaster 5Bay USB3.0 Model F55 
> (non raid). My plan is to build a software raid 6 later.
> 
> Bought here <https://www.amazon.es/dp/B083Q8Z2KM>
> 
> I think it is this one:
> 
> <https://yottamaster.com/products/yottamaster-aluminum-5-bay-usb3-1- 
> type-c-external-hard-drive-enclosure-for-3-5-2-5-inch-sata-hdd-ssd- 
> support-5-x-16tb-mac-style-direct-attached-storage-das-ps500c3>

I just realized a big bug.

Telcontar:~/tmp/disk1 # smartctl -l selftest /dev/sdg | grep "# 1"
# 1  Extended offline    Completed without error       00%      3992         -
Telcontar:~/tmp/disk1 # smartctl -l selftest /dev/sdh | grep "# 1"
# 1  Extended offline    Completed without error       00%      3992         -
Telcontar:~/tmp/disk1 #

That output is wrong, the results for each disk have to be different.


Telcontar:~/tmp/disk1 # smartctl -a /dev/sdg | grep "User Capacity"
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/sdh | grep "User Capacity"
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Telcontar:~/tmp/disk1 #

That output is correct.

Telcontar:~/tmp/disk1 # smartctl -a /dev/sdh | grep "# 1"
# 1  Extended offline    Completed without error       00%      3992         -
Telcontar:~/tmp/disk1 # smartctl -a /dev/sdg | grep "# 1"
# 1  Extended offline    Completed without error       00%       618         -
Telcontar:~/tmp/disk1 #

This output is also correct.


Thus, some smartctl commands report the wrong data, all from the same disk.


I also noticed that the denominations /dev/sdX change when hot removing and inserting the same disk, so better use UUID to refer to partitions in the raid.


  /dev/disk/by-id/ | grep sd[gh]

ata-ST1000DM003-1CH162_S1D6LGPP -> ../../sdg
scsi-SExternal_USB3.0_0000007788FC -> ../../sdg
usb-External_USB3.0_0000007788FC-0:0 -> ../../sdg
wwn-0x5000c5005b57c31a -> ../../sdg

usb-External_USB3.0_0000007788FC-0:1 -> ../../sdh


Some of the denominations are missing, the only one that is usable is "usb-..."


  /dev/disk/by-path/ | grep sd[gh]

  pci-0000:03:00.0-scsi-0:0:0:0 -> ../../sdg
  pci-0000:03:00.0-scsi-0:0:0:1 -> ../../sdh
  pci-0000:03:00.0-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sdg
  pci-0000:03:00.0-usb-0:1:1.0-scsi-0:0:0:1 -> ../../sdh
  pci-0000:03:00.0-usbv3-0:1:1.0-scsi-0:0:0:0 -> ../../sdg
  pci-0000:03:00.0-usbv3-0:1:1.0-scsi-0:0:0:1 -> ../../sdh

These are usable. Now I remove a disk. Wait... Connect it back.

  /dev/disk/by-path/ | grep sd[gh]

  pci-0000:03:00.0-scsi-0:0:0:0 -> ../../sdg
  pci-0000:03:00.0-scsi-0:0:0:1 -> ../../sdh
  pci-0000:03:00.0-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sdg
  pci-0000:03:00.0-usb-0:1:1.0-scsi-0:0:0:1 -> ../../sdh
  pci-0000:03:00.0-usbv3-0:1:1.0-scsi-0:0:0:0 -> ../../sdg
  pci-0000:03:00.0-usbv3-0:1:1.0-scsi-0:0:0:1 -> ../../sdh


Ok, they hold.

  /dev/disk/by-id/ | grep sd[gh]

  ata-ST1000DM003-1CH162_S1D6LGPP -> ../../sdg
  scsi-SExternal_USB3.0_0000007788FC -> ../../sdg
  usb-External_USB3.0_0000007788FC-0:0 -> ../../sdg
  usb-External_USB3.0_0000007788FC-0:1 -> ../../sdh
  wwn-0x5000c5005b57c31a -> ../../sdg

They also hold, but not all are present, only the "usb...".


Oh, well.


Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:0 | grep "User Capacity"
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:1 | grep "User Capacity"
User Capacity:    1,000,204,886,016 bytes [1.00 TB]

Remove and insert one disk here.

Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:0 | grep "User Capacity"
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:0 | grep "User Capacity"
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:1 | grep "User Capacity"
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:1 | grep "User Capacity"
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:1 | grep "User Capacity"
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:0 | grep "User Capacity"
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:0 | grep "User Capacity"
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Telcontar:~/tmp/disk1 #


Notice that the first time I run the command changing disk it confuses them:

Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:0 | grep "User Capacity"
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:0 | grep "User Capacity"
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:1 | grep "User Capacity"
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Telcontar:~/tmp/disk1 # smartctl -a /dev/disk/by-id/usb-External_USB3.0_0000007788FC-0:1 | grep "User Capacity"
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Telcontar:~/tmp/disk1 #



I believe all this is a consequence of overriding the disk serial number. Fortunately, I will use partition uuid or labels to mount them or create the raid...



-- 
Cheers, Carlos.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

csiph-web

Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE)

Contents

#18283

#18298

#18304

#18312

#18263

#18281

#18282

#18286

#18287

#18291

#18297

#18301

#18305

#18315

#18313