SVI/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-07-28 08:42:37 -04:00
Code Issues 2.6k Packages Projects Releases 10 Wiki Activity

Komodo Update Fail #986

New Issue
Closed
opened 2025-11-20 04:57:38 -05:00 by saavagebueno · 7 comments
saavagebueno commented 2025-11-20 04:57:38 -05:00
Owner
Copy Link

Originally created by @LucasJanin on GitHub (Apr 26, 2025).

Originally assigned to: @MickLesk on GitHub.

✅ Have you read and understood the above guidelines?

yes

📜 What is the name of the script you are using?

Komodo

📂 What was the exact command used to execute the script?

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/komodo.sh)"

⚙️ What settings are you using?

  • Default Settings
  • Advanced Settings

🖥️ Which Linux distribution are you using?

Debian 12

📝 Provide a clear and concise description of the issue.

Hi,

I'm having trouble updating my Komodo LXC with the script.

[+] Running 3/3do
 ✔ Container komodo-periphery-1  Running                                                                                                                                      0.0s 
 ✔ Container komodo-mongo-1      Running                                                                                                                                           0.0s 
 ✔ Container komodo-core-1       Running                                                                                                                                           0.0s 
  ✔️   Updated Komodo
/dev/fd/63: line 1289: CT_TYPE: unbound variable

Fortunately, this does not affect the Komodo installation :-).
Thank you in advance for your help!

🔄 Steps to reproduce the issue.

Update an exciting installation on Debian 12
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/komodo.sh)"

❌ Paste the full error output (if available).

/dev/fd/63: line 1289: CT_TYPE: unbound variable

🖼️ Additional context (optional).

No response

Originally created by @LucasJanin on GitHub (Apr 26, 2025). Originally assigned to: @MickLesk on GitHub. ### ✅ Have you read and understood the above guidelines? yes ### 📜 What is the name of the script you are using? Komodo ### 📂 What was the exact command used to execute the script? bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/komodo.sh)" ### ⚙️ What settings are you using? - [x] Default Settings - [ ] Advanced Settings ### 🖥️ Which Linux distribution are you using? Debian 12 ### 📝 Provide a clear and concise description of the issue. Hi, I'm having trouble updating my Komodo LXC with the script. ``` [+] Running 3/3do ✔ Container komodo-periphery-1 Running 0.0s ✔ Container komodo-mongo-1 Running 0.0s ✔ Container komodo-core-1 Running 0.0s ✔️ Updated Komodo /dev/fd/63: line 1289: CT_TYPE: unbound variable ``` Fortunately, this does not affect the Komodo installation :-). Thank you in advance for your help! ### 🔄 Steps to reproduce the issue. Update an exciting installation on Debian 12 bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/komodo.sh)" ### ❌ Paste the full error output (if available). /dev/fd/63: line 1289: CT_TYPE: unbound variable ### 🖼️ Additional context (optional). _No response_
saavagebueno added the buginvestigation labels 2025-11-20 04:57:38 -05:00
saavagebueno commented 2025-11-20 04:57:39 -05:00
Author
Owner
Copy Link

@Kickbut101 commented on GitHub (Apr 28, 2025):

this is kind of an odd setup and install through the scripts. It should be targeting the "mongo.compose.yaml" file instead of the "compose.env" file.

Maybe this should have a change in the install script too to make it more obvious that the db.compose file is the main stack?

Files inside /opt/komodo

Image

@Kickbut101 commented on GitHub (Apr 28, 2025): this is kind of an odd setup and install through the scripts. It *should* be targeting the "mongo.compose.yaml" file instead of the "compose.env" file. Maybe this should have a change in the install script too to make it more obvious that the db.compose file is the main stack? Files inside /opt/komodo ![Image](https://github.com/user-attachments/assets/6b56975b-7638-41f4-8e36-6adacc243b23)
saavagebueno commented 2025-11-20 04:57:39 -05:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Apr 28, 2025):

@Kickbut101 I'm not sure whats your point? docker compose uses mongo.compose.yaml and we pass it compose.env as environment file.
Its literaly in the mongo.compose.yaml:

env_file: ./compose.env

And we know which compose file was installed, because we check for it:

msg_info "Updating ${APP}"
    COMPOSE_FILE=""
    for file in /opt/komodo/*.compose.yaml; do
        if [[ "$file" != "compose.env" ]]; then
            COMPOSE_FILE="${file#/opt/komodo/}"
            break
        fi
    done
@tremor021 commented on GitHub (Apr 28, 2025): @Kickbut101 I'm not sure whats your point? docker compose uses `mongo.compose.yaml` and we pass it `compose.env` as environment file. Its literaly in the `mongo.compose.yaml`: `env_file: ./compose.env` And we know which compose file was installed, because we check for it: ```bash msg_info "Updating ${APP}" COMPOSE_FILE="" for file in /opt/komodo/*.compose.yaml; do if [[ "$file" != "compose.env" ]]; then COMPOSE_FILE="${file#/opt/komodo/}" break fi done ```
saavagebueno commented 2025-11-20 04:57:39 -05:00
Author
Owner
Copy Link

@Kickbut101 commented on GitHub (Apr 28, 2025):

@Kickbut101 I'm not sure whats your point? docker compose uses mongo.compose.yaml and we pass it compose.env as environment file. Its literaly in the mongo.compose.yaml:

env_file: ./compose.env

And we know which compose file was installed, because we check for it:

msg_info "Updating ${APP}"
COMPOSE_FILE=""
for file in /opt/komodo/*.compose.yaml; do
if ; then
COMPOSE_FILE="${file#/opt/komodo/}"
break
fi
done

You're right, that's my bad I read that line as /opt/komodo/*.compose.env when I first skimmed it. Sorry!

@Kickbut101 commented on GitHub (Apr 28, 2025): > [@Kickbut101](https://github.com/Kickbut101) I'm not sure whats your point? docker compose uses `mongo.compose.yaml` and we pass it `compose.env` as environment file. Its literaly in the `mongo.compose.yaml`: > > `env_file: ./compose.env` > > And we know which compose file was installed, because we check for it: > > msg_info "Updating ${APP}" > COMPOSE_FILE="" > for file in /opt/komodo/*.compose.yaml; do > if [[ "$file" != "compose.env" ]]; then > COMPOSE_FILE="${file#/opt/komodo/}" > break > fi > done You're right, that's my bad I read that line as /opt/komodo/*.compose.env when I first skimmed it. Sorry!
saavagebueno commented 2025-11-20 04:57:39 -05:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Apr 28, 2025):

Yes, which compose file will be installed depends on user choice, but yea, we check which one it is anyway so we can update without issues.

@tremor021 commented on GitHub (Apr 28, 2025): Yes, which compose file will be installed depends on user choice, but yea, we check which one it is anyway so we can update without issues.
saavagebueno commented 2025-11-20 04:57:39 -05:00
Author
Owner
Copy Link

@adn34 commented on GitHub (Apr 30, 2025):

I can report having the same output when trying to update komodo and the komodo version not being updated despite the output saying it is.

/dev/fd/63: line 1268: CT_TYPE: unbound variable

@adn34 commented on GitHub (Apr 30, 2025): I can report having the same output when trying to update komodo and the komodo version not being updated despite the output saying it is. > /dev/fd/63: line 1268: CT_TYPE: unbound variable
saavagebueno commented 2025-11-20 04:57:40 -05:00
Author
Owner
Copy Link

@mad2moons commented on GitHub (Apr 30, 2025):

I can also report that I am having exactly the same error when running update.

/dev/fd/63: line 1268: CT_TYPE: unbound variable

@mad2moons commented on GitHub (Apr 30, 2025): I can also report that I am having exactly the same error when running update. /dev/fd/63: line 1268: CT_TYPE: unbound variable
saavagebueno commented 2025-11-20 04:57:40 -05:00
Author
Owner
Copy Link

@MickLesk commented on GitHub (Apr 30, 2025):

The error can be ignored, but the update still worked. Maybe fixed next week.

@MickLesk commented on GitHub (Apr 30, 2025): The error can be ignored, but the update still worked. Maybe fixed next week.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
🛑 Failure to comply with the guidelines
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
Implemented in VED waiting push to Main
in project pipeline
invalid
investigation
json
maintenance
new script
new script
nice to have
not a script issue
not planned
organization
pull-request
Mirrored from GitHub Pull Request
 question
refactor
rename script
security
update script
website
wontdo
No Label bug investigation
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/ProxmoxVE#986
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?