RUST – installation issue

Forum Forums General Software RUST – installation issue

This topic contains 16 replies, has 3 voices, and was last updated by BobC Jan 21-10:45 pm.

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #16867
    Member

    russellb23

    I have just moved to antiX from Debian (systemd nay sayer!). I am finding it very comfortable. I have had rust installed through “curl https://sh.rustup.rs -sSf | sh” under ‘root’. I have no issues after exporting the PATH variable from .bash_profile. However, I am encountering ‘bash: /home/rust/.cargo/bin/cargo: Permission denied’. I am not able to think of any clue other than that it is due to permisisons.

    My guess:

    I have created a separate home partition and mounting it through ‘/etc/fstab’. Could that be a reason? Having said that, My home folder contents permission as follows:

    total 20
    drwx—— 2 root root 16384 Jan 18 08:38 lost+found
    drwxr-xr-x 22 rust rust 4096 Jan 19 19:29 rust

    Could someone shed some light to troubleshoot/fix this?

    Many thanks in advance.

    Thanks for indicating the typo. It is indeed ‘rust’ directory and not ‘russellb’.

    Here goes my ‘fstab’ entry corresponding to the /home partition, if that could be of any help.

    # Mounting home partition
    /dev/sda4 /home ext4 rw,async,exec,users 0 0

    • This topic was modified 1 month ago by russellb23. Reason: corrected mistake

    entropy

    #16868
    Member

    BobC

    You are referring to a directory /home/rust but you don’t have that directory, just a directory /home/russellb which is owned by rust and group rust.

    Was there some reason you didn’t use the rust language in the repos that comes with automatic install stuff? I don’t know anything about rust, but it sounds like it might be possible that it shouldn’t have been installed as root?

    • This reply was modified 1 month ago by BobC.
    #16880
    Member

    russellb23

    You are referring to a directory /home/rust but you don’t have that directory, just a directory /home/russellb which is owned by rust and group rust.

    Was there some reason you didn’t use the rust language in the repos that comes with automatic install stuff? I don’t know anything about rust, but it sounds like it might be possible that it shouldn’t have been installed as root?

    Thank you BobC. I have corrected the typo. It should have been ‘rust’ rather than ‘russellb’.

    I tried installing rust as ‘root’ just to check am I encountering the same issue. But no. The reason why I am using the way I did install than from the repos is my way of doing can receive periodical updates of rust unlike updates provided through repos. I have had no issues installing and running rust this way under ‘Debian’. I am doubting is this something to do with separate /home partition?

    • This reply was modified 1 month ago by russellb23. Reason: improved reply content

    entropy

    #16887
    Member

    BobC

    When you sign on, do you sign on as rust, then?

    My guess would be that if your user id is rust, all should be normal, and if not, I wouldn’t be surprised if there were permission issues. Even being a member of group rust won’t allow you to write anything.

    PS: that isn’t /home/rust that I can see, there. If you were to go to that directory in a terminal and type pwd and press enter it will tell you what that directory name is relative to how it is mounted.

    • This reply was modified 1 month ago by BobC.
    #16900
    Member

    skidoo

    symptom: willingness to blindly grant trust to curl | sh

    .

    The reason why

    symptom: willingness to invite installation of system-wide “stuff” from non-repository 3rd parties
    .

    BobC, bless your heart for caring to assist, but isn’t this situation an example of “just because you can, doesn’t mean you should… and you’re expected to sew your own hide when it eventually (or, in this case, immediately) bites you in the ass”?

    • This reply was modified 1 month ago by skidoo.
    #16904
    Member

    BobC

    I thought I did pretty “OK” there. At least I realized and said that he should have installed from the repo if possible and questioned using root authority to install it. He probably understands now why I asked if his user id is rust.

    I’ve made mistakes like that in the past, and the best answer I found was to boot from a live USB, save anything I could get to that I needed, reinstall the distro, learn from my goofs, and not make the same mistakes on the next try.

    #16907
    Member

    skidoo

    I didn’t intend to “put ya on the spot”, BobC, and I’m not entirely unsympathetic to russel23’s inquiry.
    Rust, Go, and nodejs…
    …although these are available from debian repositories, they are each a fast-moving/changing target.
    Initiates don’t want to “settle for” the currently-packages versions & ya can’t fault them for wanting/needing latest versions, but ultimately it’s a square-peg round-hole game.

    To accomplish a sane outcome, OP needs to make a choice: Use system-wide debian-stable packaged version (or check for stretch-backports version), or self-install (as non-sudo user) and accept responsibility for the chore of manually performing updating/maintenance.

    “Hey, doing that seemed to work without problems when using reg’lar Debian”
    Okay, so it seems reasonable to expect that antiX {sudo|envars|.profile} probably CAN be tweaked to match whatever worked in Debian. Rollup yer sleeves, brave trailblazer…

    #16908
    Member

    BobC

    I agree. They don’t look like easy choices. If I was going the self install route, I would do it on a test machine to avoid messing up anything important.

    #16931
    Member

    russellb23

    Yes, I do sign in as ‘rust’. I am worried now on letting ‘curl and sh’ to use ‘root’ permissions. But also wondering, rust, doesn’t do anything beside downloading binaries of compiler, doc and standard library and export its path to the user PATH variable via setting env variables in .profile/.bash_profile. After hours of examining the issue, finally found that my .bashrc is not being read at the startup! and sourcing so has also no effect on the command prompt (I have a custom set PS1 variable). However, the path is being set properly, if I set that in .bash_profile. When I try to source .bashrc from .bash_profile the shell hangs and I terminate by “Ctrl+c”. Clueless here at this point, as I have not encountered such an issue before. Is re-installing, a good way? Please advice.

    I have installed rust the way you’ve mentioned.

    • This reply was modified 4 weeks, 1 day ago by russellb23.

    entropy

    #16933
    Member

    BobC

    At this point you answered the questions of the user id and mounting of the drive in the original post, and therefore /home being on a separate drive doesn’t look like it would be an issue to me, which was the question initially I was trying to answer.

    When I saw the owner was rust and the directory name was russellb, I thought the system created the russellb directory with that name when installed because your user id was russellb. Now that the directory and user ids are corrected, that causes my theory for why it wasn’t getting access permission to be wrong.

    Sorry, I am not good enough with the scripts to help with your follow-on questions. I have fought that kind of thing before with other programs and the easier path is to install something from the repos unless you need the newer stuff badly enough to be willing to fight for it to work like this.

    • This reply was modified 4 weeks, 1 day ago by BobC.
    #16939
    Member

    skidoo

    I would first check whether the earlier “adventure” caused root ownership of any of your files:
    find /home/russelb -user root

    To fix, if any are found (consider which files have become root-owned,
    and which actions during your earlier root login were likely involved, for your future reference):
    sudo chown -R russellb:russellb /home/russellb

    Second, I would (and suggest you do the same here) revisit the Debian docs regarding dotfiles.
    https://wiki.debian.org/DotFiles
    https://wiki.debian.org/EnvironmentVariables
    The antiX userconfig defaults, as provided in /etc/skel , I don’t recall any “how/when .bashrc is sourced” differences, compared to stock debian. (If you discover/notice any proprietary handling, post back to give future readers a heads-up, eh)

    The antiX distribution almost certainly prepopulates a different set of userconfig envvars compared to stock debian.

    The antiX distribution permits, but does not encourage, “root login” and prepoulates very few of the /root configfiles ~~ expecting/necessitating the “I wannabe root” users to accept responsibility for setting up rootuser config themselves.

    Third, a point of confusion:
    You mentioned “shell”. Idunno whether the context (of your testing/reporting, above) is a tty console or a terminal emulator.
    If it’s a terminal emulator, which program? (glad to hear, but just asking rhetorically)
    If roxterm is installed, within its “preferences” you can configure so that it will run a login shell for you by default (if that suits you).
    The lxterminal program, I don’t recall that it enables storing that detail as a permanent election. Instead (man lxterminal) we can launch it with commandline option.

    ^—- when you tested changes to your .bashrc et al, maybe you hadn’t logged out/in (nor invoked a new login shell within xyzterm) before testing the result

    Hearing that the “shell” hung during your testing leads me to wonder whether you introduced some syntax error(s) while editing your .profile, .bashrc

    Rather than immediately contemplating a full reinstall, try replacing (diffing, instead, and selectively merging changes, would probably be more enlightening toward understanding what/where any error(s) had been introduced) your russellb config files with copies from /etc/skel

    When experimenting/tinkering with dotfiles, it’s safer to temporarily create an additional user account ~~ mess with the dotfiles, and perform other experimentation while logged in as the throwaway user. Or keep that other account onhand for future testing (a spartan homedir occupies only ~200kb)

    #16959
    Member

    russellb23

    Thank you skidoo and BobC. I have made the configuration files to be read on startup (customised couple of dot files, in essence). But the issue still there. As skidoo said, I can go for a re-install but would completely miss the learning process. I have tried installing as sudo. But the problem persists. May be a bug?!

    entropy

    #16974
    Member

    skidoo

    I have tried installing as sudo. But the problem persists.

    Elaborating on why I cringe when reading that (and why I called out “symptom #2” earlier).

    “Those who fail to learn from history are destined to repeat it”

    Software that is available for download/installation from non-Debian, non-antiX, 3rd parties
    might (or might not!) have “best of intentions” but probably has not been tested to ensure
    that it will operate properly on THIS operating system.
    -=-
    Allowing those 3rd parties (via software launched “as root” on your system) to silently push “updates”
    onto your system invites disastrous system-wide consequences.

    v— example (not Rust, but illustrates the risk of potential/inevitable consequences)

    https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
    .

    #16975
    Member

    skidoo

    It’s your call, but at this point I would reinstall the operating system and start afresh.
    Create a throwaway user account on the system, then login as that user and again install rust.
    Take detailed notes describing each of your installation + config steps.
    If that attempted rust installation fails, paste your notes into a followup post so that someone else can attempt to confirm the result.

    #16990
    Member

    BobC

    I would create a “throwaway system” entirely, but of course I have lots of junker PC’s on hand. I don’t like trusting automatic installs and updates.

    If its designed and setup to work on other OS’s but doesn’t work with antiX the path of least hassle is just to put it on one that it has been tested with. I say that because I’m probably not capable of fixing it, either, or if I did, it might take more time than its worth.

    You could also try convincing the devs of rust to add in another select that makes running it on antiX an option, like some of the other distro’s listed in the code. They would know how to make it work.

Viewing 15 posts - 1 through 15 (of 17 total)

You must be logged in to reply to this topic.