Upon the request of some users, I decided to add all the intermediate steps and results to my initial post so that users can better walk me through a solution. This is added under the headline Additions below the question. Below Additions, there is a section called, "resolution," where I have added extra steps that I have taken in order to resolve this issue:
Question:
Today, as I was trying to continue running my codes in the command-line shell, I noticed that none of the commands are actually recognized by the shell in Fedora 21 (kernel 4.1.13-100.fc21.i686 on an i686 (tty2)). I thought if I restart and reboot the system, the issue should resolve. However, to my surprise I noticed that the system is not starting up after login. I tried to do diagnostics by pressing CTRL+ALT+F2 when the screen goes black to see where actually it stops working. The last line that I saw a complete stop was saying:
wait for plymouth boot screen to quit
Would you mind letting me know how to fix such issue when actually no command is accepted in the diagnostic mode in the shell by saying the following?
-bash: <...>: command not found
The only thing I can think of is some possible automatic update that I was not aware of or messing my .bashrc (which I can no longer see inside it by using the following command:)
sudo gedit ~/.bashrc
Additions:
I was able to login to my system only after entering the diagnostic mode by pressing Ctrl+Alt+F2
right after reboot and login into the main startup which fails under normal conditions.
Fedora release 21 (Twenty One)
Kernel 4.1.13-100.fc21.i686+PAEdebug on an i686 (tty2)
In this mode, then the login prompt appear
localhost login:
After entering my username, then it says:
Password:
After entering my password, then it says:
Last login: Wed Mar 30 15:33:54 on tty2
[bbenjamin@localhost ~]$
It is here that none of the commands are recognized by the shell no matter what. And the error message is usually:
-bash: <...>: command not found
where <...> is basically any command. The only time I was successful in getting most commands get realized by the shell was when I ran the following code (as mentioned by in the answer):
PATH=/usr/bin:/usr/sbin
After which at least I could look for and see my files and folders and programs (since most commands are getting realized.)
However, I still need to logging normally so that I can make use of all the graphics and other features of Fedora which is impossible in the diagnostic mode. To make this possible in particular I need to open my .bashrc file and fix its issues permanently (assuming that I can have access to its original version somehow.) To do this, I need to run commands like
(sudo) gedit ~/.bashrc
However, I am receiving error messages like:
Unable to init server: Could not connect: Connection refused
(gedit:1397): Gtk-WARNING **:cannot open display:
or running commands like this one:
~/.bash_profile
which would yield error message:
bash: /home/bbenjamin/.bash_profile: Permission denied.
Now, learning from the answer, I am not supposed to run this latter command as it is not executable. And instead I should run it in the following format:
source ~/.bashrc
After which I don't know how to proceed.
However, I don't know why the former command (sudo) gedit ~/.bashrc
is not working either. I remember that I always used to make slight changes in the .bashrc file depending on my need. This time I don't know how I made changes in it that it caused all the issues explained here. So now, my question is whether there is a command-line based method that I can open .bashrc and look inside it and make needed changes permanently so my system logins appropriately leads me into its normal graphical mode where I see and utilize all Fedora features.
Resolution
I learned that once I am in the diagnostic mode through the command Ctrl+Alt+F2
right after unsuccessful login, I can temporarily fix the messed up file .bashrc by running the command PATH=/usr/bin:/usr/sbin
. Then I could take a look inside my .bahsrc file through running the command line cat .bashrc
. It was only then that I saw the contents of the file in which I had several paths added to the file. Since I had kept a record of my added files at the bottom of previous paths in a chronological order, I knew that the problematic path was the very last one. Now, in order to fix the issue, I had to actually modify the file. This was achieved by the command line nano .bashrc
after which a new page appeared in which I had the chance of commenting out the problematic line by adding # in front of it. At the end, I saved my changes and exited. The last step I had to make was to reboot the system with its new modified .bashrc file through the command line telinit 6
after which the logging proved to be successful.
~/.bashrc
should be owned by your user, and so you shouldn't need to use sudo anyways. – Xiong Chiamiov Mar 30 '16 at 20:17who -r
orrunlevel
and let us know what it says. – Paul Mar 30 '16 at 20:39systemctl
orrunlevel
orecho $PATH
? Can you reboot and take a screenshot/pic? – Paul Mar 30 '16 at 20:57PATH
variable is not set properly. Try to use absolute paths i.e/bin/ls /home/${USER}
I – Valentin Bajrami Mar 30 '16 at 21:18export PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
. Then, edit your.bashrc
and.bash_login
files and fix any PATH settings you have in there. Be sure to make copies of those files before you edit them, in case they get messed up worse...cp .bashrc .bashrc.bak
. And finally, once you're up and running again, back up your important data! Coincidentally, tomorrow is World Backup Day. Now's a great time to do it. – Paul Mar 30 '16 at 21:34