# Idea: Use Ventoy for ISO Booting (Alternative 3)

## Status: Parked — most radical option, evaluate after Alt 1 / Alt 2

## Problem

NETSetup's Proxmox installation path uses a 4-phase boot chain (WinPE → Void Linux PE →
GRUB+init-patching → Proxmox installer). The complexity comes from Proxmox's `/init` only
scanning whole block devices for the ISO medium, while NETSetup puts the ISO on a partition.
This forces ~930 lines of fragile init-patching code (BootISOGrub2.cs).

## Idea

Replace Void Linux PE and the entire init-patching machinery with
[Ventoy](https://www.ventoy.net) — an open-source tool (GPLv3) that boots ISOs directly from
a partition. Ventoy hooks the UEFI boot process to present ISO contents as a virtual CD-ROM
device. The Proxmox scanner finds a virtual CD-ROM → works natively, zero patching.

## Proposed USB Stick Layout

```
Partition 1: Ventoy EFI (FAT32, ~32 MB)  — Ventoy bootloader + GRUB
Partition 2: Ventoy Data (exFAT, rest)    — ISOs + WinPE WIM/VHD + NETSetup files
```

Ventoy supports booting:
- Windows PE from WIM files (tested, well-documented)
- Proxmox VE ISO directly (tested by community, confirmed working)
- Any other Linux ISO (NixOS, etc.)

## Flow

```
1. Boot USB → Ventoy menu
   ├── "Windows PE" → WinPE runs NETSetup → config, answer.toml written to target disk ESP
   └── "Proxmox VE" → Proxmox installer boots directly from ISO on USB
       → proxmox-fetch-answer finds answer.toml on SYSTEM partition (target disk)
       → auto-install proceeds
       → first-boot script runs NETSetup for VM creation
```

## What Gets Eliminated

- **Void Linux PE entirely** — no squashfs, no musl compatibility, no .NET-on-musl issues
- **BootISOGrub2.cs** (~930 lines) — all init patching, cpio overlay, GRUB manipulation
- **Stage4LinuxPE.cs** — the entire Linux PE stage
- **BootISOGrub.cs** — the old fallback approach
- **linux/ folder** in project — GRUB + Void squashfs + boot files
- **CopyLinuxLoaderFiles** in MainISO — no Linux boot files to copy
- Void squashfs maintenance, kernel upgrades, libstdc++ compatibility

## Answer.toml Delivery

Two options:

### Option A: SYSTEM partition on target disk (current approach, kept)
WinPE creates a small FAT32 partition labeled SYSTEM on the target disk with answer.toml.
Proxmox's `auto-installer-mode.toml` already has `mode = "partition"`, `partition_label = "SYSTEM"`.
After install, the SYSTEM partition is gone (installer reformats disk).

### Option B: Bake answer.toml into ISO at create-iso time
Use `proxmox-auto-install-assistant` to embed answer.toml directly into the ISO.
Per-customer ISOs: `create-iso --offline` already builds per-ticket ISOs.
Generic ISOs: not possible (answer varies per customer).

**Recommendation:** Option A for flexibility.

## Ventoy Customization

Ventoy supports a `ventoy.json` config file on the data partition:

```json
{
    "control": [
        { "VTOY_DEFAULT_SEARCH_ROOT": "/NETSetup/Images" }
    ],
    "menu_alias": [
        { "image": "/NETSetup/Images/Proxmox/proxmox.iso", "alias": "NETSetup Proxmox Installer" },
        { "image": "/WinPE/boot.wim", "alias": "NETSetup WinPE" }
    ],
    "auto_install": [
        { "image": "/NETSetup/Images/Proxmox/proxmox.iso", "template": "" }
    ]
}
```

## Risks

| Risk | Severity | Mitigation |
|------|----------|------------|
| External dependency (Ventoy) | Medium | Ventoy is widely used, actively maintained, GPLv3 |
| Ventoy WinPE boot integration | Medium | Test with current WinPE WIM; fallback to VHD |
| Ventoy update breaks boot | Low | Pin Ventoy version, test before rolling out |
| USB stick creation changes | Medium | `create-iso` would use Ventoy's CLI (`Ventoy2Disk.sh`) |
| NETSetup can't run between WinPE and Proxmox | Low | WinPE already writes everything needed |
| Customer-specific answer.toml per ISO | Low | Use SYSTEM partition approach (Option A) |

## Implementation Effort

- **create-iso changes:** Replace USB stick creation with Ventoy-based layout
- **Delete:** Stage4LinuxPE.cs, BootISOGrub2.cs, BootISOGrub.cs, linux/ folder
- **Modify:** MainWinPE.cs Linux branch — only write answer.toml + config to target disk ESP
- **Test:** Full end-to-end on physical hardware with Ventoy USB

## Why Parked

This is the nuclear option — highest reward but highest risk and effort.
Start with Alt 1 (pre-patched ISO) or Alt 2 (dd to whole disk) first.
If those work, Ventoy becomes unnecessary. If they don't, Ventoy is the fallback.