`zvm upgrade` failure on ArchLinux
dogue opened this issue · comments
❯ zvm upgrade
There's a new version of ZVM (v0.4.0).
Run 'zvm upgrade' to install it!
Upgrading ZVM... 100% |██████████████████████████████████████████████████████████████████████████████████████████| (7.5/7.5 MB, 34 MB/s)
2023/11/02 18:52:55 ERRO this is a new command, and may have some issues. Consider reporting your problem on Github :) github=https://github.com/
tristanisham/zvm/issues
2023/11/02 18:52:55 FATA failed to self-upgrade zvm
rename /tmp/zvm-upgrade-2633282309/zvm /home/dogue/.zvm/self/zvm: invalid cross-device link
Was on 0.3.0, tried to upgrade and now my zvm installation appears to be broken. The .zvm folder is still in place but the shell can't find the actual zvm binary.
Doing a fresh install seems to have worked to repair my install.
❯ which zvm
/home/dogue/.zvm/self//zvm
Binary path, as requested on xitter
This is similar to the issue on Windows after fixing the unzipping issue. Thanks for posting this!
I don't know whether I understand that correctly but for me it doesn't seem like the Windows issue.
On Arch Linux and maybe on other distros /tmp is an tmpfs mount which resides in memory (quote).
os.Rename won't work in this case and you need to find another solution for this.
When you already knew that it was failing because of this: just ignore this comment.
I did not know that was the case on Arch. Is /tmp really stored in memory? I just thought it was on disk and wiped during a subsequent boot process. Anyway, test primarily on Debian and haven't had an issue with the current upgrade code. Do they differ in how /tmp is managed?
That appears to be correct. My machine has 32GB and df reports /tmp as being a 32GB tmpfs.
tmpfs 32G 6.5M 32G 1% /tmp
I just saw the help wanted label.
What kind of help do you need?
Isn't the solution to simply replace the usage of the os.Rename by a function that works over partition boundries?
I think so? I haven't had time to diagnose this issue fully, thus the help wanted badge.
What're your applicable solutions?
also on openSUSE Tumbleweed, where /tmp is also tmpfs
i have this problem too. in my case i have / (including /tmp) mounted on a separate partition to /home
@xtexChooser @darccyy @dogue Could one of you guys clone from the most recent master, change the version in cli/meta/version.go to something less than the current version, build, and run ZVM_DEBUG=1 zvm upgrade and let me know if it works?
I updated the upgrade to now just use ~/.zvm as the temp dir and updated clean to take care of the upgrade files (It'll call it right after upgrading). It works on my machine, but, ya know.
I can as soon as I fix a no-boot condition.
~/Projects/External/zvm master* 50s
❯ go install .
~/Projects/External/zvm master*
❯ zvm version
v0.4.9
~/Projects/External/zvm master*
❯ ZVM_DEBUG=1 zvm upgrade
You are on ZVM v0.4.9... upgrading to (v0.5.0)2024/01/30 19:06:27 DEBU exe dir path=/home/dogue/.zvm/self
2024/01/30 19:06:27 DEBU tempDir name=/home/dogue/.zvm/4259791209.tar
Upgrading ZVM... 100% |██████████████████████████████████████████████████████████████████████████████████████████| (8.0/8.0 MB, 37 MB/s)
2024/01/30 19:06:28 DEBU zvmPath path=/home/dogue/.zvm/self/zvm
2024/01/30 19:06:28 DEBU untar tarball=/home/dogue/.zvm/4259791209.tar target=/home/dogue/.zvm/zvm-upgrade-1973702191
~/Projects/External/zvm master*
❯
@dogue what version of ZVM do you have installed now (if you just run zvm version off the zvm installed at .zvm/self/zvm?
0.5.0 😁
i was previously using the AUR version (listed as 0.5.0-1 on the AUR, but zvm version returns v0.4.2).
i installed v0.4.1 from manually from releases, and it had the same issue.
Isn't the solution to simply replace the usage of the
os.Renameby a function that works over partition boundries?
This sounds right to me 😄
Okay, so it worked correctly. @darccyy could you please try the same thing? You don't have to install zvm like @dogue did. You can just run go build and it'll build in the directory. It'll only update the binary it's called from if the install directory envs are changed. Really an option for people who have weird circumstances on their machine.
it seems to have worked😄
yeah it worked!
xtex@xtex /m/s/w/zvm (master)> g s
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
xtex@xtex /m/s/w/zvm (master)> go build .
xtex@xtex /m/s/w/zvm (master)> ./zvm version
v0.5.1
xtex@xtex /m/s/w/zvm (master)> nvim cli/meta/version.go
xtex@xtex /m/s/w/zvm (master)> bat cli/meta/version.go
───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
│ File: cli/meta/version.go
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
1 │ package meta
2 │
3 ~ │ const VERSION = "v0.4.1"
4 │
───────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
xtex@xtex /m/s/w/zvm (master)> go build .
xtex@xtex /m/s/w/zvm (master)> ./zvm version
v0.4.1
xtex@xtex /m/s/w/zvm (master)> ./zvm upgrade
You are on ZVM v0.4.1... upgrading to (v0.5.0)^C⏎ xtex@xtex /m/s/w/zvm (master) [SIGINT]> ZVM_DEBUG=1 zvm upgrade
You are already on the latest release (v0.5.0) of ZVM :)
xtex@xtex /m/s/w/zvm (master)> ZVM_DEBUG=1 ./zvm upgrade
You are on ZVM v0.4.1... upgrading to (v0.5.0)2024/01/31 09:23:21 DEBU exe dir path=/opt/zvm/self
2024/01/31 09:23:22 DEBU tempDir name=/home/xtex/.zvm/1700388745.tar
Upgrading ZVM... 100% |█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| (8.0/8.0 MB, 28 MB/s)
2024/01/31 09:23:23 DEBU zvmPath path=/opt/zvm/self/zvm
2024/01/31 09:23:23 DEBU untar tarball=/home/xtex/.zvm/1700388745.tar target=/home/xtex/.zvm/zvm-upgrade-1526013367
Okay, so it worked correctly. @darccyy could you please try the same thing? You don't have to install zvm like @dogue did. You can just run
go buildand it'll build in the directory. It'll only update the binary it's called from if the install directory envs are changed. Really an option for people who have weird circumstances on their machine.
Yeah I'm still a Go noob but I removed that version and verified that everything is good in ~/.zvm
Thanks @dogue! You really helped me out tonight,
@xtexChooser Thank you so much for helping out. You helped a ton. All three of you are awesome.