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
Peter Mortensen
  • 1,025
Ichigo Kurosaki
  • 103
  • 1
  • 8
  • 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
  • Is it even a drive? I'm not too familiar with Mac, but a character device with 0,0 looks odd to me. Can you read data from it? If not, probably nothing happened. – frostschutz Dec 28 '14 at 15:24
  • @frostschutz, how can I confirm if data can be read from it? I know its not a directory, because cd /dev/sdt tells me cd: /dev/sdt: Not a directory, so that is why I have to ask, if its not a directory, then what is it, and how did dd come back with a successful copy message where it wrote about 244Mb of data...a mystery to me. – Ichigo Kurosaki Dec 28 '14 at 15:31
  • 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
  • @frostschutz, that was a smart idea. I tried it, and got 0 bytes for the size of the "mystery" file that was attempted in your 'dd'. So I detailed my findings in the Update #3 on my post above. – Ichigo Kurosaki Dec 28 '14 at 16:20
  • What was dd's report afterwards? Did it say 234 records in ... 234 records out...? Nevermind - sdt is a char special. There won't be anything there. – mikeserv Dec 28 '14 at 19:06
  • Did you try file -s /dev/sdt? (This will ignore the "special" monkier and actually try to determine the contents.) – felixphew Dec 28 '14 at 19:38
  • Actually, don't do that on a suspected drive, as it will take forever (try and read the whole drive until EOF) – felixphew Dec 28 '14 at 19:59
  • On second thought, and in the light of what emerged here, probably your question is more suitable for the Ask different site. – MariusMatutiae Dec 29 '14 at 06:53
  • @felixphew, I did try that, actually, but it was as you said and it was taking waaaay too long, so I aborted the process. though I am not sure why it was taking so long to read the contents of a zero-byte file. – Ichigo Kurosaki Dec 29 '14 at 15:46
  • @MariusMatutiae thanks for pointing out the AskDifferent site. I actually didn't know that site existed until now. A nice resource. Thanks. – Ichigo Kurosaki Dec 29 '14 at 15:47
  • @mikeserv, just for the education side of things, can you elaborate on what it means to know that nothing will be there, since its a "special character" drive. Why are special character drives inherently empty? – Ichigo Kurosaki Dec 29 '14 at 15:49
  • @IchigoKurosaki - well, a char special doesn't have to be empty - but it is a streaming device, not a storage device. Your terminal, for example, is a char dev. Your key/mouse input, sound card, etc... So if you ddd a bunch of data to your mouse it wouldn't matter much - it would just make the pointer go crazy for a minute or two, then it would subside. char devs will not typically attempt to store data they are sent - though that can be tricky, too - some low-level flash modules register as char devs but do store data - it's just not typical is all. – mikeserv Dec 29 '14 at 17:52
  • Great, thanks for the explanation @mikeserv, I never knew anything about these types of devices, but it makes perfect sense. Thanks again. – Ichigo Kurosaki Dec 29 '14 at 18:54
  • @IchigoKurosaki It's because the drive is an empty character device, and so it will wait indefinitely for data and never send EOF. – felixphew Dec 29 '14 at 19:45
  • @felixphew, Thanks for the explanation, the behavior makes sense now. I am learning a lot! =) – Ichigo Kurosaki Jan 02 '15 at 11:37

3 Answers3

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.

MariusMatutiae
  • 4,372
  • 1
  • 25
  • 36
  • 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

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 :) ].

Peter Mortensen
  • 1,025
netikras
  • 425
  • 2
  • 4
  • 9
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.

felixphew
  • 360