[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
|
Hi, Thanks for the advice thus far, unfortunately the situation has marched smartly down the loo since I last posted. I found a website called Easy Linux Tips Project with advice on cleaning up a Linux system, but in attempting to follow that advice I discovered that / actually had /zero/ bytes, not the 8Gb which initially seemed available. At that point nothing would work so I decided to recover from my rsync backup, which seemed straightforward enough as I found instructions for that online.
That ran into permissions problems with error 13. I've tried
creating the exact same user and giving that admin permissions and
then doing the above, with the same result. It now occurs to me
the backup was created with 'su -' so I wonder if I should try to
replicate the same root user and try with that? This morning grub died just to add to the fun, so I ran my Boot
Repair disk, which is how I am now able to write this email. On the plus side the problem is now simple; get past the permissions issue and the system /should/ restore from the backup. Kind regards, Julian On 13/11/2019 18:00, mr meowski wrote:
On 13/11/2019 14:40, Julian Hall wrote:I /think/ I know what the problem is now. I loaded Mint 19.2 to the password prompt, dropped to a shell and tried 'sudo startx'. That complained it couldn't start and among other things mentioned 'low diskspace?' so I loaded Mint 17.3 and mounted /dev/sda1 - an SSD which only has / for Linux Mint 19.2 installed on it - into /media/julian/TEMP and had a look around. That claims there is only 8Gb free of around 130Gb, but I can only get about 20Gb of readable files. /root and Lost&Found are both unreadable but it seems the suspect additional content is in one of those two. Any suggestions how to identify which and clear out the - probably - extraneous rubbish?Ah still a problem I see... "sudo startx" is definitely not going to work out for you for various reasons but let's not get into that or the space issue which are both false starts. The trick is to persuade your system to cough up specific information on exactly _what_ it thinks is wrong which is sometimes surprisingly difficult. Xorg/Xwayland issues aren't captured in journald quite the way you might necessarily expect and that seems to be your issue here as a console login works just fine. I'd do a clean reboot, login over SSH from a working machine (makes it easier to copy/paste stuff from if required) and do some more recon. At the login screen check first to see what type of session you're using by default - there are properly different options to login using Xorg or Xwayland, quite probably not clearly labelled as such. Try both. You may have a simpler WM installed which will work when complex WMs like Gnome or KDE might choke on a failed dependency somwhere - like Awesome or i3 for example. If not, don't worry about it for now. See what the following have to say for themselves once you've rebooted and tried a couple of graphical logins: systemctl --failed sudo journalctl -p err -b dmesg You can also try running "sudo journalctl -b -f" in a console and then trying to login graphically which will tail journalctl in realtime and show you what is happening. I suspect you _still_ won't see what the root cause is though and my suspicion is that Xorg is dying in some weird way probably due yet again to kernel mode setting and driver misconfiguration. Can we just check the system is fully up to date and what kernel are you using? |
-- The Mailing List for the Devon & Cornwall LUG https://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq