I thought I'd make this thread as a resource for those, who like me, are looking to put together their own, multi-boot USB drives. What I have in mind when I speak of a multi-boot USB drive is a bootable drive that allows booting more than one distro or operating system. I am personally interested in booting multiple GNU/Linux distros, so my comments in this thread will focus on that. I'm off to a good start on accomplishing the aim (see link below) but there is plenty of detail that still needs to be filled in.

There are many Live CD's (in the form of iso files) out there that are geared toward booting from removable media, so available software is very congenial to doing this sort of thing. But those many live-cd images, which are made to be booted from a bootable CD/DVD drive, require adaptation when used on a multi-boot USB drive of the sort I will discuss. If one is simply aiming to boot one live distro, and only one image from a USB drive, the tried and true dd method is definitely the one to use. But I'm aiming at being able to boot more than one distro from my USB drive so using dd is not the right solution.

There are, of course, programs out there that automate the creation of multi-boot USB drives. unetbootin is an example of such a program. It's one I've successfully used in the past. But I'm looking now to accomplish more manually what a program like that automates for the user. The main reason is that the manual method gives more control over the process and avails more options--for example choice of boot loader. But the method I'm pursuing is also more time-consuming, requiring something along the lines of reverse engineering, since each distro puts together their live-CD images in slightly differing ways. This approach definitely will not be everyone's cup of tea, though I have to believe I am not the only one who will take an interest in this sort of more manual approach. But please understand that offerings of automated multi-boot solutions like unetbootin are not being solicited in this thread.

On the subject of boot loaders, I find syslinux the most readily comprehensible: it is fairly straighforward to make a USB drive bootable with syslinux, and fairly trivial to create a syslinux menu that will allow selection of such distros as may be on the USB drive. So my focus will be on using it.

One seeming benefit of using syslinux is the memdisk utility, which is capable of booting certain iso files. My own experience indicates that using memdisk to boot iso files fails more often than it succeeds. For example, I've used memdisk without problem to boot the Arch install iso. It also allowed me to boot the Porteus iso, although booting that system winds up being a two-stage process wherein the user confronts essentially two boot-loader menus in sequence; and I only finally got it to work that way by copying over, from the loop-mounted CD image, certain key files, to the USB drive. But in most other cases the iso booted using memdisk will not issue in a usable live environment. So memdisk, unfortunately, seems not to be the solution for booting to a live environment in most cases.

I only recently ran across a solution that, although heavily focused on *buntu distros, seems to offer a really good starting point. I consider the steps described at https://opensourceict.com/linux/how-...using-syslinux to provide a very sound basis for a project along the lines I'm trying to implement. In fact, if one is aiming to boot only *buntu distros and/or the few others touched on in that how-to, it could suffice as the sole guide for doing this sort of thing--although many of us will want to change every instance of "it" in the syslinux.cfg file offered there to "us" (i.e., change the default language/keyboard from Italian to American English).

Looking over that how-to, it quickly becomes apparent that the method described involves the following steps: 1) formatting a USB stick (the author uses the FAT filesystem but my experiments indicate that ext2 works also); 2) installing syslinux to the MBR of the USB drive and copying over to it key syslinux files; 3) creating a series of sub-directories on the USB drive for each distro that will be booted, directories that will hold files copied over from the loop-mounted iso images; 4) mounting desired iso's as looped filesystems and copying their content into previously-created directories; and 5) crafting an appropriate syslinux.cfg file that will provide the user, when booting from the USB drive, with a menu of choices of which distros are on the drive.

The various *buntu distros (Bodhi, Lubuntu) I have tried on the USB drive I created using those directives boot just as they should, just as though I have booted from the CD. The system rescue distros, though newer than those used for the original documentation, work fine as well. So this fellow is obviously on the right track when it comes to creating a multi-boot USB drive of the sort I'm aiming for.

Trying to implement, however, the booting of other live distros--for example Clonezilla and Void--has so far not been successful for me. So the entries that author provides in his syslinux.cfg file are not readily adaptable to many live-CD images of other distros. I suspect the reason for this is that each distro sets up its live boot environment in slightly differing ways, passing varying kernel paramters at the boot process to make it issue successfully in a live environment. Very likely the various initramfs/initrd files contain options peculiar to each distro as well.

What I hope to achieve in creating this thread, then, is to solicit the input of others as to how the live-CD images of other distros boot, and thus how valid entries for booting those images might be added to the syslinux.cfg file. With input of others, we may well be able to create an even better resource for those users who, like myself, might wish, using a process that allows greater flexibility than the automated solutions available, to create their own multi-boot USB drive.

I'll wind up with a bit of information from the syslinux wiki on why memdisk does not succeed in booting all iso files: "The majority of Linux-based ISO images will also fail to work with MEMDISK ISO emulation. Linux distributions require kernel and initrd files to be specified. As soon as these files are loaded, the protected mode kernel driver(s) take control and the virtual CD will no longer be accessible. If any other files are required from the CD/DVD, they will be missing, resulting in boot error(s)." There are some possible workarounds: "Some distributions allow you to pass/append an extra parameter to the kernel (append) line, which tells the init scripts to look for an ISO file on a disk. Some distros require for the drive and partition number (where the ISO is stored) to be explicitly specified, while others will search each partition for the specified filename. Such parameter is distro-specific, so look at the docs of your distro. Some popular ones: findiso=, iso-scan/filename="

Some pertinent URL's:
http://fomori.org/blog/?p=747 discusses creation of multiple partitions on a USB drive in order to effect the process of booting multiple distros (can't access this URL at the moment, but https://web.archive.org/web/20140706...rg/blog/?p=747 works); https://superuser.com/questions/5846...-with-syslinux is a *buntu-centric dicsussion that can augment information provided in the link offered above; https://wiki.archlinux.org/index.php...boot_USB_drive - good documentation on booting from USB drives; https://www.reversengineered.com/201...disk-and-ipxe/ discusses options using ipx; and https://www.linuxquestions.org/quest...em-4175452849/ is an earlier discussion on this forum that touches on some of the difficulties of using syslinnux to boot multiple distros from a USB drive.

A few years ago, I was able to implement all of the above using syslinux. I am a Fedora user and did not want to use dd to wipe out valuable information on the flash drive.

At that time, syslinux only supported BIOS/MBR hardware. According to their website, they now support UEFI.

Since my hardware is UEFI with gpt disks, I switched to grub a couple of years ago. I don't know if grub supports memdisk. My 128 GB Lexar usb flash can boot in either UEFI or BIOS mode. If you google "arch linux multiboot", you will find the method outlined there. They also provide a sample grub.cfg at a github link. Those kernel parameters can also be used in syslinux.cfg.

Here is the grub stanza I use for clonezilla
You can modify it for syslinux.

Thanks for your input, plasmonics. I should've mentioned that my focus is on legacy/BIOS systems, since only one of my machines uses UEFI. But of course others consulting this thread may well be using UEFI systems and will be looking for information relevant to their systems.

I personally gave up on GRUB after 2 came out and, having recently made a foray into making a GRUB-bootable USB drive for a friend, still find it quite impenetrable. But to each his own.

I will examine your Clonezilla entry and see whether it might be adaptable in some way to my scenario. Since you are apparently booting the iso file I suspect the kernel options you're passing won't be viable for me. But I'm quite new to passing these sorts of parameters so I could be wrong about that.

I have consulted the Arch wiki entry you reference many times as I've delved into creating bootable USB media using syslinux. It's definitely a valuable resource.

REFERENCE: https://opensourceict.com/linux/how-...using-syslinux

So, to get to some details of the directives I found, I'll recount here some of the more specialized steps this fellow went through to create his multiboot, syslinux bootable USB drive. Meaning I won't devote attention to the more generic issues like creating a file system on the USB drive, making the drive bootable with syslinux, or which syslinux files need to be copied over to the drive. Directives for doing those tasks are available at various sites on the internet--including at the main link I am using to document this process and which I gave in about the middle of the OP. I will only observe in this respect that, although those directives stipulate creating a FAT32 file system on the target USB drive, I used the ext2 file system and my multiboot drive is working just fine.

One of the trickier steps, but apparently a very key one, is, after having created an appropriate directory structure on the target drive, loop-mounting the iso files and copying over contents to the requisite directory on the target drive. I'm not sure the directory structure on the target drive is terribly important: the author of the directives I found and followed creates a syslinux directory at the root of the USB drive, an iso directory under that, and a separate directory under the iso directory for each of the distribution iso's whose loop-mounted contents will be copied over to the USB drive. So, for example, one of the paths he specifies in his syslinux.cfg file is /syslinux/iso/ubuntu_1404. The most important things in creating the directory structure on the USB drive is that it will be comprehensible to the drive's creator and, equally importantly, that it will be correctly stipulated in the syslinux.cfg file that will be later created and that will present the user, on boot up, with a menu of choices.

Supposing that we have followed the directives laid out at the link I provided in the middle of the OP, that we have our properly prepared USB drive already mounted at /media/mb, an iso has already been downloaded, and that we have created a directory /media/iso on the host system we are using to create our multi-boot USB drive, the next steps will be to create a sub-directory for one of the iso's we will be attemtping to boot, and to copy over to that directory the content of the loop-mounted iso file. This is done as follows: That same procedure needs to be followed for each of the iso's whose live environment we plan to boot to from our multi-boot USB drive. In other words, a sub-directory will need to be created, the iso loop mounted on the host system, and the files from the loop-mounted iso copied over to the sub-directory that was created on the USB drive.

The really crucial aspect of this scheme will be crafting a valid syslinux.cfg file. And that's the part for which I want to ask input in this thread. There are all kinds of parameters that get passed to the kernel in the syslinux.cfg file this fellow offers. And his examples work fine for the 3 or 4 different distros he has/had on his multi-boot USB drive. But further adaptations, in my experience, are required for other distros. I'm trying, for example, to get Clonezilla booting from my multi-boot drive, but am so far not meeting with success.

In a later contribution to this thread I will examine some boot entries from the sample syslinux.cfg file this fellow offers. Perhaps we can put our heads together here and determine what boot options and parameters are available, what they do, and how the content of iso's of other distros might be adapted to this scenario such that they boot to live environments from our multi-boot USB drive. More to come.

REFERENCE: https://opensourceict.com/linux/how-...using-syslinux

GREAT!!! This looks very useful;
SearchLQ with Keywords: multiboot USB uefi
finds 17 threads

I think the kernel options should be similar, passed by the "append" command. For example, here is an excerpt from my old syslinux.cfg file to boot Gparted
I don't have one for Clonezilla.

If I understand correctly, you are extracting vmlinuz, initrd, and squash files from the iso and copying them to individual directories on the flash drive. If I remember correctly, this is also what I did.

However, I recall reading somewhere that syslinux can now loop mount an iso using memdisk. This option was not available back then.
This might be a cleaner solution, as it avoids the clutter of having so many directories.

Thanks for the further input and syslinux.cfg excerpt, plasmonics. I'll look into adapting that to my thus-far-unsuccessful Clonezilla entry--further details of which I will soon post here.

Your understanding of what I (actually, the fellow whose directives I have been following and am relaying here) am doing is correct. And your suggestion of using memdisk--if it would actually work--would be a much more elegant and less troublesome resolution to creating a multi-boot USB stick. It's the obvious first choice.

But, like I mentioned in the OP, this is only a resolution if all or most iso's will boot with memdisk. As I also mentioned there, however, in my experience most iso's will not boot using memdisk (my experience indicates that perhaps 25%--as a liberal estimate-- of iso's will successfully boot to a live system when booted via memdisk). I included toward the end of the OP an explanatory note from the syslinux wiki that explains why most iso's will not boot with memdisk, a note that also suggests some workarounds. But my attempts at using those and other workarounds have so far not led me to succeed in booting additional iso's using memdisk.

That said, if you know of some way of successfully booting all or most iso's using memdisk, I'd love to hear about it: I would happily give up on the comparativley more complex and time-consuming method of loop-mounting the iso's and copying over their content to the USB drive, were there a simpler and more effective solution like that. But if there is such a solution, I have not so far managed to discover it.

REFERENCE: https://opensourceict.com/linux/how-...using-syslinux

I do recall a caveat from one of the websites that memdisk only boots some iso.

If you are intent on using syslinux, it should work. It is just a matter of figuring out the kernel parameters. You can usually just copy the contents of syslinux.cfg in the iso to the multiboot one in the flash drive. I am attaching my old syslinux.cfg file. It may not work as is, because some distros, eg, Fedora, keep changing their parameters.

I switched to grub, because it loop mounts the iso as a ramdisk. From there, I can load the kernel and initrd via the linux and initrd directives. All the isos are kept in one ext4 partition on the flash drive.

One drawback is that the grub method cannot boot windows iso. I believe syslinux used in conjunction with grub4dos can, although I never tried it.

Another drawback is that you cannot render the native graphics and fonts of each distro. The boot screen is plain ncurses. Syslinux boot screen will render each iso boot screen as the vendor intended. In grub, this has something to do with preloading png graphics support. I couldn't figure out that one.

Attached Files

syslinux.cfg.txt (15.0 KB, 39 views)

Thanks for continuing this discussion, plasmonics, and for offering your syslinux.cfg. I consider the rather extensive syslinux.cfg located at the link I offered about midway through the OP to be the definitive one, but having others as a reference--especially if the boot parameters contained in those are well understood by the file's creators, should be a big plus. See, my main problem in accomplishing the aim discussed in this thread is probably that I so poorly understand those parameters and what they contribute toward arriving at a fully booted and operational live environment. Well, actually, I have only a very sketchy understanding of setting up live environments in general, but let's deal with one area of confusion at a time. Anyway, I do plan later to offer here some examples from the reference syslinux.cfg on which I've touched, so I'd much appreciate any further input you may offer when it comes to discussing some of the particular boot parameters.

As to being intent on using syslinux, it just seems to me to be the right tool for the job. I had already become aware that GRUB is more capable than syslinux when it comes to booting iso's--something you've now confirmed. But I can't see how GRUB is the ultimate answer to a scheme that seeks to create a multi-boot USB drive of the sort I'm envisioning. The reason for that is because, judging from some recent experience with GRUB2, it seems to me designed for use in systems installed to hard drives. To me that appears obvious from the fact that the GRUB menu file can no longer be manually edited: it is meant to be generated by the system on which GRUB is installed. You can add custom menu entries by editing one of the files the system uses when generating the menu, true, but the scenario is obviously one in which only minor variations are expected--not the scenario for a multi-boot USB drive, wherein items may be replaced on a semi-regular basis owing to the appearance of newer releases of the respective distros.

So GRUB2 does a great job for those who want to install a system to a computer, having partitons and OS's detected along with auto-generation of a valid boot menu for that machine. But it just seems to me that a multi-boot USB drive is the wrong application. If you (or anyone else reading this thread) think I'm wrong, I am certainly open to arguments as to why GRUB2 is a better choice. To me, a big deciding factor is ease in comprehension and editing of the boot menu file: with syslinux it's a simple text file easily edited by hand, while with GRUB2 it's a barely intelligible mass of gobbledy-goop that must be generated by a computer. But perhaps I'm overlooking something? How, for example, when you add a new iso, do you update the menu for your GRUB multi-boot USB drive?

By the way I've already tried copying the syslinux.cfg entries from the contents of the iso's of a couple of distros (definitely Clonezilla and probably Void) to my mulit-boot USB drive's syslinux.cfg file. These entries as written (with, of course, revision of more obvious features like file paths) do not allow me, when selecting those entries, to boot into a live environment. So it looks to me as though it's not quite that simple a matter to create valid syslinux.cfg entries for the various distros. True, those sorts of entries should form the basis, but the entries will apparently need to be tweaked: my hope is to discover, using input from this thread, what sorts of tweaks are needed.

REFERENCE: https://opensourceict.com/linux/how-...using-syslinux

Time to examine some entries from the reference syslinux.cfg file. I will look at two, one quite simple (if only all entries could be so simple!) and one quite complex.

The System Rescue CD entries are the most straightforward and readily comprehensible. A sample looks as follows:
(note that I've changed "it" in the reference file to "us" so that we wind up with U.S. keyboard mapping)

The entry, after specifying a label, stipulates the location on the USB drive of the kernel to be booted. Recall that the drive has been made bootable, the iso image loop-mounted, and that its contents have been copied over to the USB drive under /syslinux/iso/srcd. So, obviously, the /syslinux directory is at the root of the USB drive. Similarly, the location of the initram filesystem has been stipulated on the "append" line. The dostartx and setkmap items are readily comprehensible. About the only option that, at least to this observer, is not very transparent, is the subdir= entry.

If such relatviely simple syslinux.cfg entries would suffice to boot into the live environments of all or most distros, a thread like this current one might not be called for. But my recent experiences indicate that creating relatively simplistic syslinux.cfg entries like this will not suffice to boot into the live environments of most distros. Rather, far
more complex entries seem to be the rule.

Take, for instance, the syslinux.cfg entry for Ubuntu 14.04 as found in the reference file: This entry has a number of additional items in the "append" line. And it is far less apparent what the various additional entries are actually doing.

A google search for boot=casper reveals that casper is "a hook for initramfs-tools to boot live systems" and that boot=casper is a kernel parameter--a parameter that gets passed to the kernel. live-media-path= on the other hand, seems not to be a kernel parameter. Other items from the "append" line could, for those not conversant with these sorts of entries (probably most of us), require additional research.

My searches to date indicates that items in the "append" line are of 2 different sorts: kernel parameters and parameters that get passed to and are interpreted by the initramfs being booted. A list of valid kernel parameters can be found at
https://www.kernel.org/doc/Documenta...parameters.txt. A fairly comprehensive list of parameters, sometimes called "cheat codes," that are often passed to initramfs's, can be found at https://craftedflash.com/info/live-d...oot-parameters.

I'll close this post by offering a few additional links that deal with boot parameters of the two sorts listed. The final link, though dated, contains some still potentially instructive sample syslinux.cfg entries for a multi-boot USB drive.
http://man7.org/linux/man-pages/man7/bootparam.7.html
http://www.porteus.org/tutorials/26-...and-how-to-use
http://clonezilla.org/fine-print-liv...parameters.doc
http://wasd.urz.uni-magdeburg.de/jsc...multiboot.html

I think it would run better if you installed the distros to the flash drive. Live CD environment isn't that great for everyday use.

I guess I should have clarified that the aim I have in mind is to be able to boot multiple distros for purposes like system rescue and the like--thus my interest in booting Clonezilla and System Rescue CD. Or perhaps to demonstrate to someone unfamiliar with Linux what one or another graphical interface looks like. Using a USB drive in the fashion described also allows for keeping abreast of newest releases of the distros involved.

As to installing and running a single distro from a USB drive, I've done that already more than once. My file server runs NAS4Free like that, while I have Arch running from an SD card in an older netbook that acts as a router. I also recently helped a friend install Lubuntu to a USB drive. So I don't really have many questions about how to accomplish that aim: it's a comparatively much more straightforward process.

Booting multiple (I'd hope for 4) live environments from a USB drive should be doable, but because these live environments are all put together in unique ways, it will likely take a bit of reverse engineering to figure out how it needs to be done for each. Thus this thread.