• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Replacement HDD not detected

L

leicray

Member
The original HDD in my HDR-Fox T2 was accumulating errors and I had had to recover several defective sectors using the tools provided in the CF. I purchased a used replacement disk on eBay which had come from an upgraded Sky box. It's the identical make and model (Seagate Pipeline HD 2 ST3500312CS 500 GB) as the disk originally fitted.

The problem is that the disk is not detected at all when I install it. If I swap the original disk back in then that disk is detected. I have mounted the replacement disk via a USB adapter onto a Windows 10 machine and can see no issues. For good measure, I re-formatted the disk: FAT 32, MBR. Still no joy when connected into in the Hummy.

Any ideas would be gratefully received.
 
Many thanks for the prompt reply. It's not a jumper issue: no jumpers on either disk. Both disks have the same firmware installed too.
 
leicray said:
The problem is that the disk is not detected at all when I install it. If I swap the original disk back in then that disk is detected. I have mounted the replacement disk via a USB adapter onto a Windows 10 machine and can see no issues. For good measure, I re-formatted the disk: FAT 32, MBR. Still no joy when connected into in the Hummy.
Click to expand...
What version of the custom firmware are you using?
 
Using the Windows disk management console, delete any partitions on the replacement disk and make sure that the drive space is unallocated. Then install the disk in the HDR-FOX and see if you get the option to format it.
 
leicray said:
Many thanks for the prompt reply. It's not a jumper issue: no jumpers on either disk. Both disks have the same firmware installed too.
Click to expand...
Get to the Humax command prompt and issue "ls /sys/block/s*" and report what it prints.
 
Many thanks for the additional ideas. Answering them in order:

1. The CF is 3.13.
2. I deleted the partition and refitted the drive. Still not detected.
3. The output is: ls: /sys/block/s*: No such file or directory
 
leicray said:
1. The CF is 3.13.
Click to expand...
I assume you are running the usual version with the kernel compiled by af123. You could try installing the alternate version with the stock kernel (ie the kernel as supplied by Humax) and see if that helps.
3. The output is: ls: /sys/block/s*: No such file or directory
Click to expand...
Where did the colons come from?
 
1. It is the usual version with the kernel compiled by af123: HDR_FOX_T2_1.03.12_mod_3.13.zip

3. The colons are exactly as seen in the output from running the command from the CLI using PuTTY to telnet in.

Breaking news: I installed a smaller Seagate disk (80 GB) which was still formatted in NTFS and with Windows 10 on it and the Hummy spotted it right away and prompted me to format it. So, the intended replacement disk must be defective in some way, but it's not at all clear what's actually wrong.

The problem disk mounts fine on my Windows 10 desktop PC, but I did have problems mounting it reliably (using the same USB adapter) onto a Linux Mint laptop. This leads me to think that it's a Linux-related issue.
 
Last edited:
leicray said:
The colons are exactly as seen in the output from running the command from the CLI using PuTTY to telnet in.
Click to expand...
The colons are normal (don't know what Martin's on about) but the result isn't good. Try the standard kernel as he suggested. If that works, then you could try the debug kernel which may or may not reveal what the problem is, but you'll probably need expert help from af123 .
 
prpr said:
The colons are normal (don't know what Martin's on about) but the result isn't good.
Click to expand...
That's the output AFTER having deleted the only partition on the disk. Perhaps it's not so strange.

I am now doing a complete reformat (exFAT) of the disk in Windows 10, but it's a slow process and I'll report back later. I remain of the opinion that the disk is defective in some way that's only a problem in Linux.
 
leicray said:
That's the output AFTER having deleted the only partition on the disk. Perhaps it's not so strange.
Click to expand...
You should at least see sda. If there was a partition, you'd see sda1 etc. as well.
Linux isn't seeing this disk.
I am now doing a complete reformat (exFAT) of the disk in Windows 10, but it's a slow process and I'll report back later.
Click to expand...
This is a pointless waste of time. The problem is not with any filesystem.
I remain of the opinion that the disk is defective in some way that's only a problem in Linux.
Click to expand...
Yes, but you will only find out what by trying the alternative kernels as suggested. This is a lot quicker than what you are doing, but you seem not to want to do it for some reason...
 
prpr said:
This is a lot quicker than what you are doing, but you seem not to want to do it for some reason...
Click to expand...
There's no need for the accusative tone. Instead, why not EXPLAIN why I might have more success with the standard and debug kernels? Is there some feature of the kernel compiled by af123 that might be preventing the disk being detected? I genuinely want to learn.
 
leicray said:
Instead, why not EXPLAIN why I might have more success with the standard and debug kernels? Is there some feature of the kernel compiled by af123 that might be preventing the disk being detected?
Click to expand...
There have been situations reported in the past where the af123 kernel has had exactly this problem of a hard drive not being recognised; I believe that af123 tweaked his kernel and the number of problem reports has certainly diminished but I think it might be worth trying. When af123 is back from his holidays he may be able to guide you through using the debug kernel to find out exactly what the problem is.
 
leicray said:
why not EXPLAIN why I might have more success with the standard and debug kernels?
Click to expand...
If you have a search on this forum (or particularly the wiki page that describes the various custom firmware downloads available), you will see that there are examples of disks not being recognised with some versions. Why that might happen with an apparently identical disk is strange though.

The problem is access at the lowest level; for the disk not to be registered at all (even for an error to be reported), there is some fundamental problem and the formatting is irrelevant.
 
Thank you to MartinLiddle and Black Hole for their explanations.

I will start by downloading the standard kernel version of the CF, and go from there. I'll report back sometime tomorrow.
 
Black Hole said:
If you have a search on this forum (or particularly the wiki page that describes the various custom firmware downloads available), you will see that there are examples of disks not being recognised with some versions. Why that might happen with an apparently identical disk is strange though.
Click to expand...

In my past life as a computer engineer we came across supposedly identical disk drives from a manufacturer, but you couldn't change the electronics between them as there had been hardware changes to the disk mechanism and changes to the electronics, which then resulted in firmware changes to handle the hardware and electronics changes. The disk drive was still marketed as the same model number though.

Most frustrating when one had a drive die with an electronic failure and found it was impossible to make one drive good drive by raiding the electronics from one that had failed platters.

I suspect the OP is finding there are subtle differences in the firmware between the two drives which causes Linux to barf with the new drive.
 
First, thanks to antipodean for these further thoughts. Could very well be the basis of the problem in spite of the disk labels claiming that both disks are running the same version of the firmware.

I have done some additional checks and remain as confused as before:

I allowed the reformatting of the replacement disk to complete. That disk now mounts without problems on my Linux laptop, where mounting had previously been rather hit and miss. However, the disk is still not recognised by the Hummy. Just to be certain, I went back to the original disk and that is recognised as normal.

Next, I installed the CF based on the stock kernel. The Hummy refused to start (whichever disk was installed) and simply went into a never ending restart cycle. Installing the CF based on the kernel compiled by af123 sorted out matters immediately. Can anybody say why there was a problem with the stock kernel version.
 
leicray said:
Next, I installed the CF based on the stock kernel. The Hummy refused to start (whichever disk was installed) and simply went into a never ending restart cycle. Installing the CF based on the kernel compiled by af123 sorted out matters immediately. Can anybody say why there was a problem with the stock kernel version.
Click to expand...
What? You are confusing me (and maybe us). What is the difference between the CF you had installed in the first place and "the CF based on the kernel compiled by af123"?
 
My understanding is that there THREE versions of the CF, each based on firmware version 1.03.12. The "default" CF appears to be the one labelled as "Custom Firmware" on the download page. In addition there are two versions labelled "Custom Firmware with Debug Kernel" and "Custom Firmware with Stock Kernel".

My Hummy fails to boot using the "Custom Firmware with Stock Kernel", but does boot successfully with the "Custom Firmware".

Does that clarify matters? Apologies if I have misunderstood your question.
 
Last edited:
You must log in or register to reply here.
Back
Top