Over the weekend I had to performed a fresh install on Ubuntu on my laptop.
I was restoring my files from my backup, but I used the wrong username.
I've tried to change the username and the $PATH but I'm still getting the same error
t0m#asuntu:~$ wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash
=> Downloading nvm from git to '/home/ubut0m/.nvm'
=> mkdir: cannot create directory ‘/home/ubut0m’: Permission denied
ls: cannot access '/home/ubut0m/.nvm': No such file or directory
fatal: could not create leading directories of '/home/ubut0m/.nvm': Permission denied
Failed to clone nvm repo. Please report this!
t0m#asuntu:~$ vim .bashrc
t0m#asuntu:~$
I've tried removing and reinstalling everthing (NPM, Node, NVM), but don't know why I can't get the script to work. Any help is appreciated.
Check that you're $HOME environment variable matches that of the user you are currently running as, which you can check with whoami. Sometimes, some tools that elevate privileges (such as sudo) preserve the old user's home directory environment variable while running as the new user.
If that's not the problem, check that your home directory exists and has the correct permissions. Usually, if that's the problem, all sorts of other issues pop up (but I can understand a tendency to ignore such things on a newly restored machine).
If it's neither of those things, you can try making sure that you are in your home directory when running the wget | bash command although that really shouldn't be necessary (and if that turns out to be the issue, I would definitely file a bug with nvm about it).
Related
I was using my git fine but suddenly when I tried to use git status it showed me
fatal: unable to access '/home/username/.gitconfig': Bad message
I first thought it is because of my git config file is in the venv, but it was OK and, as the error shows, it is because of the .gitconfig file in my user directory!
First of all as what I found on the internet I used git config --global user.name "NewUser" and git config --global user.email newuser#example.com
but it ends in the same error as before.
After I closed and opened my VScode again a Git extension gave me the warning that it cant detect any git exe file on the system and I need to install the Git again!
And when I checked for git --version it gave me the same error again!
Literally I cant use any git command!
Then I tried to write the configuration by myself and when I opened it in terminal with nano it was nothing in it! and when I wanted to save the changes it gave another error as
[ Error writing .gitconfig: Bad message ]
Then I looked at the permissions of the file and it was just question mark instead of normal permissions
Then I tried to change the permission by chmod but it gave the access denied error again!
chmod: cannot access '.gitconfig': Bad messag
Then I tried to remove it but it cant be removed too!
rm: cannot remove '.gitconfig': Bad message
I installed and removed git for several time! it did not work either.
I am using manjaro 20.2
Any idea would be appreciated!
UPDATED
This is the errors in for dmesg
Bunch of these errors here and there
As mentioned here, the question marks in the ls output just indicate that it could not stat() the directory entry.
It could be a disk error or possibly filesystem corruption: for an ArchLinux distro, see sudo journalctl --since=today or, form last boot, sudo journalctl -b -1 to reveal further details.
Check the partition you are in (df -h .) and see if this is a filesystem mounting issue.
If you see a bunch of messages like:
EXT4-fs error (device nvme0n1p2): ext4_lookup:1574: inode #4833958: comm ls: iget: checksum invalid
You should look at your partition from an external session (meaning a live session from an USB disk), as in here:
Rebooted into the live USB
Mounted a secondary drive.
fsck.ext4 -p [my root device]
fsck.ext4 -z [undo file on secondary drive] [my root device]
Stepped through all errors and allowed fsck to fix them
Rebooted into the system and opted to reinstall all packages (see script below)
Rebooted again ...
The OP amir-mohammadian confirms in the comments:
Because I am in my first steps in Linux, I always have a live boot of my distro.
So it was quick, and when I used it "fsck" first it said I cant use any -p or -z because of some errors and I have to do it manually, so I was just typing y and y and y!
And when I boot again it worked!!
Maybe this will help:
sudo chown username .gitconfig
What is the difference between the following two command lines?
root#superhero:~/Workspace/# sudo git push origin master
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
root#superhero:~/Workspace/# git push origin master
Everything up-to-date
Using sudo causes the command to run as the root user. The Git command uses credentials and configuration stored in the current user's home directory; when you run as sudo, this code is going to be looking at the root home directory, not your home directory and thus miss this context.
In most cases, it should not be necessary to use sudo. There are very few cases where it is required (such as installing software globally such as with apt-get) and when it comes to programming, use of sudo is often but not always an anti-pattern (in order to ensure that source code is hermetic and reproducable, most software should be installed in the repository, not globally).
When you are using sudo in your command. This is the root user that execute the command. The key used to access to your git server are store in a directory (.ssh/). When you run the command in root. The directory is the '.ssh/' of root so not the good one.
Another point, with sudo, this is a user from sudo group that execute the command. So the sudo group does not have access to your.ssh
Somehow, my system (Ubuntu WSL layer on Windows; so treat as exactly Ubuntu) went a bit crazy. For a directory (a git repo if it matters) /path/to/foo, running ls shows the git files ORIG_HEAD, index, and index.lock in there.
I tried to debug this by going cd .git, but an ls there showed me my same list of files as the parent!
I went as far as
/path/to/foo/.git/.git/.git
before stopping checking the recursion.
A possibly related issue that managed to show up is that the .htaccess file there is read as a file by Emacs on Windows, a file by vi on Linux, but a directory by emacs and a directory by bash.
That means that my computer really thinks
~/public_html/.git/.htaccess/.htaccess/.git/.htaccess/.git/.git
is identical to
~/public_html
So, needless to say, Apache also craps out and says that it's an invalid htaccess file .... though on an other machine (see: git repo) it runs just fine.
Help?
Tried nuking the directory via rm -rf and git clone-ing back, but the Apache problem persisted.
I removed the symlink to the directory via unlink:
~$ unlink public_html
then re-mounted it, making sure that there wasn't a trailing space
~$ ln -s /mnt/c/Users/USER/pathto/repo /home/USER/public_html
I have created a debian package and added the following code in the postinst script:
path="$HOME/sample"
echo "$path"
if [ -d "$path" ]
then
rm -rf "$path"
echo 'File deleted successfully :)'
fi
so that if the path is present, it would delete it during installation. It works perfectly when I install my .deb package through dpkg. But while installing through Ubuntu software centre, none of it works. Why does this happen?
For background, I have made an app that would create a directory in the home directory of the user or root installing to the system .So if I am reinstalling or installing again after uninstalling, I need to check if the directory is present or not; if present, I need to delete it. I have distributed the app as a Debian package. So the question is how to check if the directory is present in the home directory? The directory is not created while installing the app. It is externally created while running the app. Also note that I cannot change it to a different folder because the app cannot be changed.
The problem is not with Ubuntu, but with your use of HOME in the postinst. It apparently happens to work with sudo dpkg from your own account (although in some settings, sudo would not propagate your HOME then, either) but this is not supported or well-defined.
HOME does not make sense in a Debian package anyway, because it is a system-wide install, and HOME is a per-user variable.
If I understand your requirement correctly, you need to loop through the home directories of all users, and remove the sample folder from each if present.
# Ad-hoc
getent passwd | cut -d: -sf6 |
while read dir; do
test -d "$dir" || continue
rm -rvf "$dir/sample"
done
This is extremely intrusive so you really should try to change the app instead -- what if a user has a directory named sample for some other reason? The app should use a reasonably unique dot name (.appname-sample?) instead, or store its per-user data in a system location where it can be properly managed by the system.
In fact, in the meantime, your postinst script should probably only move the sample directory to something like .sample.dpkg-old. This is no less intrusive, but at least it avoids destroying your users' data completely by silly mistake.
I am trying to make a new branch in Gitlab by using Gitolite. I complete the installation steps. when i come across "setting up gitolite" section i have a trouble. I followed this link.
When i run
gitolite setup -pk alice.pub
command i got "bash: gitolite: command not found" error message. I don't know what is the problem.. Any one please help me.
This step comes after the Gitolite installation, which supposes you have chosen one of three possibilities:
Keep the sources anywhere and use the full path to run the gitolite command.
Keep the sources anywhere and symlink just the gitolite program to some directory on your $PATH.
Copy the sources somewhere and use that path to run the gitolite command.
So make sure gitolite is in your PATH, and that command will work.
I prefer a local installation of gitolite (in a local directory, as opposed to /usr/local, which requires root privileges.).
See, for illustration, "install_or_update_gitolite.sh"
"${github}/install" -to "${gtl}/bin" # Note: "${gtl}/bin" is in my $PATH
GITOLITE_HTTP_HOME= gitolite setup -pk "${H}/.ssh/gitoliteadm.pub"
Note that for gitolite setup to properly work, you might want to set GITOLITE_HTTP_HOME to an empty string first.
As I also faced the same problem, I found the solution(s) as below.
First way is ...,
Open your terminal and key in below code
$ PATH=$PATH:~/bin
It is because the value of $PATH variable is point to incorrected path.
So I just modify this variable.
To be more detail click here.
Second way is ...,
Edit .bashrc file going to the end and insert below line.
PATH=/home/git/bin:$PATH
To be more detail click here.
On debian, there is no /usr/bin/gitolite
Linux debian-srv 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux ls: cannot access /home/gitolite/bin: No such file or directory
ls: cannot access /usr/bin/gito*: No such file or directory
Here installing gitolite3 helped:
apt-get install gitolite3
root#debian-srv:# which gitolite
/usr/bin/gitolite