openSUSE Installations from Ventoy (WFM)

English Open Chat
1 
> ls -gGh /run/media/<filter>/V*
/run/media/<filter>/Ventoy:
total 23G
-rwxrwxrwx 1 608M Mar 19 15:22 agama-installer-Leap.x86_64-16.0.0-Leap-Build105.1.iso
-rwxrwxrwx 1 633M Mar 21 16:58 debian-12.10.0-amd64-netinst.iso
-rwxrwxrwx 1 4.4G Mar 21 16:56 KNOPPIX_V9.1DVD-2021-01-25-EN.iso
-rwxrwxrwx 1 6.0M Mar 21 17:23 memtest86+720.iso
-rwxrwxrwx 1 500M Mar 21 17:18 memtest86-usb83.img
-rwxrwxrwx 1 2.2G Jun 23 13:30 openMandrivaLx.rolling-rome-lxqt.x86_64.iso
-rwxrwxrwx 1 4.4G Mar 21 16:48 openSUSE-Leap-15.6-DVD-x86_64-Current.iso
-rwxrwxrwx 1 4.4G May  8 00:55 openSUSE-Tumbleweed-DVD-x86_64-Snapshot20250505-Media.iso
-rwxrwxrwx 1 295M May  8 22:14 openSUSE-Tumbleweed-NET-x86_64-Snapshot20250505-Media.iso
-rwxrwxrwx 1 690M Jun 27 09:13 openSUSE-Tumbleweed-Rescue-CD-x86_64-Snapshot20250626-Media.iso
-rwxrwxrwx 1 8.5M Mar 21 16:42 seaToolsDOS223ALL.ISO

/run/media/moz/VTOYEFI:
total 6.5K
drwxr-xr-x  3  512 Feb 24 06:21 EFI
-rw-r--r--  1  829 Feb 24 06:21 ENROLL_THIS_KEY_IN_MOKMANAGER.cer
drwxr-xr-x 10 1.5K Feb 24 06:21 grub
drwxr-xr-x  2  512 Feb 24 06:21 tool
drwxr-xr-x  4 3.0K Feb 24 06:21 ventoy
#

When I bought my newest iMac in April, the USB3 stick with the content listed above is what I used to install TW on it. Using a 2018 Intel Kaby Lake only in UEFI-only mode:

  1. booting Agama installer:
    a-booting Grub2 mode loops at dracut-initqueue starting timeout scripts, then reaches emergency maintenance mode. On attempting to proceed, it went >8minuts on the /dev/mapper/live-rw start job before I rebooted. I think this is why I haven’t installed 16.0beta on this PC yet, waiting to find a method to launch Agama the same way I launch previous openSUSE installers, bypassing the annoyances of locating a suitable USB device, fetching an .iso, burning it, then booting it, instead of loading merely their initrd and linux with Grub downloaded from the NET installer section of the mirrors, which last I checked minutes ago still doesn’t exist for 16.0 as it does for 15.x: 404 for http://cdn.opensuse.org/distribution/leap/16.0/repo/oss/boot/x86_64/loader/. http://cdn.opensuse.org/distribution/leap/16.0/installer/iso/ is empty
    b-booting in normal mode just flashes an error and loops back to its menu, where selecting failsafe produces a kernel oops or trap.
    c-selecting boot installed system launches TW’s Grub, just as a normal boot without any attached USB
    d-calculating SHA256 seems to work as expected
  2. selecting Debian installer to its default selection launches the Debian installer.
  3. selecting Knoppix to its default selection boots Knoppix’s fusion desktop
  4. selecting memtest86+ iso to its default selection runs memtest86+
  5. selecting memtest86 .img runs the same way as when present on ESP and launched by UEFI
  6. selecting OpenMandriva launches its default DE, from which installer can be launched
  7. selecting Leap 15.6 DVD works exactly the same way as having burned .iso to USB, whether in Normal or Grub2 mode
  8. selecting TW DVD 20250505 works exactly the same way as having burned .iso to USB, whether in Normal or Grub2 mode
  9. selecting TW NET 20250505 works exactly the same way as having burned .iso to USB, whether in Normal or Grub2 mode
  10. selecting TW Rescue CD 20250626 works the same way as having burned .iso to USB, whether in Normal or Grub2 mode
  11. selecting seaTools .iso fails, as expected from a DOS boot attempting UEFI boot, but the Ventoy menu returns after a short wait.

Note these tests all happened today in recent minutes, and I didn’t proceed beyond initial installation screens of any of the installers before rebooting to try the next Ventoy directory file.

I have a theory that openSUSE failures using Ventoy are typically equivalent to most USB installer boot failures that follow the burning of an .iso directly to USB following official instructions: sync, or equivalent wait period, did not follow the exit from the USB burn process, thus the write to USB from write cache in RAM was incomplete prior to USB device removal or a system restart. IOW, ostensibly “safe” removal was in fact unsafe and doomed to failure in some manner.

2

What is the question?

Are you asking for people to repeat: Do not use Ventoy?

1 Like
3

No question. I just didn’t find a more appropriate place to post, as it’s all about installation. I keep seeing here Ventoy is not supported comments inconsistent with my successful Ventoy experiences, and didn’t want to go OT by posting this as a reply to the latest such appearance. Ventoy doesn’t tie up an entire USB stick for a single installation target. Buying USB sticks as small as required for typical one-only .iso sizes has long been an exercise in futility, while managing a USB stick stockpile is a dismal experience. I suppose the OP itself constitutes an answer to “How can I make Ventoy work?”

1 Like
4

@mrmazda what @hcvv says…

The problem is the binary blobs and likewise you lose image integrity for secure boot. I use ImageWriter or dd…

I have a couple of 16GB USB devices, I just reuse them… I have a USB Rescue if need to boot something and fix or use dd from there. For the likes of Aeon, I use a M.2 device as a re-install will backup your $HOME and restore.

5

Well then that becomes a footnote, not a reason to denigrate the convenience Ventoy offers to those who don’t require secure boot, or who agree with me that USB storage devices are a nuisance, and/or welcome any means to reduce their drawbacks.

6

If you would have paid attention (countless forum posts and bugreports and even external reports) and have read the warnings in the wiki with the evidence, you could have seen that ventoy added arbitrary kernel commandline parameters in the past which rendered the installed system broken. Thus the openSUSE maintainers decline support as Ventoy does unpredictable things to an installed system which can not be debugged by them. Thus the warning: Do NOT use Ventoy if you want to keep support by openSUSE.

The security issues of this unsupported tool are only the icing on the cake…
(and the findings and reactions of the developer are questionable to some point)

8

@mrmazda which is pretty ironic when many users want anonymity, security etc for their openSUSE installs, which by using invalidates all of that integrity…

10

For some of us whose computers are not mobile devices, the caves we live in makes secure boot a redundant and/or annoying interference.

Remember a concept called “choice”?

11

Not necessarily. But Ventoy continous to replace the content of an unpacked ISO to load it… Recent bugreport from 3 days ago.
Even for MS Windows…so Ventoy does not only renders openSUSE broken but also does questionable things to other OS when used.

12

@mrmazda sure, likewise here, along with firewalls, but I don’t promote that, big difference between choice and informed choice.

13

As in listing advantages along with drawbacks, instead of inferring one’s computer will explode if one does X? :slight_smile:

14

Do I consider myself lucky or what? Just recently I have installed Tumbleweed KDE desktop. Being a newcomer unaware of the Ventoy discussions, my Tumbleweed installation was with a ventoy usb. Installation was without a hitch. However because of all the chatter about Ventoy, I have switched to Imagewriter, to be ready should I become forced to re-install in the future.
My 2cents.

15

Having played with it a little bit since the update that fixed some of the reported issues we’ve seen, it seems impvoved. I have used it for multibooting live ISO images to try out various things.

Not sure I would count on it for an installation image, because if there were any potential malware or exploits in those binary blobs, that could end up causing problems with an installed system.

We all have our risk tolerances, and that’s fine.

But the way I see it, if you’re having a problem and you installed using Ventoy, then it’s perfectly valid to require testing without using it to see if the problem is reproducible. That narrows down where the issue is.

That is not unusual. I have setups that I help manage that use unsupported installations - and in order to manage those setups, I run a parallel installation that is supported as a sandbox environment; so if a problem comes up, I test to see if the supported installation method’s installation has the same issue - and if it does, then I can go to the upstream project and report the issue and get help.

But if it’s only in the installation that’s using the unsupported installation method, then I have to talk to those who built/installed the software in a way that the developers don’t support.

So, if you want to use Ventoy, just be aware that if you have a problem and it’s known that you used Ventoy to do the installation, you’re probably going to be asked to try installing without it and see if the problem can be reproduced - because if the issue is introduced through something that they do, there’s absolutely nothing that the openSUSE Project can do to address something in a binary blob provided by a third-party installation tool.

That should be a consideration for anyone looking to use this tool to install openSUSE. Do you want to be supportable, or do you want to have to reinstall without it to get help with issues that come up that are potentially related to the tool you used?

Which is going to be more (or less) convenient? Personally, I know which I’d consider to be less convenient.

Just remember that choices have consequences - so as long as you’re going in fully informed as to those consequences, as we say, “have a lot of fun”. :slight_smile:

2 Likes
16

Strangely, I used Ventoy to install my current installation of TW around the time that the issues with OpenSuse and Ventoy were coming to light.

That was almost 2 years ago and the same installation is working fine to this day.

There is likely more to the install problems than meets the eye.

17

@korahen what @hendersj said :wink: However (putting on my tinfoil hat), if going to re-install, would suggest upgrading/re-install of BIOS items as well as wiping the disk with the likes of gdisk expert mode and cleaning out the MBR as well… :nerd_face:

18

@malcolmlewis Thanks, good advice, will do.

19

Ventoy tries to implement a great concept. However use cases exhibit varying mileage. When upgrading a box this morning I ran the following:

erlangen:~ # lsscsi 
[4:0:0:0]    disk    ATA      CT2000BX500SSD1  030   /dev/sda 
[5:0:0:0]    cd/dvd  PIONEER  DVD-RW  DVR-221  1.00  /dev/sr0 
[6:0:0:0]    disk    Intenso  Ultra Line       1100  /dev/sdb 
[N:0:4:1]    disk    Samsung SSD 970 EVO Plus 2TB__1            /dev/nvme0n1
[N:1:1:1]    disk    Samsung SSD 990 EVO 2TB__1                 /dev/nvme1n1
erlangen:~ # dd if=openSUSE-Tumbleweed-NET-x86_64-Current.iso of=/dev/sdb bs=4M status=progress oflag=direct
301989888 bytes (302 MB, 288 MiB) copied, 10 s, 31.3 MB/s312475648 bytes (312 MB, 298 MiB) copied, 9.71193 s, 32.2 MB/s

74+1 records in
74+1 records out
312475648 bytes (312 MB, 298 MiB) copied, 9.73098 s, 32.1 MB/s
erlangen:~ #

The same procedure always worked in the past decade. I always got what I asked for.

20

I recently stumbled upon UNetbootin.

https://unetbootin.github.io/

https://software.opensuse.org/package/unetbootin

It’s similar to Ventoy, in that you can have mutliple ISO boot files alongside a FAT (or other filesystem) partition. You just have to manually setup the partitions though, and make sure to put the filesystem as the first, so that windows recognizes it.
Other than that it is pretty straight forward. Just select the desired partition and the image you want to put on it and let it do its magic.
One caveat I stumbled upon is, if you need to install on a legacy bios, make sure the partition table is “Master Boot Record” (MBR) or “MS-DOS” (same thing) … GPT defaults to UEFI and, even though you can install a distro that way on a legacy bios, it introduces some problems after the fact.

21

I have to question if that is even possible and we’ll try some tests to verify. In my experience, an ISO underventoy is never unpacked. It is used from the original, And once the original is booted, Ventoy is not even in memory anymore. It has no way to execute. The install is entirely under the control of the ISO that has booted.

1 Like