Do I have to add a path environment variable to include files in /opt/*?

As i understand from reading the forums the process for adding environment variables systemwide is a bit different in openSUSE.

So I created a file “/etc/profile.local” but I am unsure what exactly to add here… (I want applications to find files in /opt/rocm/*)

Trying to install ROCm to use opencl with my ATI RX 6600 I jumped to a few hoops to install ROCm on Tumbleweed and now it loads successfully also “rosm-smi” shows me it’s activated and working.

AMD suggest to add

export PATH=$PATH:/opt/rocm-5.4/bin:/opt/rocm-5.4.0/opencl/bin

to the environment profile.

Is this even necessary? Shouldn’t Tumbleweed access libaries and executable files in subfolders of “/opt” by default?

Also I am not sure how exactly to add to “/etc/profile.local”…
Do I need the “export” command like in “.bashrc”?
or just the “PATH=xyz” designation?

As it is now the application I try to install (invokeai) doesn’t seem to find the ROCm libs and “code objects”… - but this might have other reasons - I am in the process of troubleshooting here at the moment…

(I am well aware that ROCm will be hit and miss in it’s current state!
But here that’s not my point - here I try to learn about the recommended way to configure basic stuff in Tumbleweed…)

Thanks for reading,

@jhhh Hi, nope it needs to be added, for the libraries etc the install should put a conf file in /etc/ for the system to know where external libraries are and run ldconfig to update the cache.

For example (I use cuda) so see;

cat /etc/

Update your ~/.profile, for me and cuda I add;

export PATH="$PATH:/usr/local/cuda/bin"

You can then just open a new terminal session and check if it’s there with;

echo $PATH

Probably not – the Linux File Hierarchy Standard only mentions that, /opt is a system directory for –

the installation of add-on application software packages

On the other hand, /usr/local is a system directory for use as follows –

for use by the system administrator when installing software locally

One of the main differences is, ‘/usr/local/bin’ is included by default in PATH but, /opt isn’t.

  • Therefore, packages installed under /opt have to take care that, the directory where the application’s executable file is located, is included in the PATH variable …

Thank you!

I wasn’t aware of that applications put their profiles into “/etc/” - I always assumed that these applications find the path because is “/opt” is in the path anyway - and I never checked…

For the local .profile I ahve been successful, always added a lot there…

So what about system wide use of the variables - is “/etc/profile.local” the correct file to add them to? So that paths are exported during system boot?

Or should systemd be used?

Well, at least for my user ROCm binaries are now found and used!

Unrelated question as I see you use CUDA:
Do you know if the GPU memory reserved by openCL is locked even if not used by any application (so not available as “normal” graphics memory)?

Or is it only ready to be used by openCL but can be freed temporarily by other applications which do not need it?

Thanks a lot!

@jhhh I have a separate gpu (Tesla P4) that is used via switcherooctl but either card (primary is a Quadro T400) it’s used on the fly by the application(s) in use…

Mon Mar 13 12:34:09 2023       
| NVIDIA-SMI 530.30.02              Driver Version: 530.30.02    CUDA Version: 12.1     |
| GPU  Name                  Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf            Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|   0  NVIDIA T400                     Off| 00000000:02:00.0 Off |                  N/A |
| 38%   41C    P8               N/A /  31W|    530MiB /  2048MiB |     12%      Default |
|                                         |                      |                  N/A |
|   1  Tesla P4                        Off| 00000000:03:00.0 Off |                    0 |
| N/A   31C    P8                6W /  75W|     46MiB /  7680MiB |      0%      Default |
|                                         |                      |                  N/A |
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|    0   N/A  N/A      1828      G   /usr/bin/Xorg.bin                           215MiB |
|    0   N/A  N/A      2046      G   /usr/bin/gnome-shell                         67MiB |
|    0   N/A  N/A      3748      G   ...,WinRetrieveSuggestionsOnlyOnDemand       69MiB |
|    0   N/A  N/A     10490      G   ...40434222,8245604340082411919,131072      102MiB |
|    1   N/A  N/A      1828      G   /usr/bin/Xorg.bin                            46MiB |

That is a cool setup!

I have an older nvidia which is not in use - maybe my best bet is to put in my box and use cuda for opencl.

Just turned out that invokeai crashes on my version of ROCm…

Oh my these time sinking rabbit holes…


@jhhh I had a RX550 that worked ok, then when added an nvidia card as well it stopped working, hence switching to all Nvidia.

Yes, ‘/etc/profile.local’ is the correct place but, the only documentation is in the openSUSE ‘/etc/profile’ file itself –

# PLEASE DO NOT CHANGE /etc/profile. There are chances that your changes
# will be lost during system upgrades. Instead use /etc/profile.local for
# your local settings, favourite global aliases, VISUAL and EDITOR
# variables, etc ...

Yet another reason for not editing system configuration files placed in ‘/etc’ by the distribution …

Please be aware of the related Bash man page entries –

   When  bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it
   first reads and executes commands from the file /etc/profile, if that file exists.  After reading  that  file,
   it  looks  for  ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands
   from the first one that exists and is readable.  The --noprofile option may be used when the shell is  started
   to  inhibit this behavior.  Please note that the file /etc/profile includes an autodetection shell code wether
   it has to source /etc/bash.bashrc as well as ~/.bashrc.

Your question related to paths being exported at system boot time is possibly answered as follows:

  • Paths defined by entries in “Profile” files are not exported at boot time.
    The file is called at user login and, the Path is exported at that point in time to the user’s session.

  • Yes, there is a systemd “” and, there are “systemd.path” units but, that’s a systemd specific issue which is only related to the boot process as such …


Some more information related to “PATH” –

  • From “UNIX® for the Impatient” – Paul W. Abrahams and Bruce A. Larson – published by Addison-Wesley:

2.6.5 Environment Variables
Each process has a set of environment variables associated with it.

2.9.2 The PATH Environment Variable
Programs and other executable files can reside in many different directories. UNIX® therefore provides a search path for executable files so that you don’t need to remember (and type) the pathname of each command that you execute. The search path is recorded in the environment variable PATH which you can examine by typing

echo $PATH

Yes, yes, I know, there is an awful amount of material which proclaims that, there’s another explanation of what a “Path” is – in other operating systems – which are usually not related to UNIX®.

  • Strangely, there doesn’t seem to be a Linux Standards definition of the PATH Environment Variable – it’s possibly defined in the source code …

It is not clear what the context the quoted text from chapter 2.9.2 is (e.g. what is the subject of 2.9 where it is part from), but as it is quoted here it is a bit loose explanation IMHO.

It is not really Unix that provides the search path and the interpretation of the PATH variable. The usage of a PATH variable (like all other process environment variables) is defined in the program that interprets it. I assume that in this thread we are talking about the program called bash. And thus the documentation (man page) of bash is where to go about all details of how bash uses it and also about the mechanisms that are offered in bash to create it’s value to one’s needs.

BTW most other shells offer the same (or almost the same) about PATH. And of course other programs may do so when they want to. Problems may arise when different programs support different interpretations of an environment variable.

Absolutely –

  • stdlib” defines the “realpath” function:

return the canonicalized absolute pathname

  • libgen” defines the “basename” and “dirname” functions:

The functions dirname() and basename() break a null-terminated pathname string into directory and filename components.

Be that as it may, for most users the PATH Environment Variable is defined by the Shell they’re using – by default when they login, the 7th field of their entry in ‘/etc/passwd’:


Sorry, I fail to see the connection between the PATH environment variable and the basename and dirname functions that in fact cut of on the last / in a pathname as offered to the user in the basename and dirname tools.

henk@boven:~> basename a/b/c/d
henk@boven:~> dirname a/b/c/d

The PATH Environment Variable (EV) defines a list of paths – as a convenience …

 > realpath /bin/ls
 > basename /bin/ls
 > dirname /bin/ls

Each user’s PATH EV defines at least the following system paths:


In other words both ‘/usr/bin’ and ‘/bin’ –

  • Taking the example of the “ls” CLI command –
    The “ls” in ‘/bin’ is a link to the “real” copy of “ls” located in ‘/usr/bin’ …

Taking the shell as an example of a program – when a command which isn’t a “built-in” command, is given to a shell, the shell will search, in one order or another, the paths listed in the PATH EV for a program with the same name as that typed by the user.

  • If the shell is cautious, it’ll call “realpath” to check if the program found is really located in the indicated directory or, somewhere else …
    A cautious shell will issue a warning with respect to the location of the program being called.