1

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?

mr.b
  • 583
  • 10
  • 25
  • 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 02 '11 at 09:01
  • @Norky: `dd if=/dev/sda of=/dev/sdN` created bootable volume, while system was running from /dev/sda. – mr.b Jun 02 '11 at 09:30
  • also, where is newimage.img? I'm hoping it's not on the local file system (i.e. within /dev/sda?)... – Norky Jun 02 '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 07 '11 at 00: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 07 '11 at 11:41

2 Answers2

2

(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.

Norky
  • 849
  • 4
  • 14
  • Thanks for the quick-and-brutal reboot tip, I was just about to ask how to do it :) – mr.b Jun 02 '11 at 09: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 02 '11 at 09:45
1

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

Caleb
  • 11,583
  • 4
  • 35
  • 49