Thanks! I'll have to think about that.

Isaac, I've been thinking about this, and I think it's not so much the boot directory that should be on the external drive, but the /bin, /usr, /sbin directories. So, I wonder if it would be good enough to rsync those directories to directories on the external drive, and then mount those external drive directories on top of the ones on the "/" directory? Is there any variable data in these directories, like there is in /etc and /var that would cause a problem? It goes without saying that if any programs are installed after the mounts, then an rsync in the other direction would be needed.

Or do I have this completely wrong?

Added:
I'd probably need to do the same with /home/bob, so I guess that poses a problem.

Now I'm confused. If the external usb drive is where you installed debian, why wouldn't these directories already be in a partition located on the usb drive?

Hi colorpurple,
No, I was not able to install onto the external drive. It appears to be a BIOS problem and the BIOS can't access drives larger than 3TB, or whatever the limitations this BIOS has. So, the external drive is just a data store. But, I was thinking that I could rsync and remount stuff to the external drive to speed things up as compared to the 2.5" drive in the eeeBox. I mean, how often do we really reboot as compared to loading programs?

My suggestion is to put /boot on the internal drive, and everything else on the external drive (in an ext4 partition).

Basically, you want "/" to be mounted on the external drive, and mount "/boot" only on the internal drive. If you try to do it the other way, with "/" on the internal drive and a bunch of /bin /usr /sbin etc on the external drive? Won't work. It will mess up badly, because a large number of those directories simply must be on the same partition as "/". /usr in particular is one which used to be safe to put on another partition but now it causes problems.

The sequence of events will be:

1) GRUB bootloader on the external drive (or the internal drive, if you wish) boots up and looks for /boot.

2) Because /boot is on the internal drive, it is found. This loads up the GRUB menu. At this point, you can select to boot either Windows or Debian.

3) GRUB attempts to load the initrd/vmlinuz files specified in the GRUB menu. Because /boot is on the internal drive, they are found and loaded.

4) The Debian initrd unpacks itself into RAM and starts loading up modules. This includes the modules necessary to mount GPT partitions on a USB drive.

5) The Debian initrd mounts the "/" partition on the USB drive. It is able to do so at this point, because all of the necessary hardware driver modules have been loaded.

6) The Debian initrd chroots over into the mounted "/" for the rest of the boot process.

Personally, I would use Windows to restore the original Windows bootloader to the internal drive's MBR (or whatever the heck is necessary for efi secure boot...I honestly have no experience with that). This leaves that tiny little /boot partition just hanging in there not really accessible by Windows in any meaningful way.

Then, I'd install the GRUB bootloader onto the USB drive. Depending on the specifics of how efi secure boot works, it might not be able to boot up Windows properly. I don't know - I've never had a problem but I also never set up Windows to use secure boot. But this way, it's not a disaster if Windows can't chainload from GRUB. If you want to boot up Windows, you just remove the external drive or use the BIOS to boot from the internal drive first.

If you know what you're doing, it's definitely possible to use rsync or cp to copy over files to move the contents around. But going from /boot in a folder vs /boot on a separate partition is a bit fiddly. You've got to factor in stuff in the modified boot entries to consider the changes in path.

I was proposing to allow the system to boot up completely on the internal drive. This allows for the external drive to be shut off during the boot process if it has failed. Then, after boot, do the rsyncs and mounts. The system shouldn't know or care about where /usr, /bin, and /sbin physically are. Or at least I wouldn't think it would.

For better or worse, a lot of those directories need to be on the same partition as "/". Certainly /usr, /bin, and /sbin need to be on the same partition as "/".

Unless you really need to give Windows every possible bit of space on the internal drive, I'd put all of "/" on the internal drive - using the 4TB external drive only for media files and perhaps backups.

Basically, if you put only /boot on the internal drive, then this will consume only 256MB. (Honestly, it only takes about 35MB - but better to have too much space than too little.)

If you put "/" on the internal drive, then this will consume perhaps 4GB - 10GB, depending on how much software you intend to install. Out of a 250GB internal drive, shrinking the Windows install by 10GB is not a big deal.