Can’t get start-cli to work in Kapsule (KDE Linux)

Help
1

I set up the service packaging environment according to the offical Start9 docs ( Environment Setup - Service Packaging ), but when checking the versions of all components at the end, I always get the message “start-cli: not found”.

Even tho after running the automated installer script it says “Installation succesful” and “start-cli is ready”.

I’m using KDE Linux (kde-linux_202605120254) and tried to setup this environment inside of a Kapsule container running Ubuntu 26.04 LTS.

I already posted this problem on the Start9 forum, but still couldn’t get it working. Also there are some more details in the forum thread already:

Any ideas on how to get it working?

2

Woah… I’ve never heard of Start9 before, but it would help to understand exactly what you’re trying to do. We need to decide if the usecase makes sense for KDE Linux before we investigate and (potentially) modify Kapsule to make it work.

According to their website, it’s a server OS for people to selfhost things easily. Why are you trying to run that in your desktop KDE Linux?

3

Start9 is the company and StartOS is their server operating system.

What I’m trying to do is package services (.s9pk) for my server. The process of setting up the necessary environment is described in the docs I linked in my first post. Therefore I need to be able to use the start-cli, which I currently couldn’t get working in Kapsule.

So, I’m not trying to setup the server itself in Kapsule, but only the development/packaging environment for the services.

I hope this explanation helps to understand my use case :sweat_smile:

4

Any news on how to get it working or would would need to chance for Kapsule? :sweat_smile:

5

Looking at the linked thread, it seems to boil down to the fact that $PATH in the Ubuntu container doesn’t automatically include ~/.local/bin.

A couple of followups on your thread there:

  1. Did the added line actually make it to ~/.bashrc? i.e. if you cat ~/.bashrc, do you see the line you tried to add?
  2. If source ~/.bashrc doesn’t work, does . ~/.bashrc (which should be synonymous) work instead?

That said, if the Kapsule shares your normal home directory, it’s a bit awkward to be editing your main ~/.bashrc for the sake of making the Ubuntu Kapsule work.

6
  1. Yes, the line was added in ~/.bashrc.
  2. . ~/.bashrc also doesn’t work inside the Kapsule.

I know it might be an edge use case that not a lot of people need, but from my understanding Kapsule should “remove” the disadvantages of an immutable distro by making use cases like that possible and feel like on a native mutable distro. So I think it’s important to get that stuff working and that’s why I posted this thread in the first place.

Maybe somebody could try to replicate my problem by following the installation instructions. Of course it could be, that I just made a silly mistake, but I tried it at least 3 times now already :sweat_smile:

7

I don’t think that’s necessary really - from the troubleshooting you already did on your thread on the Start9 forum, it seems clear what is happening:

  1. You install the software in an Ubuntu Kapsule using the installer script provided by Start9.
  2. This installs the binary to ~/.local/bin.
  3. The software does indeed get installed there, because executing /home/mark/.local/bin/start-cli --version gives the expected output.
  4. But you want to be able to invoke the program just by using start-cli without an explicit path. That doesn’t work - if you do start-cli --version then you get a not found error.
  5. That’s explained by the fact that your PATH in the Ubuntu Kapsule doesn’t include ~/.local/bin - as you checked and confirmed in the linked thread. (Contrast that to your host KDE Linux environment, where your PATH likely does include ~/.local/bin unless you consciously did something to remove it.)

Now, Kapsule passes most environment variables from the host into the container, but it explicitly doesn’t include PATH. (In fact, even if PATH wasn’t in that exclude list, Ubuntu still would overwrite the passed-through value.)

I can imagine various ways to modify the PATH within your container. But at this point I’d like to step back and ask the Kapsule devs: what’s the intended way for someone to use their Ubuntu Kapsule to run a program installed into ~/.local/bin?

8

Could you provide me with your preferred way to do it, so I can get it working?

9

So one way would be to create a file in the container, /etc/profile.d/20-path.sh, with content:

export PATH="$PATH:$HOME/.local/bin"

i suggest this way of doing it because you don’t need to touch any scripts in your homedir, which is shared between KDE Linux and the container.

10

Works, thank you!

But I would also still be interested if Kapsule can add something like this by default or what the intended way by the Kapsule devs would be?

11

Right!

Generically, when you start up a shell, you have a bunch of environment variables from various sources. Oversimplifying it, some of them come from system-wide config in /etc, while others come from files in your home directory (such as ~/.bashrc and so on, depending on your distro and shell).

Now, by default, Kapsule mounts your home directory from the host machine as the home directory in the container. So the environment you’ll get comes from the container’s /etc but from the host homedir.

Looking at the specific case here: actually, both KDE Linux and Ubuntu intend for ~/.local/bin to be in your PATH. But Ubuntu does this through ~/.profile in the homedir, whereas KDE Linux does it through a file in /etc (specifically /etc/profile.d/99-local-precedence.sh).

As we were saying: when you start your shell in the Kapsule container, you’ve got /etc from Ubuntu, but a homedir from the KDE Linux host. And neither of those adds ~/.local/bin to the path.

So I too am interested in what the intended approach is to this “mixed environment” situation.