mean the vtoycow file , shouldnt ventoy create it ?
Ah, got you. No, to keep it flexible, they let all the options to you, but include a little script. I used the command
sudo bash CreatePersistentImg.sh -s 8192 -l vtoycow -c persistence.conf -o EndeavourOS.dat
to create yours in the archive file. It’s basically just a mountable ext4 image, with a persistence.conf file in it. (Keeps USB stcik simple, using files instead of multiple partitions.)
You can even have multiple persistence files per ISO (selectable via Ventoy menu), so all this gets configured in the /ventoy/ventoy.json on the stick.
For my config, I decided to
- put all ISOs into
/ISO, - all persistence files into
/persistenceon the stick.
Note: Ventoy (as of v1.1.05) cannot currently create a bootable stick from native 4K-block devices (like some SSD-like USB sticks). They have to have 512 Bytes/sector, or at least a 512e emulation. I ran into this problem lately, trying to use a 256 GB HP x911w USB Flash Drive (manufactured by PNY, product code HPFD911W-256), which is 4K native only.
OMG. You have more than 15 ISOs in that disk. What do you do with soo many ISOs? Clonezilla I understand. Win11 also I get it. But Mint, LMDE, Manjaro,ElementaryOS, Ubunutu and others? Can I please request you to one of these days write a HowTo or some blog entry for this?
Hee hee 
Things accumulate when you’re supporting friends and family—not everyone decides to use the same OS/DE… and I encourage and love the freedom of choice the Linux and FOSS ecosystem gives us.
That said, I myself am not the “hopping type”:
- I am happily “Windows-free” since about 13 years now.
- Have been happy using Linux Mint on most of my machines (except servers) for many years, but always keeping an eye on Arch in the form of Manjaro, Arcolinux, and now EndeavourOS.
- On servers, I typically used Ubuntu, nowadays slowly switching over to Debian, because Snap starts getting on my nerves.
- For a DE, I somehow always liked Cinnamon. After an excursion to KDE and others a few years back, I found Cinnamon is my choice to be most productive. Now that KDE has matured a lot over the past years, I might give it a try again.
- Same with the Arch-based distros: I like being able to keep one or two machines at the “technological forefront”, without having to reinstall LTS versions every two or so years. Naked Arch and Arcolinux (RIP & greets to Eric) I found too nerdy for me, and recently discovered EOS, which I really, really like, because it does many things just perfectly right:
- Make installation a breeze.
- Free choice of the DE you want.
- No bloat and as close to Arch as possible.
- No problems if using Pamac for newbie installations. (Thanks Manjaro for that!)
- Rolling release that very seldom breaks.
- This will go a long way!
Can you believe the Win11 on my stick has been there a few years now, and I only had the need to use it once? 
And yes, I’ll be happy to write a How-To as soon as we get this EOS Persistence thing rolling. I strongly believe there are only benefits adding that one parameter to the ISO, and my hope is that the EOS devs and ISO testers see it the same way.
Plus, I think Ventoy is a real great tool for anyone doing teaching, support, or just installs.
As it stands now, without official EOS persistence support, I’d have Ventoy to replace 5 EOS bootloader files for fully supporting syslinux and grub booting, and that feels “unclean”. After all, these might change, and besides, Ventoy (as of 1.1.05) has an artificial limit for replacing a maximum of two files only.
So everyone please test, and support my notion to add the cow_label=vtoycow to the EOS ISOs!
Interesting
Not sure if this is possible to add by default, this would only be possible if it will not interfere with the general boot in all the usecases.
May it would need to add a boot menu entry only that has the option?
I’m rather sure adding it by default wouldn’t have any negative side-effects, and I really tested a lot (yes, also bare metal). A list of the one parameter change I made is in the GitHub issue.
Since we’re effectively already using the exact same mechanism for our 10G cowspace tmpfs, there should be nil risk. Adding cow_label=vtoycow will supercede the already given cow_spacesize=10G if a persistence partition/file is found, else fall back to the specified 10G tmpfs.
Well, I think rather not. It would mean duplicating too many already existing menu options, and possible confuse users. We already know above mechanism is safe. It’s in Arch and others, many distros use it.
By my feature request, we’d just add a tried-and-tested mechanism to support persistence, which can be a real help in teaching, supporting, and installing if you’re not in the U.S. See above screenshot as an example. The system will just use a physical (permanent) medium instead of a temporary.
Besides, tools like Ventoy already ask you (before the boot menu comes up) if you want persistence or not, doubling this is not wise in my book.
I’m using my persistent EOS almost daily (mostly for testing and installing), I didn’t yet find a situation where it would fail. And we can always ask a user to boot into “the clean ISO” by simply having him/her select the normal, non-persistent option. (Which is default for most users anyway, because persistence needs setup, either using Ventoy or by adding a partition to your USB.)
Don’t trust what I’m saying. Give it a try. Play with it. Break it. Then please implement it.
Did you test using an installation media besides Ventoy? I tested just now, and after adding this parameter the ISO no longer boots to the live environment.
Steps to reproduce:
- Install
quickemu.
yay -S quickemu
- Pull down the EOS ISO.
quickget endeavouros mercury-neo-2025.03.19
- Start the VM.
quickemu --vm endeavouros-mercury-neo-2025.03.19.conf
- Press E when the boot menu appears and add
cow_label=vtoycowto the parameter line.
- Press <Enter to boot with these options.
The ISO fails to boot because a filesystem with this label cannot be found.
I assume this parameter only works for people who are using Ventoy, in which case it should not be added as a default option because we want to be able to support other installation methods.
That would indeed be an argument for not defaulting to it, thanks for your testing!
I’m positive I tested on bare metal with a USB stick containing a) the bootable ISO image, and b) a vtoycow partition. I think I also did the test with a renamed vtoycow partition (casper-rw), and it didn’t break.
Let me try this again tomorrow, and also add some VM testing. Not VirtualBox but quickemu this time—good suggestion, thanks for the detailed example!
Seems @BluishHumility found a valid point (thank you!), and I must accidentally have had a vtoycow partition available that the boot process found (when not using Ventoy). Darn. But nobody is perfect…
I can reproduce the shown problem, and have ordered a few more USB sticks for bare metal testing. Might take a few days.
Working on this, current findings:
- We might not be able to blindly add
cow_label=vtoycowas per default. - If we don’t want to have users manually fiddle with the kernel line (yukk!), we might have to follow @joekamprad’s suggestion of adding separate menu entries. But we’d have to duplicate at least
- the normal,
- the NVIDIA, and
- the fallback entry.
- If using Ventoy, this would mean selecting a persistence option twice. Maybe tolerable.
- If not using Ventoy, as before, the user would have to provide a
vtoycow-labelled partition on his/her stick that can be found by/dev/disk/by-label/vtoycow.
I’ll try to find out how other persistence-supporting Arch-based distros do it. I have seen some variant that seems to use a ${cow} variable to construct their kernel line (containing either "" or cow_label=vtoycow). So there must be a means to set this and make the kernel line either have a cow_label entry or not.
If anyone of you has deeper insights, please let me know. I still think the benefits will outweigh the work put into this! And it should of course work with and without using Ventoy.
Btw, I didn’t choose the vtoycow label because I like Ventoy (I do), but because others use this name already, and I’d like to stay in line. Debian-based typically use casper-rw, Kali & Clonezilla use persistence, Fedora and Arch use vtoycow.
1 Like
EndeavourOS_ventoy-2025.05.05-x86_64.iso
EndeavourOS_ventoy-2025.05.05-x86_64.iso.sha512sum
Have a look here to find a “beta” build including this feature
Be aware its added to all boot entries so ISO will only boot if you actually use ventoy and have the file added.
1 Like
So yes it does work but as find out already normal boot if the falg is added will not work so no way to add the flag by default would be smart if ventoy itself would add the flag on the fly in case the json exists and you choose persistence option from menu.
We can’t add 4 boot menu entries only to add the support this would cause trillion users confusing with the boot of the ISO.
the ventoy.json config must be added into a folder named ventoy on the ventoy partition (same as where you store ISO and dat file)
ventoy.json
{
"persistence": [
{
"image": "/ISO/EndeavourOS_ventoy-2025.05.05-x86_64.iso",
"backend": "/persistence/EndeavourOS.dat"
}
]
}
I could think of a more “customer friendly” way to present the setup.. could all be done with the ventoy tool instead of manually set things up..
Like an archive with the 3 folders you only need to unpack on the ventoy stick .. will be a huge archive but anyway.. a script could create that easily..
Yah, I actually use Ventoy to replace files in the original ISO (with added parameter), see the GH post. Unfortunately, Ventoy only allows to replace two files, and we have more in /loader/entries.
Here’s my ventoy.json, just disregard the other ISOs:
{
"control":[
{ "VTOY_LINUX_REMOUNT": "1" },
{ "VTOY_DEFAULT_KBD_LAYOUT": "GERMAN" },
{ "VTOY_MENU_LANGUAGE": "de_DE" },
{ "VTOY_DEFAULT_SEARCH_ROOT": "/ISO" }
],
"persistence":[
{
"image": "/ISO/xubuntu-24.04.2-desktop-amd64.iso",
"backend":[
"/persistence/xubuntu-24.04.dat"
]
},
{
"image": "/ISO/ubuntu-24.04.2-desktop-amd64.iso",
"backend":[
"/persistence/ubuntu-24.04.dat"
]
},
{
"image": "/ISO/linuxmint-22.1-cinnamon-64bit.iso",
"backend":[
"/persistence/linuxmint-22.dat"
]
},
{
"image": "/ISO/lmde-6-cinnamon-64bit.iso",
"backend":[
"/persistence/lmde-6.dat"
]
},
{
"image": "/ISO/EndeavourOS_Mercury-Neo-2025.03.19.iso",
"backend":[
"/persistence/EndeavourOS.dat"
]
},
{
"image": "/ISO/elementaryos-8.0-stable.20250314rc.iso",
"backend":[
"/persistence/elementaryos-8.dat"
]
},
{
"image": "/ISO/archlinux-2025.04.01-x86_64.iso",
"backend":[
"/persistence/archlinux.dat"
]
}
],
"conf_replace":[
{
"iso": "/ISO/EndeavourOS_Mercury-Neo-2025.03.19.iso",
"org": "/boot/syslinux/archiso_sys-linux.cfg",
"new": "/ventoy/archiso_sys-linux.cfg"
},
{
"iso": "/ISO/EndeavourOS_Mercury-Neo-2025.03.19.iso",
"org": "/loader/entries/archiso-x86_64-linux.conf",
"new": "/ventoy/archiso-x86_64-linux.conf",
"img": 1
}
]
}
Syslinux is easy, because it’s just one file for all options.
Grub has many, so I can only only use the top (normal UEFI boot).
These are the replacements I use. They work, but I hate replacing files in the boot environment, because they might change in the distro. Besides conf_replace always replaces for the given ISO, so using this loses the non-persistent original.
There must be some easier and better way.
My /ventoy/archiso_sys-linux.cfg “overlay”:
LABEL eos64
TEXT HELP
Boot the EndeavourOS install medium on BIOS.
It allows you to install EndeavourOS or perform system maintenance.
ENDTEXT
MENU LABEL EndeavourOS default (x86_64, BIOS)
LINUX /arch/boot/x86_64/vmlinuz-linux
INITRD /arch/boot/intel-ucode.img,/arch/boot/amd-ucode.img,/arch/boot/x86_64/initramfs-linux.img
APPEND archisobasedir=arch archisolabel=EOS_202503 cow_spacesize=10G cow_label=vtoycow copytoram=n nouveau.modeset=1 module_blacklist=nvidia,nvidia_modeset,nvidia_uvm,nvidia_drm,pcspkr i915.modeset=1 radeon.modeset=1 nvme_load=yes
# Nvidia propritary (Non-Free)
LABEL eos64nv
TEXT HELP
Boot the EndeavourOS install medium on Bios NVIDIA-NONFREE driver LATEST-CARDS NO-LEGACY
It allows you to install EndeavourOS or perform system maintenance.
ENDTEXT
MENU LABEL EndeavourOS NVIDIA (latest cards, x86_64, BIOS)
LINUX /arch/boot/x86_64/vmlinuz-linux
INITRD /arch/boot/intel-ucode.img,/arch/boot/amd-ucode.img,/arch/boot/x86_64/initramfs-linux.img
APPEND archisobasedir=arch archisolabel=EOS_202503 cow_spacesize=10G cow_label=vtoycow copytoram=n nouveau.modeset=0 module_blacklist=nouveau,pcspkr i915.modeset=1 radeon.modeset=1 nvme_load=yes
# Fallback (nomodeset)
LABEL eos64fb
TEXT HELP
Boot the EndeavourOS install medium on Bios in fallback mode
It allows you to install EndeavourOS or perform system maintenance.
ENDTEXT
MENU LABEL EndeavourOS Fallback (nomodeset, BIOS)
LINUX /arch/boot/x86_64/vmlinuz-linux
INITRD /arch/boot/x86_64/initramfs-linux.img
APPEND archisobasedir=arch archisolabel=EOS_202503 cow_spacesize=10G cow_label=vtoycow copytoram=n module_blacklist=nvidia,nvidia_modeset,nvidia_uvm,nvidia_drm,pcspkr nomodeset nvme_load=yes
My /ventoy/archiso-x86_64-linux.conf:
title EndeavourOS x86_64 UEFI Default
sort-key A
linux /arch/boot/x86_64/vmlinuz-linux
initrd /arch/boot/intel-ucode.img
initrd /arch/boot/amd-ucode.img
initrd /arch/boot/x86_64/initramfs-linux.img
options archisobasedir=arch archisolabel=EOS_202503 cow_spacesize=10G cow_label=vtoycow copytoram=n module_blacklist=nvidia,nvidia_modeset,nvidia_uvm,nvidia_drm,pcspkr nouveau.modeset=1 i915.modeset=1 radeon.modeset=1 nvme_load=yes
Thanks for preparing the “test balloon” ISO! Guess (without having looked yet) you’ve done more or less the same in yours.
I feature-requested more than two files over at the Ventoy GitHub, you could chime in there if you feel that worthwile:
I wonder if we can’t make the ISO boot process look for a file or environment variable like COW_OPTIONS that would be included and used in the boot kernel line, like maybe ${COW_OPTIONS}. It could be preset with the cow_spacesize=10G.
We could then maybe let Ventoy just replace the one file where this env var gets set, for instance with COW_OPTIONS='cow_label=vtoycow'.
Think that possible? In my previous tests, I couldn’t quite manage to have the menu entries expand an environment variable (always showed ${COW} literally when I was testing).
Or better yet, react on Ventoy’s selection “with/without persistence”. I noticed that whenever you select “with persistence” the same volume appears in the device mapper: /dev/mapper/vtoy_persistent.
Would just be fantastic if we could adapt the boot process to check for that volume, and—if existent—add the command line param.
I’m not reallly sure if I would need it actually, but I’ld appreciate it if you keep us updated with your findings!
1 Like
no grub in use thats systemd-boot
okay i see the usecase for you to maintain the ventoy stick on multipurpose system scenario.. for “normal joe” on the on the two computers in use may not that needed to have support for legacy Bios devices with this it could have default and Nvidia override files.
Anyway the way to go will be to create a tutorial to create this stick instead of adding anything to the ISO itself from development standpoint.
I got this correct?
read that “img”: 1 is needed to add for systemd-boot entries to overwrite if not set it will not do that
I would imagine that usage would be quite low. So, yeah, tutorial sounds more likely than trying to maintain it.
i do not think it would not be used by many we got the request for persistence on USB quiet often.
And this way it is not very complex to setup, if you got a good little friendly tutorial, and someone putting 
into maintaining it.
Me personal already know of a lot of things you can do with it, like adding timeshift, pika, and others to it, and some documents with your personal tutorials to reset backups and stuff.. may some scripts too.
2 Likes
"img": 1 (the Ventoy docs say) is needed to make it possible overlaying the /loader/entries.
Usecase as above (somewhere): Universal install stick, some settings persisted. Should work on any type of machine.
Problems:
- Ventoy only allows a max. of two files to be overwritten.
- User would need to know how to find these on the ISO, and correctly edit them.
- They can change, and lots of crazy errors happen.
- Invalidates “non-persistent” choice (if a file replace specified in Ventoy, it happens always). But we’d like to have the user be able to start an unmodified ISO (for bug reports etc.).
We’d need something that is within the ISO, doesn’t affect normal usage, and would still prepare for the “persistence situation”.
Somehow like all the Debian-based do it using their casper-rw persistence stuff—that always “just works”.
In the “Arch world”, everyone seems to assume users are happy editing the kernel line in boot menus using e or Tab and manually entering options. This of course works, but in my eyes is much too “hacky” for an “average Joe” who just wants to learn (something else!), or play around with the live ISO. And be it just to set their keyboard right.
i just tried to have a ventoy-json with the two boot menu entries overwritten and normal boot does not show nvidia entry with this but the grub2 ventoy implementation does.
No clue why… Also seems with NVIDIA i can not restore from persistence file… It always loads defaults, needs some tinkering first… Not much time at the moment as of developing real needed things…
But we will keep on playing here for sure
1 Like
Yeah, we should. Having a user-friendly way of persistence could be a godsend for non-English users, and simplify a lot of other stuff (like you said, adding few personal settings/apps).
My USB sticks from Denmark have finally arrived, now let’s hope these are not 4K-blocks native… So maybe I can play around with all that a bit more.