You need to boot from the Ubuntu installation media, connect your USB drive, mount the root filesystem from that drive, and run grub-install with the appropriate "--boot-directory=..." and device. I don't have anything with Ubuntu 14 handy, so I can't be more specific, but grub-install has a manpage and there is plenty of help on the Web.

Personally, I keep a small flash drive with just GRUB on it so that I can always get to a GRUB command shell and use it to do whatever fixup a system might need.

If you believe that all will be well, do this simple experiment. You have a few older kernels installed, right? Go to /lib/modules and rename the directory for one of the older kernels, then try to boot that kernel. It will come up, and probably let you log in as usual, but take a look at the number of "FAILED" messages in the boot log and see what stuff isn't working, which will probably include networking, temperature sensing, CPU frequency scaling, crypto (if it wasn't needed for booting), and various other stuff. You will have a system that will boot, but isn't very useful.

And yes, I just tried that on an RHEL 6 clone, with results as described above.

Well, it's obvious that that won't work. I'm not sure, though, why you believe that the /lib/modules subdirectory for the kernel that we're going to boot, would go missing. It could be that I'm overlooking some silly little detail, but, well... I don't see it.

I had been thinking about doing the experiment of installing Ubuntu to a USB device, and doing what we're talking about here, but the CD that I tried to use produced I/O errors... Sigh...

Ahh, there is a detail that I was missing. The OP did add the qualifier, "Of course, this all assumes my grub kernals and OS kernals match." If that means the kernels in /boot do match the kernels in the root filesystem, then all should be well. I guess I was not sure what was meant by "OS kernals." I took that to mean a match between the kernels in the GRUB menu vs. the kernels present in /boot.

Here is what I did:

I deleted the partition setup on my USB with gparted. Then I made 2 new partitions. One was 1 GB with /boot mount point. The other was about 14 GB with / mount point. Both were done in ext4.

I selected sdg1 as the boatloader location. That is the /boot partition. I installed the OS to sdg2.

The install went well but when I rebooted (and took out the live cd) I got this error message:

Error: file not found
Entering rescue mode
Grub rescue>

It clearly wanted me to type something but I don't know what it wanted. This is the same error I get if I restore the FSarchiver image.

What happened? More importantly, is it even possible to get a bootable setup out of this?

I want to be able to backup and restore with FSarchiver, but I want my restores to be bootable in some manner.

You can use the commands given earlier, but as you asked about a "GUI" solution, here it is:
(for installing Grub to the MBR)
I have done this many times. For testing purposes, I created clones of my Mint 16 (when Mint 16 was still current) on a new drive, with no Grub. I booted my Rescatux CD, which boots any operating system it finds, Grub or no Grub. Once booted into the OS, I run sudo update-grub and sudo grub-install /dev/sdc

If you want to try the Rescatux/SuperGrub2 CD, here is the voodoo that you do:
Download the RescueTux CD (which includes SuperGrub2). - http://www.supergrubdisk.org/
Boot the computer with the Rescatux CD. When Rescatux starts you will get a menu to start Rescatux or SuperGrub2. The SuperGrub2 option is the one you want. After chosing SuperGrub2, the next menu will give the options of booting any installed operating system on your computer ("Detect any Operating System") or any loop mountable iso files ("Detect loop bootable ISO's"). When you chose the "Detect any Operating System" menu item, the program will search your drives for your installed operating systems and create a menu for you that will allow you to boot any one of them. It will be a slow process to search your drives and create that menu, so be patient and let it complete.
Then after you boot into your installed OS run the following commands in a terminal:
- where X is the drive you want to install Grub to. (The drive your new OS is on. sda? sdb?)

Tutorial and Troubleshooting with SuperGRUB2:
http://www.supergrubdisk.org/wiki/SuperGRUB2Disk
http://www.supergrubdisk.org/wiki/Boot_Problems

Now I'm confused; I'm puzzled by the fact that you even arrive at a GRUB prompt, since I would expect that the boot process should look at the MBR (of your boot disk) to find the boot loader. In fact, I somehow must have gotten sidetracked by your original question, as I completely ignored the fact that you booted directly off the USB disk.

Perhaps you had selected the USB disk's MBR as the boot loader location the first time that you installed Ubuntu on the USB device, and there's some GRUB stuff left over from that earlier install...

Anyway, the location for the boot loader should be the MBR of the USB disk, i.e., "/dev/sdg" (or whatever the USB device is named). If you then set up a separate boot partition, you should be able to backup and restore the root partition without any troubles... PROVIDED that the kernel versions of the boot partition and the restored root partition match.

In fact, my gut feeling tells me that you shouldn't even need the separate boot partition in this scenario... but I may be mistaken; I have no experience with installing an Operating System to a USB device.

I tried to install Ubuntu (or, more precisely, the Xubuntu variant) to a USB disk earlier today, but it looks like my computer doesn't like booting from a USB device; it does get around to loading GRUB, but then it gets stuck somehow. I'll see if I can find a computer that is happier about booting from USB, and conduct a few experiments to clear up my confusion.

I deleted my partitions and started over. I made a 1 GB /boot and 14 GB / using gparted. I installed grub to MBR (sdg). The install went well but upon reboot I received the same error message:

Error: file not found
Entering rescue mode
Grub rescue>

It seems like it just isn't possible to have the setup I want. I may try what TXlonghorn suggested with supergrub but that would involve reinstalling grub after each file system restore. I want to restore the filesystem and grub at the same time, or at least somehow retain grub in a usable format so all I must do is restore the filesystem.

Basically, I want some type of setup where I image my file system partition with FSarchiver, restore it with FSarchiver and not need to do anything else to boot then use the restored image.

Is doing so simply not possible?

Question: When exactly did you see the GRUB error? Was it immediately after installation, the first time you booted the system? Or was it after you restored it from an FSarchiver backup? (The way I understand your earlier posts, it should be the latter, but I just want to make sure.)

I'll see if I can do some testing with a Linux install on a USB device, but I will first have to find a computer that can handle it properly.

Also, could you perhaps run the following command, to list the partitions on your USB disk, and post the output here? Just so I can see how the device is partitioned exactly:

I’ve done some experiments, and my results show that it’s perfectly possible. I only tested with a separate boot partition; whether or not it will work without one, is not entirely clear to me at this point.

Here’s what I did:

• I booted my computer from the “Xubuntu 14.04.1 LTS” DVD.
• I plugged in the USB stick onto which I wanted to install Xubuntu.
• I started the Xubuntu 14.04.1 LTS installer.
• The “Welcome” screen and the “Preparing to install Xubuntu” screen that subsequently appeared, don’t need any further explanation, I suppose.
• Then, on the “Installation type” screen, I selected “Something else”.
• On the list box of disk devices and partitions, I selected my USB stick—which, in my case, was “/dev/sdb”; be careful to select the correct device here, since you will be deleting all existing data on it.
• I clicked the “New Partition Table...” button, and confirmed that I really did want to create a new partition table on the device.
• I selected the “free space” on the USB stick. Since the device was now empty, the device consisted of nothing but free space.
• I clicked the “+” button, to create a new partition.
• On the “Create partition” dialog box, I specified the following values:
  • Size: “1024” MB.
  • Type for the new partition: “Primary” (i.e., the default).
  • Location for the new partition: “Beginning of this space” (i.e., the default).
  • Use as: “Ext4 journaling file system” (i.e., the default).
  • Mount point: “/boot”.
• I selected the remaining “free space” on the USB stick.
• I clicked the “+” button again, to create another partition.
• On the “Create partition” dialog box, I specified the following values:
  • I left the size value unchanged, to make the partition use up all available remaining space.
  • Type for the new partition: “Primary”. (NOTE: This was not the default!)
  • Location for the new partition: “Beginning of this space” (i.e., the default).
  • Use as: “Ext4 journaling file system” (i.e., the default).
  • Mount point: “/”.
• I set the “Device for boot loader installation” to the Master Boot Record of my USB stick—i.e., in my case, “/dev/sdb”.
• I clicked the “Install Now” button.
• The remaining screens don’t likely need any further explanation.

After the installation completed, I rebooted the computer, and selected the USB stick as the boot device. All appeared to work fine.

So—now it was time to perform the real test, i.e., back up my root partition (which, in my case, was “/dev/sdb2”), then restore it, and see if it would still boot.

To make the backup, I booted the computer from a “System Rescue CD”. I mounted the target partition for the backup onto the “/mnt/backup” location, and set my current directory to it—e.g.,
To create the backup, I ran the following command:
I verified the resulting archive like this:
All seemed perfectly fine.

Next, I wanted to make absolutely sure that the root partition would no longer be bootable, so I simply reformatted it:
Just to verify what would happen, I attempted to reboot the computer from the USB stick. The GRUB menu appeared, and I just pressed <ENTER> to select the default entry (i.e., the Xubuntu root partition). Of course, the boot was a complete failure, but it failed in a different way from what I expected. After a pretty long wait, the following text appeared:
In other words, the system could not even find the root partition any longer. In fact, this was what I should have expected in the first place, given that Ubuntu sets up GRUB so that it addresses disk partitions by UUID (“Universally Unique ID”)—as you can see on the alert above—and, because I had reformatted the partition, it had been assigned a new UUID.

Anyway, enough distraction, and time to get back to the real job: restoring the root partition. I rebooted from my “System Rescue CD” and, using the “/mnt/backup” location as before, I ran the following command:
Without any further actions on my part, I could then successfully boot Xubuntu from the USB stick again.

The error appeared only after I rebooted. I restored the image then rebooted.

The USB flash was sdg (MBR), sdg1 (/boot) and sdg2 (/).

A further experiment confirmed my gut feeling that a separate boot partition isn’t even necessary.
This time, I installed Kubuntu onto a USB stick, in just one partition, “/dev/sdb1”.

After the installation completed, and I had verified that Kubuntu worked alright, I ran fsarchiver to make a backup of the “/dev/sdb1” partition. I subsequently reformatted the partition, but this time, I ensured that it would be reassigned its existing UUID. Something like the following got the job done:
I attempted to reboot from the USB stick. As expected, this operation failed, but this time, the error message was the following:
Aha! GRUB was clearly looking for a file by name, and was unable to locate the file—because, of course, the file was no longer there. In any case, the fact that GRUB was looking for a file name, and was not using disk blocks, kind of made me confident that the simple act of restoring the partition would be sufficient to make the USB stick bootable again.

And, indeed: After I ran an fsarchiver restore, I could boot Kubuntu from the USB stick again, without further ado!

Aha! That’s an interesting clue that you got, there!
See the difference with the “file not found” error that I got from GRUB, after I had reformatted my Kubuntu partition on my USB stick? Your error message is missing a file name!

To me, that’s an indication that your GRUB installation must be using disk block addresses to find the files it is looking for. Consequently, you can almost be sure that GRUB will no longer find its files after you do a file-by-file restore, such as fsarchiver does.

In fact, that makes me really curious about how exactly your USB device got partitioned. In other words, I would very much appreciate it if you could post the output from the “fdisk” command I mentioned earlier on:
Alternatively, you can use GParted to get at the information that I'm looking for: in the GParted window, select your USB device, then select its first partition, and select “Partition” ⇨ “Information” from the menu. The value that I'm most curious about, is the “First sector:”.

Incidentally, you mentioned that you had used GParted to partition your USB device. There may be a few points to take into account, then:

• Make sure to create a new partition table on the device, just to be sure. Also, select “msdos” as the partition type. After this operation, the device will be completely empty.
• When you create a partition, make sure to select “MiB” as the alignment value (i.e., the field labeled “Align to:”). This ensures that GRUB will find enough free space between the Master Boot Record and the first partition on the device, so that it can dump its initial code there. It is only thanks to this initial code that GRUB can address files by name, instead of having to fall back on disk block addresses.
• For best results, make sure to set the “Create as:” option to “Primary Partition” (which is default at least for the first partition that you create). I don’t believe that this is critical to the ability to restore the partitions, but in my experience, primary partitions are more robust than extended/logical partitions.

luvr - I followed your exact steps listed in your last lengthy post.

It worked.

It matches what I previously did but this time I made one change: I disconnected all other hard drives. I suspect that what happened last time was that I installed grub to the MBR of the win7 hard drive. That would explain the win7 boot problem I had, which I fixed with my win7 install CD.

I hope to use this partition scheme (grub to MBR, separate /boot, separate /) for further Linux experiments. Using a "file-by-file" program such as FSarchiver will provide substantial file restore flexibility not found in other "block-by-block" programs.

Regarding my partitioning method: this time I did it during the regular install process instead of doing it pre-install via gparted. Do you think that made a difference?

Either way: Case closed.

Thank you so much!

Great! I’m glad I could help!

Ouch! That’s a nasty little detail that I failed to consider—even though I ran into the same kind of trouble a few times, as well.

The only difference, really, is that GParted is far more flexible than the partitioner that gets invoked by the installer.

However, the only detail you really need to be careful about with GParted, is the “Align to:” option—if you want to be absolutely, positively sure that the resulting partitioning scheme will be identical to what the installer does, then always set the alignment option to “MiB”. That will guarantee that GRUB will find more than enough unused space between the Master Boot Record and the first partition—namely, 1 MiB minus the 512 bytes taken up by the MBR (i.e., 1023.5 KiB). I’m not sure about the exact minimum space required to allow GRUB to dump its initial code there, but it used to be just some 20 to 30 KiB. I’ve been told, however, that some distributions, notably Fedora, these days make use of a more complex GRUB setup, which may require perhaps 100 KiB or more, although I haven’t verified this—and even so, that’s still a far cry from the almost-1-MiB that the current-day proper partition alignment value makes available.

You’re welcome!