Incus: drive a remote Incus server from the client's default remote by MickLesk · Pull Request #154 · community-scripts/core

MickLesk · 2026-10-21T13:43:59Z

✍️ Description

Every call in the backend already uses bare names, so a switched default remote reaches another server; what still read this machine was the architecture, the keyctl probe and the df fallback for pool space. The target is announced when it is not local. This is the way in for IncusOS.

🔗 Related Issue

Fixes #

✅ Prerequisites (X in brackets)

Self-review completed – Code follows project standards.
Tested thoroughly – Changes work as expected (Proxmox VE and/or Incus, as applicable).
No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.
API.txt regenerated – If a function signature or behavior changed, API.txt was updated to match.

🤖 AI Assistance (X in brackets)

If you used an AI tool (GitHub Copilot, Claude, ChatGPT, etc.) to write or generate any code in this PR, you must confirm compliance below.
Select exactly one option.

No AI used – Code was written without AI assistance.
AI was used – The output has been reviewed and corrected, and I take responsibility for it matching this repo's conventions.

🛠️ Type of Change (X in brackets)

🐞 Bug fix – Resolves an issue without breaking functionality.
✨ New feature – Adds new, non-breaking functionality.
💥 Breaking change – Alters existing behavior in a way that may require updates in every downstream script.
🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
📝 Documentation update – Changes to README, docs/, CONTRIBUTING.md, or other docs.

Every call in the backend already uses bare names, so a switched default remote reaches another server; what still read this machine was the architecture, the keyctl probe and the df fallback for pool space. The target is announced when it is not local. This is the way in for IncusOS.

github-actions · 2026-10-21T13:44:09Z

Try this branch

The engine and the scripts resolve independently, so a production script can
be run against the engine from this PR by setting one variable:

COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/community-scripts/core/feat/incus-remote-client \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/debian.sh)"

Swap ct/debian.sh for whatever exercises the change.

This PR touches incus/, so it needs an Incus host.

Run a script from a fork as well

curl -fsSL https://raw.githubusercontent.com/community-scripts/core/feat/incus-remote-client/tools/run.sh |
  bash -s -- https://raw.githubusercontent.com/YOU/DevScripts/your-branch ct/debian.sh \
             https://raw.githubusercontent.com/community-scripts/core/feat/incus-remote-client

Note that run.sh is reached through a pipe, so the script it starts inherits
an exhausted stdin. Whiptail is fine — it opens /dev/tty — but a plain read
would see EOF. The single-variable form above does not have that problem.

Useful flags while testing

dev_mode=net logs every engine fetch with status and duration, which is the
quickest way to confirm the branch is really being used. dev_mode=keep stops a
failed build from deleting the container along with the evidence.

tai8pan · 2026-10-21T21:00:03Z

I have tested the PR on my environment.
The code correctly targets the default remote (incus-001 in may case) now, but fails to detect its architecture and to read kernel key parameters.

  ℹ️  Target: Incus remote 'incus-001' (unknown architecture)
  ✖️  Unable to read kernel key parameters. Ensure proper permissions.

These seems to be 2 separate issues:

Archecture detecton
Possible reason is wrong parsing of the YAML received from incus info in line 240 of core.func
INCUS_SERVER_ARCH="$(LC_ALL=C incus info 2>/dev/null | awk '/^environment:/ {e=1} e && /^ architectures:/ {a=1; next} a && /^ - / {print $2; exit}')"
It expects environment:architectures: array elements to have exactly one leading space, while the actual format it recives in my test is:

environment:
  architectures:
    - x86_64
    - i686

The value should be probably probablu clean app form the spaces and dashes before its saved as architecture. Or maybe it will be easier to use kernel_architecture: for this purpose.

Kernel key paramters
I think preflight_maxkeys() function in host/prefight.func file is responsible for this. It reads /proc/sys/kernel/keys/maxkeys and /proc/sys/kernel/keys/maxbytes.
I believe it still reads from the local host, which in my case (Alpine 3.22) does not have it. That is probably the reason I faced this error at all.
I’m not aware of easy way to read the remote kernel keys with incus client, but I belive in case of remote incus host it /proc/sys/kernel/keys check can be possibly skipped and used a deafult values or left to IncusOS to manage its kernel configuration. If I’m right you already addresed similar case in incus/backend.func .

…skip the local keyctl preflight The architectures list is indented differently across server versions, so the scalar is the reliable field. The kernel key limits belong to the server; a client driving a remote cannot read them (tester feedback on #154).

…e target test

MickLesk · 2026-10-22T07:53:58Z

both confirmed and fixed on the branch @tai8pan

tai8pan · 2026-10-22T10:41:18Z

@MickLesk, just tested with `bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/Incus/main/ct/pve-scripts-local.sh)"

Architecture detection seems to be soleved, but I still have “kernel keys” issue.
✖️ Unable to read kernel key parameters. Ensure proper permissions.

Probably more places that reads them them. Possible references I have found. I think two of them are already addressed, so its probaly ui.build-us.func that left to fix.

tai8pan · 2026-10-22T11:02:13Z

nothing changed, unfortunately. I’m not sure if the last commit should already work?
Should I refers some cache or sth?

MickLesk · 2026-10-22T11:08:44Z

Please test with the command above, to get the correct branch.

tai8pan · 2026-10-22T11:29:32Z

OK, my bad.

It seems “kernel keys” issue is also solved.

There is one more issue wth storage availability check.
The wizard reports there is not enough space on the storage pool which is not true.

An finally there is an error when building the container.

  ⚙️  Using Default Settings on node localhost
  💡  Incus Version 7.0.1 (Kernel: 5.10.0-ish_aok)
  🔀  Engine branch: community-scripts/core@feat/incus-remote-client
  🆔  Container ID: debian
  🖥️  Operating System: debian (13)
  📦  Container Type: Unprivileged
  💾  Disk Size: 2 GB
  🧠  CPU Cores: 1
  🛠️  RAM Size: 512 MiB
/dev/shm/cs-engine.MJoPEb/ui/menu.func: line 144: dpkg: command not found
  🚀  Creating a Debian LXC using the above default settings
  
  💡   Pool 'local' reports ~1GB free, container wants 2GB
  ℹ️  Source: incus storage info 'local' (pool free space, not full host disk)
  ℹ️  Grow: incus storage set local size=50GiB   |   Or pick another pool
  ✔️  Storage local (Free: ~1GB) [Container]
  ✔️  Storage 'local' validated
  ✔️  Image images:debian/13
  ✔️  LXC Container debian was successfully created.
  ✔️  Container debian is ready
  ✔️  Hostname set to debian
  ✔️  Network in LXC is reachable (ping)
  ✔️  IP set to 10.220.73.71
  ✔️  Customized LXC Container
  ✔️  MOTD configured
  ✔️  Functions pushed
  🚀  Starting application installation
sed: unrecognized option: u
BusyBox v1.37.0 (2026-01-10 15:38:28 UTC) multi-call binary.

Usage: sed [-i[SFX]] [-nrE] [-f FILE]... [-e CMD]... [FILE]...
or: sed [-i[SFX]] [-nrE] CMD [FILE]...

        -e CMD  Add CMD to sed commands to be executed
        -f FILE Add FILE contents to sed commands to be executed
        -i[SFX] Edit files in-place (otherwise write to stdout)
                Optionally back files up, appending SFX
        -n      Suppress automatic printing of pattern space
        -r,-E   Use extended regex syntax

If no -e or -f, the first non-option argument is the sed command string.
Remaining arguments are input files (stdin if none).
  ✖️  Installation failed in container debian (exit code: 141)
✔ Installation log: /usr/local/community-scripts/logs/incus-install-780cba32-combined.log

  Error: Broken pipe (SIGPIPE - output closed prematurely)

What would you like to do?

  1) Remove container and exit
  2) Keep container for debugging
  3) Retry with verbose mode (full rebuild)

Select option [1-3] (default: 1, auto-remove in 60s): 3

   Removing container debian for rebuild...
  ✔️  Stopped
  ✔️  Deleted debian
Rebuilding: debian → debian (verbose)
  💡   Pool 'local' reports ~1GB free, container wants 2GB
  ℹ️  Source: incus storage info 'local' (pool free space, not full host disk)
  ℹ️  Grow: incus storage set local size=50GiB   |   Or pick another pool
  ✔️  Storage local (Free: ~1GB) [Container]
  ✔️  Storage 'local' validated
  ✔️  Image images:debian/13
  ✔️  LXC Container debian was successfully created.
  ✔️  Container debian is ready
  ✔️  Hostname set to debian
  ✔️  Network in LXC is reachable (ping)
  ✔️  IP set to 10.220.73.35
  ✔️  Customized LXC Container
  ✔️  MOTD configured
  ✔️  Functions pushed
  🚀  Starting application installation
sed: unrecognized option: u
BusyBox v1.37.0 (2026-01-10 15:38:28 UTC) multi-call binary.

Usage: sed [-i[SFX]] [-nrE] [-f FILE]... [-e CMD]... [FILE]...
or: sed [-i[SFX]] [-nrE] CMD [FILE]...

        -e CMD  Add CMD to sed commands to be executed
        -f FILE Add FILE contents to sed commands to be executed
        -i[SFX] Edit files in-place (otherwise write to stdout)
                Optionally back files up, appending SFX
        -n      Suppress automatic printing of pattern space
        -r,-E   Use extended regex syntax

If no -e or -f, the first non-option argument is the sed command string.
Remaining arguments are input files (stdin if none).
  ✖️  Installation failed in container debian (exit code: 141)
✔ Installation log: /usr/local/community-scripts/logs/incus-install-780cba32-combined.log

  Error: Broken pipe (SIGPIPE - output closed prematurely)

What would you like to do?

  1) Remove container and exit
  2) Keep container for debugging
  3) Retry with verbose mode (full rebuild)

Select option [1-3] (default: 1, auto-remove in 60s): 1

   Removing container debian
  ✔️  Stopped
  ✔️  Deleted debian

Log file:
incus-install-780cba32-combined.log

The tester drives IncusOS from Alpine. dpkg does not exist there, so the architecture now comes from one helper that prefers the server; BusyBox sed has no -u, which killed the log tee with SIGPIPE; and the pool maths went through awk floats, which BusyBox truncates, so a 82 GiB pool read as 1 GB. incus storage info reports total and used only, and --bytes gives integers, so the subtraction stays in bash. The summary now names the server's kernel, not the client's.

tai8pan · 2026-10-22T11:43:32Z

I have resolved the issue with error dueling creation.

It was my clients host issue. It’s APlipne that use busy box sed , that do not support -u option.

I’ve just installed GNU sed and it completed successfully.

So the only issue use is the storage pool space detection.

tai8pan · 2026-10-22T12:01:14Z

It seems it already survives busybox , but it still reports wrong avaialable storage like before. Do you need some log or additional info to analyze it? Just tell me what.

I also noticed one more arrow just at the beginning of the script.

… floats yaml.Dump quotes the --bytes values because they are strings that look like numbers, so the integer path never matched and the text path went through BusyBox awk, which truncates floats to 32 bit: an 82 GiB pool read as 1 GB. The size parser is plain bash arithmetic now. The wizard also no longer calls systemctl on a client without it.

tai8pan · 2026-10-22T12:29:44Z

Perfect. Both systemctl to and available storage pool solved.

Good job! Thank you so much!
You the GOAT!

MickLesk · 2026-10-22T12:31:18Z

alright ^^ then i can clean up the comments in my workbench and merge it later

MickLesk added 2 commits October 22, 2026 09:20

Cover the four-space architectures list and kernel_architecture in th…

46f7c3f

…e target test

Incus remote: skip the keyring check in the wizard as well

f5031f3

Merge branch 'main' into feat/incus-remote-client

3d5e05f

MickLesk merged commit 4330ea1 into main Oct 22, 2026
4 checks passed

github-actions Bot deleted the feat/incus-remote-client branch October 23, 2026 07:14

Navigation Menu

Repository navigation

Incus: drive a remote Incus server from the client's default remote - #154

Incus: drive a remote Incus server from the client's default remote#154
MickLesk merged 7 commits into
mainfrom
feat/incus-remote-client

MickLesk commented Oct 21, 2026

Uh oh!

github-actions Bot commented Oct 21, 2026

Uh oh!

tai8pan commented Oct 21, 2026

Uh oh!

MickLesk commented Oct 22, 2026

Uh oh!

tai8pan commented Oct 22, 2026 •

edited

Loading

Uh oh!

tai8pan commented Oct 22, 2026

Uh oh!

MickLesk commented Oct 22, 2026

Uh oh!

tai8pan commented Oct 22, 2026 •

edited

Loading

Uh oh!

tai8pan commented Oct 22, 2026

Uh oh!

tai8pan commented Oct 22, 2026

Uh oh!

tai8pan commented Oct 22, 2026 •

edited

Loading

Uh oh!

MickLesk commented Oct 22, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

MickLesk commented Oct 21, 2026

✍️ Description

🔗 Related Issue

✅ Prerequisites (X in brackets)

🤖 AI Assistance (X in brackets)

🛠️ Type of Change (X in brackets)

Uh oh!

github-actions Bot commented Oct 21, 2026

Try this branch

Uh oh!

tai8pan commented Oct 21, 2026

Uh oh!

MickLesk commented Oct 22, 2026

Uh oh!

tai8pan commented Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tai8pan commented Oct 22, 2026

Uh oh!

MickLesk commented Oct 22, 2026

Uh oh!

tai8pan commented Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tai8pan commented Oct 22, 2026

Uh oh!

tai8pan commented Oct 22, 2026

Uh oh!

tai8pan commented Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MickLesk commented Oct 22, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

tai8pan commented Oct 22, 2026 •

edited

Loading

tai8pan commented Oct 22, 2026 •

edited

Loading

tai8pan commented Oct 22, 2026 •

edited

Loading