Repository navigation
feat: create containers from the linuxcontainers.org catalog when Proxmox has no template - #25
Merged
Merged
Conversation
Contributor
Try this branchThe engine and the scripts resolve independently, so a production script can COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/community-scripts/core/test/linuxcontainers-full-catalog \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/debian.sh)"Swap This PR touches both backends. Worth running on a Proxmox VE and an Incus host. Run a script from a fork as wellcurl -fsSL https://raw.githubusercontent.com/community-scripts/core/test/linuxcontainers-full-catalog/tools/run.sh |
bash -s -- https://raw.githubusercontent.com/YOU/DevScripts/your-branch ct/debian.sh \
https://raw.githubusercontent.com/community-scripts/core/test/linuxcontainers-full-catalogNote that Useful flags while testing
|
The fallback only knew what arm64_template_variant() hardcoded: debian 12/13, ubuntu 24.04/26.04, alpine. Everything else exited 225, and the Jenkins URL it built is a legacy endpoint. Resolves against the simplestreams index instead, which is what Incus already uses. The index carries aliases (debian/13 -> trixie), so the mapping table is gone rather than extended. Opens up 22 distributions and 42 arm64 images against 2 arm64 templates in a live pveam catalog: almalinux, alt, amazonlinux, archlinux, busybox, centos, devuan, kali, mint, nixos, openeuler, opensuse, openwrt, oracle, plamo, rockylinux, slackware, voidlinux and the four already covered. Only reached when pveam has nothing, so amd64 behaviour is unchanged for anything Proxmox ships. Needs jq and installs it when missing. Verified against the live catalog: lookup returns correct paths for debian, ubuntu, alpine, rockylinux, fedora, archlinux and voidlinux, refuses unknown releases, and the resulting URLs are real tarballs (debian trixie arm64 86 MB, rockylinux 9 arm64 99 MB). Not run on a Proxmox host.
…iant Gentoo ships only openrc and systemd, so a hardcoded variant == "default" filter could never find it. Nixos publishes a squashfs where everyone else has a tarball. Take a per-distro variant preference list, and fall back from root.tar.xz to root.squashfs, unpacking that into the tarball pct wants. Two things the catalog switch had lost on the way: an empty version resolved to nothing, because the hardcoded codename table went away with it -- the UI defaults cover debian/ubuntu/alpine again, and a distro with a single release answers for itself rather than being guessed at. And fetching the index is now separate from querying it, so an unreachable catalog reports as a network failure instead of claiming the image does not exist.
MickLesk
force-pushed
the
test/linuxcontainers-full-catalog
branch
from
September 7, 2026 13:21
d6c5165 to
9c22b37
Compare
Update container and VM description builders to derive script slugs from `SCRIPT_SLUG` or `NSAPP` before falling back to `APP`, matching how scripts are identified elsewhere. Slugs are now lowercased with spaces removed (not dashed), preventing broken links like `arch-linux` and preserving VM-specific suffixes such as `-vm`.
The fallback only knew what arm64_template_variant() hardcoded: debian 12/13, ubuntu 24.04/26.04, alpine. Everything else exited 225, and the Jenkins URL it built is a legacy endpoint. Resolves against the simplestreams index instead, which is what Incus already uses. The index carries aliases (debian/13 -> trixie), so the mapping table is gone rather than extended. Opens up 22 distributions and 42 arm64 images against 2 arm64 templates in a live pveam catalog: almalinux, alt, amazonlinux, archlinux, busybox, centos, devuan, kali, mint, nixos, openeuler, opensuse, openwrt, oracle, plamo, rockylinux, slackware, voidlinux and the four already covered. Only reached when pveam has nothing, so amd64 behaviour is unchanged for anything Proxmox ships. Needs jq and installs it when missing. Verified against the live catalog: lookup returns correct paths for debian, ubuntu, alpine, rockylinux, fedora, archlinux and voidlinux, refuses unknown releases, and the resulting URLs are real tarballs (debian trixie arm64 86 MB, rockylinux 9 arm64 99 MB). Not run on a Proxmox host.
…iant Gentoo ships only openrc and systemd, so a hardcoded variant == "default" filter could never find it. Nixos publishes a squashfs where everyone else has a tarball. Take a per-distro variant preference list, and fall back from root.tar.xz to root.squashfs, unpacking that into the tarball pct wants. Two things the catalog switch had lost on the way: an empty version resolved to nothing, because the hardcoded codename table went away with it -- the UI defaults cover debian/ubuntu/alpine again, and a distro with a single release answers for itself rather than being guessed at. And fetching the index is now separate from querying it, so an unreachable catalog reports as a network failure instead of claiming the image does not exist.
MickLesk
force-pushed
the
test/linuxcontainers-full-catalog
branch
from
September 7, 2026 14:06
6729e36 to
ac005d5
Compare
The version list was built after the offer was printed, so a distro pveam carries no template for at all -- Oracle, for one -- announced "select a different available version or press Enter to cancel" and then exited on the next line without ever prompting. Build the list first and only speak if it has something in it. The dead end now says which distro and architecture Proxmox came up empty for, and how to check the catalog.
…m/community-scripts/core into test/linuxcontainers-full-catalog
Expose `HWACCEL_VENDOR` consistently during hardware-acceleration setup so downstream logic can rely on the detected GPU vendor. Incus now sets vendor hints from available NVIDIA/AMD devices, and the shared hwaccel flow initializes vendor state, records when NVIDIA is actually usable, and derives the final vendor from selected GPU types (with usable NVIDIA taking priority). Also removes an outdated explanatory comment in `pve/vm-core.func`.
ARCH == arm64 stood in for "pveam has nothing", which held while the catalog was only ever consulted on ARM64 hosts. On amd64 it meant Proxmox's own catalog was the single source, so a distro pveam does not carry -- Oracle, Kali -- had no path at all and the run ended at "No oracle templates available at all". Every one of those five checks now asks whether a catalog template was actually resolved, and download_arm64_template, which is no longer arch-specific, is download_catalog_template. A catalog miss stops ending the run as well. Asking for a version that does not exist is far more common than asking for a distro nobody publishes, and only the pveam path can offer the versions this host does have -- so a miss falls through to it instead of exiting.
Member
Author
Update: amd64 works now
Two things this changes beyond reach:
On plain amd64: CORE=https://raw.githubusercontent.com/community-scripts/core/test/linuxcontainers-full-catalog
VED=https://raw.githubusercontent.com/community-scripts/ProxmoxVED/main
COMMUNITY_SCRIPTS_CORE_URL=$CORE bash -c "$(curl -fsSL $VED/ct/oraclelinux.sh)"
COMMUNITY_SCRIPTS_CORE_URL=$CORE bash -c "$(curl -fsSL $VED/ct/kali.sh)"
COMMUNITY_SCRIPTS_CORE_URL=$CORE bash -c "$(curl -fsSL $VED/ct/linuxmint.sh)"
COMMUNITY_SCRIPTS_CORE_URL=$CORE bash -c "$(curl -fsSL $VED/ct/amazonlinux.sh)"
Resolution verified against the live catalog for amd64: |
The catalog calls Arch's rolling release current, Devuan 5 daedalus and CentOS 10 10-Stream, so those three resolved to nothing on either architecture while every other distro we ship worked.
…name PVE resolves no ostype for ID 'amzn' and its fallback detection finds nothing either, so pct create aborted before configuring anything; forcing ostype centos needs the same /etc/redhat-release that openEuler already gets. RHEL-family minimal images also ship no hostname binary, which broke the MOTD line and left self-signed certs without a CN.
PVE::LXC::Setup::CentOS rejects every version outside 5..10, so writing the real version into /etc/redhat-release made pct create fail with 'unsupported centos version' for Amazon Linux 2023 and, unnoticed until now, openEuler 25.03. The guard also has to read the file instead of only checking that it exists, or an already-patched cache keeps its rejected version forever.
MickLesk
marked this pull request as ready for review
October 6, 2026 14:26
The lookup opened a message block that only the found-locally path closed. After a download every later msg_ok resumed its spinner, which kept running into the install and flickered against the container's own spinner.
An alias resolves even when the image server has nothing for the host's architecture, so Amazon Linux on arm64 went through three failing launches. The resolver now checks the image's architecture and the run ends with exit 106. The retry list no longer tries the same image twice.
The arm64 Arch image reports ID=archarm, so detect_os found no package manager and the update step failed. Its keyring is archlinuxarm, so populating only archlinux left the packages unverifiable; all shipped keyrings are populated now.
clean all dropped the metadata update_os had just fetched, so autoremove downloaded it all again: 33s instead of 2s on Oracle Linux 9, silently after Customized Container, and the 234 MB it fetched stayed in the container the cleanup was meant to shrink.
The host pushed its own profile.d MOTD before the install, whose motd_ssh then wrote the regular one, so every login printed two. The extra one read the IP from hostname -I, which images such as Oracle Linux do not ship, and showed it empty. build.func still recognises the file in containers that have it.
Since message blocks resume, a msg_info nothing closed came back after every later msg_ok and kept spinning into the container's install, flickering against its own spinner. Two template messages did that on Proxmox: "Template not present locally" on every first download, and the arm64 linuxcontainers.org notice. Both are fixed, and the host clears its blocks before handing the terminal to the install.
Their linuxcontainers images ship without hostname and free, RHEL's lang.sh reads LC_ALL unguarded under nounset, and the Incus parity helpers ran apt on every distribution.
cleanup_lxc in core.func ran apt unconditionally; silent() turns the resulting 127 into an abort, so every non-Debian update ended there.
The override put '-' in agetty's term slot, so the type stayed unknown and util-linux 2.40+ probed the console with ESC[6n.
…ut ping Oracle and Amazon Linux images ship neither, so every update ran silent after a misleading "no interactive terminal" and every Amazon Linux create warned that connectivity failed.
container-getty@ passes the pty as stdin, so the line is "-" as in the
stock unit, and the override now covers every instance. Naming tty1
made agetty fail on Kali's systemd 262; the dead unit left systemd's
size probe answers ("24;80R") on the console.
The pinned executor loses its libsystemd-shared when the package is upgraded during update_os; journald and the getty then exit 127 and the PVE console stays dead (Kali rolling). The getty restart now names the instances from container_ttys, since a dead instance is unloaded and no glob finds it.
pct mount prints "mounted CT <id> in '<path>'", so the grep for "mounted at" never matched and every Debian 13 create only stopped and restarted the container. ProxmoxVE reverted the same block on 2026-01-28 (910723c74). Parsing the path instead would chown / to host root, which is nobody:nogroup inside an unprivileged container.
pve-container 6.1.15 and pve-manager 9.2.22 dropped the label; the feature is considered stable.
…full-catalog # Conflicts: # core/core.func # incus/tools.func # ui/menu.func
… make openSUSE from pveam and the linuxcontainers.org images (Kali, Mint) boot degraded on Proxmox: sys-kernel-debug.mount and sys-kernel-config.mount fail with permission denied. Proxmox's Debian and Ubuntu templates mask them already. Mask them only where they failed.
LXC drops a console-getty override.conf into /run that lets agetty open the console itself, since systemd 258 cannot set /dev/console up as stdin in a container. Ours has the same name and replaced it, so on Incus the console getty failed at boot on Debian 14, Ubuntu 26.04, Fedora 43/44, Kali, Tumbleweed and Arch. Carry LXC's port and stdio settings over when its drop-in does that.
incus image info prints Architektur: on a German host, so the architecture check found nothing and an image without an arm64 build was launched blind until it failed with 'Failed to create container'. Same for the status and the resource listings.
Ubuntu 26.04 from linuxcontainers.org booted degraded on Proxmox: netplan-configure.service reloads udev afterwards, and an unprivileged container has none to reload. Ignore that step's failure where the unit failed.
On amd64 resolve_os_version replaced every version pveam does not ship with the nearest one it does, before the catalog was ever asked: Debian 14 became 13, Rocky and Alma 8 became 9, openEuler 24.03 became 25.03. Release names fared worse, tumbleweed scored 0 and became openSUSE 15.6. Check linuxcontainers.org first and keep the version when it has it, and only look for a nearest version between numbers. The catalog lookups move out of create_lxc_container so resolve_os_version can call them.
MickLesk
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
✍️ Description
When
pveamhas no template for the requested OS and architecture, the engine now falls back to the linuxcontainers.org simplestreams index, the same source Incus uses. The index carries the release aliases (debian/13→trixie), so the hardcoded arm64 mapping table is gone. On arm64 Proxmox this opens up 22 distributions instead of the two templatespveamships. On amd64 it only kicks in for distributions Proxmox does not ship at all (Oracle Linux, Amazon Linux, Kali, Mint).The catalog images are not prepared the way Proxmox's templates are, so several fixes come along:
incusoutput in the C locale where it is parsed (a German host never detected a missing arm64 image).Needs
jq(installed when missing) andsquashfs-toolsfor squashfs images.