Linux – Is it safe to boot a linux server from a USB drive

Regarding the bootmanager: when using FAT as filesystem then syslinux would be one approach. Especially when booting from USB you might consider using grub for booting, as you'll be flexible with the grub shell (providing a nice tab-completion). To install grub you'd be running something like:

mount /dev/sdX /mnt/
grub-install --recheck --no-floppy --root-directory=/mnt /dev/sdX

and adjust /boot/grub/menu.lst accordingly.

Your bootloader has to load kernel and initrd. So those files have to be outside your debianroot.img (unless you're using the ISO approach and grub2 with its loopback option, see http://michael-prokop.at/blog/2009/05/25/boot-an-iso-via-grub2/) and need to be referenced/configured in your bootloader (being syslinux.cfg for syslinux, menu.lst for grub1 and grub.cfg for grub2). The following is an example menu.lst file used for the grml live system (http://grml.org/) generated by grml2usb (http://grml.org/grml2usb/):

# misc options:
timeout 30
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
foreground  = 000000
background  = FFCC33

title grml  - Default boot (using 1024x768 framebuffer)
kernel (hd0,0)/boot/release/grml/linux26 apm=power-off vga=791 quiet boot=live nomce live-media-path=/live/grml/ 
initrd (hd0,0)/boot/release/grml/initrd.gz

The initrd file has to locate the debianroot.img on your devices and loopback mount it then. Then it should change your root file system via e.g. pivot_root (see http://linux.die.net/man/8/pivot_root) to inside the mounted loopback file. You can find more details regarding the initrd process in Documentation/initrd.txt of the linux kernel sources: http://lxr.linux.no/linux/Documentation/initrd.txt

If you'd like to know how common live systems do this kind of stuff check out debian-live (http://debian-live.alioth.debian.org/) or grml-live (http://grml.org/grml-live/) in combination with live-initramfs (which does all the initrd/initramfs magic and is used in most Debian based live systems; http://packages.debian.org/sid/live-initramfs).

A different approach to your debianroot.img approach would be talking an existing Debian based Linux Live system providing so called "root persistency" (for example the official Debian-live project provides this as well as grml 2009.05 does).

There are a bunch of reasons against this:

• Flash tabs are unreliable; it's not just write cycles, the damn things just like to go on holidays regularly for any reason. When people said "we need a replacement for floppy disks", they obviously included "dies regularly" in the replacement criteria.
• It's real easy to confuse which tab goes with which server; if you engineer your boot media right you can make this a non-issue (at the expense of providing a bunch of alternative problems), but any trivial implementation is going to result in tab-dependency, and then one day you boot a machine with the wrong tab and gaaaaaah...
• Extra shenanigans are required in the BIOS of many machines to make this work right, and compatibility isn't assured. Buying 100 flash tabs only to find out they don't boot (even though your samples of the "same model" worked OK) isn't fun. "I see vendor giveaways in your future, young one".
• It is stupidly easy to bump them out of place while the machine's running, since there's no "positive locking" to keep them in place. RAID-1 and very careful hardware techs help, but it's still a real risk. Reducing the number of thing hanging out the back of a server is high on my priority list of DC hardware "do's".

My previous job used flash tabs as boot devices while I was there; whilst it wasn't the worst part of their architecture, it certainly wasn't considered a plus. They've moved to an all-PXE boot architecture since I've left, and I think that's very much the right way to go.