@malcolmlewis
Come on, let’s be logical.
If you already have a bootable USB drive with Ventoy, you won’t be reading this because you already have what you need.
And that’s where
—as well as at the top of the page—we should make it clear that you should definitely not use Ventoy.
No use to argue about this. I have been in touch with Ventoy, that is I sent them multiple emails. The only thing we got back was “Thank you for reporting”. And them over and over telling others they fixed their issues. Which they did not. If you are giving others openSUSE installs from a Ventoy USB, you do not give them openSUSE but what Ventoy makes of it. Ventoy is not some industry standard, where all involved parties agree. dd, imagewriter ( uses dd ) f.e.is.
@OrsoBruno
Live_fat_stick is a bit limited because it supports only a few distributions and seems to accept only one ISO file.
If you want to add others, you can’t: you have to overwrite the first one.
Well, at least I assume so, since I haven’t tested it.
But that’s an idea for installing OpenSUSE on another PC.
Especially since Live-fat-stick is in the repository along with the GUI !
@knurpht
Thank you for being so clear: as an ordinary user, I have no choice but to believe what is written.
Coming from you, I have no trouble believing you, and I will change the way I install other OpenSUSE systems in line with these instructions.
Here’s my personal bottom line:
Ventoy is a tool that can be useful, but the build process is so convoluted as to make it nearly impossible to verify that all of the dependencies are uncompromised.
What is becoming more important to understand is that there needs to be verifiable evidence that a software build is uncompromised, and a way to track back a build to determine if a required subcomponent has been compromised, that this has been addressed.
Ventoy has numerous dependencies, not the least of which is being built on CentOS 7.8 (according to the author’s own build instructions on github), which has been out of support since June 30, 2024. That means that it’s being built on an operating system that hasn’t had any security updates in nearly 2 years.
So there’s no way to know if that developer’s system has been compromised by any number of critical kernel CVEs that have come out in the last two years, along with updates and fixes to the software development tools themselves.
It includes a large list of precompiled binaries (all of which are open source, as far as I can tell) along with checksums. Some of those are no longer actively developed (like syslinux).
One tool included is a tool called dmsetup, which is extracted from a tool called DragonFlyBSD; that BSD variant (as far as I can tell, that’s what it is) was released in 2020, but a more recent version is available - but it would be better to have included a reference to the dmsetup tool’s source rather than “extract this binary blob from an ISO that is no longer considered current”.
This makes it hard to verify the provenance of the code that’s used, or to inspect it for potential security issues or flaws.
Now, add to that the history of Ventoy modifying the installer ‘linux’ command-line to inject its own stuff into the installation process. This violates the integrity of the openSUSE image in ways that are difficult to tell. From what I understand, this has been changed, but doing that in the first place constitutes (to me) a breach of trust that needs to be rebuild - and having an incredibly difficult to follow build process doesn’t do anything to rebuild any sort of trust.
Now, as to the statement that “openSUSE” (a) the developer isn’t specifying what version of openSUSE (or even which distribution - was Tumbleweed tested (and if so, which specific release), Leap (and which version if Leap), Kalpa, Slowroll, Aeon, …?) was tested, and (b) “test support” isn’t well defined, but I would read that to mean “it boots”. Not that it installs correctly, that it works correctly, or anything beyond that.
I seriously doubt that the developer ran 275 test suites to ensure every aspect of every ‘tested’ OS worked as if it were installed from official media. That would be a massive amount of work to do.
The fact of the matter is that we have no idea what constitutes the “Ventoy test” that is performed, because the developer does not appear to have documented that anywhere.
For me, personally, I prefer to trust a development process and chain that is easily reproducible, with code that is not extracted from ISOs, but rather is built from source that I (or others) can easily find and audit. While Ventoy says it is released under GPL v3+, the inclusion of directly used or libraries or binaries makes reproducible builds nearly impossible to validate against the ‘official’ binaries.
Like here.
No, I didn’t. I just searched for… and found some… (which I told then).
Commits on Oct 1, 2019
Well, there is also https://github.com/mbusb/multibootusb
Commits on Dec 3, 2019
I come to the conclusion that there is no large intersecting set of:
What a pitty!
@hendersj @OrsoBruno @C7NhtpnK @
Well, although I’ve been using Linux for almost 30 years, I don’t have the experience that you all seem to have: in 30 years, I haven’t made any progress (apart from learning how to use my mouse).
I’d naively thought that Ventoy was just a boot loader, not that it injected code when booting an ISO.
In fact, I thought Ventoy simply loaded the ISO into RAM (much like a live CD): modern PCs can practically load an entire distribution into memory (although not everyone has 32 GB of RAM).
Balenaetcher could be useful if it could be adapted to install a mini-OpenSUSE (or a full OpenSUSE or other distribution, for those with enough RAM) into memory, leaving it up to the user to make their choices (after installation, to opt for Tumbleweed, Leap or Slowroll).
The changes needed to Balenaetcher are:
to allow more ISOs to be stored on the USB stick
for the Balenaetcher installer to be modified to:
store this programme (BalenaEtcher) on the USB stick
from the USB stick, run BalenaEtcher to install the ISO from memory rather than onto the USB stick
This would mean there would be no code injection at boot time.
But I suspect I’m just wishful thinking here.
Here (resp. the links mentioned there…) you can find some referring infos: https://en.wikipedia.org/wiki/Ventoy#Binary_blob_controversy
Well, it seems many projects about multiboot USB sticks have stalled today, sadly. Actually, Ventoy seems to be some kind of standard: feature rich and recently supported. But with “issues” annotated, though.
Additionally to
you may look here: https://wiki.archlinux.de/title/Multiboot_USB_Stick
I have heard that some professional users (IT admins at companies) tend to do so. They favour this kind of solution. And they ease up their work by some scripts (e.g. for adding new ISOs to the boot menu). In fact, most work is up to set up a general working system.
But yes, I personally favoured GUI tools, so far, as well. — I could live with TUI tools (like mentioned above in this thread) — but they support single boot only (instead of multiboot).
And, in the end, it’s not a black/white thing:
It depends on your security model and needs. It could be sufficient. (But if you really once install openSUSE by Ventoy AND rund into trouble, don’t wonder why people are asking/complaining…)
I’ve been working with computers for over 40 years, but something that’s become a recent thing is the injection of malware into software repositories - so I’ve spent a little time looking at software supply chain issues.
Basically, the Ventoy developer is following none of the best practices for ensuring that the upstream software supply chain that they’re using hasn’t been compromised, and having a complex build process makes it very difficult to actually audit anything.
From a technical perspective, it’s an interesting tool. From a security analysis perspective, in my opinion, it’s a nightmare.
Ultimately the use of software (any software) is about whether or not you have reason to trust the developer. I want to trust developers by default, but unfortunately, the world we live in right now has too many bad actors injecting malware into repositories that makes it difficult to establish that trust.
One of the issues that results in (for me) lower trust for this particular developer is that they had made changes to the linux load line of installation media and didn’t really clearly document why they were making those changes. Injecting changes like that into the installation process creates problems (and there were several people who had issues post-installation that resulted from that).
Now that is an older version, but the trust was broken, so now I look at it and wonder what we’re not seeing.
Ultimately, a USB stick that’s large enough to hold the image as produced is very cheap, so I just prefer to use one USB stick per distribution (but I also only have Tumbleweed installed on my PC; if I need to run something else, I look to distrobox or a virtual machine, and then I can just boot from the ISO because VMware or VirtualBox will use the ISO as a device directly.)
I completely agree with all of this, so I understand the reasons for not trusting a third party.
Of all the solutions that have been suggested to me, obviously none of them satisfy me: Ventoy did everything (even if it sometimes did it poorly with OpenSUSE and perhaps with others).
I thought back to an old Spanish boot loader: GAG (which could handle 9 distros).
https://gag.sourceforge.net/
When I installed multiple distros on my PC, I would put their GRUB on their respective partitions (and not on the MBR).
GAG was installed on the MBR, and all I had to do was tell it which partitions contained the GRUB loaders for each distribution.
This allowed me to use the GRUB loader of the selected distribution and thus always have the latest kernels by default for each one without needing to update a main GRUB loader.
Wouldn’t it be possible to create a GAG (or modify this program accordingly) that would install on a USB drive partitioned to accommodate each distribution to be installed?
Of course, one partition per distribution on the USB drive.
And of course, this GAG would only be able to see what’s on the USB drive.
The GAG would be installed on the USB drive’s MBR (if such a thing exists?) or on a separate bootable partition.
It seems simple to me, but I know it isn’t.
I don’t have the knowledge to do it myself.
Maybe all it would take is changing a few lines of code to make it safe and usable by everyone and on all distributions?
You may find this interesting and useful:
https://osinside.github.io/kiwi/working_with_images/iso_to_usb_stick_grub2_boot_from_iso.html
I am curious where you heard this. In all my years I have never seen or heard sysadmins do that. Stuff like Ventoy simply adds another point of failure. Which a good sysadmin tries to avoid at all times.
Also think about stuff like configuration management: what if you configure machine randomly with the OS of choice for a given moment? A separate Salt state / Ansible playbook per machine + per user?
More:
To be fair: ~5 years ago I did use a live fat stick with a couple of live distros on it, with the goal to make a video of it. Got COVID19 and it did not happen. For such a usecase Ventoy may be nice, but that is what I use VMs + my 16 cores + 64 GB RAM for.
@hendersj
Yes, this give me an idea.
It were possible to make many menu entries for different linux.
To not do any modifications in grub if the iso’s change, i propose to rename a downloaded iso (example opensuse Tumbleweed 20260616 to opensuse Tumbleweed1 and the next time for a newer verson, copy the new opensuse with the same 1 on the stick) .
The first problem is : how to install Grub2 from the repo directly on the USB stick ?
Do you think it’s possible ?
@hendersj
I suppose that during the install of an IS, it’s the grub from the ISO that will be installed on the hard disk.
Not Ventoy — build their own plain and simple GRUB toy.
I’m doing something like that.
I have a USB drive (a hard drive in an enclosure), with Tumbleweed, Leap 15.6 and Leap 16.0.
For each of those systems, I use
GRUB_DISABLE_OS_PROBER="true"
in “/etc/default/grub” so that each grub only boots its own system.
I then use “/etc/grub.d/40_custom” to add the other systems to the boot menu.
Here’s an example:
### Entry to boot openSUSE Tumbleweed on /dev/nvme0n1p2
menuentry "configfile for openSUSE Tumbleweed on /dev/nvme0n1p2" {
set bootdir='hd1,gpt2'
search --label --set=bootdir dboot1
configfile (${bootdir})/grub2/grub.cfg
}
That way, it will use the “grub.cfg” from the system being booted, so that it will boot to the latest kernel. Yes, I did need to label the file systems for the various systems (I use a separate “/boot” in the example quoted).
No matter which of those systems controls the main boot entry, there is a menu item to boot the other systems.
At this moment, i search a way to install grub2 from the repo directly to the Usb stick.
I would have a clean Grub2 without any distro entry.
So i will create new entries manually for each new distro that will be installed as i have sayed here
It were possible to make many menu entries for different linux.
To not do any modifications in grub if the iso’s change, i propose to rename a downloaded iso (example opensuse Tumbleweed 20260616 to opensuse Tumbleweed1 and the next time for a newer verson, copy the new opensuse with the same 1 on the stick) .
The first problem is : how to install Grub2 from the repo directly on the USB stick ?
Do you think it’s possible ?
I’m not sure about “from the repo directly”. But you can install to a USB stick from a running system with grub. Just use “grub2-install”. If you run
grub2-install --help
you can see the various options that are available.