Creating multiboot USB drive the manual way

English Install/Boot/Login
1

Hello again.

The release of Leap 15.1, along updating of other live distros I use, made me rethink about the possibility of a multibooting USB drive (currently I’m using CDs/DVDs, both read-only and RW).

I did take into account Malcolm’s last comment here, though after making my mind I think I’d need a USB just for Linux distributions, both live and installation, and both legacy BIOS and EFI (no 32bit EFI).

Dd is an excellent tool, as previously discussed, but it works for writing only one bootable OS to USB drive, with a special read-only file system. Correct me if wrong please.

So I went again searching, and found more than one reference:
https://en.opensuse.org/SDB:Live_USB_stick#Using_live-fat-stick.2C_live-grub-stick.2C_live-usb-gui_.28Command_line_or_GUI_way.29
https://www.debian.org/releases/stretch/amd64/ch04s03.html.en#usb-copy-flexible
https://wiki.archlinux.org/index.php/Multiboot_USB_drive
https://linuxconfig.org/how-to-create-multiboot-usb-with-linux

In general these methods have a good point, at least for me: they handle the ISOs directly, instead of modifying by extracting them like other tools.
All look alike in some way (specially last 2), as if there could be really a “general” way to do the thing for most of the Linux distributions.
But indeed, all are different. Is this precisely because each distribution is different?

Last link looks like the more general one, a method using Grub(2) and loopback devices. The tricky part is, of course, finding the correct grub parameters for each distribution…
I tried looking into Leap 15.1 ISO installer, but failed to find something similar to what’s needed here. Or perhaps I didn’t search very well…
Do you think this method can work for Leap and many other distros in general? Is there a “general” way or advise to search for a distribution’s correct grub parameters?

There’s also the syslinux method, but I couldn’t find much in-depth information about its usage.
Not sure whether it can also work for both BIOS/UEFI booting, the fact of having to use memdisk to load whole ISO file in RAM sounds not very satisfying…

Thanks.

2

Reading also your other thread, I doubt you understand what dd is made for.

dd only copies byte for byte from it’s input file (what ever that is, a “normal” file, a device, a partition, …) to it’s output file (same). Nothing more, nothing less. It does so already more then 50 years. It has no, I repeat no, “knowledge” about what those bytes, in the sequence they are copied, mean. dd worked already before Linux existed. It is just a stupid byte copy program. And when you think it is excellent, then it is excellent in just doing something very basic, carrying one byte after the other from if to of in sequence.

It is you that must decide what to copy from where to where and if the result of this has any use of doing something with it.
E.g. When you copy a whole disk (that is including it’s MBR/partition table and partitions and unsused space) to a “normal” file, then that file can be interpreted by any program that knows how a disk is formatted. But probably the only logical use to be made of this file is to dd it to some disk and see, now you have a so called “clone” of the original disk (let us hope it fits). You have a clone with te same MBR/partition table, with the same partitions and all the same UUID’s that are associated with them (so take care, you may now have two disks with double UUIDs!)

So when you talk about something being “read-only” on if, then that is read-only because something on **if **says so. When you dd it to of, that “something” is copied with it.

3

I’ve tried that. It didn’t seem too hard to setup.

But there’s a problem. I can use it to boot live media. But I cannot use it to boot the openSUSE DVD installer. The DVD installer does boot that way – sort of – but it cannot find the on media repo (the rpms to install).

So I gave up on doing that.

I do have a USB setup. It’s an older external drive, originally used for backups but no longer needed for that (because it is too small). So I installed Leap 15.1 there. I have it able to boot on legacy systems and on EFI systems. And I do have the Leap 15.1 DVD install medium unpacked into a separate partition on that drive. I can optionally boot into the installer, and have used that for installing Leap 15.1. But, mostly, that system on a USB is intended as a rescue/repair system that I can boot on any of my computers for special purpose repairs, etc.

I’m not sure whether that’s what you are looking for.

4

First, sorry for the useless rant. I was a bit desperate back then, though no pretext

After doing more in-depth searches, I stumbled with what looks like the most “plausible” possibility out there I could find around internet:
https://github.com/aguslr/multibootusb
https://gitlab.com/aguslr/multibootusb
https://mbusb.aguslr.com/

It’s got good documentation in the website; it also based partly in the Arch Linux wiki, works for both UEFI and legacy BIOS, the docs explain how to manually prepare the USB drive (or one can just use the provided script to do it all automatic), and also includes advise of how one would manually add a distro (i.e., the magic behind those freaking grub menuentries different for each distro!). Regarding this last part, heck, the tl;dr would be: one certainly needs to search and study each distro’s boot configurations, within each one’s respective ISOs.

I tried looking inside a few couple of different distros’ ISO files, looking for their boot options and comparing them to the ones included in the project (“List of supported distributions” section). Applying what I read in the docs, I was able to find match at least for Centos Live and openSUSE itself (for this last one I looked inside ISO’s EFI/BOOT/grub.cfg), but failed to understand for, say, SystemRescueCD and Slitaz.

I think I’ll give it a try.
But meanwhile only one doubt arouse. grub2-install is used to install the bootloader to the USB drive. If I use grub2-install on openSUSE, will USB also support shim signature, i.e., be secure boot proof? Or USB will not and I’ll have to turn off secure boot?

Thanks.

@nrickert:
I’m trying to search a tool which could work for both live distros and installation to hard drive.
I wonder what was the failure for you with openSUSE… maybe wrong menuentry settings…??

5

Using “live-usb-gui”: Leap 15 + Leap 15.1 + TW just works.
Another distros: it is simpler to use more than one thumb drive.
rEFInd can help you with a EFI boot: https://en.wikipedia.org/wiki/REFInd

6

Here’s how I handle that.

(1) I install grub with something like

grub2-install /dev/sdb

to install to the MBR of the USB. Actually, the install already does this.
(2) I use

shim-install --removable --no-nvram

This installs shim, is such a way that it won’t get an error if you run this command on a non-uefi system.

I’ll note, however, that on some older systems you might need to first run

grub2-install --target=x86_64-efi --removable --nvram

The “shim-install” does run “grub2-install”, but on older systems it might fail to use the “–target” option. You will probably recognize from the error messages generated.

(3) unfortunately, installing shim is not enough for secure-boot. You need to also use “linuxefi” rather than “linux” in the grub configuration. The way that I handle this is to copy “/boot/grub2/grub.cfg” to “/boot/grub2/grub.altcfg”, and then I change “linux” to “linuxefi” and “initrd” to “initrdefi” in that “grub.altcfg”. I actually use “sed” in a script to do that in one step.

(4) The above steps create a small “grub.cfg” in “/EFI/boot” in the EFI partition (or in “/boot/efi” on our USB). That file sources “/boot/grub2/grub.cfg”. I edit that, so it instead sources “/boot/grub2/grub.altcfg”.

@nrickert:
I’m trying to search a tool which could work for both live distros and installation to hard drive.
I wonder what was the failure for you with openSUSE… maybe wrong menuentry settings…??

I did not investigate very far. The installer mounts, but then prompts for whether to find the rpms. And I could not come up with an answer that it likes.

My assumption is that it searches for the included repo. It appears to search in partitions and CD/DVD devices. But it does not search in mounted iso files.

7

Thanks for all your advise, mr nrickert.

I just confirmed the “linuxefi” instead of “linux” things by looking into openSUSE and Centos ISOs; browsing for the grub.cfg files inside their corresponding /boot/EFI directories.

What I still fail to understand is, why does it become different once OS is installed?
I mean, for example, on installed openSUSE I take a look at /boot/grub2/grub.cfg and it uses plain “linux” and “initrd” instead of the “efi” counterparts. Also there’s no EFI directory or similar inside /boot directory.
Are these file and directory differences part of the installation process?

8

Whether you get “linux” or “linuxefi” depends on this line in “/etc/default/grub”

GRUB_USE_LINUXEFI="true"

You can only use “linuxefi” for UEFI booting, not for legacy booting.

If you are using UEFI booting with secure-boot enabled, then you need “linuxefi”. But if secure-boot is disabled, then you can probably use “linux” rather than “linuxefi” (I have not recently tested that).

When I want to be able to boot either way (legacy booting or UEFI booting), I install for legacy booting, then add the support for UEFI booting later.

9

I think one may indeed be able to use “linux” with UEFI and secure boot disabled (take a look at the Github links in my previous post: inside folder mbusb.d there are all the grub settings for each distribution it supports, and all use “linux” while program itself works with both UEFI and BIOS)

And when replacing “linux” for “linuxefi” to get secure boot to work, is your system still able to boot in systems with only BIOS legacy? Wouldn’t “linuxefi” actually break legacy booting?

10

The question is whether the grub support for this is included in the file “grub.efi”. And I think it is excluded there. There was a recent bug report related to this. I think it was bug 1137061 (based on my sketchy notes).

And when replacing “linux” for “linuxefi” to get secure boot to work, is your system still able to boot in systems with only BIOS legacy? Wouldn’t “linuxefi” actually break legacy booting?

I don’t replace. The file “grub.cfg” is unchanged. Instead, I create “grub.altcfg” with the changes of “linux” to “linuxefi”. And I make sure that when booting uses “shim.efi”, then it will use “grub.altcfg” rather than “grub.cfg” (by editing the small “grub.cfg” in the EFI partition that points to the real grub menu file). So yes, legacy booting still works.

11

Thanks.

As final point, installing openSUSE with DVD install in UEFI mode but secure boot disabled; after this, enable secure boot and trying to boot openSUSE installation from hard disk. Think this could work, or openSUSE will have been installed without a certain package?

12

This should work. But it depends on what you mean by “secure boot disabled”.

If you only mean that it was disabled in the BIOS, then everything should work.

When installing with UEFI support, there’s a box in the boot loader settings “Enable Secure Boot Support”. If this was unchecked during install, then it might not work. You would have to enable that.

13

Ouch, never have seen that option in the “boot loader” (meaning Grub2 in this case?); as in, never have paid enough attention…

Think this option is always enabled by default on most Linux distributions, whether secure boot is enabled or not in UEFI settings, as long as installing in UEFI mode?

14

Yes, that’s enabled by default for UEFI booting.

You can also check with

efibootmgr -v

It should show the efi file that is run for booting the system. If it shows “shim.efi”, then secure-boot support is enabled. If it shows “grubx64.efi” then secure-boot support is not enabled.

15

Er, I just did a series of tests on the system, and I got more confused due to the unexpected results…

With everything default (UEFI and secure boot enabled in firmware setup), efibootmgr obviously shows “opensuse-secureboot …] shim.efi”, as you mentioned.

However,
–with secure boot disabled in firmware, still showed shim.efi
–now even enabled CSM mode in firmware to boot in legacy BIOS mode: not only openSUSE still booted (I expected it to not), but efibootmgr still shows shim.efi! Heck, in an old PC with only BIOS mode efibootmgr shows “no efi variables found on this system” (or something like that)

Am I missing something?

16

Yes, “shim.efi” still works. But if secure-boot is disabled, then it does not attempt to verify signatures. So there’s no security checking of the boot procedure. But it otherwise still works.

–now even enabled CSM mode in firmware to boot in legacy BIOS mode: not only openSUSE still booted (I expected it to not), but efibootmgr still shows shim.efi! Heck, in an old PC with only BIOS mode efibootmgr shows “no efi variables found on this system” (or something like that)

Apparently you are still booting with UEFI.

When you enable CSM, that might just mean that the BIOS will try either legacy BIOS booting or UEFI booting. It varies between different firmware implementations.

17

Consider that booting from USB stick is not really secure. Search the web for BadUSB and you will know why.

18

Sorry if that was off-topic.

19

After doing more in-depth searches, I stumbled with what looks like the most “plausible” possibility out there I could find around internet:
GitHub - aguslr/multibootusb: A collection of GRUB files and scripts that will allow you to create a pendrive capable of booting different ISO files
Agus Lopez / multibootusb · GitLab
https://mbusb.aguslr.com/

…]

I think I’ll give it a try.

And after a big while I did.
Seems to be a matter of running the makeUSB.sh script with adequate parameters; seems to basically do this anyway:
https://wiki.archlinux.org/index.php/Multiboot_USB_drive
First thing I note is, it kind of expects to be run as normal user in order to use sudo, this for saving the current normal user’s username. This could not be done with plain “su -”, though I guess one would just need to “chown -R” USB’s final content at the end, at least in the generated data partition.

@nrickert:
I tried putting the Leap 15.1 ISO inside USB’s “isos” directory and tried booting, both in UEFI and CSM enabled (legacy BIOS) modes. Of course the original openSUSE’s graphic grub screen is not there, but all of its options are presented. Tried the “Install” option and… seemed to work?
I didn’t get any error regarding missing packages or the like. Though I still would need to do the actual installation: I just made it till the last screen before installation, without apparent errors…

But,

–when installing with UEFI support, the box “Enable Secure Boot Support” during openSUSE installation, where is that? I was not able to find it…

–read your article here; however shim-install doesn’t have a “boot-directory” option, only an “efi-directory” or the like. Would I use that to install shim to the aforementioned USB? Because, yes, the USB works, but for UEFI you need to indeed disable secure boot…

20

Maybe I should try that again.

–when installing with UEFI support, the box “Enable Secure Boot Support” during openSUSE installation, where is that? I was not able to find it…

You have to click on “Booting” in the summary page during install. And the option only appears if you have selected “grub2-efi” or “Grub2 for EFI” as the bootloader to use.

–read your article here; however shim-install doesn’t have a “boot-directory” option, only an “efi-directory” or the like.

It is for EFI booting, so it knows to use the EFI partition (assumed to be mounted at “/boot/efi” unless you give a different “–efi-directory=” option. Using “–removable” tells it to put the boot code in the directory “/EFI/Boot” in the EFI partition (instead of using “/EFI/opensuse”).

Would I use that to install shim to the aforementioned USB? Because, yes, the USB works, but for UEFI you need to indeed disable secure boot…

I explained how I get it handle secure-boot in the section of that post with heading “Tweaking for secure-boot”.