Common Problems with Linux Workstations
I Can't Seem to Log In
Possibility 1: Absent Home Directory
The Linux workstations on campus typically mount user's home directories from a nearby NFS server at login time. As such, one's home directory needs to have been created before a successful login will complete. If one's home directory has not been pre-populated and assigned, they might see an error along the lines of `Unable to initialize home directory`. If this is the case please visit my.whitman.edu/support and fill out a ticket or reach out to the WCTS Lab Manager (csmath.ilt@whitman.edu for Olin hall - for example).
Possibility 2: Incorrect Password
The Gnome Display Manager (gdm) allows for 3 different login attempts before a user is sent back to the base login prompt. If the attempted password is immediately denied, the most likely reason is that an incorrect password was attempted. Please visit my.whitman.edu/support if you would like to request a password reset.
Possibility 3: The network is down
If, for any reason, the computer is unable to establish communication with the NFS server, then no network attached accounts will be able to log in. This would be the case with accounts using their myWhitman username and password. One can verify that the wired ethernet connection is out of order by clicking on the icon on the top left corner of the login screen. If it says "Wired Connected", then network connection has been established and the network is NOT down.
Google Chrome doesn't seem to open
If a user clicks on the Google Chrome icon and sees a process start but hang and do nothing, google chrome has likely crashed. Google Chrome will not present a pop up with an error message in an X11 session.
Crash reason 1: Google Chrome is open on another session
File locking typically is a safety mechanism to ensure a file can be written to and read from by multiple processes. Google Chrome typically makes a file lock as a symbolic link to the process ID on a specific workstation host. If that link resolves to a process, then a new instance of Google Chrome does not get opened. However, the symbolic link may not have been properly written. Here's how to fix that.
Terminal Fix
A simple command to delete this lock file will do the trick: rm /home/$USER/.config/google-chrome/SingletonLock
The $USER variable will be expanded to be the username of the user who executed the command.
File manager fix
Alternatively, a user can use the file manager to navigate to /home/$USER/.config/google-chrome/
and remove the SingletonLock
file.
Crash reason 2:
There is a standing issue where two computers in the CS Lab (TedCodd and Ritchie) are not able to open a recent version of Google Chrome. The Chromium team is aware of the issue and the bug report is here: https://bugs.chromium.org/p/chromium/issues/detail?id=1493307
Firefox doesn't seem to open
Firefox will notify a user if it believes there is another session open on a different computer. This may be the case if the previous session did not terminate gracefully. The popup Firefox will show may look like this.
Terminal Fix
The files to delete are located within the user's profile directory /home/$USER/.mozilla/firefox/*.default/
where * is a placeholder for Firefox's profile hash. The specific files to delete are lock
and .parentlock
. This one line command should remove those files:
rm /home/$USER/.mozilla/firefox/*.default*/lock
File manager fix
In your preferred file manager, you are able to navigate to the directory which holds the lock on Firefox in /home/$USER/.mozilla/firefox/*.default/
Since it is impossible to know what the user profile's hash is and if they are using a default profile versus a custom profile, it is recommended to go each folder that has default
or default-release
appended.