summaryrefslogtreecommitdiff
path: root/src/Duplicating_a_USB_Stick_with_dd.ascii
diff options
context:
space:
mode:
authorAaron Ball <nullspoon@iohq.net>2015-06-01 21:53:17 -0600
committerAaron Ball <nullspoon@iohq.net>2015-06-28 14:41:14 -0600
commit6d041cdc56d8551c57780f198f0f8b4a37665ae6 (patch)
tree446adf3c3d27af0966ff5600441620686792f8ab /src/Duplicating_a_USB_Stick_with_dd.ascii
parentdc8f226be5aca4718ea5e5798aebd96e88a8898f (diff)
downloadoper.io-6d041cdc56d8551c57780f198f0f8b4a37665ae6.tar.gz
oper.io-6d041cdc56d8551c57780f198f0f8b4a37665ae6.tar.xz
Updated a few more posts
Diffstat (limited to 'src/Duplicating_a_USB_Stick_with_dd.ascii')
-rw-r--r--src/Duplicating_a_USB_Stick_with_dd.ascii79
1 files changed, 79 insertions, 0 deletions
diff --git a/src/Duplicating_a_USB_Stick_with_dd.ascii b/src/Duplicating_a_USB_Stick_with_dd.ascii
new file mode 100644
index 0000000..6f61874
--- /dev/null
+++ b/src/Duplicating_a_USB_Stick_with_dd.ascii
@@ -0,0 +1,79 @@
+Duplicating a USB Stick with dd
+===============================
+:author: Aaron Ball
+:email: nullspoon@iohq.net
+
+
+== {doctitle}
+
+I have a USB stick that I use for fixing friends computers (among other things)
+that runs Arch Linux. It seems that their most frequent problems are either
+crashed hard drives or a virus that makes their computer unusable. The quick
+solution to backing their data up in either case is to boot an external drive
+and use that OS to copy the data off their drive (assuming you can still get to
+it that is). Unfortunately, flash memory has a maximum number of times that you
+can write to it, which I hit a bit quicker than I'd like running an operating
+system off of a USB stick. As you likely guessed, my USB stick is failing
+(remarkably I've been using it to do this for several years).
+
+Last night whilst (oh yes, whilst) brushing my teeth, I had an epiphany. I
+realized that instead of re-installing Linux on a new USB stick, I could use dd
+to duplicate one USB stick onto another. I tried it, and sure enough, it works
+almost perfectly. I say almost because there was one minor problem that I will
+get to in a minute. Firstly though... The command *dd* is used for making
+bit-for-bit duplicates or data. In this case, we're duplicating the exact bits
+on one device (a USB stick) to another device (another USB stick). You can
+actually use dd to duplicate most Linux ISO installation files onto a USB stick
+as well. It works very similarly to burning a CD. Now that that's explained,
+here's the command I used.
+
+Assuming my source USB stick is at /dev/sdb and my destination stick is at
+/dev/sdc (partitions don't matter here because we're duplication the entire
+drive, not just one partition).
+
+----
+dd if=/dev/sda of=/dev/sdb
+----
+
+(The *if* is the "input file" and *of* is the "output file") That will likely
+take a while. For me it ran at 2.3 megabytes per second. Yours might run a bit
+slower as my destination USB stick has an average write speed of 25 MBps which
+is a bit higher than typical USB sticks (many thanks to Newegg for the great
+price). On the flip side, my source usb stick was starting to fail, so it might
+go way faster. I'm not really sure.
+
+Okay, now that one issue I had.
+
+Two different 8 gigabyte USB sticks (that's what I used) are likely not going
+to have the exact same amount of space on them. If your destination USB stick
+is even slightly smaller than your source disk, you'll miss some data due to
+the disk being full (in the case of dd, even empty space has bits in it that
+get transferred). This will cause problems for you because the filesystem will
+say that it starts here and ends there, when the actual partition ends earlier
+than expected. While this likely won't cause issues for you other than your
+machine complaining about it, it could result in some data loss. Either way,
+the way we get around this issue is really simple. Once you've duplicated your
+USB stick and booted the new one, you should see the following error:
+
+----
+The filesystem size (according to the superblock) is derpderpderp blocks The
+physical size of the device is blerdibler blocks
+Either the superblock or the partition table is likely to be corrupt!
+----
+
+Just run this command and it should solve your issue
+
+----
+resize2fs /dev/sd-lastpartition
+----
+
+In my case that command was *resize2fs
+/dev/sdb4* (my /home partition).
+
+May there be utility USB sticks for all!
+
+
+Category:Linux
+
+
+// vim: set syntax=asciidoc:

Generated by cgit