A few pieces of advice and comments on jc__'s tutorial
First of all, many thanks to jc__ (again) for posting his tutorial on how you can achieve the goal stated in my initial post. I can confirm the method works, despite that you might have to do some additional troubleshooting when the time to boot the installed OSes come, which is why I am making this reply to enumerate a few things you might want to consider while following the tutorial.
0. If you pick older distributions, carefully check you can boot them at all
I learned the hard way that Fedora 8 is too old to boot on more recent hardware such as my current laptop (for reminders, Fedora 8 was released around 2007; my laptop was built in the 2010s). I don't recall the exact details (as I learned this thanks to one of my colleagues), but it seems the kernel has trouble dealing with my hardware and is unable to properly mount everything, which is why I eventually dropped Fedora 8 for Fedora 14 (which works fine).
But how can you check if a distribution will boot properly on your machine ? A simple approach consists in booting from USB with a Live version of the target distribution. If everything boots normally with the Live version, then you should have no trouble installing the distribution through a VM, cloning its partition on your USB stick and boot it from the USB.
In my case, I used YUMI - Multiboot USB Creator to test multiple Live versions of older Fedora releases on my laptop. Of course, this advice only applies if you need, like me, to use older distributions.
1. Consider using FAT32 or ext3/ext4 for the data partition
At some point, my Ubuntu 16.04 had trouble dealing with the data partition when it was formatted in NTFS. Eventually, I re-formatted it as FAT32 - a older format with which any Linux distribution should be okay. ext3/ext4 should be okay too if you exclusively use Linux (as far as I know, Windows cannot deal with these filesystems), though I haven't tested it myself.
I now use the data partition as a way to easily share data between the OSes on the USB and the OSes on the host computer.
2. Consider using a secondary USB stick for partition cloning
Having a second USB stick can be very practical for the first steps, as you can use it to store the images produced by clonezilla. When clonezilla ask you where you will put the /home/partimag/ folder, select the first option in the menu (just above ssh_server) while not having your second USB stick plugged into your machine, then plug it, wait around 5 seconds and press Enter, then select your second USB stick when clonezilla enumerates your options for the /home/partimag/ folder. The subsequent operations will be identical to those enumerated by jc__.
This approach does not - of course - change the outcome and has the merit of making the whole installation and cloning of the target OSes entirely without involving your host computer. You can try this if you are unsure about toying around with partitions.
3. If booting your USB OS fails after loading kernel, rebuild initrd/initramfs image
Depending on the target OSes, you might run into issues similar to those I presented in some comments of this topic, such as having timeout with queues in dracut while booting Fedora 24.
In my case, except for the particular case of Fedora 8 (cf. item 0), I fixed the problem by rebuilding the initrd image. Depending on your distribution and how recent it is, this image can also be prefixed by initramfs rather than initrd. No matter the name, the purpose of the file is the same: having a transient filesystem at boot time before mouting the actual filesystem. If this file is corrupted, erroneous or missing, you cannot properly boot your system.
Hopefully, any Linux distribution comes with an utility to rebuild this image. From my (short) experience:
- Older distributions:
mkinitrd - Recent Ubuntu distributions:
mkinitramfs - Recent Fedora distributions:
dracut
NOTE: when (re-)building the image, each utility will take the /etc/fstab file into account. Take advantage of this to already link a swap partition with your USB OS. In /etc/fstab, you can use an UUID to denote a partition, so use fdisk and blkid to get the UUID of the desired swap partition and update the /etc/fstab accordingly.
To use one of the three commands I listed to rebuild the image, you need first to chroot into the OS which you want to rebuild the initrd/initramfs image. I basically follow the same approach as in this tutorial, which consists in mounting the partition of the buggy OS (so, one of our USB OSes) on your host computer and using a few binding commands to properly chroot in it. You can create sub-folders in your /mnt folder if needed. In my case, to chroot into my Fedora 14, I used the following commands:
sudo mkdir /mnt/usb_f14 sudo mount /dev/sdb3 /mnt/usb_f14 sudo mount --bind /proc /mnt/usb_f14/proc sudo mount --bind /dev /mnt/usb_f14/dev sudo mount --bind /sys /mnt/usb_f14/sys sudo chroot /mnt/usb_f14 Don't forget to check beforehand what /dev/sdX your partition is with fdisk. Once you are rooted in your USB OS, move to the /boot folder. If you wish to, rename the already present image (if any) to keep it (you can simply prefix it with old-, for instance) before you create the new image. Then, run
ls /lib/modules/ This will list the different kernels you have on your USB OS (most of the time, you should have only one). Indeed, any of the command I listed above requires you to give the kernel you will use to build the image. Then, depending on the utility you have access to, you should run one of the three following commands (by my-kernel, I denote one of the kernels listed by ls /lib/modules/; note that you can use other names for your images if you wish)
mkinitrd initrd-my-kernel.img my-kernelmkinitramfs -o initramfs-my-kernel.img my-kerneldracut initramfs-my-kernel.img my-kernel
Depending on your OS, there might be some messages about missing modules. As long as the image is produced, you can ignore them (I got some while rebuilding the image for my Fedora 14, and it still boots fine).
Note, also, that if you directly replace the old image, you might have to add a flag to your command to force the overwriting. For instance, with dracut, you should add --force. Refer to your manual for the other commands. Once you are done, unmount your USB OS partition and reboot your machine with the boot sequence set to boot from USB first. Your USB OS should now boot normally.
Finally, don't forget to take note of the name you gave to the new image, if different from the name of the initial image, because you will need to update your grub.cfg file to take the new image into account.
4. Double-check the partitions on the virtual machines
If you couldn't choose yourself the partitioning when installing one of your target OSes in a virtual machine (it happened to me with Fedora 14), it is possible you end up with two ext4 partitions, with a small one containing the /boot folder and the other containing the rest of the filesystem. If this happens, clone the larger partition with the method described by jc__, then boot again your virtual machine, copy somewhere (e.g., on secondary USB stick) the /boot folder and later place it in the partition you cloned after restoring it. Don't forget to update the /etc/fstab file afterwards before re-building the initrd image (see 3), as the original file will likely still list two ext4 partitions instead of one.
5. Exiting your USB GRUB, the easy way
While jc__ recommends to use super_grub2_disk_hybrid_2.02s9.iso and memdisk to get all the options on the host machine, you can also just add this simple menu entry in your grub.cfg:
menuentry 'Continue to host machine' { exit } This will make GRUB on the USB stick quit and resume the boot sequence of the host machine. In my case, since my host computer is a laptop with dual boot, I get the GRUB menu of my machine right after selecting this menu item.
That's about it for the comments I wanted to make. Since I don't have a lot of experience with Linux troubleshooting, don't hesitate to comment this post to point errors or inaccurate statements.