Notifications
Clear all

Imaging a M.2 SSD

BlueBird23
(@bluebird23)
New Member

Hi All,

Background

Recently I was asked to remove and image an M.2 SSD from a laptop.

Most of the imaging we do via a TD2u as its just so convenient to create a master copy and working copy at the same time.

I inserted the M.2 SSD into an adapter similar to the one below, expect the adapter I used outputs a USB 3.0 connection via a type C port
https://www.amazon.co.uk/Neoteck-Aluminum-Enclosure-Converter-Linux-Black/dp/B01LWSPL3E/ref=sr_1_1?ie=UTF8&qid=1495322457&sr=8-1&keywords=m.2+to+usb

When plugged into TD2u no source was recognized by the write blocker; though the IDE source light was lit despite the adapter being plugged in via USB.

I tried a different TD2u and adapter to attempt to fix the error but all were consistent in their results.

I ended up using a paladin live usb to image the devices; but this leads to my questions

1) Has anyone ever came across this error before? If so is there any fix or is live imaging of M.2 devices the only way to obtain an image as of right now?

2) Is this an adapter issue? If so what adapter would you recommend?

Any other advice would be greatly appreciated.

Thanks for you help!

Quote
Topic starter Posted : 21/05/2017 5:25 am
athulin
(@athulin)
Community Legend

When plugged into TD2u no source was recognized by the write blocker; though the IDE source light was lit despite the adapter being plugged in via USB.

Have you verified that the adapter you used works as it should? If not, that should be the first thing you do. That is, given another M.2 unit of the same (or perhaps similar) characteristics, does it work as a USB?

Without details (by which I mean M.2 and adapter manufacturer's names, product identification etc.), there's basically only guesses, and that's not a good basis for conclusions.

I tried a different TD2u and adapter to attempt to fix the error but all were consistent in their results.

Different, how? Trying a different TD2u seems odd – were you not already confident that the first one worked as it should? Testing a different M.2 adapter would make sense if you hadn't tested the first adapter, and so couldn't know that that particular unit worked correctly. But that suggests something may be wrong in your workflow using untested equipment seems … well, not quite best practice. (Yes, we all do it from time to time, but when things go wrong, the first thing is always to test that untested unit to ensure it works as it should.)

Was the second adapter another product entirely, or just another unit of the same product? (I'm assuming the same product for now.)

Did you use tested and working cables or other connecting equipment?

As it is, it seems that the M.2 unit is working, but may not interface correctly with the adapter, or that the adapter isn't working (as a product, but possibly only as a unit), or that cables and other equipment used for connecting the units aren't working. (I exclude the possibility that the TD2u product isn't working as unlikely, even though you don't state that you have tested that.)

Additional tests, consequently, should be performed to reduce those possibilities as much as possible. (As you know the exact conditions, and what prior tests of the equipment you have performed, you may come up with a different list of things to do.)

1) Has anyone ever came across this error before? If so is there any fix or is live imaging of M.2 devices the only way to obtain an image as of right now?

Without any information as to what products are involved, no one can say if this particular error has been encountered before. The adapter producers may be in the best place to say, provided they take customer support seriously. The M.2 manufacturers may also be well-placed, though it depends on the actual product it could be special in some way. (Just like you occasionally may come across hard disks with a sector size of 520 or 528 bytes, and find that some part of your workflow doesn't handle those well.)

Similar problems have been encountered hard disks from laptops cannot always imaged away from that laptop, but needs to be imaged in place. This may be due to some kind of additional protective setup that marries the disk to the laptop, either on unit-to-unit basis, or on a product-to-product basis. I can't remember having seem any detailed investigation of the problem – I don't think I have encountered it myself. But something like that *might* be the case here as well.

2) Is this an adapter issue?

There's nothing in your test description that identifies it as more than a possibility. You need to perform additional tests (or describe the tests in more detail) to definitely nail it down to the adapter.

If the adapter manufacturer is a reputable company, you may find them to be in the best position to answer your question they would be likely to have the same question from many other buyers, and may have investigated it already.

ReplyQuote
Posted : 21/05/2017 2:40 pm
C.R.S.
(@c-r-s)
Active Member

Probably all those adapters for approximately ten dollars retail price are simple USB 3 to SATA bridges, SATA on the M.2 connector. Notice that Amazon recommends the "Samsung 250GB 850 EVO M.2 SATA SSD" to buy with the adapter, whereas the adapter's description just says, it doesn't support M keyed SSDs (which is a statement on the physical shape but not on the bus type of the - apparently - B keyed interface). Adapters for PCIe M.2 are in a different price range and you will have a hard time finding a bunch of them to cover all PCIe types and speeds in a robust manner, just one example http//www.microsatacables.com/m-2-ngff-pcie-ssd-to-usb-3-0-adapter-with-case

ReplyQuote
Posted : 21/05/2017 5:09 pm
Share: