HDD diagnosis under PartedMagic

[Romaniac]

Hey all.

Did some searching, nothing came up.
When diagnosing HDDs, I sometimes run into this error:

exist status 1
udevil: error 64: unable to determine device fstype - specify with -t

The drive seems to be spinning up ok. Is this a logical issue, that could be fixed without sending to the DR experts?

In case data recovery would be needed, is there anything I can try while in PM?
Anything I can invest in, that deals with this particular error? (Software, perhaps? not looking for $Ks worth of equipment)
I guess the obvios would be to specify 'ntfs', but google has given me little.
How can I specify with -t? And has anyone ever had success with that?

I'm guessing this error could be caused by a myriad of issues...?

Thanks for the help!

 

[phaZed]

It sounds like your trying to mount the fs, correct? Are you doing this through the GUI or through the CLI?

From the error, you should be able to tack "-t" + the File system type as listed in udevil --help

What *NIX are you running?

 

[Romaniac]

This is all while running PartedMagic (off a boot CD) which runs under Linux.

I'm trying to mount the whole HDD via dock station.

 

[doubleohalex]

It looks like PM cannot determine the filesystem type of the suspect drive. This could be due to the docking station, have you used this specific dock with PM before? What are your goals with the drive? Please bare with me as I'm typing this out quickly before heading out.

Lets make sure PM can see the drive in the first place. Open up Terminal and run:

fdisk -l

This will list all recognized storage media. You should see disks labeled /dev/sda, /dev/sdb, /dev/sdc ..etc. The suspect drive, if recognized, would be listed along with its size. Below the drive listing you will see the partitions listed such as /dev/sda1, /dev/sda2 along with its filesystem type. You'll want to make note of the main data partition. For this example I'll use /dev/sda1 as the partition and assume the filesystem of the suspect drive is NTFS.

Using udevil you should be able to just run:

udevil mount -t NTFS /dev/sda1

If that failed, you can try to mount the drive the manual way by creating a mount point and running the mount command with -t to specify the suspect drives filesystem type. To do this you can create a folder anywhere within root drive of PM and mount the drive to that folder. For this example we'll create a folder under the /mnt directory and name it "test". To do this you will want to open the terminal and run the command:

mkdir /mnt/test

Once this is complete, I like to verifiy the directory was created by running:

ls /mnt

This will list all files and folders under the /mnt directory. You should see the test folder listed. Now we are going to want to mount the suspect drives data partition to the mount point we just created. Run:

mount -t NTFS /dev/sda1 /mnt/test

You should now be able to browse to the /mnt/test folder and see the contents of the suspect hard drive. By default, you will only have read access to NTFS in linux. Additional steps will be needed if you want read write access.

I'm not sure how mounting with the standard mount command will fare with the diagnostic tools in PM, I've never used the combination of the 2. At the least, you'll be able to see if the data is accessible.

 

[NJW]

mount -t NTFS /dev/sda1 /mnt/test

To mount an NTFS partition in modern Linux (incl. PartedMagic, afaik) this should be:

ntfs-3g /dev/sda1 /mnt/test

or

mount -t ntfs-3g /dev/sda1 /mnt/test

Using the option '-t NTFS' will not work, as Linux is case sensitive ("mount: unknown filesystem type 'NTFS'"). ntfs is usually symlinked to ntfs-3g, so

mount -t ntfs /dev/sda1 /mnt/test

will probably also work.

ntfs-3g has long provided both read and write access to NTFS partitions. Use

ntfs-3g -o ro /dev/sda1 /mnt/test

for read-only.

 

[lcoughey]

When diagnosing HDDs, I sometimes run into this error:

exist status 1
udevil: error 64: unable to determine device fstype - specify with -t

The drive seems to be spinning up ok. Is this a logical issue, that could be fixed without sending to the DR experts?

This is a very bad first step for diagnosing a hard drive. You may want to review the article I posted on how to triage a hard drive - https://www.technibble.com/forums/resources/how-to-triage-a-hard-drive.17/
The first step should be to get a clone of the drive.

In case data recovery would be needed, is there anything I can try while in PM?

As I just stated, you should be getting a clone. You should use ddrescue...if you are unable to complete the clone or encounter a significant amount of read errors, you should stop and seek the advice of your partner data recovery lab.

Anything I can invest in, that deals with this particular error? (Software, perhaps? not looking for $Ks worth of equipment)
I guess the obvios would be to specify 'ntfs', but google has given me little.
How can I specify with -t? And has anyone ever had success with that?

I'm guessing this error could be caused by a myriad of issues...?

There is a chance that the issue is because of the need to be mounting ntfs-3g vs ntfs (as mentioned by NJW), but it is unlikely that this is the case and more likely due to other reasons that should not be explored until the drive is cloned.

 

[doubleohalex]

To mount an NTFS partition in modern Linux (incl. PartedMagic, afaik) this should be:

ntfs-3g /dev/sda1 /mnt/test

or

mount -t ntfs-3g /dev/sda1 /mnt/test

Using the option '-t NTFS' will not work, as Linux is case sensitive ("mount: unknown filesystem type 'NTFS'"). ntfs is usually symlinked to ntfs-3g, so

mount -t ntfs /dev/sda1 /mnt/test

will probably also work.

ntfs-3g has long provided both read and write access to NTFS partitions. Use

ntfs-3g -o ro /dev/sda1 /mnt/test

for read-only.

Thanks for the correction. I did not mean to capitalize NTFS, was in a rush. Not using ntfs-3g should work, although I've never used ntfs-3g so thanks for pointing that out! My experience is with SLES for legacy products and disaster recovery and I've never really had a need to give NTFS writeable access. In a diagnostic scenario, you probably don't want write access either.

 

[NJW]

In a diagnostic scenario, you probably don't want write access either.

Exactly, but mounting the NTFS partition, unless explicitly using the read-only option, will allow writing. The danger is not that the technician will deliberately write something, rather that the system will – atime, for example.

It all comes back to using ddrescue first, which doesn't require anything to be mounted.

 

[mrapoc]

I'd be doing a DDrescue.

Anything like this makes my hair stand on edge

 

[LifelineIT]

In my experience, if PM can SEE the drive, it will mount symlink it to the desktop. It does NOT mount by default, but it WILL mount if you double click it. There's a utility in the taskbar that'll show you all connected drives, mounted or otherwise. PM does NOT need explicit instructions to mount any modern filesystem afaik, I do HFS and NTFS all the time. It's likely that it is your dock, although again I've never had any of my docks cause me issues. Gsmart does NOT need the drive to be explicitly mounted to do what it does, it'll do that on its own.

I'd personally direct-connect the drive, then image it, then fiddle with it.

 

[Romaniac]

Great support. Thanks to all and thanks doubleohalex for the walk-through; and NJW.
Will be checking that thread, lcoughey.

If the issue is logical, and not physical/mechanical, can a mount attempt under PM/linux environment do more damage?


Answers:
The dock works, and tested it with another drive. Used it before plenty of times.
I will try another usb to sata connector, to be sure - this was on the 'to do' list, but a reminder is good.

I suppose I should make a clone - these are very likely headed to partner lab though, and rate is same for logical or mechanical (most cases, anyway).

That's why I just wanted to see if specifying with -t would yield anything.
ddrescue will take so much time, and space.

It sucks sending in stuff for logical issues...

 

[lcoughey]

these are very likely headed to partner lab though, and rate is same for logical or mechanical (most cases, anyway).

Then you are either overpaying for easier recoveries or underpaying for clean room projects, depending on what that rate is.

That's why I just wanted to see if specifying with -t would yield anything.
ddrescue will take so much time, and space.

At the very least, it takes time and resources to do data recovery. You should not offer data recovery if you are cheap and lazy.

It sucks sending in stuff for logical issues...

Assuming it is a logical issue.

Just to put things in perspective, I just received a client drive that makes no unusual noises, detects but won't mount. The tech tried to read via multiple systems, with no luck. The problem with the drive is that of the 2 read/write heads, one head is not reading at all. The one head that does read is the first head that reads sector 0, showing a partition table, but because the other head is toast, the drive fails to read the MFT.

Fortunately, the tech recognized that this was beyond his capabilities and sent the user directly to me. Had he assumed that this was a logical issue and fought tried to fight with it, he would have completely killed the drive. As it stands right now, the one head that is reading is barely reading and it looks like a head change cannot be avoided.

 

[Romaniac]

Yeah, I think that is the case - overpay and underpay. They're still the best for me and my area. Some local DR start at $200 just to recover deleted data (which I've done for clients, for less). After that, prices just soar. Few even differentiate between clean-room or not.

Most clients say no to big $ recovery - they just can't afford it and move on. Sometimes 'cheap' works out for them; they know the deal/risks and agree to it.

For some, it works out. The ones that have physical damage and/or logical just cut their losses.

Thanks for the no noise, not logical issues example though; that's a good thing to keep in mind.