Help! Password wont work

Linuxminhelp wrote:
These are the steps I have to take to log in,
1) At password screen of GUI press control alt f3
2) at black screen terminal enter username then new password
3) type "ecryptfs-mount-private" then my OLD password to decrypt it
4) CD /home/user
5) Ls -la
6) sudo chown user:user .Xauthority
7) control alt f7 to get GUI OS login. Works normal now.

On a side note, There is no sound from speakers or even visible slider on the host OS or virtual boxes but the virtual machine KVM qemu sound works.

Thanks for that very clear procedure that you follow. It is not standard and really shouldn't be so involved.

You can consider re-installing as Tolkem suggests since you have other issues as well with sound.

Usually with linux there are ways and means of dealing with issues so that re-installation is not required, but it can become a cost/benefit issue ... there may be more benefit and less cost (in terms of time and research) with re-installation.

That said, there are some things you can try. These are things I would try so they are opinions if you like and they can all be reversed unproblematically. Note that I will not deal with the decryption process ... you'll have to insert that yourself in the procedure.

You could try to log in and start the GUI session without first booting to a GUI. The point of this would be to see if it avoids permission issues. To do this I would alter the target of the display manager (as root) and configure the computer to boot to a text prompt:
Code:
systemctl set-default multi-user.target
Rename the .Xauthority in your home directory to something else so it is out of the process, for example rename it .XauthorityBackUp.

When those are set, reboot.

When you reboot, you would normally boot to a text prompt. There you login as user. That's what should happen.
You should now be able to bring up X and the GUI with:
Code:
startx

If you can bring up the GUI with these steps, then that is normal without having to change any permissions.
Now it may actually be the case that no .Xauthority file reappears in your home directory at all. That is not uncommon and generally has no effect on X starting up. You can create an .Xauthority if you need it and generate its contents with xauth. It's usually needed if forwarding X stuff between computers, but on stand alone computers you may not need it.

If none of this works, there are other things to try, but I'll leave it for the moment.
 
Last edited by a moderator:


If you're still playing with it, in case it's a broken package causing the problem you could try

From terminal run sudo apt-get update then run sudo apt-get update --fix-missing
 
Last edited:
You can consider re-installing as Tolkem suggests
Just to be clear, my suggestion is to re-install the DE only, i.e. Cinnamon, not the whole OS.
 
Tolkem wrote:

Thanks for clarifying that.
Yeah, sure. Although, that's what I originally meant:
1650238928198.png

:)
 
Yes, I understand what you meant, and I can see how my sentence could have been ambiguous, but only if the reader did not actually read what you recommended because that was what I was referring to and implicitly directing the reader to. I also mentioned the sound problem that the OP mentioned, and that can also be disturbed by desktop environments because they almost invariably impose a layer of software from the desktop to access the sound programs. So your suggestion may have had positive consequences for both problems, or not. The rest of my proposal I cast as my opinion as to what I would do. I was interested in a more fine-grained attempt to discover where the problem lay and so my suggestion was a first step to see what would work without any problem so as to establish a baseline of problem-free functioning if it existed so that one could build on from that point and hopefully eventually identify where the issues are and correct them if possible.
 
Yes!!!!!!! Woooooioo!!! I fixed it!!!!

The problem was that Linux mint GUI login assumes the encryption password is the same as the user password. When I reset the user login via passwd earlier in this thread, I never changed ecryptfa password which was done using the wrapped file.

Other distros have by default different GUI login for encryption or user passwords.

Huge thank you to everyone who helped. Even though your exact command didn't solve it, it got me doing things in the terminal that lead to an eventual fix.
 
Linuxminthelp wrote:
Yes!!!!!!! Woooooioo!!! I fixed it!!!!
Congratulations to you. I'm certainly glad you fixed it, and pleased for you that it was done without having to get into some of the more involved intricacies.
 
So if Desktop environment is reinstalled , it doesn't change any files? Just useful to know for future errors
If you mean $USER files, no, it won't. The DE is just another pkg.
 
It's probably worth noting that the a desktop environment usually consists of a number of packages which may have quite complex interactions with each other. The default desktop environment for Mint being Cinnamon is not an exception to that. In the case of Cinnamon one is looking at the following suite of packages:
Depends: cinnamon-common (= 5.2.7-2), cinnamon-control-center (>= 5.2), cinnamon-desktop-data (>= 5.2), cinnamon-screensaver (>= 5.2), cinnamon-session (>= 5.2), cinnamon-settings-daemon (>= 5.2), cjs (>= 5.2), cups-pk-helper, dbus, gir1.2-accountsservice-1.0, gir1.2-caribou-1.0, gir1.2-clutter-1.0, gir1.2-cmenu-3.0 (>= 5.2), gir1.2-cogl-1.0, gir1.2-cvc-1.0 (>= 5.2), gir1.2-ecal-2.0, gir1.2-edataserver-1.2, gir1.2-gdkpixbuf-2.0, gir1.2-gkbd-3.0, gir1.2-glib-2.0, gir1.2-gnomedesktop-3.0, gir1.2-goa-1.0, gir1.2-gtk-3.0, gir1.2-gtkclutter-1.0, gir1.2-ical-3.0, gir1.2-keybinder-3.0, gir1.2-nemo-3.0 (>= 5.2), gir1.2-nm-1.0, gir1.2-nma-1.0, gir1.2-notify-0.7, gir1.2-pango-1.0, gir1.2-polkit-1.0, gir1.2-soup-2.4, gir1.2-timezonemap-1.0, gir1.2-upowerglib-1.0, gir1.2-xapp-1.0 (>= 1.9.0), gkbd-capplet, gnome-backgrounds, gnome-themes-extra, gsettings-desktop-schemas (>= 0.1.7), iso-flags-png-320x240, libcinnamon-desktop4 (>= 5.2), libcinnamon-menu-3-0 (>= 5.2), libcjs0 (>= 5.2), libglib2.0-bin, libmuffin0 (>= 5.2), mesa-utils, muffin (>= 5.2), nemo (>= 5.2), network-manager-gnome, policykit-1-gnome (>= 0.105-6), python3, python3-dbus, python3-distro, python3-gi, python3-gi-cairo, python3-pampy, python3-pexpect, python3-pil, python3-pyinotify, python3-requests, python3-setproctitle, python3-tinycss2, python3-tz, xapp, dconf-gsettings-backend | gsettings-backend, libatk-bridge2.0-0 (>= 2.5.3), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.29), libcairo2 (>= 1.10.0), libgdk-pixbuf-2.0-0 (>= 2.22.0), libgirepository-1.0-1 (>= 1.29.15), libgl1, libglib2.0-0 (>= 2.52.0), libgstreamer1.0-0 (>= 1.4.0), libgtk-3-0 (>= 3.9.12), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libstartup-notification0 (>= 0.11), libx11-6, libxfixes3 (>= 1:5.0), libxml2 (>= 2.7.4)
Recommends: blueman, cinnamon-core, cinnamon-l10n (>= 5.2), gnome-terminal, libcanberra-pulse, metacity-common
Suggests: cinnamon-desktop-environment, cinnamon-doc, python3-opencv

On the matter of what changes when you reinstall a desktop environment, several possible things can occur. If the user has made alterations to the default configurations, the software may maintain those configurations, or it may restore the defaults discarding the configuration alterations, or it may restore the defaults and keep the user-altered configurations in files with special names so that the user can retrieve them. It's a long time since I used Cinnamon, but I believe it maintains the user's configurations if they re-install it.

Generally I think the impulse to re-install as an early response to a technical problem is sub-optimal on a number of grounds because these problems often have reasonably accessible solutions with a little investigation, as was found in the case in this thread. Investigating solutions also has the side benefit of promoting learning which equips the user for more informed use of their software in the future. There is a place for re-installation of parts or whole operating systems when things become intractable which is always a matter of judgement on the part of the user and depends in part on their capacity and the help that is available to them together with a cost/benefit assessment. In my experience, the impulse to head for the re-installation route is a remnant of the way in which problems were characteristically addressed in MS systems where the software was proprietary and not transparent and the user only had the tools the proprietor provided to manage the system, which were often singular and sometimes simply not fit for purpose. I understand things may have improved in recent times. With linux, and unix systems in general, the multiplicity of tools and the ability to modify them in numerous ways to deal with issues has obviated the need to embrace re-installation at anywhere near the level of MS in the past.
 
With linux, and unix systems in general, the multiplicity of tools and the ability to modify them in numerous ways to deal with issues has obviated the need to embrace re-installation at anywhere near the level of MS in the past.
Amen.
 
In my experience, the impulse to head for the re-installation route is a remnant of the way in which problems were characteristically addressed in MS systems where the software was proprietary and not transparent and the user only had the tools the proprietor provided to manage the system, which were often singular and sometimes simply not fit for purpose.
Well, you can't re-install the DE in Windows. I agree that re-installing the entire OS should be the last resort just and when everything else has failed, but for a pkg, even one as the DE, I think re-installing is just one way to fix a problem that seems to be out of our reach. When you re-install the DE, all of its dependencies are installed, too.
 
Sounds like the problem was created by the user and not Linux Mint as I have never had this problem but I don't encrypt anything either. :)
 

Staff online

Members online


Top