Thank you so much for your time! I will work on it with these suggestions.

I just thought of something: If I do create a separate boot partition (separate from OS root partition) and later upgrade my Linux kernel, then what would happen? Would my system break or still work?

"fsarchiver" stands for "File System Archiver", so my opinion is that it's perfectly reasonable for it to backup filesystems and nothing more. To expect it to do more than that might be called somewhat of a stretch of reasonable interpretation.

I have plenty of non-bootable disks. They contain valuable data. I use them all the time. Booting from them is not required. Of course, something has to boot, somewhere, to gain access to them. But booting directly from those disks themselves is certainly not a requirement.

Whether you have a separate boot partition or not, does not make any difference to the kernel update process. The new kernel is installed on your root partition, and the GRUB boot loader is subsequently reconfigured to recognise the presence of the new kernel. Without further action on your part, the old kernel will remain available, both on your root file system and on your GRUB boot menu.

The GRUB configuration doesn't care whether or not your boot loader sits on a separate partition; its location will be known as "/boot" either way.

You do raise an important point, though: If your "/boot" location is on its own partition, and you back up your root file system, then you will have to be careful to avoid removing the kernel version that was in use at the time of the backup. When you subsequently restore your root file system, it will not have any newer kernel versions installed, so you will need a way to select the older kernel from your boot menu; the option to select that older kernel will, however, be removed when you remove the older kernel from your system.

luvr - your last paragraph caught my attention but I don't fully understand it. I apologize but could you provide a simple example to illustrate your meaning? I usually better understand things in that manner.

Of course, thanks again for your valuable input.

Well... Let's assume that your system is running on kernel version "A". Your boot loader menu will, then, have an entry to let you boot "Linux with Kernel A".

Now, you make a backup of your root file system. The backup will contain a "Linux with Kernel A" system.

Next, a kernel update arrives, which you install. Your boot loader menu will now include an entry to boot "Linux with Kernel B". The old option, to boot "Linux with Kernel A", however, will still be available as well.

Subsequently, you restore your root partition from the backup that you had made. If you are using a separate boot partition, then your boot menu will still show both options: "Linux with Kernel B" (the updated one) and "Linux with Kernel A" (the original one). However, the "Linux with Kernel B" option will no longer work, since Kernel B was not present on the backup and, consequently, was not restored either. Thus, you will have to select the "Linux with Kernel A" option in order to successfully boot your Linux system again. You can then reapply the updates, which will add the Kernel B again (and reconfigure your boot loader, though that won't really change much in this case).

Now, what happens if you remove Kernel A from your system, after you made the backup? The removal will reconfigure your boot loader, and remove the option for "Linux with Kernel A". As a result, only "Linux with Kernel B" will remain available as a boot option. If you then do the restore, this "Linux with Kernel B" option will, again, no longer work. This time, however, the "Linux with Kernel A" option is no longer available. In effect, the boot loader configuration and your root partition are no longer in sync.

To get back in business, you will then have to reconfigure your boot loader through some other means, e.g., while running off a Live CD.

Oh, I see now.

The new kernal was not present during the imaging so obviously it won't be available to restore.

Questions:

1) Does updating the kernal automatically delete the old kernal? In other words, would I be given the option of keeping both the old and new kernal?

2) If I wanted to have a separate boot partition, then how would it be labeled? Would it simply be: /boot

Installing an updated kernel will leave the old kernel in place. Your GRUB boot loader will be reconfigured, so that the new kernel will be selected by default, but the old kernel will remain available.

If you do want to remove the old kernel, you will have to use the package manager to do so. Removing a kernel will also cause the boot loader to be reconfigured, to remove the entry for said kernel from the menu.

The separate boot partition will have to be mounted as "/boot". In effect, it will act in the exact same way as a normal "/boot" directory. You root partition will contain an empty "/boot" directory, which will be "overlaid" with the contents of the boot partition.

When you install Linux, you get the option to select multiple partitions for your system, including a "/boot" partition if you so desire.

To set up a separate boot partition after installation, you will have to move the contents of the "/boot" directory to the boot partition, and add an entry for it to the "/etc/fstab" file. You will probably have to reconfigure the boot loader as well, or perhaps simply reinstall it to let the system work out the new configuration for you.

luvr - that clarifies much. Thanks.

To further clarify:

1) Making a separate /boot is NOT the same as installing grub to MBR.

Correct or not?

2) First, assume I make my separate /boot partition. Second, assume I make my separate / partition for the OS file system (root). Third, assume I backup (image) only the OS file system (root). Fourth, assume that in the future I restore the saved image to / (root). If I use a "file-by-file" program like FSarchiver, then I should be able to boot into the restored image because the booting grub was stored on an unaffected partition this whole time. Of course, this all assumes my grub kernals and OS kernals match.

Correct or not?

Yes, you are absolutely correct on both accounts.

Great. Thank you so much for all your help!

Not correct. Yes, the system will boot, up to a point, but the kernel will not find any modules that it tries to load after the switch to the "real" root filesystem. It will have only those modules that were needed to get that root filesystem mounted. The files in /lib/modules/{kernel_version}/ are what will be missing.

rknichols - OK, so how would I proceed in my situation?

Situation: I image my USB flash (it has only 1 partition) with FSarchiver. When I restore it, it will not boot. I learned FSarchiver is a "file-by-file" program so it excludes grub.

I like FSarchiver. It is flexible. What I mean is this: It can restore the file system to a destination of any size as long as the destination is large enough to hold the uncompressed data. The only problem is that I can't get the restored image to boot.

How can I overcome this obstacle?

It would be a perfect "one-stop-shop" if I could just find an easy way to make the restored image bootable.

I don't think that's correct. The boot process will load the kernel and the initrd ("Initial RAM Disk"), which ensures that a successful switch to the "real" filesystem can be made.

Granted, if the initrd doesn't include the required modules, then the switch will fail, but under Ubuntu, I have never had to worry about getting the initrd right.

Or are you thinking about a situation that I am overlooking?

There is only one way to know. I will post the results here after I do it.

Though I must ask - how do I install grub to the separate /boot for this test? Can I use my distro's live CD? What command line do I use? Or is there a GUI install version somewhere?