When posting your question, post below this line →
Out of the blue, I can no longer log in to my lubuntu, single user. I have no recollection of intentionally changing my password. I’ve been using that same password for a long time, so I well-practiced at remembering and typing it. I’ve checked to insure that the caps lock is disengaged. I’ve waited overnight to retry logging in, just in case lubuntu has a feature to ignore login attempts after a series of failed login attempts. Those delayed login attempts also failed.
I do remember that my prior session with a successful login ended with a unresponsive idle screen. The session became unresponsive when I left it idling for a day or more without my interacting with it. The graphic on the screen no longer moved or changed the geometric shapes. I shrugged off this situation and turned off the computer. (I had no other option since keystrokes were ignored and I could not issue the proper shutdown commands.)
I cannot rule out that I inadvertently changed the password, but I really, really, REALLY doubt it. I’ve had previous hangs where I could simply turn off the computer and later re-boot it successfully.
I did try to login from the terminal prompt, having entered the control-alt-f4 key sequence. This also was rejected.
So, what are my options of -
Restoring my host to working order?
And yeah, I don’t have a backup of my data. Can I re-install without over-writing the data?
Failing that, can I use a ‘live’ session to reach the data and do a proper backup before a reinstall?
Will I have ownership conflicts of datafiles, if I can back them up?
I always try and avoid using the power-off to turn off a computer; you can usually use SysRq commands to direct the Linux kernel to shutdown the machine safely regardless of any stuck gui/application unless you have hardware issues (PSU/RAM/swollen-caps issues etc) or a kernel panic. If you’re not familiar with SysRq commands (they aren’t Lubuntu/Ubuntu specific - relating to the Linux kernel used any all GNU/Linux distributions) pull out your phone and search “magic sysrq” and you’ll usually find the wikipedia page near the top, which is as good as any to refresh memory (on commands; ie. REISUB for example).
I’d boot a live system (eg. Lubuntu installation media) and fsck or perform file-system checks before I attempted to reboot after a power outage. If problems are detected & fixed, you’ll likely find a login will work next boot.
You’ve not said if you’re using encryption - but yes from the live session you can access data (even with encryption; it’s just more involved).
Can you re-install without over-writing data - Yep; however system directories will be erased; but user data will not be touched if the correct options are used. The re-install can also automatically re-install packages you had added to your system when they are from Ubuntu repositories. Lubuntu has a QA-testcase of that actual install (install with an existing partition). You use the “Manual Partitioning” option, select your existing partitions but ensure you DO NOT have format checked. It’ll cause
your packages installed are noted (ie. those you added post-install, or really those marked manually installed)
system directories are wiped
system is installed
additional packages noted earlier are installed (if available for the new release from Ubuntu repositories)
no user file is touched UNLESS you formatted
I’d not expect file-ownership conflicts - assuming your file-system does not contain errors; ie. as stated, after any power outage I don’t boot into my system until after I’ve booted live media & performed a fsck or partitions. Clean shutdowns prevent this; and SysRq commands can achieve this and are super-fast.
Thank you for your detailed response, the description of options to correct my situation and warning of possible pitfalls.
I’ll read about and use the sysrq and fsck commands as you suggest in the future.
Prior to reading your note, I downloaded the installation media and booted the live system. I groped around rather blindly with the intent of looking for data files and backing them up. While in the live session, I continued to try logging in and probably rebooted the live system. And to my complete surprise, I succeeded in logging on!! The system accepted the password which had consistently failed up to this point!! I have no clear idea of what I did to log in successfully.
However, I noticed an aberration that accompanied my failure to login. My password is 11 characters long. I noticed that when I typed it into the password field below the icon representing me, only 8 dots went into the field. I used the left arrow key to count characters back to the initial character. As I reached the 8th character to the far left side of the field, I expected that the remaining 3 characters would come into view as continued to hit the left arrow key. This did not happen. The sequence of left arrow key strikes told me there were really just 8 characters in the field, even though I typed in 11 characters. Maybe that’s significant?
Thank you for the guidance on how to re-install the OS without disturbing the user files. I may not be “out of the woods” yet and need to re-install. I’ll do backups!
My primary box password is 10 characters, and don’t have issues. I booted up a testbox besides me that had a recent 20.04.3 QA-test install made to it, changed the password to 16 characters and was able to login fine. The behavior was as expected with sddm greeter.
That testbox shows 10 dots in the password field, but I’ve noted before the count can vary from box to box; likely related to the video cad OR resolution of displays. I booted up another box and it likewise had 10 dots on entry (different video card & resolution but same 10 dots in field).
Your testing persuades me that the dot characters do not correspond, one for one, with the characters entered as the password and that the lack of correspondence is not evidence of loss of input characters to the password prompt.
I am greatly relieved to re-gain access to my system. I’ll institute better practices of dealing with shutdowns.
Some years ago while I was installing a Linux system in a friend laptop we got a similar error.
My friend wrote his password during the installation but then he couldn’t log in after booting.
The explanation was that the system doesn’t recognise all the keyboard keys after the installation.
I think that in your issue could be that there are differences in the password length because the system doesn’t recognise all the keyboard keys, but perhaps I’m wrong.
Thank you for sharing your experience. My 11-character password contains one capital letter, numbers, and an exclamation mark (!). When I enter my password and it is rejected, the cursor stops moving when I enter the final 3 characters, <!>
I’m thinking these 3 characters are so common that would be known and acceptable to the keyboard logic. My suspicion is that a 8-character buffer was overrun and the last 3 characters were discarded.
Thanks for this contribution to my experience.
Clarification: If you have insufficient space in $HOME (user directory; or /home/$USER), GUI logins will fail, but switching to a text terminal (eg. CtrlAltF4) will still allow you to login so you can explore available space (eg, df -hl) & correct the space issue.