Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have couple of servers running off of an usb stick each. Servers are basically hypervizors.

What I was thinking of doing is distributing binary updates in form of downloading system image and unpacking it directly onto live usb disk device, followed by a reboot. This technique would boil down to dd if=newimage.img of=/dev/sda && reboot.

However, I have tried this, and it doesn't quite work as expected. Newly imaged disk is unable to boot.

As it's possible to run series of commands on each host and have them updated that way most of the time, this is not something critical to me. But, I'd like to learn if there's a way to unpack disk image on top of live running system, and have it boot properly into new environment, whichever it is. For example, I might decide to replace those linuxes by completely different OS some day, who knows :)

Ideas, suggestions?

share|improve this question
does this work to produce a bootable image on a separate machine, i.e. does dd if=newimage.img of=/dev/sdN give you a bootable USB device when performed on a machine that is not using sdN? – Norky Jun 2 '11 at 9:01
@Norky: dd if=/dev/sda of=/dev/sdN created bootable volume, while system was running from /dev/sda. – mr.b Jun 2 '11 at 9:30
also, where is newimage.img? I'm hoping it's not on the local file system (i.e. within /dev/sda?)... – Norky Jun 2 '11 at 10:09
@Norky: No, it's more something along the lines of wget http://...gz -O - | gunzip | dd of=/dev/sda – mr.b Jun 7 '11 at 0:57
were you able to get anywhere with locking (making read-only) the filesystem before writing the raw image 'underneath' it? I don't think it'll work but I'd be interested in where you got with your problem... – Norky Jun 7 '11 at 11:41

(Assuming that the answer to my previous question is a "yes"). Possibly the host is writing to (its idea of the correct filesystem layout on) the USB device while or after dd is running. You could try a remount -o ro,remount on the filesystems of the running host before doing the dd, but you might then prevent dd itself from working when it tries to write to /dev/sda. You might also want a quick and 'brutal' reboot (echo b > /proc/sysrq-trigger) so that the OS does not try to write anything during shutdown.

share|improve this answer
Thanks for the quick-and-brutal reboot tip, I was just about to ask how to do it :) – mr.b Jun 2 '11 at 9:31
depending on your distribution, you might have to explicitly enable sysrq first. However I don't think this necessarily solves the main problem... – Norky Jun 2 '11 at 9:45

Clobering the file system of the currently running system sounds like a bad idea. You might get it to work by remounting the root filesystem read-only, then doing the dd command, then reseting the system (Note: don't use the reboot script because you don't want to do the shutdown stuff if you have clobbered the root file system, you just want to restart the system onto it.)

share|improve this answer

Your Answer


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.