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:
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
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
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.