Talk:Multiboot USB drive

From ArchWiki

Redirect to avoid duplication?

Everything seems to be already covered on GRUB page: GRUB#Installation, GRUB#Generating main configuration file, GRUB#Booting ISO9660 image file directly via GRUB... (it is obvious that GRUB can be installed on USB drive)

Maybe we can just redirect to GRUB#Booting ISO9660 image file directly via GRUB to avoid duplication?

-- Lahwaacz (talk) 15:42, 10 September 2014 (UTC)

What about compacting the article instead by keeping the general idea and the steps in the procedure while replacing the duplicated parts with links, and then merging the result into USB_flash_installation_media#Using_a_multiboot_USB_drive, which is this article's only backlink? -- Kynikos (talk) 10:49, 11 September 2014 (UTC)
Moving GRUB#Booting ISO9660 image file directly via GRUB could also be considered, but "Multiboot USB drive" is too generic title for this. It all depends if similar setups (even without booting ISO images) are possible with other boot loaders, e.g. syslinux. -- Lahwaacz (talk) 11:56, 11 September 2014 (UTC)
Do you mean "moving" it to a separate article or into USB_flash_installation_media#Using_a_multiboot_USB_drive? In either case, as you point out splitting GRUB#Booting ISO9660 image file directly via GRUB would require more research about other boot loaders to justify having it in a separate article from GRUB, I'm not sure how long would that take to be implemented...
If our immediate goal is only removing the duplicated content, my solution seems more readily feasible.
-- Kynikos (talk) 14:06, 12 September 2014 (UTC)
As there was another method to be added (Syslinux + memdisk), I have merged the GRUB#Booting ISO9660 image file directly via GRUB section here. Aside from the obvious style issues, there is also USB_flash_installation_media#Loading_the_installation_media_from_RAM (see also the preceding forum thread), which is surprisingly presented as Windows-only method. If it was a Linux method, I would have already merged it here, but now I'm not so sure. -- Lahwaacz (talk) 16:49, 13 September 2014 (UTC)
Well done with the merge. About USB_flash_installation_media#Loading_the_installation_media_from_RAM I'm not sure either, if you want you can consider flagging it with Template:Merge to attract more opinions here. -- Kynikos (talk) 04:23, 14 September 2014 (UTC)
OK, marked as suggested, closing. -- Lahwaacz (talk) 07:50, 14 September 2014 (UTC)
Re-opening, this discussion is still needed as a reference for #Scope and title, but let's continue discussing there. -- Kynikos (talk) 11:06, 21 September 2014 (UTC)
To clarify what this article was meant to be: My intention was to make an article specifically about how to boot multiple ISO files from one usb drive. I agree that the title is too generic as is. Whilst a lot of the content here might seem simple and already found elsewhere, configuring the various boot menuentries is difficult, and not documented on any other page. The boot menuentries are poorly documented on the homepages of clonezilla, ubuntu, and so on. Therefore maintaining a list of these entries on the wiki seems to be a good idea. I have now added 3 entries beyond the one for the archiso. This list does not really fit on any of the existing pages. It is entirely possible to achieve a similar result using syslinux, which could be added later.
-- Teateawhy (talk) 15:52, 12 September 2014 (UTC)
Ahem... What about GRUB#Booting_ISO9660_image_file_directly_via_GRUB as we linked from our posts above? :) -- Kynikos (talk) 02:57, 13 September 2014 (UTC)

Scope and title

If I may, I have some comments about this article.

First, the "introduction" (the first section of the article right after the title):

A multiboot USB flash drive allows booting multiple ISO files from a single device

A multiboot (USB flash) drive can manage the booting options in different ways. I mean, it is not limited just to booting "ISO images as-is". This is one valid method, with pros and cons.

Considering the name of the article (and the current relations / links to/from it), I would tend to think that limiting this article to this "full ISO images approach only" would be at least inaccurate. It should at least mention that there are other approaches available, with other pros and cons.

Alternatively, the name (title) of the wiki article should be modified so to reflect the specific approach being described. The disadvantage of such alternative is that it might leave the impression that this is "the" ("best", "only") way to have a multiboot (USB flash) drive.

I understand the initial intention of Teateawhy about the scope of the article. By reading the links to/from this article and the current title, IMHO some adjustments are needed, hence my above comments.

Now, regarding parts of the current content...

  • At this date (2014Sep), MEMDISK works on BIOS only, not UEFI (UEFI not being supported by these bootloaders using this "ISO mapping" approach is mentioned under Multiboot_USB_drive#Using_GRUB_and_loopback_devices but not under Multiboot_USB_drive#Using_Syslinux_and_memdisk.
  • The MEMDISK method is not limited to Syslinux. Bootloaders that are capable of loading a Linux kernel (on BIOS hardware) should be able to load MEMDISK too.
  • There are other bootloaders also capable of mapping (ISO) images (e.g. grub4dos).
  • Syslinux is mentioned in conjunction with MEMDISK, but someone could claim that using Syslinux by itself on a multiboot USB flash drive might be better than mapping entire ISO images (depending on pros and cons or each method). Additionally, Syslinux (and others) can support UEFI.

Of course, adding all this info in detail to this (one) article might make the scope of it "too wide" to be actually useful/clear.

So, it is fine to provide information about making a multiboot USB flash drive by "simply throwing ISO images" on the drive, but I also think that the title of the article and the links to/from it should be "more accurate", specially reflecting that other possibilities exist (instead of mapping whole ISO images) and mentioning pros and cons (more RAM needed, time to load the mapped image, consecutive blocks, used space in the USB drive...). Ady (talk) 21:40, 14 September 2014 (UTC)

Hi, thank you for your observations. This article has clearly large margins for improvement, including changing the title itself and the sections that link to it from other articles. I agree with all of your points, your contribution would be very welcome; if you have a better title to propose, please let us know here. -- Kynikos (talk) 03:00, 15 September 2014 (UTC)
About suggesting an alternative title...
The procedures described here are mostly valid for different storage media. Indeed, a typical use-case is on a USB flash drive, but you could do the same on non-flash drives, and on non-USB drives, whether removable or not.
Additionally, the content describes different variations of only one particular approach: mapping images. Although the method is typically used with ISO images, you could do the same with other types (e.g. HDD and superfloppy) of bootable images.
It seems that two words, "multiboot" and "image(s)", are essential to the article. I also think that, either together or by themselves, they give enough information so to attract potential interested readers. IMHO, words such as "USB", "flash" and "drive" are not really needed for the title, and they can be (and in fact are) mentioned in the content as typical use-cases of this multiboot method.
So, perhaps something about "Multiboot images" (or "Multibooting images") could be appropriate? Optionally add the "ISO" term too; although, these methods are not exclusively used with ISO images.
Once the scope and the title are refined, it would be helpful for users to have a hint about the existence of other methods (instead of mapping images), mentioning some of the generic pros and cons. Then (a) future new article(s) about such other multiboot methods could be linked to/from this (renamed) page. Ady (talk) 14:14, 16 September 2014 (UTC)
Good reasoning. What about "Multibooting disk images" as an improvement? Just "images" sounds too ambiguous to me, and "disk images" seems to be the correct term according to Wikipedia:Disk image. -- Kynikos (talk) 02:46, 17 September 2014 (UTC)
"Multiboot disk images" sounds reasonable. Just for the record, although many users don't care / remember / know, in this context the generic term "disk" includes the "disc" optical media (ISO images). Now, "only" the content needs some improvements :). Ady (talk) 13:12, 17 September 2014 (UTC)
Um... sorry but coming back here after a few days, I think I'm less convinced by the (current and intended) scope of this article, which is/would become too heterogeneous. I'd consider merging the GRUB section back to GRUB instead (or maybe even better in a GRUB/Subpage), and then, if you wanted (@Ady), you could rename this article as "MEMDISK" and expand it on how to load and use MEMDISK with some bootloaders; this would probably also make it easier to merge USB_flash_installation_media#Loading_the_installation_media_from_RAM here, and we could easily add a link to the new GRUB subpage in USB_flash_installation_media#Using_a_multiboot_USB_drive. I'm also re-opening #Redirect to avoid duplication? because it's related. -- Kynikos (talk) 11:05, 21 September 2014 (UTC)
Whichever the case, ATM the suggested title ("Multiboot disk images") seems (to me) more accurate than the current title ("Multiboot USB drive") according to the current content. "Multiboot disk images" also matches what seems to be the scope that User:Teateawhy intended for this page.
WRT merging / moving (part of) the content into other pages, I might have a slightly different view on the matter (or perhaps it is not so different?). GRUB is capable of dealing with many different scenarios. For the content / scope of a wiki article, I would tend to focus on what a user wants / needs / thinks, instead of concentrating on "every single thing that GRUB can do".
One user might be thinking about a very simple and generic task ("boot my newly installed OS, which I attempt to test with the very-basic features and nothing fancy").
Another user might want to have LVM, encryption, RAID, with several OSes... And yet another user wants a portable device with several "rescue" tools, or several OSes so to show to friends on their own hardware.
Writing every single scenario related to bootloaders (or to GRUB) under one single article would make it more complex for users to focus on their respective interests / tasks. IMHO, having different articles focusing on the task (i.e. what each user is thinking about) rather than focusing on a certain name/tool or certain software such as "everything GRUB", is more useful for users.
You can always have links from GRUB and from other alternative bootloaders' wiki pages to the "task-oriented" articles. Of course, the in-common information regarding GRUB shall not be repeated, but just mention the relevant info / steps so to achieve the goal/task. So the question becomes, how much "in-common" information (or details / steps) can and should be moved back to GRUB? Would/should this page be just a list of entries for different OSes, leaving the "HowTos" for each bootloader's wiki pages? Then you can decide how to name this page. Ady (talk) 16:45, 21 September 2014 (UTC)
'Multiboot' is misleading. This page presents very useful information about how to boot from a disk image file. 'Booting from a disk image file' would be an appropriate findable title, as would 'Booting from disk image files.' I'm not sure which style the arch wiki prefers.

DonJaime (talk) 13:32, 7 August 2015 (UTC)

I really don't see the point in keeping all this information on other distributions. Those have wikis of their own; and that's where this information belongs. -- Alad (talk) 21:33, 16 July 2016 (UTC)
It saves a lot of time to have all this information in one place. Yes, most menuentries are not related to Arch and could be moved to some cross-distribution wiki on the Web to which the Arch wiki could provide a link. But unless that happens, please keep the information. Pelzflorian (talk) 05:52, 17 July 2016 (UTC)
I love having these working entries, but I do think they would be better in a separate grub examples area not-specific to usb-drives, which could resolve the scope and title issue. AskApache (talk) 21:28, 7 June 2017 (UTC)
And what would be the scope of the new separate area? -- Lahwaacz (talk) 06:06, 8 June 2017 (UTC)

Arch dual iso

I tried booting the archlinux-2016.05.01-dual.iso using the menuentry in this wiki page but got a kernel panic and a message to specify init=.

My menuentry:

menuentry '[loopback]archlinux-2016.05.01-dual.iso' {
	set isofile='/boot/iso/archlinux-2016.05.01-dual.iso'
	loopback loop $isofile
	linux (loop)/arch/boot/x86_64/vmlinuz img_dev=$imgdevpath img_loop=$isofile earlymodules=loop
	initrd (loop)/arch/boot/x86_64/archiso.img

—This unsigned comment is by Entodoays (talk) 08:37, 29 June 2016‎. Please sign your posts with ~~~~!

Windows asks to reformat USB stick after generating Hybrid UEFI GPT + BIOS GPT/MBR USB

After following the instructions in Multiboot USB drive#Hybrid UEFI GPT + BIOS GPT/MBR boot, booting into Windows 10 and connecting the multiboot USB, Windows refuses to recognise the partitions on the device and shows an error saying "You need to format the disk in drive E:\ before you can use it.". Perhaps a warning on the wiki entry to notify people that this will happen should be added and/or the instructions in the entry should be changed to prevent this?

Schicko (talk) 13:05, 22 September 2017 (UTC)

What file system have you used for the data partition in the third step? -- Lahwaacz (talk) 07:00, 24 September 2017 (UTC)
Apologies for the late reply. GParted indicates 3 partitions on the flash drive:
  • sdb1 is a 1MiB grub2 core.img with flag bios_grub.
  • sdb2 is a 500MiB fat32 with flags boot and esp.
  • sdb3 is a 14.16GiB fat32 with flag msftdata.
There is also 1MiB unallocated space at the end.
lsblk -fs indicates that sdb2 and sdb3 are both vfat though.
Schicko (talk) 00:12, 28 November 2017 (UTC)
What happens if you remove the msftdata flag? Also according to the section on this page, the boot flag should be on the third partition, not the second. -- Lahwaacz (talk) 09:27, 28 November 2017 (UTC)
GParted automatically re-applies the msftdata flag after removing it and applying the changes. I think it is a default flag that is set automatically when no other flags are set. I also tried your suggestion of having the boot flag on the third partition (along with the esp flag which GParted automatically sets on partitions with the boot flag) instead of the second (which now has the msftdata flag automatically set to it). However, this didn't fix the issue as Windows still doesn't recognise the partitions, but the flash drive does remain bootable.
Schicko (talk) 13:03, 28 November 2017 (UTC)

Isohybrid from the syslinux suite

Am I right that isohybrid from is also capable for the task of preparing a multiboot USB drive? The way I understand it, for bios booting it support up to 4 iso images, where each image is on a separate primary partition. It also state to have a similar application for UEFI.

The bios of one 2006 PC I encountered doesn't recognize as bootable a USB stick that was created for a single small iso image by isohybrid with its default values. That bios can boot another iso image, one that Rufus wrote to another stick.

Regid (talk) 18:14, 1 December 2018 (UTC)

Isohybrid is something different. It refers to a way of preparing .iso images such that you can boot them in two ways:
  1. Via burning the image onto an optical drive (e.g. CD-R) and booting from the CD/DVD/whatever. This uses an ElTorito bootloader.
  2. Via dd if=my.iso of=/dev/usbstick and booting from the USB stick. This uses another bootloader, from the MBR sector.
By a fortunate coincidence (or maybe a thoughtful design; I don't really know), ISO9660 sort-of ignores the contents of the first 32kiB of its image. That's what allows to cram an MBR (including a partition table and a bootloader such as isolinux) into an ISO image — which then allows to pretend that this .iso is also a bootable HDD/USB image file (without breaking the ElTorito boot!) — which finally allows to just dd the .iso onto a USB stick and forget the army of "LiveUSB creator" crapwares.
This kind of ISO images is called Isohybrid — because, well, they're MBR/ElTorito hybrids. Not all bootable ISOs are Isohybrid — that's why you cannot in general just take any bootable ISO, plop it onto a flashstick with dd and boot from it successfully. You can, however, convert any boot ISO into IsoHybrid: just discard the bootloader it already has, and install the IsoHybrid combo instead. I've done this successfully using xorriso with a bunch of .iso images; this process is well documented.
Finally, in the context of Multiboot USB — Isohybrid is not really useful; you'll have a totally different setup on the USB image, involving a GPT+MBR, a bootloader specifically with GPT capabilities (e.g. GRUB), and probably a selection of .iso files (distros) you'll want to boot from that stick. The USB image itself won't even be ISO, evenless IsoHybrid; the .iso distros you store inside might be IsoHybrid — but it's only useful so much, since you already know the single way you'll boot into them: via the GRUB. I can see one scenario when you'll be happy to have Isohybrid distros on a MultiBoot USB (again, as .iso files on an ext3-or-whatnot partition): when you'd want to take a distro.iso from that Multiboot USB, and dd it straight onto another USB stick. Can you see why IsoHybrid plays well here? If not, try reading again; I apologize in advance for overly complicated sentences.
Hope that helps. --Ulidtko (talk) 15:11, 21 February 2019 (UTC)