search

termux / proot

An chroot-like implementation using ptrace.
https://wiki.termux.com/wiki/PRoot
Other
774 stars 160 forks source link

[Bug]: Rust/Cargo problems after closing #250

Closed luciodaou closed 1 year ago

luciodaou commented 1 year ago

Problem description

Both cargo and the programs installed through it don't work after closing and opening a linux distro.

Tested 2 different phones on different android versions and different distros, getting the same result.

Cargo doesn't work after reopening, throwing the following error: the given reference name 'refs/remotes/origin/.l2s.HEAD.lock0001' is not valid; class=Reference (4) image

And the programs at ~/.cargo/bin doesn't work either, links are dead: image

What steps will reproduce the bug?

Install any distro Install rust/cargo through package manager or rustup Use cargo install <xxx> to install a rust program They'll work fine after installing Exit distro Run distro again Try to run one of the installed programs, it'll say command not found Check ~/.cargo/bin Links are dead

Using --shared-tmp flag makes no difference. Cargo can work again by removing its registry folder ~/.cargo/registry, but reinstalled programs still doesn't survive distro reopening.

What is the expected behavior?

No change cargo and programs installed by it after closing and reopening the distro.

luciodaou commented 1 year ago

Made a google search for the cargo error, found this issue, also involving proot-distro: https://github.com/wez/wezterm/issues/1329#issuecomment-974747913

Grimler91 commented 1 year ago

Try logging into the proot distro with --no-link2symlink before cargo install and when logging out and logging in again. Might help (or make things worse) considering issue is with the hardlink -> symlink extension

luciodaou commented 1 year ago

Try logging into the proot distro with --no-link2symlink before cargo install and when logging out and logging in again. Might help (or make things worse) considering issue is with the hardlink -> symlink extension

Unfortunately it didn't work.

Looks like there's some instability going on /tmp. I made a search regarding "cargo tmp directory" and found this: https://stackoverflow.com/a/64616981 I'm investigating as apparently it needs to be declared before each run of cargo, so probably a solution would be creating an alias.

michalbednarski commented 1 year ago
  1. Make sure you don't nest proot (e.g. don't launch proot-distro when you're already in another distro or autostart termux-chroot)
  2. Sounds like this is some proot side issue, although with following commands I wasn't able to reproduce, are these sufficient to trigger bug on your side (Warning: first command wipes you current distro, but I'd need ability to reproduce issue from clean state)
proot-distro reset ubuntu
proot-distro login --isolated ubuntu -- apt update
proot-distro login --isolated ubuntu -- apt upgrade
proot-distro login --isolated ubuntu -- apt install cargo
proot-distro login --isolated ubuntu -- cargo install cargo-space
proot-distro login --isolated ubuntu -- /root/.cargo/bin/cargo-space
luciodaou commented 1 year ago

Looks like there's some instability going on /tmp. I made a search regarding "cargo tmp directory" and found this: https://stackoverflow.com/a/64616981 I'm investigating as apparently it needs to be declared before each run of cargo, so probably a solution would be creating an alias.

Update: this didn't solve the issue, still reappeared.

Try logging into the proot distro with --no-link2symlink before cargo install and when logging out and logging in again. Might help (or make things worse) considering issue is with the hardlink -> symlink extension

Unfortunately it didn't work.

  1. Make sure you don't nest proot (e.g. don't launch proot-distro when you're already in another distro or autostart termux-chroot)

Ok, I reviewed but it's not the case.

Sounds like this is some proot side issue, although with following commands I wasn't able to reproduce, are these sufficient to trigger bug on your side (Warning: first command wipes you current distro, but I'd need ability to reproduce issue from clean state)

Will check later, thanks for the instructions. I was using a Ubuntu installed a few months ago, with lots of stuff, way too messed up (and already deleted anyway) and a brand new installation of Arch. I did the check @Grimler91 mentioned on Arch.

luciodaou commented 1 year ago

So, after a throrough check on Ubuntu and Arch, no problems using --isolated flag. I'm closing the issue.

If you wanna investigate further, as the behavior may affect other software, feel free to reopen it!

Thanks once again.

BTW, just to keep a record: The tmp variable declaration is just a workaround and doesn't solve the problem. Even if declared before each time cargo is invoked, it doesn't stop the issue from happening, neither fix it, just reduces the number of times it happens.

michalbednarski commented 1 year ago

In that case I'm going to guess that resetting distro was the fix, probably because of issue fixed in #244 (although there could also be other proot-side fixes for avoiding creation of bad links)

luciodaou commented 1 year ago

In that case I'm going to guess that resetting distro was the fix, probably because of issue fixed in #244 (although there could also be other proot-side fixes for avoiding creation of bad links)

Yes, maybe --no-link2symlink would have worked too after the reset. Thanks for the tip regarding issue 244.