Problem? What Problem?

My distaste for Ventoy - the popular usb multiboot tool - started this year when i was working on Lufus. We wanted to add a multiboot feature, similar to ventoy, to Lufus as well and were brainstorming on various way in which we can achieve this. One of the ideas was that we can just use ventoy itself but due to it being GPL and Lufus being MIT we avoided it. Almost every multiboot tool uses GRUB anyways so there isn't really any alternative anyways.

While researching on Ventoy and how it works I came to know that Ventoy uses 'hooks' or custom configuration for EVERY SINGLE distribution it supports to enable multiboot. This is a very nasty way to program stuff - mainly because it is very tiresome and redundant for developers as they need to update the configuration in case of major updates to enable multiboot - but we can't blame the Ventoy devs at all.

The problem lies at the core of every distribution and how they implement their boot processes. On paper it might seem that they must have atleast some standard for this but in reality it is rarely followed. The UEFI standards tell where the boot firmware should be located but inside the ISO it can be anywhere the devs put it and as ventoy boots from this very ISO, it becomes a problem to boot using a universal configuration. Not to mention that some distros don't even use EFI among other techincal limitations. So the ventoy devs have to hardcode the paths in the configuration for every distro.

Okay, but how to fix this?

My first intuition to solve this and introduce a new uniform method was "Can a bootloader not just recursively look for the files it needs?". The first problem with this is that there can be multiple files of same name at different locations so how will the bootloader use the correct file? Secondly, even if the bootloader correctly identifies the firmware and boots the kernel, the kernel can not automatically know where the root filesystem is unless explicitly told. It tries to find a CD-ROM but since that won't exist, it will crash and cause a kernel panic. Lastly, there is also driver issues for different filesystem which ventoy solves by carrying its own drivers.

Okay, but how to actually fix this?

The problem is with distributions having different path structure right? So why not introduce a new standard which will implement uniformity ? Well, I am pretty sure people have tried this before and it hasn't worked. Why you ask? Here, the popular xkcd 927 will tell you:

Is there even a solution?

Well for starters, instead of creating a new standard - that is almost certain to not be followed - we can propose additions to existing standards and then implement those standards in the different distros. Turns out that there is already a specification standard which aims to achieve standardzied directory structure and format called UAPI.1 The Bootloader Specification (BLS) but it lacks the stuff needed for our purpose. As the BLS standard is for normal partition and not for ISOs, We have to add two new keys to the BLS standard file to support booting from ISOs:

1. iso_file
This key tells bootloader the path to linux and initrd relative to the ISO so the bootloader can actually look inside the iso for the kernel files instead of trying to find it in the physical disk.
2. iso_type
As different distros use different hooks to find files (dracut, casper, mkinitcpio), the distro just specify it in this key.

So the new BLS conf should look like this if we follow the example from the official UAPI.1 documentation:

      title        Fedora 19 (Rawhide Live ISO)
      sort-key     fedora
      machine-id   6a9857a393724b7a981ebb5b8495b9ea
      version      3.8.0-2.fc19.x86_64
      # New Keys
      iso_file     /ISOs/Fedora-Workstation-Live-19.iso
      iso_type     dracut
      # ---
      options      root=live:CDLABEL=FEDORA-19 quiet
      architecture x64
      linux        /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux
      initrd       /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd
      extra        /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/somedata.cred
      extra        /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/somethingelse.cred
      

So now when the bootloader runs and reads the keys it can loopback the iso file and re-map that as the root path for executing stuff. This removes the need for hardcoded paths of firmware for each and every distro (as done in tools like Ventoy) as now the distro itself tells the bootloader where to find them. It is also backwards compaitable with older bootloaders.

So... what's next?

The problem with using BLS for now is that not every distro supports the BLS standard yet. So even after the new keys are added we will have to slowly make other distros support it. Regarding adding the new keys, that in itself is painstakingly hard and time-consuming to do. I have made a thread in the official github discussion for the new keys proposal but it hasnt seen any response for almost a month at the time of this writing. This method obviously only supports linux distros and for other OS such as Windows or MacOS hardcoded configs will still be needed I assume. Regarding the Type #2 enteries Unified Kernel Images (UKIs), it will be useless for this method since it compiles the command line parameters to a binary and will require the Type #1 conf anyways.

Keep in mind that this is an experimental thought on how we can improve and unify the process. My deduction and reasoning can be wrong at times as I am not a professional system level programmer. Ventoy is a good tool right now (because it works) and I appreciate the hard work of every single developer. I am open to any feedback or advice you may have for me regarding which you can contact me on my discord or email me at mynamesplayer[at]gmail[dot]com .

Last Edited: 12:40 PM 04 June 2026