Talk:Multiboot USB drive

From ArchWiki
Revision as of 18:41, 8 February 2018 by Ady (talk | contribs) (Accuracy note about Hybrid MBR: re)
Jump to: navigation, search

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)

Accuracy note about Hybrid MBR

IMHO, the edition made by User:Nl6720 is not appropriate.

I think an "Accuracy" flag note should express an objective doubt, such as a potential different interpretation of facts or values, or conflicting information based on 2 (or more) different trusted sources.

In the aforementioned edition, there is no conflicting objective information. In fact, the UEFI specs claim that MBR is supported, but some systems fail to boot in such cases (just as an example, search for MJG's blog posts about the matter).

The fact that some/many/most systems don't need Hybrid MBR does not contradict its potential use-cases. And so, if the goal is to be able to boot as many different systems as possible with the same "Multiboot USB drive", then some users might want/need to have this method/information available.

I'm not saying that using Hybrid MBR is always recommended. Whether it is "sane", is subjective. Whether it is "needed", depends on users' needs/desires.

IMHO, either the edition (i.e. the "Accuracy note") should be removed/undone, or objective reasons should be provided for it. Ady (talk) 19:20, 7 February 2018 (UTC)

I might have slightly exaggerated with the wording and Template:Accuracy is most likely not the correct template for this.
Does hybrid MBR being a nonstandard hack for a obsolete use case count as an objective reason to discourage it's usage? If not, I have no other reason. Most systems should have no problems with UEFI/MBR on a removable drive and it would make the setup slightly simpler. -- nl6720 (talk) 08:46, 8 February 2018 (UTC)
I think that the Hybrid MBR section does not claim that its usage is a "must" but rather a possible alternative. Quote: "This configuration is useful for creating an universal USB key, bootable everywhere." (BTW, it is "an universal...".)
In a similar sense, many ISO images for Linux distribution (including the monthly release for ArchLinux) simultaneously have the ability to boot using several alternative booting methods: MBR, GPT, El Torito, and even more (I am referring to the ISO images themselves, not to installing the OS); this is done in order to support as many different systems as possible by means of the same ISO image. The simultaneous presence of these booting methods could be considered by some people as a non-standard hack too; and yet, it is useful, effective and popular with many distros (including Arch, of course).
Perhaps the wording of the section can be improved for clarity and make it easier to follow? Perhaps adding cons/pros? I don't know whether the matter deserves it, though.
IMHO, I don't see any specific reason to discourage it; it's just one possibility for users to achieve the goal ("booting everywhere", which is not the same as "my one and only personal system successfully boots my installed ArchLinux OS), especially relevant for portable USB storage devices.
When I started this Talk section, my point was about the specific "Accuracy" note (now gone, thanks). If someone wants to improve the article, or add pros/cons or whichever additional info (maybe in a sub-article, or in this Talk page, instead of using the main article page?) I would not be against it (FWIW). Ady (talk) 18:37, 8 February 2018 (UTC)