Modules.sh: line 11: uname: command not found error after upgrade to Fedora 33

After upgrading to Fedora 33, whenever I try a scp, or even scheduled crons

 scp root@myserver:/etc/profile.d/modules.sh .
/etc/profile.d/modules.sh: line 11: uname: command not found                                                                                                                                                             

So on the F33 server:

file /etc/profile.d/modules.sh
/etc/profile.d/modules.sh: symbolic link to /etc/alternatives/modules.sh

file /etc/alternatives/modules.sh
/etc/alternatives/modules.sh: symbolic link to /usr/share/lmod/lmod/init/profile

So the first part of the profile file is:

 /usr/share/lmod/lmod/init/profile
########################################################################
. /etc/profile.d/00-modulepath.sh

#  This is the system wide source file for setting up modules
########################################################################

if [ -z "${USER_IS_ROOT:-}" ]; then

  if [ -z "${MODULEPATH_ROOT:-}" ]; then
    export USER=${USER-${LOGNAME}}  # make sure $USER is set
    export LMOD_sys=`uname`

    export MODULEPATH_ROOT="/usr/share/modulefiles"
    MODULEPATH_INIT="/usr/share/lmod/lmod/init/.modulespath"
    if [ -f ${MODULEPATH_INIT} ]; then
       for str in $(cat ${MODULEPATH_INIT} | sed 's/#.*$//'); do   # Allow end-of-line comments.
          for dir in $str; do
              if [ -d $dir ]; then
                  export MODULEPATH=$(/usr/share/lmod/lmod/libexec/addto --append MODULEPATH $dir)
              fi
          done
       done
    else
       export MODULEPATH=$(/usr/share/lmod/lmod/libexec/addto --append MODULEPATH $MODULEPATH_ROOT/$LMOD_sys $MODULEPATH_ROOT/Core)
       export MODULEPATH=$(/usr/share/lmod/lmod/libexec/addto --append MODULEPATH /usr/share/lmod/lmod/modulefiles/Core)
    fi

So I believe this is for OpenMPI

module avail

---------------------------------------------------------------------------------------- /usr/share/modulefiles -----------------------------------------------------------------------------------------
   mp-x86_64    mpi/mpich-x86_64    mpi/openmpi-x86_64 (D)

--------------------------------------------------------------------------------- /usr/share/lmod/lmod/modulefiles/Core ---------------------------------------------------------------------------------
   lmod    settarg

  Where:
   D:  Default Module

Use "module spider" to find all possible modules and extensions.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".

This error does not happen if you scp directly from the Fedora 33 server. Only when you scp from another server where the source is on the F33 server. Since Line 11 is:

export LMOD_sys=uname

What’s the fix?

Edit: similar issue here albeit on Mint.

1 Like
sudo dnf install coreutils
sudo dnf provides \*/bin/uname

Are you suggesting uname is not installed? No, I believe this is something with the environment variables set in the profile.sh file and scp is not finding where uname is installed:

# dnf install coreutils
Last metadata expiration check: 2:12:29 ago on Tue 12 Jan 2021 05:34:39 PM EST.
Package coreutils-8.32-12.fc33.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

# sudo dnf provides \*/bin/uname
Last metadata expiration check: 2:12:35 ago on Tue 12 Jan 2021 05:34:39 PM EST.
coreutils-8.32-12.fc33.x86_64 : A set of basic GNU tools
                              : commonly used in shell scripts
Repo        : @System
Matched from:
Filename    : /usr/bin/uname

coreutils-8.32-12.fc33.x86_64 : A set of basic GNU tools
                              : commonly used in shell scripts
Repo        : fedora
Matched from:
Filename    : /usr/bin/uname

coreutils-single-8.32-12.fc33.x86_64 : coreutils multicall
                                     : binary
Repo        : fedora
Matched from:
Filename    : /usr/bin/uname

rr-testsuite-5.3.0-19.20200828gitb53e4d9.fc33.x86_64 :
     ...: Testsuite for checking rr functionality
Repo        : fedora
Matched from:
Filename    : /usr/lib64/rr/testsuite/obj/bin/uname

rr-testsuite-5.4.0-1.fc33.x86_64 : Testsuite for checking rr
                                 : functionality
Repo        : updates
Matched from:
Filename    : /usr/lib64/rr/testsuite/obj/bin/uname

# which uname
/usr/bin/uname
1 Like

It shouldn’t make a difference but have you tried

     LMOD_sys=`uname`; export LMOD_sys

Yes still the same. Here are results from scp -vvv

debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env HISTCONTROL
debug3: Ignored env HISTSIZE
debug3: Ignored env HOSTNAME
debug3: Ignored env EDITOR
debug3: Ignored env PWD
debug3: Ignored env LOGNAME
debug3: Ignored env XDG_SESSION_TYPE
debug3: Ignored env TZ
debug3: Ignored env MOTD_SHOWN
debug3: Ignored env HOME
debug3: Ignored env SSH_ASKPASS
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env LS_COLORS
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env MOZ_GMP_PATH
debug3: Ignored env XDG_SESSION_CLASS
debug3: Ignored env TERM
debug3: Ignored env LESSOPEN
debug3: Ignored env USER
debug3: Ignored env DISPLAY
debug3: Ignored env SHLVL
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env SSH_CLIENT
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env PATH
debug3: Ignored env HISTIGNORE
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env MAIL
debug3: Ignored env SSH_TTY
debug3: Ignored env _
debug1: Sending command: scp -v -f /etc/profile
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd ext data 61
/etc/profile.d/modules.sh: line 12: uname: command not found
debug2: channel 0: written 61 to efd 6
debug2: channel 0: rcvd ext data 39
Sending file modes: C0644 1816 profile
debug2: channel 0: written 39 to efd 6
Sink: C0644 1816 profile
profile                                                                                                                                                                     100% 1816     1.6MB/s   00:00

So something is being ignored.

OK here is the work-around I used, putting full path to uname:

LMOD_sys=/usr/bin/uname; export LMOD_sys

1 Like

That tells me the incoming scp connection does not have the standard $PATH variable to use and needs the full path in the variable it does use - LMOD_sys

1 Like

Hmm but $PATH on the destination server (running scp) has it has it:

echo $PATH
/root/perl5/bin:/usr/share/Modules/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/opt/openmpi/bin

The users environment may have it defined, but it seems scp did not use that.

OK how to force scp to use that?

I think you have already found the problem, and bypassed the $PATH issue. I use rsync which runs using ssh and have never had an issue with paths nor access.