[Feature Request]: On being able to mount the ventoy partition read-write from within booted OS

[hgkamath]

Official FAQ

• I have checked the official FAQ.

Ventoy Version

1.0.62

What about latest release

Yes. I have tried the latest release, but the bug still exist.

BIOS Mode

UEFI Mode

Partition Style

GPT

Disk Capacity

2Tb

Disk Manufacturer

Seagate

Image file checksum (if applicable)

Yes.

Image file download link (if applicable)

NA

What happened?

Firstly, thank you for making such a useful utility.

This issue corresponds to the discussion forum thread.

• https://forums.ventoy.net/showthread.php?tid=130

I have read the thread on the Ventoy-forum and understood that this feature is still under consideration.

I searched the github-issues to find if this issue with feature request has been already filed. But did not find any. So filing this issue, so as to track ideas and progress of the implementation of the feature. Sorry if duplicate issue. It's okay if this issue cannot be resolved any time soon.

Feature Request: One should be able to mount the Ventoy partition read-write from within booted OS
Present status: The partition /dev/sdb1 will be reported to be busy if attempted to be mounted.

One suggestion that is given is to just reserve some space after the VTOYEFI partition and create a new data partition sdb3, for writing etc. The reason this is not optimal is because it fragments the free-space between two partitions the Ventoy partition and the data partition, and one would want all the free-space on the disk consolidated together. ex: If there is 50% usage on both partitions, it is somewhat constraining to have to decide where an image should go to. Making the size of either partition less reduces availability of space to one or the other. Ideally, one would like to keep Ventoy-bootable images and data-virtual-disk-images on the same partition. So for the purposes of this issue, let us assume that that this workaround is not the optimal.

This feature lets ventoy be useful for running live-images, and not just for installation-iso-s and repair-tool-iso-s.

• With Linux kernel-5.15 guest-OS-es have both ExFAT and NTFS3 in-kernel support. Does this obviate the need for a FUSE driver and/or make the implementation more possible?
• I also tried reading the code in https://github.com/ventoy/Ventoy/blob/master/INSTALL/grub/grub.cfg and https://github.com/ventoy/Ventoy/blob/master/GRUB2/MOD_SRC/grub-2.04/grub-core/ventoy/ventoy_cmd.c , but I must admit that it is too deep for me to get into. A documentation on the idea of how Ventoy tells the guest-image to mount and lock the file would be a good read.
• I noticed that even for images which have a boot-to-RAM feature, such as gparted the Ventoy partition is not released.
• Essentially in remounting the Ventoy partition read-write one needs to make a self contract, not to touch or modify the booted-image on the partition.
• I have noticed that for VHDX native boot feature of windows, such booted OS can modify other files in the containing filesystem, so also loopback mounted Linux live-iso images.

My intended use case on a 2Tb HDD with partitioning given below was as follows

- sdb1: 1.4 GB : Ventoy NTFS (Images and Data)
- sdb2:  32 MB : VTOYEFI (GPT type changed to 0700 hidden)
- sdb3:   1 GB : EFI (2700) 
- sdb4:   1 GB : linux boot partition, with custom grub menu to chainload to VTOYEFI
- sdb5:  80 GB : linux root OS on btrfs subvolume
- sdb6:  16 GB : linux swap
- sdb7:  16 MB : Windows reserved
- sdb7:  92 GB : Windows OS
- sdb7:   1 GB : Windows Recovery

This allows either Linux or Windows to mount and use sdb1 for storing data/images/virtual-disks/virtual-machines. Additionally, I was hoping I could make native bootable VHD/VDI/raw images and have ventoy boot them natively. Currently, if I choose to boot off an image from sdb1, using ventoy, then the entirety of data stored in sdb1 is unavailable.

[hgkamath]

IDEA01: One idea that came to my mind is as follows

1. Let Ventoy use a 3rd partition for the Ventoy image say sdb3. Let the size of this partition be say large enough for any boot image of the user, say the user decides this 64Gb, which is small wastage.
2. This special method of booting can be invoked via a dot-ventoy file or chosen by a grub menu.
3. After the image to be booted is chosen, Ventoy, will first, through some mechanism read the image from the the Ventoy-partition and sequentially-block-copy (like dd-copy) the image onto /dev/sdb3, while being careful to only write within its partition boundaries.
4. Then Ventoy does its boot mechanism from /dev/sdb3 directly, and allow /dev/sdb1 to be free for being mounted read-write.
5. In case the user wants to make persist changes that happened to image in /dev/sdb3 while booted, then after OS shutdown, the user may later remember and from an OS that and write to filesystem copy /dev/sdb3 back onto file in /dev/sdb1. It is understood that such image format has to be fixed (immutable size and block allocations) and not dynamic, as the sequence of blocks will be reserved by dmsetup in the booted-OS.

The disadvantage of this method

• sequentially-block-copying 64 Gb on a HDD to same HDD can be a 2 minute wait
• some extra user work to persist live-image changes, as grub cannot do filesystem file-write

A plus benefit is that

• the container file-system layer is no longer required and so booted this way can more performant
• the 64 gb partition, can be reformatted and used for other things when , as long as the user knows that anything stored in it is temporary and will be lost and overridden on a Ventoy boot.

An optimization to avoid the 2 minute wait on repeated boots could be

• One could keep track of what image has been already copied to /dev/sdb3, so as to not have to copy the same image over for multiple reboots.

- sdb1: 1.4 TB : Ventoy NTFS (Images and Data) 
- sdb2:  32 MB : VTOYEFI (GPT type changed to 0700 hidden)
- sdb3:  64 GB : Ventoy temporary boot part
- sdb4:   1 GB : EFI (2700)
:
: 

[hgkamath]

IDEA00: The conventional idea is

• load kernel, initramfs into memory
• pass parameters to kernel of booted-OS , so that the initramfs boot phase can
  • mount filesystem
  • mount image as loopback
  • pivot the root filesystem to that of the image
  • bind-mount the original filesystem in the new root filesystem's /mnt to be read-write

[hgkamath]

IDEA02: Another idea I had considered was

- sdb1:  64 GB : Ventoy NTFS or ExFAT
- sdb2:  32 MB : VTOYEFI (GPT type changed to 0700 hidden)
- sdb3:   1 GB : EFI (2700)
- sdb4: 1.4 TB : NTFS (Images and Data)
:
: 

When one wants to boot from a ventoy image, one manually copies desired image from sdb4, the large DATA partition, to sdb1 while booted from an OS.
The disadvantage of this are -

• One needs this extra forethought to copy an image to sdb1 beforehand in order to boot.
• Essentially losing out on Ventoy's ability to boot from a 100 images on a single volume.

Compromise-Workaround: Perhaps keep a few emergency boot repair images permanently on sdb1

[ventoy]

@hgkamath
You can try latest 1.0.64 with VTOY_LINUX_REMOUNT option.

[hgkamath]

Confirming that, I

• used ventoyplugson to set the VTOY_LINUX_REMOUNT
• was able to boot fedora-workstation-rawhide-20220113-livecd (5.17.0-0.rc0), gparted-1.3.1-1(5.10.0-8), garuda(5.15.12), alpine-linux-3.15(5.15.4), archlinux-2022.01.01(5.15.12)
• was able to mount sdc1 using both the ntfs-3g-tuxera-fuseblk-driver as well as ntfs3-paragon-internal driver (>5.15.4), able to edit file on sdc1

Looks good, just the way one expects it to work. Thank you!!

• HBCDPE (windows-pe-10.0.19041.1) booted, able to edit file on sdc1
• Rocky-Linux 8.5 (4.18.348) booted, can edit file on sdc1, after installing ntfs-3g from epel-release repo.

Q1) So what cautions / precautions does a user need to know?
apart from " do not touch the livecd file and its path; don't mess with partition"

Q2) Details on how this experimental feature works, components that it relies on?

Q3) How to know which Linux live-CDs do and don't support it? or is it transparent to the linux-kernel, (ie Linux kernel is oblivious to it)?

Q4) noticed that VTOY_LINUX_REMOUNT is a global option. Would there ever be a need for per-image option override setting for a Linux live image that needs it disabled? or can one disable it temporarily from with ventoy-grub interface.? (so as to not having the extra work to have previously used ventoyplugson to disable it for one time image boots)

Q5) Will it also work on native virtual-disk that has bootable Linux partition in it, that is mounted as read-write?

[ventoy]

Q1:
" do not touch the livecd file and its path; don't mess with partition" yes, that's I can think of right now.

Q2:
I slightly patch the linux kernel dm-mod.ko

Q3:
All ventoy supported linux LiveCD

Q4:
Currently no per-image option. But you can enable/disable it in the grub shell

set VTOY_LINUX_REMOUNT=1
unset VTOY_LINUX_REMOUNT

Q5:
No

[hgkamath]

with regard to Q5: I made a 40gb image, installed Fedora-36 beta, then ran the vtoyboot.sh script. I was able to easily and successfully do a ventoy-native-boot. But, herein I confirm your answer that the 'ventoy partition' /dev/sdc1 cannot be mounted read-write under ventoy-native-boot. An attempt to mount complains that partition is busy/dirty.

I hope this feature for ventoy-native-boot is still under consideration for development, as being able to mount the 'ventoy partition' as read-write is more useful for this case. A custom install rewritable-image, which preserves state (installed software, configuration, data), is more useful than a read-only livecd that loses all written data in the overlay tmpfs on reboot.
Microsoft fixed size VHDX-native-boot allows the native-booted Win-OS to be able to edit files in the containing filesystem. So Ventoy/Linux should also aspire to do the same.

I think I see what the difficulty is, that writing to the disk-sectors that constitute the dm-image, should not be known to the filesystem containing it. It should be do-able as image is fixed and only already allocated sectors are modified

Should I file a separate bug under vtoyboot project? [Edit] Already did so: ventoy/vtoyboot#43

[candrapersada]

is there an option 2 and 3 for VTOY_LINUX_REMOUNT in /ventoy/ventoy.json like
{ "VTOY_LINUX_REMOUNT": "2" } for ISO
{ "VTOY_LINUX_REMOUNT": "3" } for VTOY

[ventoy]

NO.

[candrapersada]

will there be a feature for VTOY_LINUX_REMOUNT only for VTOY in future (just like the { "VTOY_LINUX_REMOUNT": "3" } for VTOY)?

[ventoy]

NO.
You can add VTOY_LINUX_REMOUNT=1 in the kernel cmdline in the grub.cfg inside the VTOY file.

[candrapersada]

then why is there no information about
You can add VTOY_LINUX_REMOUNT=1 in the kernel cmdline in the grub.cfg inside the VTOY file or
Edit /etc/default/grub file, append VTOY_LINUX_REMOUNT=1 to the end of GRUB_CMDLINE_LINUX_DEFAULT option.
For example, GRUB_CMDLINE_LINUX_DEFAULT="quiet splash VTOY_LINUX_REMOUNT=1"
After that, run sudo update-grub
in the Ventoy Document?

[hgkamath]

a) See, when longpanda says, to give VTOY_LINUX_REMOUNT=1 as a grub.cfg linux kernel command line argument, longpanda has, IMHO, given 100% complete and all that is required information for someone with the prerequisite skills to act on it, do the needful and do come up with customized set of steps for their system.

b) The other details change between distributions as they are specific to various other tools, machines, bootloaders, linux distributions and operating systems.

c) The right place for new ventoy users to get help and teach each other, is via ventoy discussion forum, or their respective OS distirbution forums, and community q&a sites and community managed documentation sites.

d) It may not prudent to mess with one's boot-loader when one does not know what they are doing and also for others to give unsupported recipe instructions to someone who does not know what they are doing. For newbie users who want to install, fire, forget and use, it is best users keep it in the simplest minimal configuration on their USB flash drive, drag and drop live-isos to it, until they learn the ins and outs. The rest is for risk-takers.

e) If an user, with surety, files a bug, "I did as longpanda suggested, this is the distribution, this is what I did, but still it not working" it does convey that there is something more specific in the OS concerned, that there is some unhandled case that requires special handling in the initramfs script, or ventoy-grub or elsewhere. Such bug will be helpful.

f) How to add linux kernel argument is common self-help tech topic, that comes up in many situations and is not a ventoy-limited special topic.

g) the feature is still WORK IN PROGRESS. This particular feature has been in discussion and planning for over two years. This bug was filed just two months ago, and longpanda just made the patches very recently. This feature should still be considered EXPERIMENTAL. No-one can say yet what can go wrong without trying. The fact that he hasn't closed the bug yet, signals that longpanda has other ideas related to this bug still being worked. You never know, if the specifics given today is the way longpanda intends this feature to be used in the long term. Longpanda will perhaps update documentation when certain that things won't change.

h) Ventoy is a tool that is very lowlevel and general, and perhaps needs to be as distribution agnostic as possible. I think ventoy documentation just needs to be appropriate for people who know what they are doing when they tinker with boot-loaders. Ventoy itself may not want to be a bootloader training ground.

i) The Ventoy documentation, level should target those who know what they are doing, know they are taking risks, can fill in relevant omitted details for themselves, can assume responsibility for mistakes, and have the ability to restore/recover, just like partitioning tools, and the like.

j) If ventoy website gives too much hand holding instructions, there is the chance someone screws up their system, and can't recover themselves. It causes them to seek support apart from having potentially lost time, money, data and energy. Ventoy disclaimers apply. Sometimes, the barrier to entry might be for the good.

k) The recipe you seek is Linux distribution and tool specific. There are perhaps a 1000 linux distributions. Instructions for one distribution may mislead user of another distribution. Ventoy, as a multi-OS booting system appeals to people who want multi-boot systems involving many distributions.

l) So who is going to long term maintain the distribution-specific documentation? Maintaining those details as they become outdated is a chore in themselves. Its best done at the community associated with the distribution, who can react spontaneously to their releases.

m) I would rather that the respected developers focus their very valuable time and energy on making reliable code improvements. That is something I cannot do, and something few others can or will volunteer to do. Linux community users should step up and volunteer to do the easier tasks of creating self-help guides for their favorite distributions and not impose that on ventoy developers. Arch linux is said to have an amazing community managed wiki where you can contribute.

n) The recipe changes with time, also differing as to when distributions adopt changes. As you saw in Fedora itself, the recommended method changed after Fedora-30. There is no finality that grubby and bootloader-spec will forever be the final way to do things. Major upgrades to tools such as dracut, grub etc can potentially break things.

o) I am 100% certain, that longpanda hasn't set VENTOY_LINUX_REMOUNT to be the default, even though it is obvious that that is the more useful case, because there is good reason for not doing so right now. Indeed, this is how it is for windows native-boot. The kernel version needs to have the native file system driver for exfat and ntfs (>5.15). I think, one day the default will be inverted when longpanda is sure all distributions are ready for it.

p) When this becomes an advertised feature, and this bug is closed, if you still think documentation is inadequate at the level of users of ventoy, then you should file another documentation bug . I don't think existing bugs filed for specific reasons should be derailed for support.

[johndoe71rus]

Can you explain. Is this option for the kernel of the system that is inside the iso file? Or does it need to be added to the grub ventoy settings? which is located on a separate partition on the flash drive.
For example I want to boot ubuntu iso and access Ventoy partition