refine post-install and hardware GPU docs, Monitor UX and CLI styling

- rewrite the 15 post-install pages and the 3 hardware GPU pages so they reflect the current scripts (reversibility, tracked-tool counts, kernel parameters, per-tool commands, Alpine LXC propagation flow)
- migrate the legacy step-badge helper on post-install/optional and create-vm/synology to the canonical pill component, with the stepLabel key added in each locale
- fix rich-text i18n calls missing helpers across network, automated, optional, security, customization and the post-install landing pages, and escape the `<iface>` placeholder in automated so intl no longer parses it as a tag
- remove the mouse-follow blue overlay from the docs landing layout
- reposition the App-tab Edit button and stack the Search and Register controls vertically on mobile
- move the Bulk update Configure/Edit control into the section header so it behaves the same on desktop and mobile
- show a spinner during the final autoremove/autoclean pass of update-pve-safe so the cleanup step reads as active instead of silent
- restyle the shell spinner and msg_info in a distinctive purple and drop the unused msg_lang duplicate
- add a web-docs i18n build script and its CI workflow, plus tests for the pushover notification channel

web/messages/en/docs/create-vm/synology.json

@@ -1,5 +1,6 @@
 {
   "title": "Synology VM Creator Script",
+  "stepLabel": "Step",
   "intro": {
     "heading": "Introduction",
     "intro": "ProxMenux provides an automated script that creates and configures a virtual machine (VM) to install Synology DSM (DiskStation Manager) on Proxmox VE. This script simplifies the process by downloading and adding one of the available loaders to the VM boot, giving you the option between four different choices:",

web/messages/en/docs/hardware/gpu-vm-passthrough.json

@@ -45,7 +45,7 @@
     "heading": "Walking through the flow",
     "detect": {
       "title": "Detect GPUs and check IOMMU",
-      "body": "The script lists every GPU it finds. If IOMMU isn't already enabled in the running kernel cmdline, you'll get a yes/no prompt to append <code>intel_iommu=on</code> (or <code>amd_iommu=on</code>) + <code>iommu=pt</code> to the right boot file — <code>/etc/kernel/cmdline</code> on ZFS (systemd-boot) or <code>/etc/default/grub</code> on LVM/ext4. If you accept and the kernel cmdline changes, the script flags that the reboot prompt at the end will be required.",
+      "body": "The script lists every GPU it finds. If IOMMU isn't already enabled in the running kernel cmdline, you'll get a yes/no prompt to append <code>intel_iommu=on</code> (or <code>amd_iommu=on</code>) + <code>iommu=pt</code> to the right boot file. Selection is based on the bootloader: <code>/etc/kernel/cmdline</code> when the host boots via systemd-boot (detected by the presence of <code>root=ZFS=</code> in that file, the default on ProxmoxVE-installed ZFS-on-root systems), otherwise <code>/etc/default/grub</code>. If you accept and the kernel cmdline changes, the script flags that a reboot will be needed at the end.",
       "tipTitle": "Already ran post-install?",
       "tipBody": "If you previously enabled <postLink>VFIO IOMMU support</postLink> from the post-install scripts, IOMMU is already on and this step silently passes. Good.",
       "imageAlt": "List of detected GPUs with vendor and PCI address"
@@ -74,8 +74,8 @@
       "intro": "The script scans every VM config and every LXC config on the host looking for the GPU you picked. Three possible outcomes:",
       "items": [
         "<strong>GPU is free.</strong> Nothing to do, continue.",
-        "<strong>GPU is in a different VM.</strong> You're offered to remove it from that other VM before assigning it here. If you decline, the script aborts — two VMs can't share an exclusive VFIO assignment.",
-        "<strong>GPU is in an LXC (shared mode).</strong> You're offered to remove the LXC passthrough configuration (<code>lxc.cgroup2.devices.allow</code> + <code>lxc.mount.entry</code> lines). The LXC won't see the GPU anymore, but the VM will — this is the \"switch mode\" mechanic that gives this menu entry its secondary label."
+        "<strong>GPU is in a different VM.</strong> If the source VM is currently running, the script aborts — two VMs can't share an exclusive VFIO assignment, and the source VM has to be stopped first. If the source VM is stopped, you get two options: <em>Keep GPU in the source VM's config but disable Start on boot</em>, or <em>Remove the GPU lines from the source VM's config and keep Start on boot</em>. A fast-path also exists: if the GPU is already bound to <code>vfio-pci</code> and the source VM is a plain VM→VM swap, no host reconfiguration is done and no reboot is needed.",
+        "<strong>GPU is in an LXC (shared mode).</strong> You get two options on a menu: <em>Keep GPU in the LXC config but disable Start on boot</em>, or <em>Remove the GPU lines from the LXC config (<code>lxc.cgroup2.devices.allow</code> / <code>lxc.mount.entry</code>) and keep Start on boot</em>. Either way the LXC won't see the GPU after the switch, and the VM will — this is the \"switch mode\" mechanic that gives this menu entry its secondary label."
       ],
       "imageAlt": "Dialog offering to remove the GPU from an LXC before assigning it to the VM",
       "smartTitle": "Audio siblings are cleaned up smartly too",
@@ -100,10 +100,10 @@
         "<code>/etc/modules</code> — adds <code>vfio</code>, <code>vfio_iommu_type1</code>, <code>vfio_pci</code> (plus <code>vfio_virqfd</code> on kernels &lt; 6.2).",
         "<code>/etc/modprobe.d/vfio.conf</code> — for AMD / Intel, sets <code>options vfio-pci ids=&lt;vendor:device,...&gt; disable_vga=1</code> so VFIO claims the GPU early at boot. For NVIDIA the file only adds <code>softdep nvidia pre: vfio-pci</code> (plus <code>_drm</code>/<code>_modeset</code>/<code>_uvm</code>) — actual binding is per-BDF via the udev rule below. On AMD, also adds <code>softdep</code> lines forcing <code>vfio-pci</code> to load before <code>radeon</code> / <code>amdgpu</code>.",
         "<code>/etc/modprobe.d/iommu_unsafe_interrupts.conf</code> and <code>kvm.conf</code> — sensible workarounds that most Windows / macOS VMs need (<code>allow_unsafe_interrupts=1</code>, <code>ignore_msrs=1</code>).",
-        "<code>/etc/modprobe.d/blacklist.conf</code> — blacklists the open-source companion drivers (<code>nouveau</code>, <code>amdgpu</code>, <code>radeon</code>, <code>i915</code>) that would otherwise grab the GPU before VFIO. The proprietary <code>nvidia</code> module is <strong>never blacklisted</strong> — it stays available for any OTHER NVIDIA GPU you keep on the host.",
+        "<code>/etc/modprobe.d/blacklist.conf</code> — blacklists only the open-source drivers for the selected vendor (<code>nouveau</code>/<code>lbm-nouveau</code> for NVIDIA; <code>radeon</code>+<code>amdgpu</code> for AMD; <code>i915</code> for Intel), so drivers for other vendors on the same host stay loaded. The proprietary <code>nvidia</code> module is <strong>only</strong> blacklisted (via a separate <code>/etc/modprobe.d/proxmenux-nvidia-vfio-blacklist.conf</code>) once <em>every</em> NVIDIA GPU on the host has been switched to VFIO — until that point it stays loaded so any NVIDIA card you keep on the host keeps working.",
         "<code>/etc/udev/rules.d/10-proxmenux-vfio-bind.rules</code> + <code>/etc/proxmenux/vfio-bind.bdfs</code> — <strong>NVIDIA only</strong>. Per-BDF binding state. The udev rule applies <code>ATTR'{'driver_override'}'=\"vfio-pci\"</code> at the PCI ADD event for each tracked Bus:Device.Function, so only the GPU(s) you've explicitly passed go to VFIO. This is what makes multi-GPU NVIDIA work — your other NVIDIA cards keep their <code>nvidia</code> driver and stay usable on the host.",
         "<strong>AMD only.</strong> Dumps the GPU ROM from sysfs (<code>/sys/bus/pci/.../rom</code>) or the ACPI VFCT table to <code>/usr/share/kvm/vbios_&lt;card&gt;.bin</code>. The VM references it via <code>romfile=</code> so cards that misreport their own VBIOS still initialise correctly.",
-        "<strong>NVIDIA only.</strong> Stops and disables host NVIDIA services that could probe / lock the GPU at boot (<code>nvidia-persistenced</code>, <code>nvidia-powerd</code>, <code>nvidia-fabricmanager</code>). The <code>nvidia</code> module itself is left loaded so other NVIDIA GPUs on the host keep working with <code>nvidia-smi</code>.",
+        "<strong>NVIDIA only.</strong> Host NVIDIA services (<code>nvidia-persistenced</code>, <code>nvidia-powerd</code>, <code>nvidia-fabricmanager</code>) are stopped and disabled only when every NVIDIA GPU is assigned to VFIO. With a mixed host they remain active, together with the <code>nvidia</code> module, for the GPU(s) that stay native.",
         "<code>update-initramfs -u -k all</code> — only runs if any of the above actually changed."
       ]
     },

web/messages/en/docs/hardware/nvidia-host.json

@@ -1,16 +1,16 @@
 {
   "meta": {
     "title": "Install NVIDIA Drivers on the Host | ProxMenux Documentation",
-    "description": "Install and configure NVIDIA proprietary drivers on a Proxmox VE host using ProxMenux. Covers kernel compatibility, VFIO setup, persistence service, optional NVENC patch and automatic LXC propagation."
+    "description": "Install and configure NVIDIA proprietary drivers on a Proxmox VE host using ProxMenux. Covers GPU support filtering, DKMS validation, persistence service, optional NVENC patch and automatic LXC propagation."
   },
   "header": {
     "title": "Install NVIDIA Drivers on the Host",
-    "description": "Install the NVIDIA proprietary driver on a Proxmox VE host using ProxMenux. The installer handles kernel compatibility, nouveau blacklisting, VFIO configuration, persistence service and can propagate the driver to any LXC container that already has NVIDIA passthrough configured.",
+    "description": "Install the NVIDIA proprietary driver on a Proxmox VE host using ProxMenux. The installer filters maintained branches by GPU PCI ID, validates the selected release through DKMS, manages nouveau, installs the persistence service and can propagate the driver to LXC containers with NVIDIA passthrough.",
     "section": "Hardware: GPUs and Coral-TPU"
   },
   "intro": {
     "title": "What this does",
-    "body": "ProxMenux automates the whole NVIDIA driver lifecycle on the host: detects your GPU, picks a driver version that is compatible with your running kernel, blacklists <code>nouveau</code>, downloads and runs the official NVIDIA <code>.run</code> installer with DKMS, installs the <code>nvidia-persistenced</code> service and udev rules, and offers to apply the optional NVENC patch. If you already have LXC containers with NVIDIA passthrough, it can update the userspace libraries inside them so their version matches the host."
+    "body": "ProxMenux automates the whole NVIDIA driver lifecycle on the host: detects your GPU, offers maintained NVIDIA branches that list its PCI Device ID, blacklists <code>nouveau</code>, downloads and runs the official NVIDIA <code>.run</code> installer with DKMS, installs the <code>nvidia-persistenced</code> service and udev rules, and offers to apply the optional NVENC patch. The DKMS build is the final compatibility check against the running kernel. If you already have LXC containers with NVIDIA passthrough, it can update their userspace libraries to match the host."
   },
   "who": {
     "heading": "Who is this for?",
@@ -22,7 +22,7 @@
     "gpuCheck": "lspci | grep -i nvidia",
     "notVm": "The GPU <strong>is not currently assigned to a VM via VFIO passthrough</strong>. If it is, the script will refuse to install the host driver to avoid breaking the passthrough config.",
     "internet": "Internet access on the host. The installer downloads the driver from <code>download.nvidia.com</code> and, optionally, clones <code>nvidia-persistenced</code> and <code>nvidia-patch</code> from GitHub.",
-    "space": "About <strong>2 GB of free space</strong> in <code>/opt/nvidia</code> (workdir) plus the RAM used during the install. A reboot is required at the end."
+    "space": "Some free space in <code>/opt/nvidia</code> for the <code>.run</code> installer plus the RAM used during the build. When propagating to LXCs on non-Arch distros, each container needs at least 1.5 GB free; ProxMenux temporarily raises container RAM to 2 GB and restores it after. A reboot is required at the end of the host install."
   },
   "vmWarn": {
     "title": "GPU assigned to a VM? Stop here",
@@ -46,40 +46,11 @@
     },
     "version": {
       "title": "Choose the driver version",
-      "body1": "ProxMenux fetches the list of available drivers from NVIDIA and <strong>filters out versions that are not compatible with your running kernel</strong>. The <em>Latest available</em> option is almost always the right pick.",
-      "body2": "The compatibility matrix the script uses:",
-      "headerKernel": "Kernel",
-      "headerPve": "Typical PVE version",
-      "headerMin": "Minimum NVIDIA driver",
-      "rows": [
-        {
-          "kernel": "6.17+",
-          "pve": "Proxmox VE 9.x",
-          "minCode": "580.82.07",
-          "minTail": " or newer"
-        },
-        {
-          "kernel": "6.8 – 6.16",
-          "pve": "Proxmox VE 8.2+",
-          "minCode": "550.x",
-          "minTail": " or newer"
-        },
-        {
-          "kernel": "6.2 – 6.7",
-          "pve": "Proxmox VE 8.0 – 8.1",
-          "minCode": "535.x",
-          "minTail": " or newer"
-        },
-        {
-          "kernel": "5.15+",
-          "pve": "Proxmox VE 7.x (legacy)",
-          "minCode": "470.x",
-          "minTail": " or newer"
-        }
-      ],
-      "whyTitle": "Why kernel matters",
-      "whyBody": "Kernel 6.17 introduced internal API changes that break older NVIDIA drivers. If you install a driver below the minimum for your kernel, DKMS will fail to build the module and the GPU will not be available after reboot. ProxMenux filters the list so you can't pick an incompatible version by accident.",
-      "imageAlt": "Driver version selector with kernel-compatible versions, Latest available on top"
+      "body1": "ProxMenux fetches the list of available drivers from NVIDIA and narrows the picker to versions that <strong>list your GPU's PCI Device ID in the supported chips table</strong> of the corresponding branch on <code>nvidia.com</code>. Additional heuristics discard developer / beta CDN drops that would otherwise appear at the top. The first entry is labelled <em>&lt;version&gt; — Recommended</em>: it prefers the head of the branch of the driver already installed on the host (bugfix in place), otherwise the head of the current Production Branch, otherwise the highest supported numeric.",
+      "body2": "If the currently installed driver was patched via keylase (NVENC), the picker auto-narrows to versions still covered by the patch table, so applying <em>Reinstall / update</em> without losing the patch is one click.",
+      "whyTitle": "How kernel compatibility is validated",
+      "whyBody": "The version list is filtered by NVIDIA branch maintenance and GPU PCI support, not by a hard-coded kernel/driver matrix. After selection, DKMS builds the module against the running kernel. A failed build stops the installation from being treated as valid; choose another maintained branch if NVIDIA has not adapted that release to your kernel.",
+      "imageAlt": "Driver version selector with GPU-supported NVIDIA branches and the Recommended entry on top"
     },
     "uninstall": {
       "title": "Clean uninstall (only if reinstalling)",
@@ -90,8 +61,8 @@
       "body": "Behind a single confirmation, the script:",
       "items": [
         "Installs <code>pve-headers-$(uname -r)</code> (or <code>proxmox-headers-$(uname -r)</code>), <code>build-essential</code> and <code>dkms</code>.",
-        "Creates <code>/etc/modprobe.d/nouveau-blacklist.conf</code> blacklisting <code>nouveau</code>, and tries to unload it immediately.",
-        "Writes <code>/etc/modules-load.d/nvidia-vfio.conf</code> with <code>vfio</code>, <code>vfio_pci</code>, <code>nvidia</code>, <code>nvidia_uvm</code> and related modules."
+        "Creates the ProxMenux-owned <code>/etc/modprobe.d/proxmenux-nouveau-blacklist.conf</code> with <code>blacklist nouveau</code> and <code>options nouveau modeset=0</code>, records whether it added the companion line to <code>blacklist.conf</code>, and tries to unload the module immediately.",
+        "Writes <code>/etc/modules-load.d/nvidia-vfio.conf</code> with <code>nvidia</code> and <code>nvidia_uvm</code> so the modules load early at boot."
       ]
     },
     "download": {
@@ -112,7 +83,7 @@
     "propagate": {
       "title": "Optional: propagate the driver to LXC containers",
       "body1": "If the overview screen listed containers with NVIDIA passthrough, ProxMenux now offers to update the userspace libraries inside each one to match the host. Host kernel module and container userspace <strong>must be the exact same version</strong> — otherwise <code>nvidia-smi</code> inside the container will fail with a \"version mismatch\" error.",
-      "body2": "The update is distro-aware: <code>apk</code> for Alpine, <code>pacman</code> for Arch, and the same <code>.run</code> installer (with <code>--no-kernel-modules --no-dkms --no-install-compat32-libs</code>) for Debian/Ubuntu and other distros. It temporarily raises container RAM to 2 GB if lower, runs the install, then restores the original RAM setting.",
+      "body2": "The update is distro-aware. For Debian / Ubuntu and other glibc distros, the same <code>.run</code> installer (with <code>--no-kernel-modules --no-dkms --no-install-compat32-libs</code>) is pushed into the container and executed; container RAM is temporarily raised to 2 GB if lower and restored after. For <strong>Arch, Manjaro and EndeavourOS</strong> the update is a <code>pacman -Syu nvidia-utils</code> pinned to the host's driver branch. <strong>Alpine</strong> uses a different path — the <code>.run</code> is extracted on the host, only the userspace libraries are packaged as a tarball and pushed with <code>pct push</code>, then <code>gcompat</code> + <code>binutils</code> shims are installed via <code>apk</code> and SONAME symlinks are recreated with <code>readelf</code> so the glibc-linked libraries load correctly on musl.",
       "imageAlt": "Prompt listing LXCs with NVIDIA passthrough and current driver version, with Yes/No to update them all"
     },
     "reboot": {
@@ -122,33 +93,32 @@
   },
   "reinstallUninstall": {
     "heading": "Reinstall or uninstall",
-    "intro": "When the installer detects that a NVIDIA driver is already loaded (<code>nvidia-smi</code> returns a version), it doesn't silently re-install on top. Instead it shows an action menu so you can choose what to do.",
+    "intro": "When the installer detects that the <code>nvidia</code> kernel module is currently loaded and <code>nvidia-smi</code> returns a version, it doesn't silently re-install on top. Instead it shows an action menu so you can choose what to do. (Binaries present on disk but the module not loaded do not count as installed — the module has to be live.)",
     "imageAlt": "NVIDIA action menu offered when a driver is already installed — two choices: Reinstall / update driver, or Uninstall the NVIDIA driver completely",
     "imageCaption": "The action menu only appears when an NVIDIA driver is currently active on the host.",
     "reinstallHeading": "Reinstall / update",
-    "reinstallBody": "Continues with the normal install flow but, before downloading anything, runs a clean removal of the current driver (apt purge + DKMS entries dropped + leftover modules unloaded). This is the safe path to apply a newer driver version, switch branches when the kernel demands it, or recover from a half-broken state. The LXC propagation and NVENC patch prompts re-run at the end.",
+    "reinstallBody": "Continues with the normal install flow but, before downloading anything, runs a clean removal of the current driver (apt purge + DKMS entries dropped + leftover modules unloaded). This is the safe path to apply a newer same-branch version, choose another maintained branch when needed, or recover from a half-broken state. The LXC propagation and NVENC patch prompts re-run at the end.",
     "uninstallHeading": "Uninstall — what gets removed",
     "uninstallIntro": "Confirms with a yes/no dialog first. Then performs a full, idempotent rollback:",
     "uninstallItems": [
-      "Stops and disables <code>nvidia-persistenced</code>, unloads the kernel modules (<code>nvidia_uvm</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia</code>) — any LXC container with NVIDIA passthrough will be cleanly cut off.",
-      "Runs <code>apt purge</code> on every NVIDIA package, removes the DKMS source tree and the <code>/opt/nvidia</code> .run installer cache.",
-      "Reverts the nouveau blacklist (<code>/etc/modprobe.d/nouveau-blacklist.conf</code>) and the modules-load config (<code>/etc/modules-load.d/nvidia-vfio.conf</code>) so nouveau can come back if you want generic graphics again.",
-      "Removes the udev rules (<code>/etc/udev/rules.d/70-nvidia.rules</code>) and the NVENC patch state file (if the keylase patch was applied earlier).",
-      "Rebuilds <code>initramfs</code> for all kernels and prompts for a reboot to finalise (the nouveau unblacklist only takes effect after restart)."
+      "Runs <code>nvidia-uninstall --silent</code> first (the counterpart to the <code>.run</code> installer), then stops and disables <code>nvidia-persistenced</code> and <code>nvidia-powerd</code>, and unloads the kernel modules (<code>nvidia_uvm</code>, <code>nvidia_drm</code>, <code>nvidia_modeset</code>, <code>nvidia</code>) — any LXC container with NVIDIA passthrough will be cleanly cut off.",
+      "Runs <code>apt purge</code> on <code>nvidia-*</code>, <code>libnvidia-*</code>, <code>cuda-*</code> and <code>libcudnn*</code>, removes the DKMS source tree and the <code>/opt/nvidia</code> .run installer cache.",
+      "Removes the modules-load config (<code>/etc/modules-load.d/nvidia-vfio.conf</code>) and the nouveau blacklist entries owned by ProxMenux. Legacy two-line ProxMenux blacklist files are migrated and removed too; modified or unrelated administrator files are preserved.",
+      "Removes the udev rules (<code>/etc/udev/rules.d/70-nvidia.rules</code>) and clears the NVENC patch state (a field in the ProxMenux managed-installs registry, set to <em>removed</em> — no separate file to delete).",
+      "Rebuilds <code>initramfs</code> for all kernels, runs <code>proxmox-boot-tool refresh</code> on systemd-boot hosts, and prompts for a reboot to finalise."
     ],
     "lxcWarnTitle": "LXC containers with NVIDIA passthrough",
     "lxcWarnBody": "Removing the host driver invalidates the device paths and CUDA libraries mapped into any LXC with NVIDIA passthrough. Plan the operation during a maintenance window if Frigate / Plex / Jellyfin / Ollama (or anything else) depends on it."
   },
   "updates": {
     "heading": "Update notifications",
-    "body": "The installed NVIDIA driver is tracked in ProxMenux's managed-installs registry. On startup and every 24h the Monitor checks the upstream listing at <code>download.nvidia.com/XFree86/Linux-x86_64/</code> against the version <code>nvidia-smi</code> reports, and fires a notification when a newer compatible version is available.",
-    "kindsHeading": "Two kinds of update message",
+    "body": "The installed NVIDIA driver is tracked in ProxMenux's managed-installs registry. On startup and every 24h the Monitor checks the upstream listing at <code>download.nvidia.com/XFree86/Linux-x86_64/</code> against the version <code>nvidia-smi</code> reports, and notifies only when a newer maintenance release exists in the installed branch.",
+    "kindsHeading": "Update message",
     "kindsItems": [
-      "<strong>Same-branch patch.</strong> A newer maintenance release in your current driver branch (e.g. installed 580.65.06 → available 580.105.08). Bug fixes and security patches without changing branch.",
-      "<strong>Branch upgrade required by kernel.</strong> If the host is on a kernel that no longer supports your current branch (e.g. you upgraded the host kernel to 6.17 while still on driver 570.x), the message says so explicitly and recommends the kernel's minimum compatible branch — same matrix the installer uses to filter the version menu."
+      "<strong>Same-branch maintenance.</strong> A newer release in your current driver branch (e.g. installed 580.65.06 → available 580.105.08). The Monitor does not infer cross-branch kernel compatibility."
     ],
     "antiTitle": "Anti-cascade by design",
-    "antiBody": "One notification per distinct upstream version, never on every 24h scan. The branch-upgrade message in particular only fires once you actually need to switch — until then the same-branch tracker stays muted.",
+    "antiBody": "One notification per distinct upstream version, never on every 24h scan. If no newer release exists in the installed branch, the tracker stays quiet.",
     "applyTitle": "Applying the update",
     "applyBody": "The Monitor doesn't auto-apply driver updates — reinstalling the NVIDIA driver always needs a reboot. Open the same installer entry described above, pick <strong>Reinstall / update</strong>, and the new version is downloaded, the DKMS module rebuilt against the running kernel, and the reboot prompted at the end."
   },
@@ -161,7 +131,7 @@
   "troubleshoot": {
     "heading": "Troubleshooting",
     "smiFailTitle": "`nvidia-smi` says 'NVIDIA-SMI has failed'",
-    "smiFailBody": "Almost always a <strong>nouveau</strong> still loaded or a <strong>kernel header mismatch</strong>. After reboot, run <code>lsmod | grep nouveau</code> — if it returns anything, the blacklist didn't take effect (check <code>/etc/modprobe.d/nouveau-blacklist.conf</code> exists and rebuild initramfs with <code>update-initramfs -u -k all</code>, then reboot). If nouveau is gone, check <code>dmesg | grep -i nvidia</code> — DKMS build errors usually mean your kernel headers don't match the running kernel; reinstall them with <code>apt install --reinstall pve-headers-$(uname -r)</code>.",
+    "smiFailBody": "Almost always a <strong>nouveau</strong> still loaded or a <strong>kernel header mismatch</strong>. After reboot, run <code>lsmod | grep nouveau</code> — if it returns anything, check <code>/etc/modprobe.d/proxmenux-nouveau-blacklist.conf</code>, rebuild initramfs with <code>update-initramfs -u -k all</code>, and reboot. If nouveau is gone, check <code>dmesg | grep -i nvidia</code> — DKMS build errors usually mean the headers do not match the running kernel.",
     "lxcMissTitle": "LXC container can't see the GPU after host update",
     "lxcMissBody": "The container's userspace libraries are stuck at the previous driver version. Either re-run the NVIDIA installer and accept the LXC propagation prompt, or install the same driver version manually inside the container with <code>--no-kernel-modules</code>.",
     "logTitle": "Check the install log",

web/messages/en/docs/hardware/switch-gpu-mode.json

@@ -49,7 +49,7 @@
   "prereqs": {
     "title": "Before you start",
     "assigned": "<strong>A GPU already assigned</strong> — either in a VM via VFIO or attached to at least one LXC. If you haven't assigned it yet, start from Add GPU to VM / LXC instead.",
-    "iommu": "<strong>IOMMU enabled on the host</strong> — only strictly required when switching <em>to</em> VM mode, but worth having on either way. The script warns if the kernel param is missing.",
+    "iommu": "<strong>IOMMU enabled on the host</strong> — only strictly required when switching <em>to</em> VM mode, but worth having on either way. If the kernel param is missing the script auto-adds <code>intel_iommu=on iommu=pt</code> or <code>amd_iommu=on</code> to the boot command line (via <code>proxmox-boot-tool refresh</code> on systemd-boot or <code>update-grub</code> on GRUB) and includes it in the reboot prompt at the end.",
     "iommuCheck": "dmesg | grep -i 'IOMMU enabled' | head -1",
     "reboot": "<strong>Be OK with a reboot.</strong> Switching GPU bindings at the kernel level means the host regenerates initramfs and you reboot to apply. The script prompts at the end.",
     "knowList": "<strong>Know which VMs / LXCs are using the GPU.</strong> The script will find them and ask what to do with each, but it's faster if you already know the list."
@@ -110,7 +110,7 @@
     },
     "apply": {
       "title": "Apply host + workload changes",
-      "body": "Once you confirm, the script writes the host-side changes — <code>vfio.conf</code>, blacklist, modules, and (for NVIDIA) the per-BDF udev rule at <code>/etc/udev/rules.d/10-proxmenux-vfio-bind.rules</code> plus the BDF state at <code>/etc/proxmenux/vfio-bind.bdfs</code>. It also applies the chosen conflict policy to each affected VM/LXC. If the host config actually changed, it runs <code>update-initramfs -u -k all</code> — otherwise it skips that step."
+      "body": "Once you confirm, the script writes the host-side changes — <code>vfio.conf</code>, blacklist, modules, and (for NVIDIA) the per-BDF udev rule at <code>/etc/udev/rules.d/10-proxmenux-vfio-bind.rules</code> plus the BDF state at <code>/etc/proxmenux/vfio-bind.bdfs</code>. It also applies the chosen conflict policy to each affected VM/LXC. If the host config actually changed, it runs <code>update-initramfs -u -k all</code> followed by <code>proxmox-boot-tool refresh</code>; otherwise both are skipped."
     },
     "reboot": {
       "title": "Reboot",

web/messages/en/docs/introduction.json

@@ -107,7 +107,7 @@
       },
       {
         "title": "Notifications",
-        "description": "Telegram, Discord, Email, Gotify and Apprise (multi-channel) — with deduplication, cooldown, burst aggregation, quiet hours and a complete history.",
+        "description": "Telegram, Discord, Email, Gotify, Pushover and Apprise (multi-channel) — with deduplication, cooldown, burst aggregation, quiet hours and a complete history.",
         "icon": "Bell",
         "href": "/docs/monitor/notifications"
       },

web/messages/en/docs/monitor/architecture.json

@@ -254,8 +254,8 @@
     "items": [
       "<strong>Watchers</strong> push events: <code>JournalWatcher</code> tails the system journal, <code>TaskWatcher</code> polls the Proxmox task list, <code>ProxmoxHookWatcher</code> reacts to backup / replication / snapshot hooks, and <code>PollingCollector</code> handles slow data sources.",
       "<strong>Templates</strong> turn an event into a (title, body) pair. The same template can run through the configured AI provider (OpenAI / Anthropic / Gemini / Groq / Ollama / OpenRouter) to produce a plain-language rewrite; both versions are stored in <code>notification_history</code>.",
-      "<strong>Channels</strong> deliver messages: Telegram, Discord, Email, Gotify and Apprise (multi-channel). Each is implemented in <code>notification_channels.py</code> behind the same <code>create_channel()</code> / <code>send()</code> interface, so adding a new channel is a single class.",
-      "<strong>Encryption.</strong> Sensitive settings (<code>telegram.token</code>, <code>discord.webhook_url</code>, <code>ai_api_key_*</code>, <code>email.password</code>) are XOR-encrypted with the key in <code>.notification_key</code> before being written to the DB. Plaintext never touches disk."
+      "<strong>Channels</strong> deliver messages: Telegram, Discord, Email, Gotify, Pushover and Apprise (multi-channel). Each is implemented in <code>notification_channels.py</code> behind the same <code>create_channel()</code> / <code>send()</code> interface, so adding a new channel is a single class.",
+      "<strong>Encryption.</strong> Sensitive settings (<code>telegram.bot_token</code>, <code>discord.webhook_url</code>, <code>pushover.user_key</code>, <code>pushover.api_token</code>, <code>ai_api_key_*</code>, <code>email.password</code>) are encrypted with the key in <code>.notification_key</code> before being written to the DB and are masked in the interface."
     ],
     "linksFooter": "Per-event toggles, channel overrides and AI configuration are surfaced in <notifLink>Settings → Notifications</notifLink> and <aiLink>Settings → AI Assistant</aiLink>."
   },

web/messages/en/docs/monitor/dashboard/vms-lxcs-updates.json

@@ -25,6 +25,7 @@
   "mechanisms": {
     "heading": "How an update method is selected",
     "lead": "The integrated Proxmox VE Helper-Scripts path follows the official <helper>update-apps mechanism</helper>. Other install types use the matching package, Docker or custom path.",
+    "officialReference": "Official reference: the <helper>Proxmox VE Helper-Scripts update-apps documentation</helper> covers interactive and unattended modes, backups, dry runs, temporary build resources, logs and exit codes.",
     "colSource": "Source",
     "colAction": "Displayed action",
     "colNotes": "What runs",

web/messages/en/docs/monitor/index.json

@@ -105,7 +105,7 @@
     "body1": "Inside the dashboard, the <strong>Health Monitor</strong> runs continuously in the background and produces a structured stream of events: high CPU temperature, disk SMART warnings, ZFS pool degradation, OOM kills, VM/CT failures, security incidents, and so on. Each event has a category, a severity (INFO / WARNING / CRITICAL) and a stable <code>error_key</code> so duplicates collapse instead of flooding the screen.",
     "feedsIntro": "Events feed three things at the same time:",
     "feedsHealth": "The <strong>Health Monitor view</strong> in the dashboard (active + dismissed lists).",
-    "feedsChannels": "The <strong>notification engine</strong> — Telegram, Discord, Email, Gotify and Apprise (multi-channel). Each channel is configured independently and per-event categories can be silenced.",
+    "feedsChannels": "The <strong>notification engine</strong> — Telegram, Discord, Email, Gotify, Pushover and Apprise (multi-channel). Each channel is configured independently and per-event categories can be silenced.",
     "feedsAI": "The optional <strong>AI assistant</strong> — when enabled, the configured provider (OpenAI, Anthropic, Gemini, Groq, Ollama or OpenRouter) explains incoming events in plain language and, if enabled in the AI settings, proposes next steps.",
     "suppressionTitle": "Suppression instead of mute-all",
     "suppressionBody": "Each category has its own <em>Suppression Duration</em>: once you dismiss an alert, the same alert is silenced for that window (default 24 hours, configurable per category up to permanent). Real escalations — e.g. CPU temperature crossing the critical threshold — always re-trigger regardless of suppression."

web/messages/en/docs/monitor/notifications.json

@@ -1,15 +1,15 @@
 {
   "meta": {
-    "title": "Proxmox Notifications — Telegram, Discord, Email, Gotify, Apprise | ProxMenux Monitor",
-    "description": "Send Proxmox VE notifications to Telegram, Discord, Email, Gotify and ~80 extra services via Apprise. ProxMenux Monitor turns events from the Health Monitor, the journal watcher and the Proxmox VE webhook into rich messages with deduplication, cooldown, burst aggregation, an optional AI rewrite and a complete history.",
-    "ogTitle": "Proxmox Notifications — Telegram, Discord, Email, Gotify, Apprise",
-    "ogDescription": "Send Proxmox VE alerts to Telegram, Discord, Email, Gotify and ~80 extra services via Apprise — with deduplication, cooldown, burst aggregation and an optional AI rewrite.",
+    "title": "Proxmox Notifications — Telegram, Discord, Email, Gotify, Pushover, Apprise | ProxMenux Monitor",
+    "description": "Send Proxmox VE notifications to Telegram, Discord, Email, Gotify, Pushover and ~80 extra services via Apprise. ProxMenux Monitor turns events from the Health Monitor, the journal watcher and the Proxmox VE webhook into rich messages with deduplication, cooldown, burst aggregation, an optional AI rewrite and a complete history.",
+    "ogTitle": "Proxmox Notifications — Telegram, Discord, Email, Gotify, Pushover, Apprise",
+    "ogDescription": "Send Proxmox VE alerts to Telegram, Discord, Email, Gotify, Pushover and ~80 extra services via Apprise — with deduplication, cooldown, burst aggregation and an optional AI rewrite.",
     "twitterTitle": "Proxmox Notifications | ProxMenux Monitor",
-    "twitterDescription": "Send Proxmox VE alerts to Telegram, Discord, Email, Gotify and ~80 extra services via Apprise."
+    "twitterDescription": "Send Proxmox VE alerts to Telegram, Discord, Email, Gotify, Pushover and ~80 extra services via Apprise."
   },
   "header": {
     "title": "Notifications",
-    "description": "The fan-out engine that takes events from every collector inside the Monitor and delivers them to Telegram, Discord, Email, Gotify and ~80 extra services via Apprise — with deduplication, cooldown, burst aggregation, per-event and per-channel toggles, an optional AI rewriter, and a queryable history.",
+    "description": "The fan-out engine that takes events from every collector inside the Monitor and delivers them to Telegram, Discord, Email, Gotify, Pushover and ~80 extra services via Apprise — with deduplication, cooldown, burst aggregation, per-event and per-channel toggles, an optional AI rewriter, and a queryable history.",
     "section": "ProxMenux Monitor"
   },
   "intro": {
@@ -29,7 +29,7 @@
       "aiLabel": "AI rewrite (opt.)",
       "aiDetail": "OpenAI / Anthropic\nGemini / Groq\nOpenRouter / Ollama\n(off by default)",
       "channelsLabel": "Channels",
-      "channelsDetail": "Telegram\nDiscord\nEmail (SMTP)\nGotify\nApprise (~80 services)"
+      "channelsDetail": "Telegram\nDiscord\nEmail (SMTP)\nGotify\nPushover\nApprise (~80 services)"
     }
   },
   "enabling": {
@@ -43,8 +43,8 @@
       "Registers a Proxmox VE webhook target in <code>/etc/pve/notifications.cfg</code> pointing at <code>POST http://127.0.0.1:8008/api/notifications/webhook</code>. From this moment on, anything Proxmox VE emits on its own (HA, replication, vzdump from the GUI) flows into the same pipeline as the Monitor's own events. See <pvelink>PVE webhook integration</pvelink> below for the full mechanics.",
       "Starts the dispatch background thread. The thread polls the event queue and walks every event through the pipeline diagrammed above."
     ],
-    "activeAlt": "Notifications card after enabling — Active badge, channel tabs (Telegram, Gotify, Discord, Email), Display Name field and Advanced AI Enhancement collapsible section",
-    "activeCaption": "Active state — channel tabs at the top (Telegram / Gotify / Discord / Email), the Display Name field, the per-channel category list, and the collapsible <em>Advanced: AI Enhancement</em> section."
+    "activeAlt": "Notifications card after enabling — Active badge, channel tabs, Display Name field and Advanced AI Enhancement collapsible section",
+    "activeCaption": "Active state — channel tabs at the top (Telegram / Gotify / Discord / Email / Pushover / Apprise), the Display Name field, the per-channel category list, and the collapsible <em>Advanced: AI Enhancement</em> section."
   },
   "sources": {
     "heading": "Event sources",
@@ -89,9 +89,9 @@
   },
   "channels": {
     "heading": "Channel walkthroughs",
-    "intro": "Five channels are currently supported: Telegram, Discord, Gotify, Email (SMTP) and Apprise. The first four are native — each one has its own tab inside the Notifications panel with a <em>+ setup guide</em> link opening an in-app modal. Apprise is a generic hub that adds ~80 additional services (ntfy, Matrix, Pushover, Slack, Teams, Pushbullet, AWS SNS, Mattermost…) through a single URL field. They are all documented step by step below.",
+    "intro": "Six channels are currently supported: Telegram, Discord, Gotify, Email (SMTP), Pushover and Apprise. The first five are native integrations with their own configuration fields. Apprise is a generic hub that adds around 80 additional services (ntfy, Matrix, Slack, Teams, Pushbullet, AWS SNS, Mattermost…) through a single URL field. They are all documented step by step below.",
     "credsTitle": "Where credentials live",
-    "credsBody": "Tokens, webhook URLs and SMTP passwords are stored locally in the Monitor's SQLite database under <code>/usr/local/share/proxmenux/</code>. They never leave the host except to reach their respective services. A backup of that directory is enough to recover the configured channels."
+    "credsBody": "Tokens, keys, webhook URLs and SMTP passwords are stored locally in the Monitor's SQLite database under <code>/usr/local/share/proxmenux/</code>. Sensitive values are protected and masked in the interface. They never leave the host except to reach their respective services. A backup of that directory is enough to recover the configured channels."
   },
   "telegram": {
     "heading": "Telegram",
@@ -176,12 +176,28 @@
     "relayTitle": "Self-hosted SMTP relay",
     "relayBody": "If you run your own SMTP relay (Postfix, msmtp, etc.) on the LAN, point the Monitor at it and skip the app-password dance entirely. The relay handles auth upstream and the Monitor sends in cleartext on a trusted network."
   },
+  "pushover": {
+    "heading": "Pushover",
+    "intro": "Pushover is a mobile push service with official apps for iOS, Android and desktop browsers. The dedicated ProxMenux channel talks directly to the <a>Pushover API</a>, so no Apprise URL is required.",
+    "stepsTitle": "Setup",
+    "steps": [
+      "Create a <a>Pushover account</a>, install the official app on the devices that should receive alerts and sign in.",
+      "Copy the <em>User Key</em> shown on your Pushover dashboard. A group key can be used instead when several people or devices must receive the same alert.",
+      "Open <a>Create an Application/API Token</a>, create an application named <em>ProxMenux</em> and copy its 30-character API token.",
+      "In <em>Settings → Notifications → Pushover</em>, paste the user or group key and the application API token. The device and sound fields are optional.",
+      "Save the settings and press <em>Send test</em>. The Pushover app should receive the message immediately."
+    ],
+    "priorityTitle": "Priority mapping",
+    "priorityBody": "Normal ProxMenux messages use Pushover priority 0. When <strong>High priority for critical alerts</strong> is enabled, CRITICAL events use priority 1 so they stand out and bypass the user's Pushover quiet hours. ProxMenux does not use emergency priority 2, which would require repeated notifications and an acknowledgement callback.",
+    "secretTitle": "Protect both values",
+    "secretBody": "The user or group key and the application API token both authorize message delivery. ProxMenux stores them as protected notification secrets and masks them in the interface; do not publish either value in screenshots or support logs."
+  },
   "apprise": {
     "heading": "Apprise (generic hub for ~80 services)",
-    "intro": "Apprise is an open-source notification library that speaks the protocol of around 80 different services through a single URL format. Adding it as one more channel inside the Monitor means you can deliver alerts to services that don't have a dedicated tab — ntfy, Matrix, Pushover, Slack, Microsoft Teams, Mattermost, Pushbullet, AWS SNS, Pushsafer, Rocket.Chat, Signal API and many others — without ProxMenux having to implement each integration separately.",
-    "listIntro": "The full list of supported services and the exact URL format for each one lives in the official Apprise wiki:",
+    "intro": "Apprise is an open-source notification library that speaks the protocol of around 80 different services through a single URL format. Adding it as one more channel inside the Monitor means you can deliver alerts to services that don't have a dedicated tab — ntfy, Matrix, Slack, Microsoft Teams, Mattermost, Pushbullet, AWS SNS, Pushsafer, Rocket.Chat, Signal API and many others — without ProxMenux having to implement each integration separately. Pushover can also be reached through Apprise, although its dedicated tab is simpler for a single Pushover destination.",
+    "listIntro": "The full list of supported services and the exact URL format for each one is available in the official Apprise documentation:",
     "listItems": [
-      "<a>github.com/caronc/apprise/wiki</a> — full index of supported services.",
+      "<a>Apprise service documentation</a> — full index of supported services.",
       "<a>URL basics</a> — how Apprise URLs are structured."
     ],
     "stepsTitle": "Steps",

web/messages/en/docs/post-install/automated.json

@@ -1,13 +1,13 @@
 {
   "meta": {
     "title": "Automated Post-Install Script | ProxMenux Documentation",
-    "description": "The ProxMenux Automated post-install script applies a curated set of 13 safe, hardware-aware optimizations to a fresh Proxmox VE host with zero prompts. Every change is registered for later reversal via Uninstall Optimizations.",
+    "description": "The ProxMenux Automated post-install script applies a curated set of 14 safe, hardware-aware optimizations to a fresh Proxmox VE host with zero prompts. Reversible configuration changes are registered for later restoration.",
     "ogTitle": "Automated Post-Install Script | ProxMenux Documentation",
-    "ogDescription": "13 curated optimizations applied to a fresh Proxmox VE host with zero prompts. Hardware-aware (SSD/NVMe auto-detect) and fully reversible."
+    "ogDescription": "14 curated optimizations applied to a fresh Proxmox VE host with zero prompts. Hardware-aware, with reversible configuration changes tracked."
   },
   "header": {
     "title": "Automated Post-Install Script",
-    "description": "One click, zero prompts — ProxMenux applies a curated set of 13 safe optimizations that almost every Proxmox host benefits from. Every change is registered in the tools JSON so you can undo any of them later from Uninstall Optimizations.",
+    "description": "One click, zero prompts — ProxMenux applies a curated set of 14 safe optimizations that almost every Proxmox host benefits from. Reversible configuration changes are registered for Uninstall Optimizations; package upgrades are not described as reversible.",
     "section": "Post-Install · Automated"
   },
   "intro": {
@@ -55,7 +55,7 @@
     },
     {
       "tool": "Memory tuning",
-      "what": "Sets vm.swappiness=10, balanced dirty ratios, vm.overcommit_memory=1, vm.max_map_count=262144 and compaction proactiveness when supported.",
+      "what": "Sets vm.swappiness=10, balanced dirty ratios, vm.max_map_count=262144 and compaction proactiveness when supported. The kernel's memory-overcommit policy is left at the Proxmox default.",
       "category": "System",
       "categorySlug": "system"
     },
@@ -103,7 +103,7 @@
     },
     {
       "tool": "Persistent interface names",
-      "what": "Writes one /etc/systemd/network/10-proxmenux-<iface>.link per physical NIC (each starting with a 'Managed by ProxMenux' header) that pins the MAC to the current name, so eth0 / enp… names stay stable across reboots and new NIC additions.",
+      "what": "Writes one <code>/etc/systemd/network/10-proxmenux-&lt;iface&gt;.link</code> per physical NIC (each starting with a 'Managed by ProxMenux' header) that pins the MAC to the current name, so <code>eth0</code> / <code>enp…</code> names stay stable across reboots and new NIC additions.",
       "category": "Network",
       "categorySlug": "network"
     }

web/messages/en/docs/post-install/basic-settings.json

@@ -9,7 +9,7 @@
   },
   "intro": {
     "title": "What this category covers",
-    "body": "Four foundational options you typically want on any fresh Proxmox host: switch to the free community repositories and run a full system upgrade, auto-configure the timezone and NTP sync, strip APT language downloads to save bandwidth and disk, and pick from a list of 25 common system utilities."
+    "body": "Five foundational options you typically want on any fresh Proxmox host: switch to the free community repositories, run a full system upgrade, auto-configure the timezone and NTP sync, strip APT language downloads to save bandwidth and disk, and pick from a list of 25 common system utilities."
   },
   "upgrade": {
     "heading": "Update and upgrade system",
@@ -45,7 +45,7 @@
     "shortTitle": "In short",
     "shortBody": "The option runs the exact <code>apt update && apt full-upgrade -y</code> Proxmox recommends, wraps it with the repo hygiene and post-upgrade cleanup that the official guide also tells you to do, and prompts for the reboot at the end. See <link>Proxmox System Update</link> — the same updater is also available as a standalone utility in the main menu, with the full process diagram.",
     "subTitle": "Don't apply to a subscribed host",
-    "subBody": "If you actually have a Proxmox subscription and want to keep using the enterprise repositories, skip this option. Re-running it would disable the enterprise repo and route you to the community channel. You can restore enterprise repos from the Uninstall menu if you change your mind later.",
+    "subBody": "If you actually have a Proxmox subscription and want to keep using the enterprise repositories, skip this option. Running it disables the enterprise repository and routes the host to the community channel. The package upgrade and repository rewrite are not presented as reversible in Uninstall Optimizations; restore your repository configuration deliberately if you need to change channels later.",
     "safetyTitle": "Post-update safety check",
     "safetyBody": "After the upgrade, the script checks for disks with stale PV (Physical Volume) metadata — an edge case that can happen when a VM with disk passthrough scribbles LVM headers onto a raw disk. If anything suspicious is found you'll see a warning suggesting <code>pvs</code> to inspect. No action is taken automatically."
   },
@@ -209,8 +209,8 @@
       }
     ],
     "actionTitle": "A few of them in action",
-    "noBulkTitle": "No bulk uninstall for utilities",
-    "noBulkBody": "The Uninstall Optimizations menu does <strong>not</strong> track which utilities you installed — only whether the \"apt languages\", \"time sync\" and \"apt upgrade\" options were applied. To remove a specific utility later, uninstall it by hand:"
+    "noBulkTitle": "Only ProxMenux-installed utilities are removed",
+    "noBulkBody": "ProxMenux records only the selected utility packages that were not already installed before this action. Uninstall Optimizations can purge those packages later, while utilities that were already present on the host are left untouched. The general APT system upgrade is intentionally not tracked as reversible because upgraded packages have no safe atomic rollback."
   },
   "related": {
     "heading": "Related",

web/messages/en/docs/post-install/customizable.json

@@ -1,22 +1,22 @@
 {
   "meta": {
     "title": "Customizable Post-Install Script | ProxMenux Documentation",
-    "description": "Cherry-pick exactly which optimizations to apply to a Proxmox VE host with ProxMenux. 10 categories, ~30 individual tools, checklist UI. Includes everything the Automated script does, plus opt-in features (IOMMU, Fastfetch, Figurine, Ceph, HA, AMD fixes…).",
+    "description": "Cherry-pick exactly which optimizations to apply to a Proxmox VE host with ProxMenux. 10 categories, ~35 individual tools, checklist UI. Includes everything the Automated script does, plus opt-in features (IOMMU, Fastfetch, Figurine, Ceph, HA, AMD fixes…).",
     "ogTitle": "Customizable Post-Install Script | ProxMenux Documentation",
-    "ogDescription": "10 categories, ~30 individual optimizations. Pick exactly what you want on a Proxmox VE host. Fully reversible."
+    "ogDescription": "10 categories, ~35 individual optimizations. Pick exactly what you want on a Proxmox VE host. Reversible changes are tracked."
   },
   "header": {
     "title": "Customizable Post-Install Script",
-    "description": "Cherry-pick exactly which optimizations to apply to a Proxmox VE host. ProxMenux groups ~30 individual tools into 10 categories, each with its own checklist dialog. Same engine as Automated, but with full control over what gets applied.",
+    "description": "Cherry-pick exactly which optimizations to apply to a Proxmox VE host. ProxMenux groups ~35 individual tools into 10 categories, each with its own checklist dialog. Same engine as Automated, but with full control over what gets applied.",
     "section": "Post-Install · Customizable"
   },
   "intro": {
     "title": "When to pick Customizable",
-    "body": "Choose this path when you already know which tweaks you want on the host — or which you definitely do not want. The script presents a checklist per category so you can pre-select, deselect or mix-and-match optimizations. Every item can be applied again later (it is idempotent) or reverted from <link>Uninstall Optimizations</link>."
+    "body": "Choose this path when you already know which tweaks you want on the host — or which you definitely do not want. The script presents a checklist per category so you can pre-select, deselect or mix-and-match optimizations. Items can be applied again later, and reversible configuration changes are tracked for <link>Uninstall Optimizations</link>. Package upgrades are not presented as reversible."
   },
   "compare": {
     "heading": "How it compares to Automated",
-    "body": "Customizable is a superset of the <link>Automated script</link>. It covers the same 13 baseline optimizations plus a long list of opt-in ones that Automated intentionally skips — things that are useful only on specific hardware (AMD fixes), specific hosting (OVH RTM), or specific workloads (IOMMU/VFIO, Ceph repo, High Availability, Fastfetch, Figurine, ZFS ARC tuning, pigz, ZFS auto-snapshot, vzdump speed limits, Open vSwitch, TCP BBR…)."
+    "body": "Customizable is a superset of the <link>Automated script</link>. It covers the same 14 baseline optimizations plus a long list of opt-in ones that Automated intentionally skips — things that are useful only on specific hardware (AMD fixes), specific hosting (OVH RTM), or specific workloads (IOMMU/VFIO, Ceph repo, High Availability, Fastfetch, Figurine, ZFS ARC tuning, pigz, ZFS auto-snapshot, vzdump speed limits, Open vSwitch, TCP BBR…)."
   },
   "categoriesSection": {
     "heading": "The 10 categories",
@@ -37,11 +37,11 @@
     },
     {
       "name": "Network",
-      "description": "Harden and tune the host's network stack. Forces APT over IPv4, applies sysctl hardening + TCP buffer tuning, offers Open vSwitch and BBR, and pins persistent interface names by MAC."
+      "description": "Harden and tune the host's network stack. Forces APT over IPv4, applies sysctl hardening + TCP buffer tuning, offers Open vSwitch, TCP BBR + TCP Fast Open, and pins persistent interface names by MAC."
     },
     {
       "name": "Storage",
-      "description": "Set up Proxmox's common storage subsystems: ZFS ARC sizing, ZFS auto-snapshot, and vzdump speed limits to avoid saturating the disk during backups."
+      "description": "Set up Proxmox's common storage subsystems: ZFS ARC sizing, ZFS auto-snapshot, ZFS autotrim for SSD/NVMe pools, and vzdump speed limits to avoid saturating the disk during backups."
     },
     {
       "name": "Security",
@@ -61,7 +61,7 @@
     },
     {
       "name": "Optional",
-      "description": "Niche pieces not every host needs: AMD CPU fixes, Fastfetch banner, Figurine 3D hostname, Ceph repository, High Availability services and Log2RAM to reduce SSD wear."
+      "description": "Niche pieces not every host needs: AMD CPU fixes, Fastfetch banner, Figurine 3D hostname, PVE Appliance Manager index refresh, Ceph repository, High Availability services and Log2RAM to reduce SSD wear."
     }
   ],
   "mixTip": {

web/messages/en/docs/post-install/customization.json

@@ -5,7 +5,7 @@
   },
   "header": {
     "title": "Post-Install: Customization",
-    "description": "Cosmetic and quality-of-life tweaks for the Proxmox host. None of them change functional behaviour — they just make the shell nicer to use and hide the subscription nag in the web UI. All three are tracked and reversible from the Uninstall menu.",
+    "description": "Cosmetic and quality-of-life tweaks for the Proxmox host. They make the shell nicer to use and hide the subscription nag in the web UI. Bashrc, MOTD and the subscription banner are tracked and reversible from the Uninstall menu.",
     "section": "Settings post-install Proxmox"
   },
   "intro": {
@@ -24,7 +24,7 @@
     "heading": "Set up custom MOTD banner",
     "intro": "Prepends <em>\"This system is optimised by: ProxMenux\"</em> to <code>/etc/motd</code>, the message shown after a successful SSH login (above the shell prompt, before any <code>update-motd</code> scripts run). Harmless and purely informational — useful as a quick visual confirmation that ProxMenux has been applied on this host.",
     "writesTitle": "What ProxMenux writes",
-    "writesOutro": "Original <code>/etc/motd</code> is backed up to <code>/etc/motd.bak</code> on first apply. The operation is idempotent: if the marker line is already present, nothing is added."
+    "writesOutro": "On first apply, ProxMenux records whether <code>/etc/motd</code> existed and stores its original contents under <code>/usr/local/share/proxmenux</code>. The operation is idempotent: if the marker line is already present, nothing is added. Older installations with an existing <code>/etc/motd.bak</code> are migrated to the same reversible state."
   },
   "banner": {
     "heading": "Remove subscription banner",
@@ -43,8 +43,8 @@
   "verify": {
     "heading": "Verification",
     "intro": "After applying all three:",
-    "reversibleTitle": "All three are reversible",
-    "reversibleBody": "<link>Uninstall Optimizations</link> restores <code>/root/.bashrc</code> and <code>/etc/motd</code> from their <code>.bak</code> backups, and either restores the patched UI files from the backup directory or reinstalls <code>pve-manager</code>, <code>proxmox-widget-toolkit</code>, <code>libjs-extjs</code> and <code>libpve-http-server-perl</code> with <code>--force-confnew</code> to bring the web UI back to vanilla."
+    "reversibleTitle": "All three customization changes are tracked",
+    "reversibleBody": "<link>Uninstall Optimizations</link> restores <code>/root/.bashrc</code>, returns MOTD to its exact pre-ProxMenux contents (or removes the file if it did not previously exist), and restores the patched UI files from backup or reinstalls the affected Proxmox packages when necessary."
   },
   "related": {
     "heading": "Related",

web/messages/en/docs/post-install/index.json

@@ -1,7 +1,7 @@
 {
   "meta": {
     "title": "Proxmox VE Post-Install Script — Automated and Customizable | ProxMenux",
-    "description": "Overview of the ProxMenux Post-Install scripts for Proxmox VE. Run the Automated script for sane defaults with zero prompts, the Customizable script to pick exactly what you want across 10 categories (system, virtualization, network, storage, security, performance, optional), or fully reverse any change with the Uninstall Optimizations option.",
+    "description": "Overview of the ProxMenux Post-Install scripts for Proxmox VE. Run the Automated script for sane defaults with zero prompts, the Customizable script to pick exactly what you want across 10 categories, or restore supported reversible changes with Uninstall Optimizations.",
     "ogTitle": "Proxmox VE Post-Install Script — Automated and Customizable",
     "ogDescription": "Apply common Proxmox VE post-install optimizations across 10 categories — automated or à la carte, with reversible options.",
     "twitterTitle": "Proxmox VE Post-Install Script | ProxMenux",
@@ -9,26 +9,26 @@
   },
   "header": {
     "title": "Post-Install Scripts",
-    "description": "Configure a fresh Proxmox VE host with ProxMenux's post-install optimizations. Three paths: run everything automatically, cherry-pick what you want, or reverse any change. All changes are tracked.",
+    "description": "Configure a fresh Proxmox VE host with ProxMenux's post-install optimizations. Apply the baseline automatically, choose individual options, update installed functions or restore supported reversible changes. Package upgrades are not presented as reversible.",
     "section": "Settings post-install Proxmox"
   },
   "intro": {
     "title": "What this menu is for",
-    "body": "Right after installing Proxmox VE, there are dozens of small changes that make the host faster and easier to maintain — free repositories, sane journald limits, sensible TCP buffers, SSD-friendly log storage, bashrc niceties, and more. ProxMenux automates all of them, tracks what it changed, and lets you revert."
+    "body": "Right after installing Proxmox VE, there are dozens of small changes that make the host faster and easier to maintain — free repositories, sane journald limits, sensible TCP buffers, SSD-friendly log storage, bashrc niceties, and more. ProxMenux automates them and tracks the supported reversible configuration changes."
   },
   "openingMenu": {
     "heading": "Opening the menu",
     "body": "From ProxMenux's main menu, select <strong>Settings post-install Proxmox</strong>. You will see this:",
-    "imageAlt": "Post-Installation Scripts menu with 3 ProxMenux options (Automated / Customizable / Uninstall) followed by the Community Scripts section"
+    "imageAlt": "Post-Installation Scripts menu — Automated, Customizable, the conditional Apply Available Updates (only when updates are pending), and Uninstall, followed by the Community Scripts section"
   },
   "threeWays": {
-    "heading": "Three ways to apply optimizations",
-    "body": "The three ProxMenux entries share the same underlying code and the same registry of installed tools — they just give you different levels of control. Pick the one that matches how much you want to decide."
+    "heading": "Four ways to apply optimizations",
+    "body": "The four ProxMenux entries share the same underlying code and the same registry of installed tools — they just give you different levels of control. The <em>Apply Available Updates</em> entry only shows when at least one installed optimization has a newer version on disk than what is registered; on a freshly applied host it stays hidden."
   },
   "routes": [
     {
       "title": "Automated",
-      "description": "A curated set of 13 safe, always-useful optimizations applied in sequence with zero prompts. Good default for most users.",
+      "description": "A curated set of 14 safe, always-useful optimizations applied in sequence with zero prompts. Good default for most users.",
       "bullets": [
         "Free repos + system upgrade",
         "Memory, kernel, network tuning",
@@ -39,7 +39,7 @@
     },
     {
       "title": "Customizable",
-      "description": "~30 individual optimizations across 10 categories. You pick exactly which ones to apply. Same engine as Automated, but with full control.",
+      "description": "~35 individual optimizations across 10 categories. You pick exactly which ones to apply. Same engine as Automated, but with full control.",
       "bullets": [
         "Checklist UI per category",
         "Includes everything Automated does, plus opt-in items (IOMMU, Fastfetch, Figurine, Ceph, HA, AMD fixes…)",
@@ -57,10 +57,10 @@
     },
     {
       "title": "Uninstall Optimizations",
-      "description": "Every change made by either path is tracked in a JSON registry, and every optimization has a reverse function. Pick what to revert, and the host goes back.",
+      "description": "Supported reversible changes are tracked in a JSON registry and paired with a restoration function. Actions without a safe rollback, such as a full package upgrade, are intentionally excluded.",
       "bullets": [
         "Detects previously applied optimizations automatically",
-        "Reversal restores original configs from backup files",
+        "Reversal picks the right path for each item — restores from a .bak backup where one was made, deletes the sysctl.d snippet where nothing needed backing up, or reinstalls the vanilla package with --force-confnew (e.g. subscription banner)",
         "Reboot prompt if needed (VFIO, persistent names, etc.)"
       ]
     }

web/messages/en/docs/post-install/monitoring.json

@@ -25,13 +25,11 @@
     "remoteTitle": "Remote script piped to bash",
     "remoteBody": "The installation runs <code>wget -qO - https://…apply.sh | bash</code>. If the OVH mirror is ever compromised, the script executes as root on your host. Before enabling this option, decide whether you trust OVH's mirror chain more than the monitoring you gain. For most home-lab or non-OVH users this option should simply stay off.",
     "noOpTitle": "Only enable if the host is actually at OVH",
-    "noOpBody": "The option is a no-op on non-OVH servers, so ticking it on a home-lab Proxmox doesn't break anything. But there is a cosmetic bug today: even on non-OVH servers the script prints <em>\"Server belongs to OVH\"</em> at the end, which can be misleading. See the troubleshooting note below.",
+    "noOpBody": "The option is a no-op on non-OVH servers, so ticking it on a home-lab Proxmox doesn't break anything. On a non-OVH host the script prints <em>\"Not an OVH server, skipping RTM installation\"</em> and exits cleanly; no packages are installed.",
     "runsTitle": "What ProxMenux runs",
     "verifyTitle": "Verification",
     "verifyBody": "On a real OVH host, after a reboot you should see the <a>RTM dashboard</a> in your OVH Manager populated with live data for the host. On the Proxmox side, the RTM collector is a systemd service — check it directly:",
     "troubleTitle": "Troubleshooting",
-    "spuriousTitle": "\"Server belongs to OVH\" but I'm not on OVH",
-    "spuriousBody": "This is a known cosmetic quirk in the current script: the success message fires outside the OVH-detected conditional, so it prints on every run. If the RTM install did <em>not</em> actually happen (check <code>systemctl status ovh-rtm</code> — it will not exist), the message is spurious and can be ignored. Nothing was installed on your host.",
     "revertTitle": "Not reversible from the Uninstall menu",
     "revertBody": "There is no dedicated uninstall entry for RTM. On a real OVH host, remove the packages manually with <code>apt purge ovh-*</code> and delete any puppet manifests under <code>/etc/puppet/</code> that RTM installed. On a non-OVH host, nothing was ever installed, so there's nothing to revert."
   },

web/messages/en/docs/post-install/network.json

@@ -34,7 +34,7 @@
       },
       {
         "area": "Routing safety",
-        "settings": "<code>accept_redirects=0</code>, <code>accept_source_route=0</code>, <code>secure_redirects=0</code>, <code>send_redirects=0</code>"
+        "settings": "<code>accept_redirects=0</code>, <code>accept_source_route=0</code>, <code>secure_redirects=0</code>, <code>send_redirects=0</code>, <code>log_martians=0</code>"
       },
       {
         "area": "Reverse path filter",
@@ -55,7 +55,7 @@
     ],
     "sourceOutro": "It also adds <code>source /etc/network/interfaces.d/*</code> to <code>/etc/network/interfaces</code> if not already present — standard practice so you can drop modular interface snippets without editing the main file.",
     "fwbrTitle": "Automatic tuning of virtual firewall bridges",
-    "fwbrBody": "Alongside the sysctl profile, ProxMenux installs a helper at <code>/usr/local/sbin/proxmenux-fwbr-tune</code> that applies <code>rp_filter=0</code> and <code>log_martians=0</code> to the <code>fwbr*</code> / <code>fwln*</code> / <code>fwpr*</code> / <code>tap*</code> interfaces Proxmox creates around VMs and containers. The helper is invoked by the <code>proxmenux-fwbr-tune.service</code> one-shot unit at boot, and by the <code>/etc/udev/rules.d/99-proxmenux-fwbr-tune.rules</code> rule on every <code>net add</code> event matching those prefixes — covering interfaces that Proxmox recreates on VM start/stop, reboot and live migration.",
+    "fwbrBody": "Alongside the sysctl profile, ProxMenux installs a helper at <code>/usr/local/sbin/proxmenux-fwbr-tune</code> that applies <code>rp_filter=0</code> and <code>log_martians=0</code> to the <code>fwbr*</code> / <code>fwln*</code> / <code>fwpr*</code> / <code>tap*</code> interfaces Proxmox creates around VMs and containers. The helper is invoked by the <code>proxmenux-fwbr-tune.service</code> one-shot unit at boot, and by the <code>/etc/udev/rules.d/99-zz-proxmenux-fwbr-tune.rules</code> rule on every <code>net add</code> event matching those prefixes — covering interfaces that Proxmox recreates on VM start/stop, reboot and live migration. The helper also runs immediately after install to sweep interfaces already present.",
     "rpFilterTitle": "Why rp_filter=2 (loose) instead of 1 (strict)",
     "rpFilterBody": "Strict reverse-path filtering drops packets whose source would be routed out a <em>different</em> interface. That's the right default on a client machine, but breaks badly on a Proxmox host where VM traffic often arrives on a bridge and leaves on an uplink with asymmetric routes. <code>rp_filter=2</code> (loose) only drops packets with truly unroutable sources. It's a pragmatic trade-off — slight reduction in local-IP-spoof detection in exchange for not breaking your VM network."
   },
@@ -64,8 +64,8 @@
     "intro": "Installs <code>openvswitch-switch</code> + <code>openvswitch-common</code>. These packages add OVS as a bridge implementation alternative to the standard Linux bridges that Proxmox uses by default. The install alone doesn't change any networking — existing <code>vmbrX</code> bridges keep working. OVS becomes available in the Proxmox UI when you <em>create</em> a new bridge and pick it from the type dropdown.",
     "tipTitle": "When OVS makes sense",
     "tipBody": "Consider OVS if you need <strong>VLAN trunking with non-contiguous VLAN IDs</strong>, <strong>LACP with LLDP on specific modes</strong>, <strong>fine-grained flow programming</strong> (OpenFlow), or interoperation with SDN controllers. For a home lab with a couple of VLANs and a single LACP uplink, standard Linux bridges + <code>vmbrX.VID</code> are simpler and perfectly fine.",
-    "revertTitle": "Not reversible from the Uninstall menu",
-    "revertBody": "Installing OVS is not tracked in Uninstall Optimizations. If you decide you don't want it, remove it manually — but only after migrating any bridges back to Linux bridges first:"
+    "revertTitle": "Reversible from the Uninstall menu",
+    "revertBody": "OVS is tracked. <link>Uninstall Optimizations</link> runs <code>apt purge</code> on <code>openvswitch-switch</code> and <code>openvswitch-common</code>. Migrate any OVS bridges back to Linux bridges <em>before</em> uninstalling, otherwise the VMs on those bridges lose networking on next boot. Manual equivalent:"
   },
   "bbr": {
     "heading": "Enable TCP BBR + TCP Fast Open",
@@ -73,8 +73,8 @@
     "verifyTitle": "Verification",
     "impactTitle": "Impact is workload-dependent",
     "impactBody": "BBR shines on high-latency or lossy links (cross-continent replication, VPN tunnels, mobile clients). On a LAN between two machines on the same switch, the difference is often within noise. TFO helps short, repeated HTTP connections the most.",
-    "revertTitle": "Not reversible from the Uninstall menu",
-    "revertBody": "BBR/TFO aren't tracked. To revert, remove the two sysctl files and reload:"
+    "revertTitle": "Reversible from the Uninstall menu",
+    "revertBody": "BBR/TFO are tracked. <link>Uninstall Optimizations</link> removes the two sysctl files (<code>/etc/sysctl.d/99-tcp-bbr.conf</code> and <code>99-tcp-fastopen.conf</code>) and reloads sysctl so the kernel returns to <code>cubic</code> and <code>tcp_fastopen=1</code>. Manual equivalent:"
   },
   "names": {
     "heading": "Interface Names (persistent)",

web/messages/en/docs/post-install/optional.json

@@ -9,6 +9,7 @@
   "title": "Optional Settings",
   "intro": "The <strong>Optional Settings</strong> category provides additional features and optimizations that you can choose to apply to your Proxmox VE installation. These settings are not essential but can enhance your system's capabilities in specific scenarios.",
   "available": "Available Optional Features",
+  "stepLabel": "Step",
   "ceph": {
     "title": "Add Latest Ceph Support",
     "intro": "This option installs the latest Ceph storage system support for Proxmox VE. Ceph is a distributed storage system that provides high performance, reliability, and scalability.",
@@ -28,9 +29,8 @@
     "doesIntro": "What it does:",
     "doesItems": [
       "Detects if an AMD EPYC or Ryzen CPU is present",
-      "Applies kernel parameter 'idle=nomwait' to prevent random crashes",
-      "Configures KVM to ignore certain MSRs (Model Specific Registers) for better Windows guest compatibility",
-      "Installs the latest Proxmox VE kernel"
+      "Applies kernel parameter 'idle=nomwait' to prevent random crashes (via /etc/kernel/cmdline on systemd-boot hosts, or /etc/default/grub on GRUB hosts — with a .bak of the original)",
+      "Configures KVM to ignore certain MSRs (Model Specific Registers) for better Windows guest compatibility"
     ],
     "howUse": "How to use: These fixes are applied automatically and require a system reboot to take effect.",
     "automates": "This adjustment automates the following commands:"
@@ -47,21 +47,16 @@
     "howUse": "How to use: After enabling these services, you can configure HA groups and resources in the Proxmox VE web interface.",
     "automates": "This adjustment automates the following commands:"
   },
-  "testing": {
-    "title": "Enable Proxmox Testing Repository",
-    "intro": "This option enables the Proxmox testing repository, allowing access to the latest, potentially unstable versions of Proxmox VE packages.",
+  "pveam": {
+    "title": "Update Proxmox VE Appliance Manager",
+    "intro": "Refreshes the local index of container templates that <code>pveam</code> exposes in the Proxmox UI, so the list of available appliances is up to date the next time you create an LXC.",
     "doesIntro": "What it does:",
     "doesItems": [
-      "Adds the Proxmox testing repository to the system's package sources",
-      "Creates a new file in /etc/apt/sources.list.d/ for the testing repository",
-      "Updates the package lists to include packages from the new repository"
+      "Runs <code>pveam update</code> against the Proxmox mirrors to fetch the current appliance catalogue",
+      "Populates the appliance list shown by the web UI when creating a container"
     ],
-    "howUse": "How to use: After enabling this repository, you can update and upgrade your system to get the latest testing versions of Proxmox VE packages. Use with caution as these versions may be unstable.",
-    "manualIntro": "To manually add the Proxmox testing repository, you can use these commands:",
-    "noteLabel": "Note:",
-    "noteBody": "$(lsb_release -cs) automatically detects your Proxmox VE version codename (e.g., bullseye).",
-    "warnLabel": "Warning:",
-    "warnBody": "Enabling the testing repository may lead to system instability. It's recommended for testing environments only."
+    "howUse": "How to use: run it once when the appliance list in the UI feels stale, or after switching mirrors. It does not download the templates themselves — only the catalogue index.",
+    "automates": "This adjustment automates the following command:"
   },
   "fastfetch": {
     "title": "Install and Configure Fastfetch",

web/messages/en/docs/post-install/performance.json

@@ -25,8 +25,8 @@
     ],
     "replacesTitle": "This replaces a system binary",
     "replacesBody": "Replacing <code>/bin/gzip</code> with a wrapper is unusual. It is safe (the wrapper produces gzip-compatible output), but worth knowing: scripts that hardcode paths, run inside restrictive chroots, or verify binary hashes may behave differently. The original binary is preserved as <code>/bin/gzip.original</code> so you can always swap it back.",
-    "revertTitle": "Not reversible from the Uninstall menu",
-    "revertBody": "This optimization is applied by Customizable, but <strong>does not currently have a matching entry in the Uninstall Optimizations menu</strong>. To revert it by hand, restore the original gzip and clear the wrapper:",
+    "revertTitle": "Reversible from the Uninstall menu",
+    "revertBody": "This optimization is tracked. <link>Uninstall Optimizations</link> restores <code>/bin/gzip.original</code> back into place, removes the <code>pigzwrapper</code>, reverts the two lines added to <code>/etc/vzdump.conf</code>, and runs <code>apt purge pigz</code>. Manual equivalent:",
     "verifyTitle": "Verification",
     "verifyBody": "After applying, <code>gzip --version</code> should mention pigz. A quick benchmark also shows the speed difference on a multi-core host:",
     "whenTitle": "When this matters most",

web/messages/en/docs/post-install/security.json

@@ -23,11 +23,11 @@
     "nfsTitle": "Don't disable this if you use NFS",
     "nfsBody": "NFS server <strong>and</strong> NFS client rely on <code>rpcbind</code> to negotiate the ports used by <code>mountd</code>, <code>statd</code>, <code>lockd</code>, etc. If your Proxmox host either <em>exports</em> NFS shares to other machines or <em>mounts</em> NFS shares from a NAS, do not apply this option. Mounts will fail with <code>mount.nfs: rpc.statd is not running</code> or similar.",
     "runsTitle": "What ProxMenux runs",
-    "runsOutro": "The package stays installed (so you or another tool can re-enable it later). The service unit is disabled so the service does not come back on reboot.",
+    "runsOutro": "The package stays installed. ProxMenux records the original enabled/active state of both rpcbind.service and rpcbind.socket, then disables and stops both units so socket activation cannot bring the service back.",
     "verifyTitle": "Verification",
     "verifyBody": "After applying, confirm <code>rpcbind</code> is off and nothing is listening on port 111:",
-    "reversibleTitle": "Reversible from the Uninstall menu",
-    "reversibleBody": "This change is tracked. Open <link>Uninstall Optimizations</link> and pick <em>RPC Disable</em> to restore it. Nothing is purged from the system — just re-enable the service and it starts again."
+    "reversibleTitle": "Restores the original service state",
+    "reversibleBody": "This change is registered in <code>installed_tools.json</code>. <link>Uninstall Optimizations</link> restores each rpcbind unit to the enabled/disabled and active/inactive state captured before ProxMenux changed it; it does not assume that rpcbind was enabled on every host."
   },
   "related": {
     "heading": "Related",

web/messages/en/docs/post-install/storage.json

@@ -9,10 +9,10 @@
   },
   "intro": {
     "title": "What this category covers",
-    "body": "Three storage-related optimizations: tune the <strong>ZFS ARC</strong> cache size to a sensible fraction of host RAM, install and schedule <strong>ZFS auto-snapshots</strong>, and remove throttles from <strong>vzdump</strong> so backups run at full speed. All three are independent — pick the ones that match your setup. A fourth storage-adjacent optimization, <link>Log2RAM</link>, reduces SSD/NVMe wear by moving <code>/var/log</code> to a ramdisk — it lives on the Optional page because the ProxMenux Customizable menu groups it there."
+    "body": "Four storage-related optimizations: tune the <strong>ZFS ARC</strong> cache size to a sensible fraction of host RAM, install and schedule <strong>ZFS auto-snapshots</strong>, enable <strong>ZFS autotrim</strong> on SSD/NVMe pools, and remove throttles from <strong>vzdump</strong> so backups run at full speed. All four are independent — pick the ones that match your setup. A fifth storage-adjacent optimization, <link>Log2RAM</link>, reduces SSD/NVMe wear by moving <code>/var/log</code> to a ramdisk — it lives on the Optional page because the ProxMenux Customizable menu groups it there."
   },
-  "notTrackedTitle": "None of these are in the Uninstall menu",
-  "notTrackedBody": "Unlike most post-install optimizations, the three Storage options are <strong>not currently tracked</strong> in the Uninstall Optimizations flow. If you apply them and later want to revert, you'll have to do it by hand. The manual rollback commands are shown below each section.",
+  "trackedTitle": "All four are tracked in the Uninstall menu",
+  "trackedBody": "Each of these options registers a tool in <code>installed_tools.json</code>, so they appear in <link>Uninstall Optimizations</link>. Reverting <code>zfs_arc</code> removes <code>/etc/modprobe.d/99-zfsarc.conf</code> and rebuilds initramfs; <code>zfs_auto_snapshot</code> reverses the cron schedule and offers to purge the package; <code>zfs_autotrim</code> sets <code>autotrim=off</code> on the pools it enabled; <code>vzdump_speed</code> restores <code>/etc/vzdump.conf</code> from the <code>.bak</code> the install created.",
   "arc": {
     "heading": "Optimize ZFS ARC size",
     "intro": "The <strong>Adaptive Replacement Cache (ARC)</strong> is ZFS's in-memory read cache. Without explicit tuning, ZFS happily grabs up to half the host RAM for itself, which is excessive on a Proxmox host that also needs memory for VMs and LXCs. This option caps ARC to a sane fraction of total RAM based on the size of the machine.",
@@ -21,19 +21,27 @@
     "headerMax": "ARC cap",
     "rows": [
       {
-        "ram": "≤ 16 GB",
-        "max": "512 MiB"
+        "ram": "Formula",
+        "max": "RAM / 10, capped at 16 GiB, with a 64 MiB floor"
       },
       {
-        "ram": "17 – 32 GB",
-        "max": "1 GiB"
+        "ram": "8 GB host",
+        "max": "≈ 819 MiB (RAM/10)"
       },
       {
-        "ram": "> 32 GB",
-        "max": "RAM / 8 (floor 512 MiB)"
+        "ram": "16 GB host",
+        "max": "≈ 1.6 GiB (RAM/10)"
+      },
+      {
+        "ram": "64 GB host",
+        "max": "≈ 6.4 GiB (RAM/10)"
+      },
+      {
+        "ram": "≥ 160 GB host",
+        "max": "16 GiB (cap)"
       }
     ],
-    "after": "On a 64 GB host, that means an 8 GB cap for ARC. The file <code>/etc/modprobe.d/99-zfsarc.conf</code> contains a single directive — <code>options zfs zfs_arc_max=…</code>. Every other ZFS module parameter (<code>zfs_arc_min</code>, L2ARC prefetch/write throttle, TXG timeout) is left at its OpenZFS default. After writing the file, ProxMenux runs <code>update-initramfs -u -k all</code> and, when applicable, <code>proxmox-boot-tool refresh</code>, so the cap also lands in the initramfs used by ZFS-on-root setups.",
+    "after": "The file <code>/etc/modprobe.d/99-zfsarc.conf</code> contains a single directive — <code>options zfs zfs_arc_max=…</code>. Every other ZFS module parameter (<code>zfs_arc_min</code>, L2ARC prefetch/write throttle, TXG timeout) is left at its OpenZFS default. Before writing, a reconcile step scans any other <code>*.conf</code> in <code>/etc/modprobe.d/</code> that sets <code>zfs_arc_min</code> / <code>zfs_arc_max</code>, backs them up to <code>/usr/local/share/proxmenux/backups/zfs_arc/</code> with a manifest, and strips the conflicting lines so only ProxMenux's file is active. After writing the file, ProxMenux runs <code>update-initramfs -u -k all</code> and, when applicable, <code>proxmox-boot-tool refresh</code>, so the cap also lands in the initramfs used by ZFS-on-root setups.",
     "rebootTitle": "Requires a reboot to take effect",
     "rebootBody": "ARC settings are read when the <code>zfs</code> kernel module loads. To make the cap take effect on ZFS-on-root hosts, ProxMenux regenerates the initramfs with <code>update-initramfs -u -k all</code> and, when applicable, refreshes the boot loader with <code>proxmox-boot-tool refresh</code>. A reboot is still required to pick up the new module parameter; the \"reboot required\" flag is set automatically.",
     "safeTitle": "Safe on non-ZFS hosts",
@@ -115,8 +123,8 @@
     "heading": "Increase vzdump backup speed",
     "intro": "By default, Proxmox vzdump throttles backups to protect running VMs/CTs from IO starvation. On many setups that throttle is more conservative than needed. This option removes the bandwidth cap and lowers the I/O priority so vzdump can saturate the storage path during backup windows.",
     "changedTitle": "What gets changed in /etc/vzdump.conf",
-    "noBackupTitle": "No backup of vzdump.conf",
-    "noBackupBody": "The script <strong>edits <code>/etc/vzdump.conf</code> in place</strong> without creating a <code>.bak</code> first. If you had custom values there (bwlimit, ionice, compress, pigz, tmpdir, exclude-path, etc.), the changes to <em>those two lines</em> are made with <code>sed</code> — surrounding config is preserved — but there's no \"undo\" snapshot. Make a manual backup if your config is non-trivial: <code>cp /etc/vzdump.conf /etc/vzdump.conf.pre-proxmenux</code>.",
+    "backupTitle": "First run creates a .bak of vzdump.conf",
+    "backupBody": "The first time this option runs, ProxMenux copies <code>/etc/vzdump.conf</code> to <code>/etc/vzdump.conf.bak</code> before touching it. Subsequent runs re-use that backup and won't overwrite it, so a hand-edited config from before the first apply stays recoverable. The changes to <code>bwlimit</code> and <code>ionice</code> are then made with <code>sed</code>, and any other options in the file (compress, pigz, tmpdir, exclude-path, etc.) are preserved.",
     "skipTitle": "When to skip this",
     "skipBody": "On a host with slow local storage and VMs that are latency-sensitive, removing the bandwidth cap can cause noticeable slowdowns during backups. If you've previously set a specific <code>bwlimit</code> for that reason, keep it — skip this option.",
     "verifyTitle": "Verification and manual rollback"

web/messages/en/docs/post-install/system.json

@@ -85,7 +85,7 @@
     "intro": "Installs <code>kexec-tools</code> and wires it up so you can reboot the host straight into a new kernel <em>without going through BIOS/UEFI firmware</em>. On big servers where POST takes 45 – 90 seconds, this turns a reboot from a coffee break into a few seconds of downtime.",
     "installsTitle": "What ProxMenux installs",
     "installsItems": [
-      "Package <code>kexec-tools</code> (with debconf pre-answered so apt doesn't prompt during install).",
+      "Package <code>kexec-tools</code> (debconf pre-answered with <code>kexec-tools/load_kexec boolean false</code> so apt doesn't prompt and the auto-load on shutdown stays off).",
       "Systemd unit <code>/etc/systemd/system/kexec-pve.service</code> — loads the Proxmox kernel and initrd into memory at boot, reusing the current cmdline.",
       "An alias in <code>/root/.bash_profile</code>: <code>reboot-quick</code> → <code>systemctl kexec</code>."
     ],

web/messages/en/docs/post-install/uninstall.json

@@ -1,16 +1,16 @@
 {
   "meta": {
     "title": "Uninstall Optimizations | ProxMenux Documentation",
-    "description": "Reverse any post-install optimization applied by ProxMenux. Every change is tracked in a JSON registry, and every tool has a dedicated uninstaller that restores the original configuration."
+    "description": "Restore reversible post-install configuration changes applied by ProxMenux. Registered tools use dedicated uninstallers that preserve the pre-existing host state where possible."
   },
   "header": {
     "title": "Uninstall Optimizations",
-    "description": "Reverse any change made by the Automated or Customizable post-install scripts. ProxMenux keeps a registry of every optimization it applied and has a dedicated reversal function for each one — pick which to revert, and the host goes back.",
+    "description": "Restore reversible changes made by the Automated or Customizable post-install scripts. ProxMenux registers each supported optimization with its dedicated restoration function; package upgrades are intentionally excluded.",
     "section": "Settings post-install Proxmox"
   },
   "intro": {
     "title": "Why this exists",
-    "body": "Every tweak the post-install scripts apply is <strong>tracked</strong> in a JSON registry at <code>/usr/local/share/proxmenux/installed_tools.json</code>. That registry is what powers the uninstall flow — it shows you the list of optimizations currently applied, and a reversal function that restores the original state for each one (from backup files where possible, or by reinstalling the affected packages)."
+    "body": "Every supported reversible tweak is <strong>tracked</strong> in <code>/usr/local/share/proxmenux/installed_tools.json</code>. That registry powers the uninstall flow: it lists the active optimizations and dispatches the matching restoration function. Actions without a safe rollback, such as a full package upgrade, are not added."
   },
   "openMenu": {
     "heading": "How to open it",
@@ -40,21 +40,21 @@
         "body2": "Each reversal logs its progress. Items that require a reboot (VFIO, persistent interface names) set a flag that triggers the reboot prompt at the end."
       },
       {
-        "title": "Reboot if needed",
-        "body1": "If any reversed item modified kernel parameters, kernel modules, or network naming, you'll be offered a reboot. Otherwise the changes are live immediately."
+        "title": "Reboot prompt at the end",
+        "body1": "After the reversal finishes the menu shows a reboot prompt. Items that changed kernel parameters, kernel modules or network naming (VFIO, persistent interface names) do need the reboot to take effect; other items do not, and the prompt is a safety default rather than a per-item check."
       }
     ]
   },
   "reversible": {
     "heading": "What is reversible",
-    "intro": "Every optimization the post-install scripts apply has a matching uninstaller. Grouped here by area:",
+    "intro": "Registered reversible optimizations and their matching uninstallers are grouped here by area:",
     "groups": [
       {
         "title": "Repositories & APT",
         "items": [
           {
             "tool": "Subscription Banner Removal",
-            "restores": "Reinstalls pve-manager, proxmox-widget-toolkit, libjs-extjs and libpve-http-server-perl with force-confnew to restore the original UI files. Also clears cached .js / .gz copies."
+            "restores": "First tries to restore the UI files from ProxMenux's own backups (/usr/local/share/proxmenux/backups/proxmoxlib.js.backup.* and, when the mobile UI is patched, index.html.tpl.backup.*). Only if a backup is missing or corrupt, falls back to reinstalling pve-manager, proxmox-widget-toolkit, libjs-extjs and libpve-http-server-perl with force-confnew. Also clears cached .js / .gz copies."
           },
           {
             "tool": "APT Language Skip",
@@ -63,6 +63,10 @@
           {
             "tool": "APT IPv4 Force",
             "restores": "Removes /etc/apt/apt.conf.d/99-force-ipv4."
+          },
+          {
+            "tool": "System Utilities",
+            "restores": "Purges only the selected utility packages that ProxMenux recorded as newly installed. Packages already present before the action are never added to this list and are left untouched."
           }
         ]
       },
@@ -79,7 +83,7 @@
           },
           {
             "tool": "System Limits Increase",
-            "restores": "Removes /etc/sysctl.d/99-maxwatches.conf, 99-maxkeys.conf, 99-swap.conf, 99-fs.conf and /etc/security/limits.d/99-limits.conf. Reverts PAM limits and systemd DefaultLimitNOFILE."
+            "restores": "Removes /etc/sysctl.d/99-maxwatches.conf, 99-maxkeys.conf, 99-swap.conf, 99-fs.conf and /etc/security/limits.d/99-limits.conf. Reverts PAM limits and systemd DefaultLimitNOFILE, and strips the ulimit -n 256000 line from /root/.profile."
           }
         ]
       },
@@ -88,7 +92,15 @@
         "items": [
           {
             "tool": "Network Optimizations",
-            "restores": "Removes /etc/sysctl.d/99-network.conf together with the proxmenux-fwbr-tune.service unit, the /usr/local/sbin/proxmenux-fwbr-tune helper and the /etc/udev/rules.d/99-proxmenux-fwbr-tune.rules udev rule. Reloads sysctl, systemd and the udev ruleset."
+            "restores": "Removes /etc/sysctl.d/99-network.conf, 97-proxmenux-fwbr.conf and 98-proxmenux-rpf.conf together with the proxmenux-fwbr-tune.service unit, the /usr/local/sbin/proxmenux-fwbr-tune helper and the /etc/udev/rules.d/99-zz-proxmenux-fwbr-tune.rules udev rule. Also strips the source /etc/network/interfaces.d/* line from /etc/network/interfaces. Reloads sysctl, systemd and the udev ruleset."
+          },
+          {
+            "tool": "Open vSwitch",
+            "restores": "Runs apt purge on openvswitch-switch and openvswitch-common. Migrate any OVS bridges back to Linux bridges before running this uninstall — otherwise the VMs on those bridges lose networking on next boot."
+          },
+          {
+            "tool": "TCP BBR + TCP Fast Open",
+            "restores": "Removes /etc/sysctl.d/99-tcp-bbr.conf and 99-tcp-fastopen.conf and reloads sysctl so the kernel returns to the cubic congestion control and to tcp_fastopen=1."
           },
           {
             "tool": "Persistent Interface Names",
@@ -124,9 +136,13 @@
             "tool": "Bashrc Customization",
             "restores": "Restores /root/.bashrc from the .bak backup. If no backup exists, removes the PMX_CORE_BASHRC block by markers."
           },
+          {
+            "tool": "Custom MOTD Banner",
+            "restores": "Restores the exact original /etc/motd content kept under /usr/local/share/proxmenux, removes the file when it did not exist before, or safely removes the legacy marker when migrating an older installation."
+          },
           {
             "tool": "Fastfetch",
-            "restores": "Removes the binary, config directory, update-motd hook and the bashrc block. Purges the apt package if installed."
+            "restores": "Removes the binary, config directory, update-motd hook and the fenced BEGIN FASTFETCH / END FASTFETCH block from /root/.bashrc, ~/.profile, /etc/profile and /etc/profile.d/fastfetch.sh. Purges the apt package if installed."
           },
           {
             "tool": "Figurine",
@@ -144,6 +160,27 @@
           {
             "tool": "AMD CPU fixes (Ryzen/EPYC)",
             "restores": "Removes idle=nomwait from kernel cmdline (ZFS) or GRUB, and the ignore_msrs / report_ignored_msrs options from /etc/modprobe.d/kvm.conf."
+          },
+          {
+            "tool": "QEMU Guest Agent (templates)",
+            "restores": "Reads /usr/local/share/proxmenux/guest_agent.pkg (recorded at install time) and apt purges whichever package was installed (qemu-guest-agent for standard hosts, spice-vdagent when Spice mode is used)."
+          }
+        ]
+      },
+      {
+        "title": "Storage",
+        "items": [
+          {
+            "tool": "ZFS ARC sizing",
+            "restores": "Removes /etc/modprobe.d/99-zfsarc.conf, restores any conflicting external *.conf that was staged aside in /usr/local/share/proxmenux/backups/zfs_arc/, rebuilds initramfs and runs proxmox-boot-tool refresh on systemd-boot hosts."
+          },
+          {
+            "tool": "ZFS auto-snapshot",
+            "restores": "Removes the cron entries the script wrote and offers to apt purge zfs-auto-snapshot. Existing snapshot datasets on the pools are left intact — remove them separately if you want them gone."
+          },
+          {
+            "tool": "vzdump speed limits",
+            "restores": "Restores /etc/vzdump.conf from the .bak the install created, bringing back bwlimit and ionice to their pre-ProxMenux values."
           }
         ]
       },
@@ -160,7 +197,27 @@
           },
           {
             "tool": "kexec (fast reboots)",
-            "restores": "Disables kexec-pve.service, removes the unit file and the reboot-quick alias, purges kexec-tools."
+            "restores": "Disables kexec-pve.service, removes the unit file and the reboot-quick alias from /root/.bash_profile, purges kexec-tools."
+          },
+          {
+            "tool": "RPC / rpcbind Disable",
+            "restores": "Restores rpcbind.service and rpcbind.socket independently to the enabled/disabled and active/inactive states recorded before ProxMenux changed them."
+          },
+          {
+            "tool": "pigz (parallel gzip)",
+            "restores": "Puts /bin/gzip.original back in place, removes the /bin/pigzwrapper, reverts the pigz and bwlimit lines in /etc/vzdump.conf and apt purges pigz."
+          },
+          {
+            "tool": "High Availability services",
+            "restores": "Stops and disables pve-ha-lrm, pve-ha-crm and corosync. Existing HA groups and resource definitions are not deleted — remove them from the web UI if you no longer need them."
+          },
+          {
+            "tool": "Ceph repository",
+            "restores": "Purges the Ceph packages installed by this option, removes the deb822 /etc/apt/sources.list.d/ceph.sources on PVE 9 (or the legacy Ceph list on PVE 8), and refreshes the APT cache."
+          },
+          {
+            "tool": "OVH RTM (monitoring)",
+            "restores": "apt purges any ovh-* packages the RTM installer added and deletes the puppet manifests it dropped under /etc/puppet/. On non-OVH hosts nothing was ever installed, so nothing is removed."
           }
         ]
       }

web/messages/en/docs/post-install/updates.json

@@ -66,8 +66,14 @@
       {
         "title": "No reboot unless the function says so",
         "body": "Most updates take effect immediately. Updates that touch kernel modules, persistent interface names, or VFIO show the same reboot prompt as a fresh install would."
+      },
+      {
+        "title": "Registry refresh sent to the Monitor",
+        "body": "Once the batch finishes, the menu POSTs to <code>http://127.0.0.1:8008/api/updates/post-install/scan</code> to rebuild <code>/usr/local/share/proxmenux/updates_available.json</code>. That is what makes the Monitor's Optimizations card and the shell menu entry disappear immediately after the update, without waiting for the next scheduled scan."
       }
-    ]
+    ],
+    "jqTitle": "jq is required",
+    "jqBody": "The Path A checklist relies on <code>jq</code> to parse the pending-updates JSON. If <code>jq</code> is missing, the flow exits silently — you would see the menu entry with a count but nothing would happen after picking rows. On any modern Proxmox install <code>jq</code> is present; if in doubt run <code>apt install -y jq</code>."
   },
   "differs": {
     "heading": "How it differs from the other paths",

web/messages/en/docs/security/ssl-letsencrypt.json

@@ -117,7 +117,7 @@
   },
   "switchToHttps": {
     "heading": "Switch the Monitor to HTTPS",
-    "bodyRich": "Once <code>/etc/pve/local/pveproxy-ssl.pem</code> is signed by Let's Encrypt, the Monitor side is one click: open <strong>Settings → Security → HTTPS / SSL</strong>, confirm the issuer shown in the detected-certificate panel reads <em>Let's Encrypt</em> (and not the local Proxmox CA), and click <strong>Use Proxmox Certificate</strong>. The Monitor service restarts and the next browser load is HTTPS on port 8008 — no certificate warning, since the chain is publicly trusted."
+    "bodyRich": "Once <code>/etc/pve/local/pveproxy-ssl.pem</code> is signed by Let's Encrypt, the Monitor side is one click: open <strong>Settings → Security → HTTPS / SSL</strong>, confirm the issuer shown in the detected-certificate panel reads <em>Let's Encrypt</em> (and not the local Proxmox CA), and click <strong>Use Proxmox Certificate</strong>. The Monitor service restarts and the next browser load is HTTPS on port 8008 — no certificate warning, since the chain is publicly trusted. Later Proxmox ACME renewals are validated and selected during the next new TLS connection; there is no recurring certificate poller or renewal-time service restart. <strong>Update certificate</strong> remains available in Security as an explicit diagnostic and recovery action."
   },
   "custom": {
     "heading": "Custom certificate — when to use it",