[EdLUG] Unable to login to my kubuntu 20.04 desktop

Alistair alistair at archerry.plus.com
Thu Apr 8 12:17:21 UTC 2021


On Thursday, 8 April 2021 10:18:33 BST Roy wrote:
> On 07/04/2021 19:54, Alistair wrote:
> > I have managed to foul up my Thinkpad running kubuntu 20.04, and
> > cannot login to the desktop.
> > 
> > I can login to the TTY2 console, where 'HOME=/'. The /home folder
> > contains only '.' and '..'.
> > 
> > I was trying to delete some folders and files from an external hdd.
> > These had previously been created using the 'rsync' command on this
> > m/c and account.
> > 
> > Deleting failed using the GUI so I tried to recursively remove the
> > from the command line as the normal user, then using sudo.
> > 
> > At this point I started getting messages about system crash, kmail
> > started complaining that it could not write to mailboxes. There were
> > other messages so I shut the box down, during which it reported that
> > it could not write to the drive.
> > 
> > It booted up to the GUI login screen, but refused login to my account.
> > 
> > I switched to the TTY2 console and logged in there:
> > 
> > It reports "no directory, logging in with HOME=/"
> > 
> > The 'ls -a /home' command results in "'.' and '..'" only.
> > 
> > It refuses to start the gui (startx) timing out with:
> > 
> > "xauth: timeout in locking authority file //.Xauthority
> > 
> > xaut: timeout in locking authority file //.Xauthority
> > 
> > (EE)
> > 
> > Fatal server error
> > 
> > (EE) Cannot open log file "//.local/share/xorg/xorg.1.log
> > 
> > (EE)
> > 
> > (EE)
> > 
> > Please consult the X.Org Foundation support at http://wiki.x.org for help
> > 
> > (EE)
> > 
> > xinit: giving up
> > 
> > Xinit: unable to connect to X server: connection refused
> > 
> > xinit: server error
> > 
> > xauth: timeout in locking authority file //.Xauthority"
> > 
> > How do I recover the system?
> > 
> > Regards,
> > 
> > Alistair
> 
> Alistair,
> 
> Your /home/<username> has been removed. Maybe all of /home.
> 
> As others have said, restore your user data from backups. Some or all of
> your data may still be there.
> 
> Deleting files returns the space to the the free space pool so it can be
> overwritten. On rotating rust, that's all that happens. On SSD, the
> drive will do housekeeping from time to time. That essentially means
> that it will erase the free space, so its ready for the next write.
> Erase is a slow operation, so SSDs try to do it ahead of time.
> 
> With magnetic storage, you have a chance to get some of your data back,
> if there is really no other way. How much and what depends on luck and
> what space has been overwritten. With flash storage, the probability of
> data recovery is a lot less as what the drive does by way of internal
> housekeeping is not under user control, nor is when it does it.
> 
> Regards,
> 
> Roy Bamford.

Everybody,
Thanks for your advice. I have spent the morning re-installing and restoring 
from backups.
Part of the initial update to 20.04 was to install a new ssd so, as 
interesting as Thomas' idea of trying to recover the deleted files is, Roy may 
be right that the m/c had been too efficient for me anyway.
It would have been an interesting and perhaps frustrating exercise to attempt 
- it would have ground into my brain the need for extreme care when using that 
recursive command.
With tat in mind, I will not be upgrading my main box to ssd in the near 
future.
Regards,
Alistair





More information about the EdLUG mailing list