v1.2.4.2-beta

ProxMenux v1.2.4.2-beta

A focused beta on the LXC Apps and Updates tabs. The App tab keeps its cache warm across every action and promotes Docker as the parent workload during cold start; the Updates tab covers Docker end-to-end — Engine and per-image versions on the same 24-hour cycle as OS packages, with a "Check now" action on demand. A new detection catalog with over 380 tracked workloads is generated live from community-scripts across seven detector methods. NVIDIA passthrough moves to per-BDF ownership so a multi-GPU host can pass one card to a VM and keep the other operational on the host or in LXCs. Pushover joins the native notification channels. The post-install scripts gain precise rollback for every registered flow and are ready for Debian 13, plus fixes for Proxmox storage availability, ZFS ARC sizing under memory pressure and OOM diagnostics.

📦 LXC Apps & Updates — phases 1 to 6 (#305, discussion #306)

Thanks to @SystemIdleProcess for the modern /root/.<app> marker behaviour and its failure caveat, plus Docker Hub / LTS and SearXNG testing across around 30 real application configurations. @TCBWZA shared the /usr/bin/update wrapper behaviour, Docker updater observations and feedback from a personal LXC update workflow.

• App tab cache stays warm across every action. Successful add / edit / check / dismiss / delete operations write the returned sidecar directly into both backend and shared frontend caches; post-update scans revalidate in the background while the last valid content stays visible. Switching tabs no longer falls back to "Loading applications…" for data ProxMenux already has, and an older in-flight GET cannot overwrite a newer saved result.
• Cold-start Docker detection promotes Docker as the parent workload. If Docker becomes ready between the initial filesystem probe and the container inventory probe, the Engine's verified version detector is retried and Docker becomes the LXC's parent app. Portainer, SearXNG and similar workloads remain Docker links/workloads instead of temporarily appearing as native app suggestions.
• Application discovery is explicit and scoped to one LXC. "Find applications" runs a fresh catalog-backed scan only when requested and keeps existing cards visible while it runs. Empty LXCs offer the same action beside "Register application"; populated LXCs use the standard neutral action row. Every locale gets short, unambiguous labels — the raw vmLxc.appEditor.searchApplications key no longer appears.
• Detected-but-unregistered applications belong to the startup cache. The initial LXC sweep stores complete suggestions alongside the registered sidecar; the App tab renders both immediately without starting a hidden scan; registering or hiding a suggestion updates the visible state from the same cached payload.
• Guest lifecycle events drive the complete per-guest refresh. Starting, stopping, restarting or restoring a guest reuses the PVE task watcher that already fires VM/LXC notifications, then rebuilds only that LXC/VM — OS updates, registered apps, suggestions, versions, ports, details, mounts and schedules — with an additional Docker Engine/image refresh when Docker exists. Unrelated guests keep their cached content on screen instead of flashing loading placeholders.
• Docker registry comparisons follow the 24-hour rolling cycle. The inventory is derived and retained only in process memory — no docker_inventory.json written outside ProxMenux. Opening Updates does not bypass the cycle with an automatic forced scan. The daily collector performs the scheduled refresh, completed Docker updates and guest lifecycle events force an immediate verification, and a translated "Check now" action lets the user explicitly request fresh digests without shortening the global cache window.
• Restored Docker LXCs have an explicit inventory-transition state. A Docker binary/socket that exists before the daemon has finished waiting for network-online.target renders as "waiting for Docker" instead of a misleading green "no tagged images". Bulk-update summaries no longer expose opaque docker-unit:<hash> values during this boot window; a manual check made while Docker is still starting preserves the same pending state after a Monitor restart.
• The Docker inventory rejoins the normal startup cache. ProxMenux rebuilds it once after discovering the running LXCs, so restarting the Monitor no longer leaves the Docker Images section empty. No persistence file, no additional recurring scanner.

🎯 Application detection catalog — 380+ workloads from live community-scripts

• The catalog is generated from the real upstream source, not from slug guesses. .github/scripts/generate_app_tracking_catalog.py pins one exact community-scripts/ProxmoxVE commit via the GitHub API, analyzes only ct/*.sh LXC launchers and follows their matching install/update contracts. A detector becomes operational only when independent script evidence agrees; ambiguous candidates stay in the audit instead of leaking into runtime data.
• 389 operational tracking hints plus 23 real-container overrides now cover file, binary, dpkg, apk, Python distribution, Docker exec and Docker label detection. Runtime-confirmed paths include qBittorrent's real binary, Tandoor's version_info.py, Open WebUI's UV Python environment, Proxmox Backup Server / Jellyfin packages and several Docker-backed applications.
• Ordered detector fallback is first-class. A catalog entry can try its primary detector, cross-method alt_detectors and same-method file_fallbacks; the resolved working detector is what the editor and runtime use. The catalog therefore supports both new and historical LXC layouts instead of assuming /root/.<slug> for every app.
• Every generation produces three reviewable artifacts: the compatible runtime hints, a detailed audit explaining accepted / rejected candidates and provenance, and a v2 multi-detector catalog. The workflow can refresh the catalog without turning unverified heuristics into production defaults.
• The app catalog now carries user-facing metadata as well as version logic: default ports, official website and theme-aware logo data can prefill the registration flow while remaining editable by the user.

🟢 NVIDIA — multi-GPU passthrough and driver lifecycle by exact BDF

• NVIDIA passthrough and mode switching now use exact PCI BDF ownership throughout. A host with two NVIDIA GPUs can assign one card and its IOMMU endpoint functions to a VM while the other remains operational on the host or in LXCs, including when both cards share the same vendor:device IDs. The native NVIDIA driver, udev rule and host services stay available in mixed mode; host-wide NVIDIA suppression is applied only when every NVIDIA display/3D controller is assigned to VFIO.
• Legacy NVIDIA VFIO configuration migrates without changing the effective ownership unexpectedly. Old global ids=10de:… entries are expanded to every matching exact BDF before those IDs are removed. Subsequent VM ↔ LXC changes remove only the selected GPU and its endpoint functions, preserve other NVIDIA assignments and leave unrelated Intel/AMD VFIO IDs untouched.
• Interactive and Monitor GPU switchers share the same fail-closed safety policy. Both require pci_passthrough_helpers.sh, skip PCI bridges that vfio-pci does not support, maintain NVIDIA soft dependencies only while an NVIDIA BDF remains assigned and rebuild initramfs only after a real host-configuration change. The VM preflight evaluates the exact BDF state and no longer requests a reboot because it expected obsolete global NVIDIA blacklist lines.
• NVIDIA service state now lives under /usr/local/share/proxmenux. Any state produced by the short-lived /var/lib/proxmenux implementation is migrated once, used to restore the original enabled/running services and removed from the provisional location.
• NVIDIA driver uninstall now restores only the nouveau policy owned by ProxMenux. New installations use a dedicated managed blacklist plus ownership state; uninstall removes that state and supports safe migration of the exact legacy two-line file without deleting an administrator's independent nouveau policy.
• NVIDIA version guidance now matches the real validation path. Dead kernel-floor code and prevalidated-kernel-compatibility claims were removed from the installer. Notifications and English / Spanish hardware documentation now describe the actual validation path (branch + GPU PCI ID filter + DKMS build) instead of promising a matrix that never ran.
• Regression coverage includes the real collision scenario. A Linux test with two identical NVIDIA GPUs plus their audio functions verifies legacy-ID migration, selective return of one card to the host, continued VFIO ownership of the other card, preservation of unrelated VFIO IDs and migration / restoration of legacy service state.

🔔 Pushover — native notification channel (discussion #308, suggested by @benginx)

• Pushover is a first-class notification channel alongside Telegram, Gotify, Discord, Email and Apprise. The Settings panel accepts the user / group key and application API token, plus optional device and sound selectors, and includes the same category, event, quiet-hours, daily-digest and test controls as the other channels.
• Critical alerts can use Pushover high priority without creating acknowledgement loops. Normal messages use priority 0; CRITICAL events can use priority 1 when enabled. Emergency priority 2 is deliberately excluded because it requires repeated delivery and an acknowledgement callback.
• Both Pushover credentials are treated as notification secrets. The user / group key and application API token are encrypted in the existing settings store, masked in the interface and available through the protected reveal flow. API errors are sanitised so neither value appears in support output.
• Pushover API limits are enforced before sending. Titles and message bodies are truncated to the official limits, optional device / sound values are validated, and the native adapter uses the official Messages API without adding a new runtime dependency.
• The Apprise Pushover example uses the correct pover:// scheme. The in-app helper links to the official Apprise service catalogue, while the web documentation explains both the dedicated Pushover path and the generic Apprise alternative.

🛡 Post-install — precise rollback and Debian 13 readiness

• RPC / rpcbind disable is registered and exactly reversible. ProxMenux records the independent enabled/active state of rpcbind.service and rpcbind.socket before changing either unit, exposes the action in Uninstall Optimizations and restores the captured state instead of blindly enabling both units. The success message no longer claims the package was removed.
• Ceph repository setup no longer uses deprecated apt-key. PVE 8 and PVE 9 repository definitions use the Proxmox archive keyring through signed-by / deb822 Signed-By; missing keyrings and repository-signature failures stop the installation safely. Ceph uninstall also removes the legacy ceph-squid.list repository file.
• MOTD and selected system utilities now have provenance-aware rollback. MOTD records the original file contents or absence before adding the ProxMenux marker. System Utilities records and later purges only selected packages that were not already installed on the host, preserving pre-existing administrator packages.
• Subscription-banner tracking is consistent in both post-install flows. Automated and Customizable register the optimization only after the patch helper succeeds, and its uninstaller keeps the registry entry when restoration is incomplete.
• APT full-upgrade is deliberately not advertised as reversible. Package upgrades have no safe atomic rollback, so the misleading dead uninstaller was removed instead of registering a false recovery action. The English and Spanish documentation now distinguishes reversible configuration changes from irreversible package upgrades.
• Post-install menus and output were cleaned up. The empty Hardware category and orphaned uninstall labels were removed, and kexec now distinguishes a fresh package / service / alias change from an already configured state. Modified functions carry newer local versions so installed hosts can receive the normal post-install update notification.

🧠 ZFS ARC sizing and OOM diagnostics (credit: LeidenSpain)

• ZFS ARC optimization now follows the Proxmox VE sizing policy. optimize_zfs_arc v1.2 replaces the old 512 MiB / 1 GiB / RAM÷8 tiers with 10 % of physical RAM capped at 16 GiB, reports the currently effective value and the proposed value before writing 99-zfsarc.conf, and warns when that cap is below Proxmox's 2 GiB + 1 GiB per TiB pool-size guideline. The existing initramfs refresh and reboot requirement remain in place so ZFS-on-root hosts actually load the new cap.
• optimize_zfs_arc v1.3 safely reconciles duplicate ARC limits left in other /etc/modprobe.d/*.conf files. Before writing the ProxMenux-managed limit it backs up each conflicting file under /usr/local/share/proxmenux/backups/zfs_arc, removes only active zfs_arc_min / max tokens, preserves every other ZFS option and records the post-migration checksum. Uninstall restores those files only while they still match the migrated state; later administrator edits are never overwritten.
• The generic memory optimization no longer forces vm.overcommit_memory=1. optimize_memory_settings v1.2 in both automatic and customizable post-install flows leaves the kernel / PVE overcommit policy untouched. Existing ProxMenux-managed hosts are offered the function update through the normal installed-tool version mechanism.
• OOM alerts no longer blame a VM, ZFS or the process that happened to invoke the allocator without evidence. The known-error guidance now explains that an OOM can belong to the host, a memory cgroup, a cpuset or a NUMA scope, distinguishes the allocation trigger from the killed victim and asks for the complete OOM block before recommending an allocation change. Health-log summaries recognise invoked oom-killer, oom-kill and oom_reaper lines and name a victim only when the kernel actually reports Killed process.
• Multi-line OOM blocks are correlated into one evidence-based event. The parser recognises CONSTRAINT_MEMCG, extracts oom_memcg=/lxc/<ctid>, cgroup memory / swap limits and the actual Killed process; the live journal watcher buffers the kernel block and the Health monitor deduplicates its lines. A real report from LXC 108 is now described as a 128 MiB, zero-swap container limit instead of a host-wide or ZFS memory failure.

🖥 Bash prompt customization (credit: LeidenSpain)

• The Bashrc customization now makes the working-directory style explicit. bashrc_custom v1.1 keeps the automated post-install non-interactive, preserves an existing ProxMenux-managed choice on re-run and continues to use compact \W (current directory only) for new automatic installations. The customizable flow offers \W or \w (full path), preselecting the current managed value instead of overwriting the user's preference blindly.
• Applying Bashrc customization no longer implies that an already-open terminal changed immediately. The completion message explains that new sessions load the prompt automatically and gives the correct source /root/.bashrc command for users who want to refresh their current shell. ProxMenux deliberately does not run source inside its child process because that cannot alter the parent shell.
• The new Bash prompt selector and activation guidance are available in all seven translated CLI languages. The technical \W and \w escapes remain unchanged in every locale so the choice cannot be mistranslated.

🗄 Fix #309 — Proxmox storage availability

• Storage reachability now follows Proxmox's authoritative status independently from capacity reporting. An available base iSCSI storage with maxdisk=0 remains active and no longer produces a critical health alert; genuine non-available and missing storages continue to be reported. The API exposes whether capacity is known, and the Monitor shows "Capacity not reported" instead of a fictitious 0 GB / 0 % capacity block.
• Community report credit: @Atredis76 — identified the maxdisk=0 iSCSI false positive and validated the expected status across a five-node Proxmox cluster.