[error] failed to relocate zsh (RHEL7 and CentOS 7)

Question

[error] failed to relocate zsh (RHEL7 and CentOS 7)

gipert opened this issue 4 years ago · 21 comments

Hi! I'm trying to install on a remote server where I don't have root access. I'm getting the following error:

$ ./install
Choose installation directory for Zsh 5.8:

  (1)  /usr/local        <= uses sudo (recommended)
  (2)  ~/.local          <= does not need sudo
  (3)  Custom directory.
  (q)  Quit and do nothing.

Choice [123q]: 2

===> installing Zsh 5.8 to /home/ge28fok/.local
===> fetching zsh-5.8-linux-x86_64.tar.gz
===> verifying archive integrity
===> sha256 signature matches
===> md5 signature matches
===> extracting files
[error] failed to relocate zsh

Which comes from zsh itself, if I'm not mistaken. Have you ever seen this before? Any suggestions on what could cause the issue or how to debug it further? Thanks so much in advance for helping.

Answer 1 · 2021-01-14T16:31:01.000Z

What OS is this?

Answer 2 · 2021-01-14T17:12:05.000Z

Oh right, sorry for not pointing that out. It's a RHEL7 server.

Answer 3 · 2021-10-25T07:40:42.000Z

Facing the same issue on CentOS 7.

Answer 4 · 2021-10-25T08:36:54.000Z

Just to add: I experience the problem in all CentOS servers I usually work on. So it looks like an OS-specific issue. Would be great to know how to get around this since CentOS is such a common HPC distribution!

Answer 5 · 2021-10-25T12:37:30.000Z

I cannot reproduce this in the official centos7 docker container. Here's what I've tried:

% docker run -e TERM -it --rm centos:centos7 bash
[root@a25cbb17346d /]# curl -fsSLO https://raw.githubusercontent.com/romkatv/zsh-bin/master/install
[root@a25cbb17346d /]# sh ./install -d ~/.local -e no
===> installing Zsh 5.8 to /root/.local
===> fetching zsh-5.8-linux-x86_64.tar.gz
===> verifying archive integrity
===> sha256 signature matches
===> md5 signature matches
===> extracting files

Installed Zsh 5.8 to /root/.local

To start Zsh, type:

  export PATH="/root/.local/bin:$PATH"
  zsh

[root@a25cbb17346d /]# export PATH="/root/.local/bin:$PATH"
[root@a25cbb17346d /]# zsh
a25cbb17346d# ls -l /proc/$$/exe
lrwxrwxrwx 1 root root 0 Oct 25 12:35 /proc/184/exe -> /root/.local/bin/zsh

If I start with the docker command as above, what do I need to run in the container before installing zsh-bin to get the same error as you?

Answer 6 · 2021-10-27T10:06:24.000Z

Hi @romkatv, after some research I think I managed to pin this down. I get the error when I try to run the install wizard from within a zsh shell. With bash, the procedure works. Can you reproduce?

Answer 7 · 2021-10-27T10:18:12.000Z

This works:

% docker run -e TERM -it --rm centos:centos7 bash
[root@94be1666aad7 /]# yum install -y zsh
[root@94be1666aad7 /]# zsh
[root@94be1666aad7]/# curl -fsSLO https://raw.githubusercontent.com/romkatv/zsh-bin/master/install
[root@94be1666aad7]/# sh ./install -d ~/.local -e no
===> installing Zsh 5.8 to /root/.local
===> fetching zsh-5.8-linux-x86_64.tar.gz
===> verifying archive integrity
===> sha256 signature matches
===> md5 signature matches
===> extracting files

Installed Zsh 5.8 to /root/.local

To start Zsh, type:

  export PATH="/root/.local/bin:$PATH"
  zsh

[root@94be1666aad7]/# export PATH="/root/.local/bin:$PATH"
[root@94be1666aad7]/# zsh
94be1666aad7# ls -l /proc/$$/exe
lrwxrwxrwx 1 root root 0 Oct 27 10:16 /proc/230/exe -> /root/.local/bin/zsh

Answer 8 · 2021-10-28T09:20:13.000Z

As an additional test I've created a centos7 droplet on DigitalOcean. zsh-bin works fine there, too.

There is something on your machine(s) that breaks zsh-bin. I need to know what it is before I can do anything.

Answer 9 · 2021-10-28T16:59:35.000Z

I tested this on my laptop running Arch:

$ cat /etc/os-release
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://www.archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux

And I get the same (/usr/bin/zsh is my default shell):

$ echo $SHELL
/usr/bin/zsh
$ curl -fsSLO https://raw.githubusercontent.com/romkatv/zsh-bin/master/install
$ sh ./install -d ~/.local -e no
===> installing Zsh 5.8 to /home/gipert/.local
===> fetching zsh-5.8-linux-x86_64.tar.gz
===> verifying archive integrity
===> sha256 signature matches
===> md5 signature matches
===> extracting files
[error] failed to relocate zsh

I really have no clue what special setting (in common with remote machines running different distros and managed by other people) could be causing this. Maybe a zsh config? I've got no clue how to debug this, what can I try?

Answer 10 · 2021-10-28T17:05:05.000Z

Did you install arch on your laptop yourself? If yes, how? If no, where did you get it? (I really hate remote debugging. If I cannot reproduce this, your best bet is to try to debug by yourself.)

Answer 11 · 2021-11-04T08:41:05.000Z

Perhaps you are using a confined SELinux user who's not allowed to execute files in the home directory? Can you ask an admin to check /var/log/messages on that machine after you try (and fail) to install zsh-bin?

Answer 12 · 2021-11-04T08:42:23.000Z

You can run id -Z to check whether you are logged in as a confined SELinux user.

Answer 13 · 2021-11-04T17:33:13.000Z

You can run id -Z to check whether you are logged in as a confined SELinux user.

id: --context (-Z) works only on an SELinux-enabled kernel

Does not look like to be the case...

Sorry for the slowness but it's hard in this moment to find time to debug this by myself. I will let you know if I discover anything new. Since zsh-bin works if I use bash, for me the problem is solved. Feel free to close this issue, if you think it should be closed. Thanks!

Answer 14 · 2021-12-02T19:56:48.000Z

I get the same error as well.

Choose installation directory for Zsh 5.8:

(1) /usr/local <= uses sudo (recommended)
(2) ~/.local <= does not need sudo
(3) Custom directory.
(q) Quit and do nothing.

Choice [123q]: 2

===> installing Zsh 5.8 to /home/j587yang/.local
===> fetching zsh-5.8-linux-x86_64.tar.gz
===> verifying archive integrity
===> sha256 signature matches
===> md5 signature matches
===> extracting files
[error] failed to relocate zsh

OS information:

NAME="Rocky Linux"
VERSION="8.4 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.4"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Rocky Linux 8.4 (Green Obsidian)"

Output of id -Z

unconfined_u:unconfined_r:unconfined_t:s0

Answer 15 · 2021-12-02T20:07:29.000Z

I don't intend to do anything here until someone provides instructions that allow me to reproduce this.

Answer 16 · 2022-06-08T18:11:57.000Z

I had the same issue on an HPC CentOS7 server which after some troubleshooting was due to the presence of FPATH in my environment. This caused the current value of FPATH to be used for fpath and fail the check at the end of the relocate script. Unsetting this variable prior to running the install script allowed the installer to work and the zsh appears to be functional, as long as FPATH is not set when it is run (which I think would break normal zsh anyway).

Answer 17 · 2022-06-09T07:38:20.000Z

@jgoodson Thanks a ton! I've reproduced and fixed this.

Note that you should never export special zsh parameters such as FPATH or PS1. I highly recommend fixing whatever code is responsible for exporting FPATH on your system.

Answer 18 · 2022-06-09T14:11:12.000Z

Absolutely. Given the common aspects of the commenters, I would bet most or all of this is due to the presence of the lmod module system. At least the version of lmod I have exports an FPATH for utility ksh functions all supported shells that aren't zsh (since that breaks zsh). If you are already using zsh when your shell is initialized, you won't have this issue, but if you use anything else on a system with lmod configured normally, you'll have FPATH exported.

Answer 19 · 2022-06-09T14:29:18.000Z

Can anyone confirm that my fixed has resolved this issue?

Answer 20 · 2022-06-09T14:50:56.000Z

Thank you @romkatv and @jgoodson, the fix works on my end.

Answer 21 · 2022-06-09T14:51:51.000Z

Thanks for the verification. Closing as fixed.