You know the scene. You are helping a friend with a couple of corrupted/dead microSD cards. You want to access tools on a Linux machine but you moved to Windows a long while back.
You only have your trusty Windows 10 laptop that you’ve had a year onto which you have meticulously set-up your data and apps and other custom bits and pieces (ssh scripts, Virtual Machines). So what do you do?
My first thought was to use an existing Debian VirtualBox to do this. However I soon found out that VirtualBox does not yet support microSD device pass-through. USB devices work fine but not microSD… 🙁
So what now? Being an experienced Software Engineer you insert a SystemsRescueCD liveCD USB into your Windows 10 laptop and then boot into a SystemRescue system. You then fire up gParted, plug in each microSD card in turn and proceed to examine the state of each card.
For the first card you spot some oddities and use “dd” to write zero’s to the whole device. Once that is done you create a new partition table. Eject and insert it. There are still weird things happening. You still see the old partition layout. Curious. You give up and declare this microSD card unusable.
Next you try the other microSD card your friend has given you. It’s late, 2131hrs, and you’re tired, it’s a working day and tomorrow is a Friday. Yay end of a busy week. With gParted open you insert the microSD card and without thinking much, proceed to delete the partition table and answer “Yes, I really want to do this destructive action” to the dialog prompt…
Hmm, something odd. Where is the card in the device list from /proc/devices … Oh no. No no no. The device was not detected by the system. Therefore it did not appear as the default device in gParted. Therefore I just deleted the partition table… of my perfectly fine and working laptop HDD. Arghhhhhhhhhhhh!
OK… calm down. Do not panic. I have a running system and that system happens to be SystemRescue OS. I can recover from this if I just keep my head straight.
The data is still present on disk it’s just the disk layout table, telling the OS where to find each partition is just not there.
Thankfully, I had SystemRescue USB at hand. On this are handy tools to help recover from just such an eventuality. After all it does not have “rescue” in the name for nothing!
After some Googling of similar problems I discovered the tool I needed is called “testdisk” –
this attempts to scan an entire disk to find partitions (and guess it’s type). In running this myself I found that one can simply just use the defaults options it gives me.
In other words, the default options “just work”. Just let it run and find the partitions. It will present a candidate partition table to you. You can use the “p” key to view the contents of each partition it finds as an extra check (examples from all three partitions below).
Make sure you also make the first partition bootable (indicated by the asterisk *).
Windows 10 normally will have three partitions: a boot partition, the system (where Windows 10 actually lives, all your apps, photos, userdata, etc) and a recovery partition.
After checking that everything looks OK, accept the partition table and write it to the hard disc.
Now at this stage if you boot the system you will probably see some scary black or blue screens. You need to do another step which is to rebuild the “Boot Configuration Data”.
The way I did this was to get a Windows 10 install media USB (or CD), boot into it and follow this guide to get to the command prompt.
At this point I did:
…then reboot. For me that fixed it. Phew! Thank Zangief for that!
If that does not work for you I recommend trying these in order:
bootrec /FixMbr bootrec /FixBoot bootrec /RebuildBcd
More info here
Moral of the story is: do not do sysadmin work as root when you’re tired (obvious in hindsight!)
Note: I did an additional un-needed step after I wrote the candidate partition table to the HDD. This was to use “testdisk” to “Write TestDisk MBR code to first sector”. This was not needed since we will use the Windows 10 install media to write the MBR.