Support Ventoy persistence plugin backend (/dev/mapper/vtoy_persistent) as a MiniOS persistence target (per-ISO, no separate partition)

[marat2509]

Description

MiniOS already supports persistence via the perch mechanism and related boot parameters (perchdir, perchmode, etc.).
MiniOS also has Ventoy integration and documents two approaches:

1. Separate persistence partition (recommended): create an ext4 partition in Ventoy “Reserve Space” and label it persistence.
2. Standard Ventoy install: MiniOS creates/uses a dynamic file on the main Ventoy partition (dynfilefs mode).

What’s missing (feature request): support for Ventoy’s official “persistence plugin” (/ventoy/ventoy.json + backend image file), where Ventoy exposes the selected backend as a block device (commonly seen as vtoy_persistent). Ventoy’s plugin is designed to allow different persistence backends per ISO and even multiple backends per ISO with a pre-boot selection menu.
In practice, when the user chooses “Boot with persistence”, Ventoy presents a device/partition named vtoy_persistent.

Because Ventoy virtualizes files as block devices on Linux (device-mapper based mapping), MiniOS could treat this exactly like a “real” persistence disk.

Why this matters

Using Ventoy plugin persistence provides benefits that the current MiniOS Ventoy approaches don’t fully cover:

• Per-ISO persistence on the same Ventoy stick (keep MiniOS changes isolated from other ISOs).
• Ability to choose different persistence backends for the same ISO from Ventoy menu (e.g., “work”, “test”, “clean”).
• No need for a dedicated partition (Reserve Space) just for MiniOS persistence.
• Keeps the main Ventoy partition tidy (avoid MiniOS auto-creating its own persistence file when user already configured Ventoy plugin).

Current behavior

When booting MiniOS via Ventoy with the Ventoy persistence plugin configured:

• Ventoy exposes the chosen backend device (typically vtoy_persistent).
• MiniOS does not reliably/explicitly use that device as the perch storage target and may fallback to the documented approaches (separate persistence partition / MiniOS-created dynfilefs file), or simply not persist into the plugin backend.

Expected behavior

If MiniOS is booted in a Ventoy environment and a Ventoy plugin persistence device is present (e.g. /dev/mapper/vtoy_persistent, or by-label match), then MiniOS should:

1. Prefer that device as the persistence backend for perch (instead of creating its own dynfilefs file on the Ventoy partition).
2. Support the standard perch workflow (resume / new / ask) and perchmode where applicable.
3. Work with Ventoy’s ability to select different backends per ISO / per boot.

Steps to reproduce expected behavior

1. Install Ventoy to a USB drive.
2. Copy a MiniOS ISO onto the Ventoy partition.
3. Create a persistence backend image file (ext4) and label it persistence (or whatever MiniOS expects for “separate persistence partition” compatibility).
4. Configure Ventoy persistence plugin in /ventoy/ventoy.json, e.g.:

{
  "persistence": [
    {
      "image": "/MiniOS.iso",
      "backend": "/persistence-minios.dat"
    }
  ]
}

5. Boot with Ventoy → select MiniOS → choose “Boot with persistence”.
6. Inside MiniOS, check devices:

lsblk -f
sudo ls -l /dev/mapper | grep -i vtoy
blkid | grep -i persistence

7. Make a change (create a file in $HOME, install a package, etc.), reboot, and verify whether the change is stored in the Ventoy plugin backend.

Proposed implementation idea (high-level)

In the early boot/persistence initialization logic (where MiniOS configures perch / detects Ventoy environment):

• If Ventoy environment is detected and a persistence plugin block device exists (commonly vtoy_persistent), mount/use it as the persistence backend automatically.
• Avoid creating a separate dynfilefs file on the Ventoy partition if the plugin device is available.

This aligns with Ventoy’s plugin persistence design (“backend file per ISO”, “multiple backends”, pre-boot selection).