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).
I eventually resolved this problem by following the advice given by Michael above. Zeroing out the first few megabytes of the drive and then re-installing the operating system did the trick. I suppose there was some sort of MBR or partition table corruption at play.
If you are stuck at a grub screen after a fresh CentOS installation, try following these steps:
- Insert the CentOS installation disc or mount the ISO.
- Boot into rescue mode and enter into shell. Skip any steps to mount the existing file-system.
- Run the command
fdisk -l to determine the label of the drive you need to zero out (e.g., /dev/sda, /dev/sdb). If you have multiple drives, be very careful to pick the right one.
- Run the command
dd if=/dev/zero of=/dev/sdX bs=512 count=4000 where /dev/sdX is the drive in question (e.g., /dev/sda, /dev/sdb).
- Exit out of the rescue shell and reboot.
- Re-install CentOS 6 as per normal.
Best Answer
If you are talking about full virtualization, the boot process is the same as a physical machine: CPU initialization, BIOS/POST (memory, PCI initialization), MBR/GRUB, kernel+initrd loading, kernel boot, initrd execution, pivot root, service startup.
If you talk about containers, then the BIOS/POST, MBR/GRUB and the kernel are not performed.