Bricked Drive?

I would be looking more at the possibility of my bricking the drive if the first one wasn't already toast when I got it. I pulled the drive out and CrystalDiskInfo agreed it was bad. I immediately used my USB2SATA adapter to connect it to my system and use Fabs to back it up. I then was able to image the drive. The drive was then set aside and a replacement was ordered. When it arrived I restored the image to the new drive and installed it in the original machine. No love. It would start to boot, but then reboot. Then it would start to load Windows, then reboot. Then it just quit altogether. I tried a different SATA connection, same thing. I even took it and put it into my own machine thinking maybe his MB had a bad temperature sensor or something. My thought at this point was that it was a software issue that came over from the old drive. It did the same thing in mine. Now I'm thinking there's a problem with the drive itself. Rare, but it happens. I went back to the original drive and tried to mount it in the original machine. Zip, nothing, Nada. Alright, something strange is going on here. So, I go looking for information on the MB (Pegatron m2n78-la), and read thread after thread about this board's failure rate being insanely high. The problem? Losing connection to the SATA drives. My suspicion is that the MB started acting up on him awhile back and he just ignored it until it wouldn't boot at all anymore and brought me in.
How does any of that invalidate the theory that the client's system you plugged your new drive,which was working until you did that, into didn't cook the drive? If this board has a reputation for HDD problems....
 
My thought at this point was that it was a software issue that came over from the old drive. It did the same thing in mine.

When you connect it to your own system via a SATA cable, does BIOS recognize it correctly?

I would expect that if the drive is so boned that it can't be seen via a known good SATA/USB adapter, it was a lemon out of the box and you should shoot it back to the distributor. Likely it won't show up correctly if connected as above, if you go straight into BIOS without trying to boot Windows.

How does any of that invalidate the theory that the client's system you plugged your new drive,which was working until you did that, into didn't cook the drive? If this board has a reputation for HDD problems....

This could be a Cougar Point chipset, late 2010 early 2011, so mayhaps the system boned the drive. I haven't heard of a Cougar Point actually ruining a drive, usually just slow performance as I recall, but also possible that the drive was defective right out of the gate.

I picked up one brand spanking new WD Black that initially was ok, but a week later it sounded like it was arc welding it's girlfriend's initials onto the servo tracks. Customer called me about it, his phone was picking it up from the next room. It was just a factory clinker. Still had the image from the old drive, slipped in a new copy of the same model and it's been good as gold for 5 years. Might be time to retire it...
 
Last edited:
How does any of that invalidate the theory that the client's system you plugged your new drive,which was working until you did that, into didn't cook the drive? If this board has a reputation for HDD problems....

It doesn't. In fact, that is precisely my contention, and the question I asked in the beginning. As it is, Linux Mint is able to see that there is a drive, but is unable to know anything about it such as size, partitions,, or files.
 
So the client has a bad 1TB drive. I order a new WD 1TB Black drive and when it arrives I image the drive and install it. After several "What the...?" moments I conclude that the MB isn't seeing the drive. I investigate and apparently this MB has a history of failing to see the SATA drives. Nice. I call the client and give them the good news and he agrees to buy a new system. Fine. I plug the new drive in via USB and my system won't see it. I attempt to initialize it but am unable to because "The disk is not convertible because the size is less than the minimum size required for GPT disks." I can't initialize it as an MBR because "The device is not ready." WD's Data Lifeguard is no use to me either. Did installing it in the bad system brick this brand new drive?

Ok,
Just let me know if I'm missing something.
New drive never worked right, except for the initial image, (which it may have failed during)?
Have you considered you received a faulty drive, (replace under warranty)?

I'm still on my 1st cup of coffee, so maybe I'm mis-reading the original post?
 
I'm wondering if this has something to do with the drive using 4K sector size, which makes it look 1/8th it's correct size on MBs or using USB bridges that don't support drives with 4K native sector size?
 
I was under the impression that the drive worked just fine until he plugged into the clients system. He was able to pull the old drive out of the system and image it via a USB connector. He was also able to use the same USB connector to place the image on the new drive. He then put the new drive into the old system and it promptly died. He put the original drive back in the system and it too died. Now neither drive can be seen on the clients system nor via USB connector. He has been asked the question of whether he has tried to use a SATA cable and connect to his system directly. I've not been able to figure out if he did that or not. He mentions Linux on a laptop.

But again it sounds to me like the client's PC has either a bad Mobo, bad PSU or both and it cooked both drives. Been in this business for 20 years and seen it happen before. It is rare but not unheard of.
 
I'm wondering if this has something to do with the drive using 4K sector size, which makes it look 1/8th it's correct size on MBs or using USB bridges that don't support drives with 4K native sector size?

Yes but if we understood him correctly he was able to access the drive initially via the USB link. He imaged the old drive using it and imaged TO the new drive using it.
 
Yes but if we understood him correctly he was able to access the drive initially via the USB link. He imaged the old drive using it and imaged TO the new drive using it.
Exactly, which is why I finally agreed with you, that the PSU/MB bricked both drives. It was a little difficult understanding the sequence of events, but on re-reading I reached the same conclusion as you did. Not his fault, nothing he could have done to prevent it. Really tough break for his customer and Mike.
 
The BIOS on the drive can identity a drive in kernel mode. I need to know if it shows the correct model and capacity.

Old drive - old machine: Initially, yes. However, that became sporadic as time went on. When it could see it completely, it would boot into Windows and hang when I lost the drive. If it could only see the drive but not capacity it would hang at POST.

Newly imaged drive - old machine: Same as above.

Newly imaged drive - direct SATA connection my machine: Initially would see model and capacity. same boot problems. Then, quit seeing capacity, then quit seeing model.

Newly imaged drive - USB2SATA: Same as direct SATA connection.

Newly imaged drive - USB2SATA - Linux Mint: Could only tell that a disk was connected, no model or capacity.

Now, this morning I decide to again connect each drive into the old machine. No video signal. Fans turn but that's all. Whatever it's problem is, it's hosed. So I connect the new drive once again via my USB2SATA adapter and everything seems fine. Explorer recognizes it, assigns drive letters to the partitions, and all the files are available. No apparent problems with it at all! Seeing an opportunity I delete the partitions and format the drive. I then switch to the old drive and it seems fine too! Had to go out for the day and so have not followed up. I know that this makes me look completely incompetent, and I must admit I don't know why there would be all these problems with the drives, only to magically repair themselves when I'm not looking. Perhaps your assessment of me is correct after all.
 
2 funqui.

I know that this makes me look completely incompetent, and I must admit I don't know why there would be all these problems with the drives, only to magically repair themselves when I'm not looking. Perhaps your assessment of me is correct after all.

Please. If that were so, you'd be wearing a Geek Squad uniform. My guess is you mostly get things right. I guess you're saying you might have this or that to learn and I salute that.

Sometimes, based on your experience, you may discount the notions of other techs, recommendations and requests for further info all over the place, it's the nature of the forum. I'd tend to give requests for info from a D.R. guy wrt HDD's more cred, but that's just me.

So all in all, you're getting some pretty whacky results.

So I connect the new drive once again via my USB2SATA adapter and everything seems fine.

You connected it to your bench, or the customer's system?

Does the customer's system have a Cougar Point chipset, with Sata 3 and Sata 2 ports?
 
On the new drive you need to perform via a SATA connection, not that damn USB, on your PC not the clients a full diagnostic. If it doesn't fully pass then you need to RMA it.

On the client's system you need to test the Power Supply.
 
Please. If that were so, you'd be wearing a Geek Squad uniform. My guess is you mostly get things right. I guess you're saying you might have this or that to learn and I salute that.

I absolutely have lots to learn. Who doesn't? I never intended to suggest I thought otherwise otherwise.

Sometimes, based on your experience, you may discount the notions of other techs, recommendations and requests for further info all over the place, it's the nature of the forum. I'd tend to give requests for info from a D.R. guy wrt HDD's more cred, but that's just me.

I'm not sure I understand this statement. If you are referring to the unintentional oversights, distractions, and general human weakness, I agree. We're all subject to those weaknesses. If you're suggesting that because I have some puffed-up opinion of myself (pride), such that I would blow-off someone of greater knowledge/experience in any way, you are mistaken.

The truth is that this is a generally poor form of communication for a number of different reasons. Things get overlooked, misinterpreted, conclusions are jumped toward, assumptions are made, and people are just messy to deal with.

So all in all, you're getting some pretty whacky results.

In technical terms, yes. My thinking at this point is that perhaps if the board has been losing communication with the drive repeatedly and over time, that the on again/off again voltage may cause problems with the drive, even if connected for a short time. The biggest reason I'm looking at the board being the problem is because of the high failure rate focused on losing SATA connections, which is what I've seen personally.

You connected it to your bench, or the customer's system?

Ugh, both, if you're referring to my last post. First to the client system where I note an apparent complete board failure, then to my bench where the drives seem to magically heal themselves.

Does the customer's system have a Cougar Point chipset, with Sata 3 and Sata 2 ports?

According to this 34 page thread ( http://h30434.www3.hp.com/t5/Deskto...m2n78-la-mother-board-doesn-t-see/td-p/181716) on the problems with this board, it has an NVIDIA chipset.
 
On the new drive you need to perform via a SATA connection, not that damn USB, on your PC not the clients a full diagnostic. If it doesn't fully pass then you need to RMA it.

On the client's system you need to test the Power Supply.

Why would I connect anything via USB to the client's system which will not boot under any circumstances?

I can certainly test the PS, though the board is toast either way.
 
Why would I connect anything via USB to the client's system which will not boot under any circumstances?
Why would you under ANY circumstances? I only use a USB device if I literally have no other choice. I'm onsite with a client and all we have are laptops. They frak up too often to risk.

I can certainly test the PS, though the board is toast either way.
A faulty PSU could be causing all the issues with your motherboard. You might be amazed how the board you thought was dead will work perfectly once the bad PSU is replaced. Unless you are 100% certain of the condition of your PSU your assumptions about the motherboard are totally worthless to me. And you may end up being totally correct but I've seen too many weird stuff with flaky power supplies not to test it first. The PSU is the MOST LIKELY component to fail in a PC. Even higher than a HDD. 20 years of computer repair has taught me that the hard way.
 
Hooked it up to a netbook running Linux Mint. It could see that there was a drive attached, but could not tell me anything about it, nor could it do anything with the drive. There was nothing Linux could see about it, or do with it.

What did you do with the drive when hooked up in linux?

Here is what I would have done:

After booting up linux I would open a term window and type in the following:

sudo tail -f /var/log/kern.log

Hit enter. (Now you are setup to see what the computer sees when you plugin the sata drive )

Now plugin the sata drive and watch the new entries in the log file. Capture the lines of the log file that you see and post them in your reply to this post. That way I can see what is going on.

BTW -- Mike, Do not be so short fused. I saw the reply to the post from lcoughey. I also did not see your reply to their questions. They asked:

1. Model number of drive.
2. Does the bios see it? and if it does is it the correct model number?

All you said was "The MB does not see it". MB and Bios are two different things really. I can understand the misunderstanding on this. So, Do not get upset over this.

Now, Just post the output of the log file. It will tell us a lot.

:) coffee
 
What did you do with the drive when hooked up in linux?

Here is what I would have done:

After booting up linux I would open a term window and type in the following:

sudo tail -f /var/log/kern.log

Hit enter. (Now you are setup to see what the computer sees when you plugin the sata drive )

Now plugin the sata drive and watch the new entries in the log file. Capture the lines of the log file that you see and post them in your reply to this post. That way I can see what is going on.

BTW -- Mike, Do not be so short fused. I saw the reply to the post from lcoughey. I also did not see your reply to their questions. They asked:

1. Model number of drive.
2. Does the bios see it? and if it does is it the correct model number?

All you said was "The MB does not see it". MB and Bios are two different things really. I can understand the misunderstanding on this. So, Do not get upset over this.

Now, Just post the output of the log file. It will tell us a lot.

:) coffee

Jun 15 12:15:17 MobileDork-SCS kernel: [ 332.640169] usb 1-3: new high-speed USB device number 3 using ehci-pci
Jun 15 12:15:17 MobileDork-SCS kernel: [ 332.774498] usb 1-3: New USB device found, idVendor=152d, idProduct=2338
Jun 15 12:15:17 MobileDork-SCS kernel: [ 332.774520] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Jun 15 12:15:17 MobileDork-SCS kernel: [ 332.774533] usb 1-3: Product: USB to ATA/ATAPI Bridge
Jun 15 12:15:17 MobileDork-SCS kernel: [ 332.774545] usb 1-3: Manufacturer: JMicron
Jun 15 12:15:17 MobileDork-SCS kernel: [ 332.774557] usb 1-3: SerialNumber: D57CA6594824
Jun 15 12:15:17 MobileDork-SCS kernel: [ 333.254110] usb-storage 1-3:1.0: USB Mass Storage device detected
Jun 15 12:15:17 MobileDork-SCS kernel: [ 333.254394] scsi2 : usb-storage 1-3:1.0
Jun 15 12:15:17 MobileDork-SCS kernel: [ 333.254767] usbcore: registered new interface driver usb-storage
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.253606] scsi 2:0:0:0: Direct-Access WDC WD10 EADS-65M2B1 0A01 PQ: 0 ANSI: 2 CCS
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.255351] sd 2:0:0:0: Attached scsi generic sg1 type 0
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.256757] sd 2:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.257772] sd 2:0:0:0: [sdb] Write Protect is off
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.257788] sd 2:0:0:0: [sdb] Mode Sense: 00 38 00 00
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.258766] sd 2:0:0:0: [sdb] Asking for cache data failed
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.258784] sd 2:0:0:0: [sdb] Assuming drive cache: write through
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.268496] sd 2:0:0:0: [sdb] Asking for cache data failed
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.268514] sd 2:0:0:0: [sdb] Assuming drive cache: write through
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.275970] sdb: sdb1
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.279856] sd 2:0:0:0: [sdb] Asking for cache data failed
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.279875] sd 2:0:0:0: [sdb] Assuming drive cache: write through
Jun 15 12:15:18 MobileDork-SCS kernel: [ 334.279889] sd 2:0:0:0: [sdb] Attached SCSI disk
 
Back
Top