Arch Linux User Repository

@Tyilo I've updated the package. Please have a try with 1.0.42-3 and see if it works normally.

@C0rn3j I think it might make sense to open an issue about this upstream, so both could be supported depending on what is available on the system.

Upstream actually have bundled mkexfatfs and mount.exfat-fuse binaries for us. But I thought, there are existing binaries in exfat-utils, so why not use them?

What I didn't anticipate is that exfatprogs provides and conflicts with exfat-utils, but is not fully compatible with exfat-utils -- missing binaries, different CLI arguments...

So let's just put everything back then -- just use the bundled binaries.

I think it might make sense to open an issue about this upstream, so both could be supported depending on what is available on the system.

@Tyilo Thanks for pointing that out!

Since exfatprogs provides exfat-utils and conflicts exfat-utils, but is in fact incompatible with exfat-utils, it would be evil for us to conflict exfatprogs. We may have to preserve the bundled mkexfatfs binary.

@Kr1ss @Tyilo What do you guys think?

update: also I noticed that exfat-utils has /usr/bin/mount.exfat-fuse but exfatprogs don't. I think mount.exfat-fuse should also be preserved too.

What a sad package exfatprogs...

I get the following "error" using exfatprogs and running ventoy -I /dev/sda:

Usage: mkfs.exfat
    -L | --volume-label=label                              Set volume label
    -c | --cluster-size=size(or suffixed by 'K' or 'M')    Specify cluster size
    -b | --boundary-align=size(or suffixed by 'K' or 'M')  Specify boundary alignment
        --pack-bitmap                                     Move bitmap into FAT segment
    -f | --full-format                                     Full format
    -V | --version                                         Show version
    -v | --verbose                                         Print debug
    -h | --help                                            Show help

Using strace I can see that mkfs.exfat is invoked as:

mkfs.exfat -n Ventoy -s 64 /dev/sda1

It seems like -n should be replaced by -L and -s should be replaced by -c for exfatprogs.

Yeah, seems sensible to me, although I can't test this at the moment - I'm on mobile.

@solstice Hi thanks for pointing that out.

I noticed that both exfat-utils and exfatprogs offers mkfs.exfat. However, only exfat-utils offers mkexfatfs, where mkfs.exfat is symlinked to mkexfatfs. So I guess a better solution would be symlink Ventoy's mkexfatfs to system /usr/bin/mkfs.exfat?

What do you guys think?

exfatprogs package provides exfat-utils so ventoy-bin package installs fine but breaks later when running ventoy:

./tool/VentoyWorker.sh: line 284: mkexfatfs : command not found

It would be fine if one can use exfatprogs instead of exfat-utils because gparted rely on exfatprogs. Otherwise, find a way to warn about the possible problem.

Thank you.

In that case, you might as well just make it a link to /opt/ventoy/CreatePersistentImg.sh.

ln -s /opt/ventoy/CreatePersistentImg.sh /usr/bin/ventoy-persistent

Thanks @FirstAirBender, the image location should now be fixed and the image will be created in the directory where you run ventoy-persistent.

Why does the ventoy-persistent script create the persistence data inside /opt/ventoy? This is contrary to what is said in the documentation. The file should be created in the current directory.

Just sudo /opt/ventoy/CreatePersistentImg.sh ... is all I needed to create the persistence file