How to get my Dell Ubuntu server to boot from a different drive?

cp is indeed deprecated in general for Unix cloning, but as far as I know the Gnu cp that comes with Linux is perfectly well-behaved; there's no particular need to jump through tar or cpio hoops to work around deficiencies it simply doesn't have. Using dd (or, better, http://www.gnu.org/software/ddrescue/ddrescue.html) is a good idea when (a) the system you're cloning is mostly full - otherwise you waste a lot of time copying empty space (b) the clone's mount tree is the same shape as the source's and (c) you'll be physically disconnecting the source drives before attempting to boot the clone - dd clones all the filesystem UUIDs along with everything else. It probably is a bit rude trying to do install-grub from inside a chroot with a /etc/mtab that tells lies, but whatever you've done seems to have worked in any case; you're way past grub in the boot sequence when you strike your mount problem, which in my opinion is almost certainly caused by booting up with a copy of your original installation's initrd. This in turn will contain a copy of your original installation's /etc/fstab, including all the original UUIDs, which will make it impossible for init to find your clone's real root filesystem, which makes that impossible to mount, which makes all its mount points unavailable, which makes everything else impossible to mount. Running update-initramfs from inside the chroot should copy the clone's /etc/fstab into the clone's initrd image, and as long as that fstab contains a correct reference to the clone's root filesystem's UUID, all should then be well. When you rsync'd it probably skipped copying /proc /sys /dev because they're not normal filesystems. So your new /root is simply missing a empty directory named proc that needs to be there for the the real /proc to get mounted on via fstab. I have experimental results that show that cp -ax does not cause this trouble. If you've got a second filesystem mounted on /foo/bar and you cp -ax /foo /qux you will end up with an empty directory at /qux/foo/bar (whcih makes sense; -x means "stay on one filesystem" and in the original /foo filesystem there is an empty mount-point directory at /foo/bar).

I was clearly labouring under the misapprehension that it was even fluffier still! Thanks for the clear exposition.

Doesn't look like a grub problem to me; looks like an initrd issue. How did you go about getting your system onto the new disk, and was update-initramfs -u -k all involved at any stage?

How? I don't think you can do this anymore, but it's easier to think about the old days when you could boot a Linux system from a single floppy disk. The kernel is built with support compiled in for a simple extfs filesystem. Parts of it are compressed and a block of code with the compressed size and the uncompressor/loader code is stuck on the front. You dd that out to a floppy and say it takes up the first 500 sectors. Then you build a extfs filesystem starting at block 501 to the end. The computer boots, load the first sector and executes it. The boot code uncompresses and loads the kernel into memory, then loads the root inode of the following filesysem into the kernel's / inode space and passes execution off to the loaded kernel. The kernel then looks for an init or failing that a sh in the only filesystem it knows about and presto! running linux. Later on in the HD age, the kernel has a couple of set offset places that hold the device information for the / device, and you have a MBR based boot loader. You don't bother with compression. You build your kernel with the filesystem support for your / filesystem, then (ls -l /dev/sda1 => brw-rw---- 1 root disk 8, 1 2011-04-30 02:09 /dev/sda1) you patch your kernel with and give it the 8,1. Then you patch the MBR loader with the raw disk blocks location of the kernel. The computer boots, the MBR runs, it loads the kernel into memory, the kernel looks for device 8,1 and loads the / inode from there and continues with the init hunting process. Now with things like GRUB and initrd, grub will load the kernel, then uncompress initrd into memory and then patch the kernel with the device info for (brw-rw---- 1 root disk 1, 0 2011-04-30 02:09 /dev/ram0) IIRC. Anyway, the kernel gets the / inode of a in-memory filesystem with bunches of modules and fru-fru, loads the init from that. The init on the initrd has access to the libraries and programs needed to probe the machine to determine which special modules to load (raid, encryption, lvm), then processes the arguments passed in by the bootloader letting you dynamically control which / filesystem you want to use among other things. Then it does a 'pivot' to possibly remove the initrd filesystem, and chain on to the realroot init. By now, Ubuntu's initrd has so much fluf in it that it is practically it's own OS.

So now I've found out more or less how, and my assumption that the initrd contains an /etc/fstab is indeed dead wrong. Sorry for the mislead. For the record: the init script inside the Debian initrd finds out where to look for the real root filesystem by parsing the root= command line option passed to the kernel, which it extracts from /proc/cmdline after doing mount -t proc -o nodev,noexec,nosuid none /proc very early on. However, the fact remains that I have often needed to do a chrooted update-initramfs before a cloned system would boot properly for me. I'd always assumed it was fstab. Now I'm assuming it's actually down to some difference in the modules required for startup. The initrd images are just gzip-compressed cpio archives, so it's pretty easy to find out what your chrooted update-initramfs actually did, if you're interested (I am!). After you've exited the chroot but before unmounting /mnt, you can do cd /tmp mkdir initrd-orig initrd-clone cd initrd-orig zcat /boot/initrd.img* | cpio -i cd ../initrd-clone zcat /mnt/boot/initrd.img* | cpio -i cd .. diff -r initrd-orig initrd-clone | less If you've got more than one initrd.img* file in /boot, put in the whole name of the one you've actually been working with (tab-completion fails for me, probably because zcat wants its argument filenames to end in .gz).

It simply mounts root How?

flabdablet, I really don't think fstab has anything to do with initrd. At least not unless Ubuntu Server is different than Ubuntu Desktop and CentOS and Gentoo and just plain old generic kernel. The initrd just holds kernel modules needed to get the root filesystem mounted (esoteric fstype modules like reiser/crypt) and on the fru-fru systems a fancy graphics screen to hide the boot messages. It simply mounts root, rebinds proc and sys that it mounted in its fakeroot so it could do all the fru-fru stuff, finds a suitable /sbin/init, /bin/init, /init, /bin/sh and then pivots the filesystem over and execs init. I looked at the initrd for my Ubuntu Desktop and that is what it does. I've mix and matched various distros kernel/initrd combos across different roots and even different distros and bare kernels with no modules with no problems. The initrd if any just needs to match the kernel for module loading.

cat /proc/mounts is really valuable, btw - didn't know about it.

So good, thanks everyone - flabdablet and zengargoyle I think your advice was exactly right! I ran initrd and I also made sure that /proc exists ahead of time on the new system. It got well past the /proc stage, running into problems only when one of the other volumes on the system (the one where I moved /home to) needed to be fscked. I let that run for a bit and then switched back to the original drives to do a bit more maintenance. I'm going to complete the switch sometime this weekend.