Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
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
show 4 more comments

2 Answers

up vote 5 down vote accepted

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 ;)

share|improve this answer
    
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. </irony> –  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
1  
@mailq - you are assuming that the LAN has internet access ;) –  Mark Henderson Sep 27 '11 at 23:56
show 2 more comments

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

share|improve this answer
    
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 5 '11 at 13:09
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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