1

I currently have an embedded video server that I developed using embed linux, c and c++. I currently have our assembly line workers flash the ide drives from a usb flash drive like so:

dd if=/dev/sdb1 of=/dev/sda1.

Yesterday, I accidentally erased one of my new versions of the O.S. and software when I reversed IF and OF. Anyhow, I decided to start storing a copy of the firmware to our fileserver so, 1. They don't need to use the usb flash drives anymore (very slow), then they could just use the file server's file in the flash and 2. I don't accidentally erase one of my dev images again.

My question is a simple one. 1st, is there a better way to do this? 2nd, As I am currently doing it, should I use a file extension and what should it be?

Edit

Also, can I do the flash in such a way that it copies over the mbr? I am tired of installing grub on each ide.

Jonathan Henson
  • 889
  • 2
  • 10
  • 16
  • 1
    "*.dd-image-of-my-system" Extensions do mean nothing in *nix. – mailq Sep 27 '11 at 22:07
  • I know that the extension is more for windows users, but the image will on occasion be used from a windows machine. – Jonathan Henson Sep 27 '11 at 22:08
  • 1
    So what. Windows can handle very long extensions since Windows 95. And can't read the image anyways. – mailq Sep 27 '11 at 22:11
  • @mallq cool, thanks. See my edit, I have another question. – Jonathan Henson Sep 27 '11 at 22:17
  • @mdpc do what? Your answer was cut off. – Jonathan Henson Sep 27 '11 at 22:37
  • Hey. Don't add a third question into one! Answer: do `dd if=/dev/sdb of=/dev/sda` – mailq Sep 27 '11 at 22:40
  • @mailq Thanks, should I make it a separate question? – Jonathan Henson Sep 27 '11 at 22:41
  • If there is only 1 partition on the drive, why not just copy the whole drive dd if=/dev/sda of=/dev/sdb? This should pickup everything. – mdpc Sep 27 '11 at 23:14
  • @mdpc, the reason is that the if file has to be smaller than or equal to the output file. if sdb is larger than sda, but sdb1 is smaller than sda1, the copy will not work. The reason I was doing it that way was because my original flash ide was 4022mb while the ones we are using in production are 4014 mb. So, I had to partition off my source flash and do a partition copy. – Jonathan Henson Sep 28 '11 at 01:00

2 Answers2

5

In the past I've seen firmware images with .image or .img or .bin - take your pick. I quite like mailq's suggestion of .dd-image-of-my-system as it's at least verbose, and file extensions are irrelevant for things like dd images, and with tab-completion they shouldn't have any issues typing it out.

As for storing it on a file server, this sounds like a very wise idea. I assume your file server is backed up and also on RAID? If so, you probably should have been doing that from the beginning.

Next step - make your firmware update itself via FTP so your users don't have to manually interact at all ;)

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
  • Well, I am a software engineer that doesn't have a systems guy around to tell me these things. As to the FTP push, 1. the file is about 3gb and 2. These servers will be hanging in industrial areas behind 12 gauge steel. They will usually not have a wlan connection. – Jonathan Henson Sep 27 '11 at 22:16
  • No worries. Sorry, I didn't mean to sound like I was having a go at you, but we're *all* systems guys here so it sounds obvious to us :) The FTP update thing was really a bit tongue in cheek; I didn't mean to sound like I was telling you how to do your job - it's just a feature that I have wished for a hundred times but still only seems to be present in SIP phones. – Mark Henderson Sep 27 '11 at 22:19
  • @JonathanHenson Then they have a LAN connection. And I was told that you can do FTP over LAN, too. – mailq Sep 27 '11 at 22:20
  • I didn't take you wrong. It's all good. :) – Jonathan Henson Sep 27 '11 at 22:21
  • @mailq Only if they are on the same LAN as the FTP server. Or are you talking about in our actual assembly line? – Jonathan Henson Sep 27 '11 at 22:22
  • I even saw `.dsk` or `.disk` to make clear that it is an image of a hard disk and not of a floppy, RAM or ROM. – mailq Sep 27 '11 at 22:25
  • 1
    @mailq - you are assuming that the LAN has internet access ;) – Mark Henderson Sep 27 '11 at 23:56
3

Common .img is used for an disk image of some sort. If the image is smaller than 20GiB you can compress it also on the fly like this;

dd if=/dev/SOURCE | gzip > /BACKUP_PATH/image.gz

Pro: a smaller dd image, Con: takes longer to restore

restore the image like this;

gzip -dc /BACKUP_PATH/image.gz | dd of=/dev/SOURCE

mailq
  • 16,882
  • 2
  • 36
  • 66
Bart
  • 203
  • 1
  • 2
  • For what reason did you chose this 20GiB fictional limit? – mailq Sep 27 '11 at 22:37
  • @mailq - I'm going to guess that there's a cutover time where the increased savings in file transfer size are outweighed by the additional time it takes to unzip. That's why I get so frustrated downloading a ZIPped file that might have been 50kb smaller than the un-zipped version, but because it took an extra 30 seconds just to unzip it, and 50Kb takes 0.5 of a second to download even on an average connection, I'm down 29.5 seconds. Repeat this hundreds and hundreds of times a year, and it adds up. – Mark Henderson Sep 27 '11 at 23:58
  • @MarkHenderson Larger files would benefit more from the compression in transit, which fits with your example (saving 50KB on already small file makes no sense). But Bart suggests the opposite. There's no penalty for large zip files, they're handled as a stream when they're over the dictionary size anyway. On a side note: modern computers are usually fast enough that bzip or xz (lzma) can be done on the fly and get better compression. – Chris S Oct 05 '11 at 13:09