3

I have what I hope is not a huge problem, but it could end up being a very large problem.

For some context, I mistakenly ran this command on my 27" iMac:

sudo dd if=ubuntu-rescue.img of=/dev/sdt bs=1m

After which, it gave me the following output:

233+1 records in
233+1 records out
244570112 bytes transferred in 2.275065 secs (107500277 bytes/sec)

The problem is, that I was NOT INTENDING to move the ubuntu-rescue.img to the location of /dev/sdt. Yikes!

I am now trying figure out what the original contents of /dev/sdt/ was (before I erroneously wrote data to that file), and if there is a way to inspect the contents (to either delete the disk image that was mistakenly copied there, or in some way restore the contents of /dev/sdt back to its original state).

Also, would this dd command erase everything that was there before, or just add data to it?

The main problem for me right now, is that I am unaware of what /dev/sdt is (is it a file? a driver? a mounted drive? etc..), so I have no way of knowing how to inspect the damage that was done. So I need to understand what I am looking at when I run this command:

ls /dev

and how to inspect/access/read the contents of these files.

What should I do?


For some further analysis, here are various output from various commands:

Not a directory:

    $ cd /dev/sdt
    -bash: cd: /dev/sdt: Not a directory

"Special Character" file

    $ file /dev/sdt
    /dev/sdt: character special

Verbose ls output:

    $ ls -l /dev/sdt
    crw-rw-rw-  1 root  wheel    0,   0 Dec 28 14:02 /dev/sdt

"Size of" `/dev/sdt`

    $ du -sk /dev/sdt
    0    /dev/sdt

I ran the same commands from update #1 on a new Mac Mini (that didn't have its `/dev/sdt` drive tampered with `dd`, and it gave me the **exact same** output as I got on the the iMac after I ran the erroneous `dd` command. Does this mean that the /dev/sdt didn't "record" the contents of the dd transfer? Because the "size" of /dev/sdt displays as zero when I run `$ ls -l /dev/sdt`. Could it be that I got lucky and didn't do any permanent damage?

Both of these commands: `$ du -sk /dev/sdt` and `$ ls -l /dev/sdt` give me the same results on the iMac (where the erroneous `dd` command was run) as it did on the untouched Mac Mini, showing that the data stored in `/dev/sdt` reads at 0 bytes. This makes me assume that this drive is a temporary system drive that is not meant to store data, because even after 240 MB of data was erroneously `dd`'d into it, it still reads at zero byes.

Lastly, I was given a good idea (by user frostschutz) to run this command:

    dd if=/dev/sdt of=mystery bs=1M count=234

And compare the results of the "mystery" file with the contents of the ubuntu-resuce.img, and the output from that experimental `dd` left me with a file called "mystery" which was exactly zero bytes. So I am starting to feel confident that I didn't do any lasting damage, and that this drive is always empty.

After listening to your very helpful discussions, and reading more on an [another (separate, but closely-related) question of mine here on U&L][1], I discovered that my question has already been asked, so for anyone wanting to read more on this discussion, you can look [here][2].

  [1]: https://unix.stackexchange.com/questions/176304/why-does-the-unix-system-need-so-many-0-byte-drives-at-dev?noredirect=1#comment291323_176304
  [2]: https://unix.stackexchange.com/questions/18239/understanding-dev-and-its-subdirs-and-files



  • What does ls -l /dev/sdt show? – frostschutz Dec 28 '14 at 14:56
  • @frostschutz, When I run this command:ls -l /dev/sdt it gives me the following output: crw-rw-rw- 1 root wheel 0, 0 Dec 28 14:02 /dev/sdt – Ichigo Kurosaki Dec 28 '14 at 14:58
  • /dev/sdX is almost always a storage device of some kind. And since this was not an inode deletion (e.g., rm) there is little chance you will be able to recover whatever data was overwritten. – HalosGhost Dec 28 '14 at 15:09
  • Are file recovery methods valid on drives like /dev/sdt ? – Ichigo Kurosaki Dec 28 '14 at 15:20
  • 2
    dd if=/dev/sdt of=mystery bs=1M count=234 and then compare that with your ubuntu-recovery.img. – frostschutz Dec 28 '14 at 15:56
3

I was surprised to discover that my Mac Book Air does have a /dev/sdt character special device. Since I could not fathom its nature, I looked up my copy of Mac OS X for Unix Geeks. At page 60, there is the list of all entries in /dev. sdt is indeed mentioned, with the unenlightening explanation:

sdt Undocumented

It is its only mention in the whole book.

So, first of all it is not a storage device. And second, it is unlikely you will manage to do anything with it. At the same time, I cannot see any real reason to worry.

  • Maybe something to do with flash mem? Sometimes firmware modules pop-up as scsi devs - and I can understand why a manufacturer would not document one of those. They're not typically easily written either - or read, for that matter. But, I guess, it's probably the NSA. – mikeserv Dec 28 '14 at 19:09
  • This is all making me feel better that I didn't do any damage, and I got to learn a bit of what lives "under the covers" on my mac. =) – Ichigo Kurosaki Dec 29 '14 at 15:52
1

Don't worry - it's always empty, and the data doesn't seem to be going anywhere important.

Just in case you ever run into this problem with a real drive, the best program for this kind of work (recovering entire deleted partitions) is called TestDisk, by Chrstophe Grenier. You can download it here.

1

Did you notice any malfunction on the system after dd'ing your img file to sdt?

If not - I assume you're safe. /dev/sdXYZ usually are storage LUN representing files. sdt might be undocumented because of the same reason as sdx, sdfa or sdlg - they are not attached by default.

I see minor and major numbers of the file are both zero, so if it's indeed a storage device - it is not attached. If you did not notice any malfunctions on your system I'd say you simply copied your img file to the black hole on the other side of the universe [a.k.a. /dev/null :) ].

  • No, [thankfully] I haven't noticed any strange behaviors on the system. – Ichigo Kurosaki Dec 29 '14 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.