[EdLUG] Kubuntu Desktop broken after 'apt-get dist-upgrade'

[Alistair]

Roy

You are correct, once I fail to get a useful graphic session working I change to a second console to login and investigate.
I tried another user (created last week).
The only difference was that the spinning cog wheel disappeared  quickly, but the black screen with the white outline mouse pointer did come up.
After a while it also timed-out to the graphic lockscreen.
Again the log file for this user was in the home folder.

Regards,
Alistair

On Tuesday, 27 September 2022 19:18:42 BST Roy wrote:
> 
> On 27/09/2022 19:13, Roy wrote:
> >
> > Alistair,
> >
> > Looking at dmesg first
> >
> > [    2.145084] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
> >
> > That's the kernel creating /dev/dri/card0 and
> >
> > [    2.277515] Console: switching to colour frame buffer device 240x67
> > [    2.306335] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device.
> >
> > The kernel is good.
> >
> > Now your Xorg.0.log. The error about /dev/dri/card0 is gone and the 
> > modesetdriver is in use.
> >
> > That's correct too.
> >
> > At the end the log shows
> >
> > [    37.620] (II) modeset(0): Modeline "1920x1080"x0.0  110.92  1920 1968 2000 2080  1080 1083 1088 1111 +hsync -vsync (53.3 kHz e)
> > [    80.054] (**) Option "fd" "27"
> > [    80.054] (II) event2  - Power Button: device removed
> >
> > So Xorg ran for about 43 seconds, then shut down. There are no errors 
> > there either.
> >
> > The file name
> >
> > ~/.local/share/xorg/Xorg.0.logfile
> >
> > is significant.
> >
> > When the login screen is show, Xorg runs as root and the log is in 
> > /var/log.
> >
> > The file you posted is in your /home directory. As Xorg is running as 
> > you, you must have logged in already.
> >
> > That points to kde-plasma having problems because the kernel and Xorg 
> > are good.
> >
> > The potential problems fall into two sorts. The software install and 
> > the per user setup, the per user setup is the easiest to test.
> >
> > Add a new user to your system, just with the defaults that your system 
> > provides.
> >
> > Using the new user, does everything appear to work?
> >
> >
> > Regards,
> >
> > Roy Bamford
> >
> Alistair,
> 
> "So Xorg ran for about 43 seconds, then shut down." is not correct.
> 
> [    80.062] (II) AIGLX: Suspending AIGLX clients for VT switch
> 
> You switched to a text console leaving Xorg running. The conclusion is 
> not changed.
> 
> Test with a new user.
> 
> 
> Regards,
> 
> Roy Bamford.
> 
> 
> > On 27/09/2022 12:49, Alistair wrote:
> >> Roy,
> >>
> >> I thought that if I am getting a screenlock / login screen, then the X window system must be starting, and thus creating a logfile...
> >> I searched and found it at:
> >> ~/.local/share/xorg/Xorg.0.logfile
> >> The timestamp is: Sept 27 12:14
> >>
> >> Two new files have been uploaded to the dpaste site:-
> >>
> >> >From today's login, t480-dmesg-2022-09-27:
> >> https://dpaste.com/77VLC9YMS
> >>
> >> >From today's login, t480-Xorg.0.log-2022-09-27
> >> https://dpaste.com/8HSS7RK5S
> >>
> >> Hope these help.
> >>
> >> Regards,
> >> Alistair
> >>
> >> On Sunday, 25 September 2022 21:37:13 BST Roy wrote:
> >>> Alistair,
> >>>
> >>> None of the files in /dev, /sys and /proc are real files. They are the
> >>> kernel exposing some of its internal data structures as files.
> >>>
> >>> Here I have
> >>>
> >>> $ ls -l /dev/dri/ total 0 crw-r----- 1 root video 226, 0 Sep 28 2021
> >>> card0 crw-rw---- 1 root video 226, 64 Sep 12 2021 controlD64
> >>>
> >>> On card0, the 226 is the kernel major device number, the 0 is the minor
> >>> device number. There are no file sizes there.
> >>>
> >>> You really don't want to know about the timestamps but other readers may
> >>> be curious. I run this system with a static /dev. /dev entries are made
> >>> by hand with mknod and the file timestamp is the create time. They do
> >>> not indicate my uptime.
> >>>
> >>> Anyway, /dev/dri/card0 is the way that Xorg communicates with the kernel
> >>> part of the video driver.
> >>>
> >>> If its present with the right owner/group/permissions you should be good.
> >>>
> >>> $ mount | grep devtmpfs dev on /dev type devtmpfs (...
> >>>
> >>> Run the above command. The sample output shows that a dynamically
> >>> managed /dev generated by the kernel is in use. udev gets a signal when
> >>> devices are added and removed, the kernel updates /dev and udev changes
> >>> permissions and adds/removes symlinks.
> >>>
> >>> If its all automatic like that, I don't understand how you get
> >>>
> >>>   > [ 272.782] (EE) open /dev/dri/card0: No such file or directory
> >>>
> >>> That means that /dev/dri/card0 is missing. Incorrect permissions
> >>> generate a Permission Denied error.
> >>>
> >>> If the file is missing, that's a kernel problem. If its there, Xorg
> >>> should see it.
> >>>
> >>> That contradiction makes me ask if the dmesg and Xorg.0.log you shared
> >>> are a self consistent set. Did they come from the same boot of the system?
> >>>
> >>> Gentoo does not have x11-apps but
> >>> https://packages.debian.org/stretch/x11-apps  shows it includes
> >>>
> >>> - oclock and xclock, graphical clocks;
> >>>     
> >>>
> >>> Providing you have twm and xterm, default startx will start.
> >>>
> >>> Regards,
> >>>
> >>> Roy Bamford
> >>>
> >>> On 25/09/2022 16:12, Alistair wrote:
> >>>> Roy,
> >>>>
> >>>>> [ 272.782] (EE) open /dev/dri/card0: No such file or directory
> >>>> This (zero size) file does exist, owner: root; group: video.
> >>>>
> >>>> I tried the startplasma-x11 command:
> >>>>
> >>>> $ startplasma-x11
> >>>>
> >>>> $DISPLAY is not set or cannot connect to the x server
> >>>>
> >>>> Searching on that error took me to the arch forum and wiki
> >>>>
> >>>> systemctl status sddm.service
> >>>>
> >>>> sddm service
> >>>>
> >>>> loaded: masked (Reason: unit sddm.service is masked.)
> >>>>
> >>>> Active: inactive (dead)
> >>>>
> >>>> (On a working system I get:
> >>>>
> >>>> ●sddm.service - Simple Desktop Display Manager     Loaded: loaded
> >>>> (/lib/systemd/system/sddm.service; enabled; vendor preset: enabled)
> >>>>      Active: active (running)since Sun 2022-09-25 08:55:39 BST...)
> >>>>
> >>>> I followed the trail of text files from:
> >>>>
> >>>> systemctl get-target
> >>>>
> >>>> graphical.target
> >>>>
> >>>> All contained similar to a working system, but did not lead me
> >>>> anywhere useful.
> >>>>
> >>>> Trying:
> >>>>
> >>>> systemctl enable sddm.service
> >>>>
> >>>> (input password three separate times)
> >>>>
> >>>> ...
> >>>>
> >>>> ...
> >>>>
> >>>> ...
> >>>>
> >>>> Each get "===AUTHENTICATION COMPLETE==="
> >>>>
> >>>> The final line stated:
> >>>>
> >>>> Failed to enable unit: unit file /etc/systemd/system/sddm.service is
> >>>> masked.
> >>>>
> >>>>> to test with startx, you need to install twm, xterm
> >>>>> and xclock. Be warned that tmw only uses the primary
> >>>>> mouse button.
> >>>> Checking for these three and installing as required, xclock "has no
> >>>> installation candidate" and suggested x11-apps instead.
> >>>>
> >>>> This has made no difference.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Alistair
> >>>>
> >>>> On Thursday, 22 September 2022 17:41:29 BST Roy wrote:
> >>>>
> >>>>> Alistair,
> >>>>> First, your t480-dmesg-2022-09-22:https://dpaste.com/F626WA62N  
> >>>> kernel log.
> >>>>
> >>>>> The i915 lines starting with
> >>>>> [ 2.043003] i915 0000:00:02.0: vgaarb: deactivate vga console
> >>>>> are good
> >>>>> [ 2.233768] fbcon: i915drmfb (fb0) is primary device
> >>>>> [ 2.245684] Console: switching to colour frame buffer device 240x67
> >>>>> Tells that kernel support for your Intel GPU in the kernel is correct
> >>>>> and working.
> >>>>> That's good as the Xorg driver will use it.
> >>>>> Now your Xorg.0.log-2022-09-22
> >>>>> Xorg is doing its automatic thing, that works for a single display setup
> >>>>> [ 272.780] (==) Matched modesetting as autoconfigured driver 0
> >>>>> [ 272.780] (==) Matched fbdev as autoconfigured driver 1
> >>>>> [ 272.780] (==) Matched vesa as autoconfigured driver 2
> >>>>> Its worked out that there are three possible drivers for your GPU.
> >>>>> They all loaded.
> >>>>> [ 272.782] (EE) open /dev/dri/card0: No such file or directory
> >>>>> That's a bad thing. That /dev file is created by the kernel. The kernel
> >>>>> part of the driver started OK. Is that file really missing?
> >>>>> Its required for hardware video acceleration.
> >>>>> Eventually Xorg gets going on the fbdev driver.
> >>>>> [ 272.782] (II) FBDEV(0): Creating default Display subsection in
> >>>> Screen section
> >>>>
> >>>>> "Default Screen Section" for depth/fbbpp 24/32
> >>>>> [ 272.782] (==) FBDEV(0): Depth 24, (==) framebuffer bpp 32
> >>>>> The log ends with
> >>>>> [ 401.971] (II) Server terminated successfully (0). Closing log file.
> >>>>> which suggests that Xorg started, found nothing to do then exited.
> >>>>> That's expected when you run startx as there is no ~.xinitrc file
> >>>>> to tell Xorg what to do, so it tries to start three xterms and an
> >>>>> analogue clock all wrapped up in twm. Quite likely, none of those
> >>>>> things are installed.
> >>>>> In short Xorg, worked but somewhat suboptimally.
> >>>>> Rather than testing with startx, try startplasma-x11
> >>>>> to test with startx, you need to install twm, xterm
> >>>>> and xclock. Be warned that tmw only uses the primary
> >>>>> mouse button.
> >>>>> I use MATE. I suspect that plasma will not start properly
> >>>>> without that  /dev/dri/card0 file because it will want hardware
> >>>>> acceleration.
> >>>>> The file is created by the kernels DEVTMPFS option.
> >>>>> udev may create symlinks and fiddle with permissions but
> >>>>> your file appears to be missing completely.
> >>>>> Check that as a next step. If its missing, try another
> >>>>> kernel.
> >>>>> Regards,
> >>>>> Roy Bamford.
> >>>>> On 22/09/2022 11:19, Alistair wrote:
> >>>>>> Roy
> >>>>>> I think the Xorg.0.log file is all there is.
> >>>>>> This time I am including the Xorg.0.log.old file for comparison.
> >>>>>> On the T480 the Xorg.0.log file is only 2/3 the size of the
> >>>> Xorg.0.log.old file.
> >>>>
> >>>>>> The machine is a Thinkpad T480 with a i5-8350U CPU, and onboard
> >>>> Intel UHD Graphics 620.
> >>>>
> >>>>>> I saved/copied the files to USB then copied to my good machine
> >>>> before "select all; copy; paste." to the dpaste site.
> >>>>
> >>>>>> Uploaded files:
> >>>>>> Xorg.0.log.old-2022-09-22:https://dpaste.com/787GM4L7X
> >>>>>> Xorg.0.log-2022-09-22:https://dpaste.com/9A3LVBGCY
> >>>>>> t480-dmesg-2022-09-22:https://dpaste.com/F626WA62N
> >>>>>> Hope there is some useful data here.
> >>>>>> Regards,
> >>>>>> Alistair
> >>>>>> On Wednesday, 21 September 2022 22:12:10 BST Roy wrote:
> >>>>>>> Alistair,
> >>>>>>> Both logs are truncated. They will be several screenfuls of each log.
> >>>>>>> There are no errors there.
> >>>>>>> Save them to some removable media then post the whole files.
> >>>>>>> We can see that Xorg is doing its automatic thing and that you have a
> >>>>>>> 8086:5917 GPU.
> >>>>>>> 8086 means Intel.
> >>>>>>> 5917 is the PCI product ID of your GPU. That's a UHD Graphics
> >>>> 620. All
> >>>>
> >>>>>>> the interesting things are further down the log,
> >>>>>>> Current logs would be best as they will show the current state of
> >>>> your
> >>>>
> >>>>>>> system.
> >>>>>>> Regards,
> >>>>>>> Roy Bamford
> >>>>>>> On 21/09/2022 19:24, Alistair wrote:
> >>>>>>>> Roy,
> >>>>>>>> I copied out the contents of dmesg about a week (~13 boots)
> >>>> after the event, and the file date on the Xorg log is about the same
> >>>> day. I have just copied it out this evening.
> >>>>
> >>>>>>>> The files are at:
> >>>>>>>> dmesg:https://dpaste.com/4NKF4VDTX
> >>>>>>>> Xorg.0.log:https://dpaste.com/FDSEQTEWN
> >>>>>>>> I hope these are useful, and you can explain what I should look for.
> >>>>>>>> Regards,
> >>>>>>>> Alistair
> >>>>>>>> On Wednesday, 21 September 2022 17:26:17 BST Roy wrote:
> >>>>>>>>> Alistair,
> >>>>>>>>> I'm a Gentoo user so I can't tell you the steps to fix it but
> >>>> extracting
> >>>>
> >>>>>>>>> some debug information is distro agnostic.
> >>>>>>>>> The X server and desktop are two separate bits. It's possible
> >>>> for the X
> >>>>
> >>>>>>>>> Server to start and then for the desktop to fail. Since the desktop
> >>>>>>>>> depends on a working X Server, the other way round is not possible.
> >>>>>>>>> Step 1 is narrow the problem space.
> >>>>>>>>>  From you failed update system post the output of the dmesg
> >>>> command. If
> >>>>
> >>>>>>>>> you have the wgetpaste script, that will do all the hard work
> >>>> and return
> >>>>
> >>>>>>>>> a URL that you can share, like
> >>>>>>>>> $ wgetpaste -c dmesg
> >>>>>>>>> Your paste can be seen here:http://dpaste.com/49PQNMDVM
> >>>>>>>>> It will tell what your kernel did when it started. Errors or
> >>>> omissions
> >>>>
> >>>>>>>>> here make give a few hints.
> >>>>>>>>> Xorg also has a startup log file. If root runs Xorg, its at
> >>>>>>>>> /var/log/Xorg.0.log. If a normal user runs Xorg its in
> >>>>>>>>> /home/<username>/... but I don't know where. That will be good
> >>>> to see too.
> >>>>
> >>>>>>>>> $ wgetpaste -s 0x0 /var/log/Xorg.0.log
> >>>>>>>>> Your paste can be seen here:https://0x0.st/oVYj.0.log
> >>>>>>>>> If you use a graphical login, you will have both. The graphical
> >>>> login
> >>>>
> >>>>>>>>> runs Xorg as root, then when you log in, its run as the logged
> >>>> in user.
> >>>>
> >>>>>>>>> The idea, is just to get a few pointers to whats broken.
> >>>>>>>>> Those links are my real examples.
> >>>>>>>>> Regards,
> >>>>>>>>> Roy Bamford.
> >>>>>>>>> On 21/09/2022 14:16, Alistair wrote:
> >>>>>>>>>> Kevin,
> >>>>>>>>>> I created a new user, shutdown, and then booted normally.
> >>>>>>>>>> On logging in as the new user I tried to start the desktop,
> >>>> with the same result.
> >>>>
> >>>>>>>>>> Last week I extracted the .xsession-errors file from the machine.
> >>>>>>>>>> Unfortunately I had booted the box several times before then,
> >>>> such that the first shutdown recorded shows errors and is different to
> >>>> the sequence recorded on a good machine. It is different to all the
> >>>> subsequent entries immediately prior to attempting to startx.
> >>>>
> >>>>>>>>>> I have yet to find anything meaingful (to me at least) when
> >>>> searching for these messages.
> >>>>
> >>>>>>>>>> Last error before first startx attempt:
> >>>>>>>>>> XIO: fatal IO error 4 (Interrupted system call) on X server ":0"
> >>>>>>>>>> First error after first startx attempt:
> >>>>>>>>>> QDBusConnection: error: could not send signal to service ""
> >>>> path "//home/alistair/.kde/share/config/kdeglobals" interface
> >>>> "org.kde.kconfig.notify" member "ConfigChanged": Invalid object path:
> >>>> //home/alistair/.kde/share/config/kdeglobals
> >>>>
> >>>>>>>>>> The file '/home/alistair/.kde/share/config/kdeglobals' does
> >>>> exist and is similar to a good one. Is the extra leading '/' an error?
> >>>> and if so where is the file it is read from?
> >>>>
> >>>>>>>>>> Second error:
> >>>>>>>>>> Qt: Session management error: networkIdsList argument is NULL
> >>>>>>>>>> Andrew,
> >>>>>>>>>> I cannot now remember if the upgrade included a kernel update,
> >>>> but 'linux-generic' is one of 25 packages now being held back by
> >>>> 'apt-get dist-upgrade'.
> >>>>
> >>>>>>>>>> This box has kernels 5.15.0-46, and 5.15.0-47 installed.
> >>>>>>>>>> I booted into 5.15.0-46 and tried to start the desktop without
> >>>> success.
> >>>>
> >>>>>>>>>> It boots to the console, and after logging in and then
> >>>> starting X, I get the "plasma by kde"(?) black screen with a moveable
> >>>> mouse pointer.
> >>>>
> >>>>>>>>>> Regards
> >>>>>>>>>> Alistair
> >>>>>>>>>> On Tuesday, 20 September 2022 22:40:10 BST Andrew Robinson wrote:
> >>>>>>>>>>> Did the kernel upgrade at the same time? Did you try booting
> >>>> into the older kernel and still get the problem? I have had something
> >>>> similar and I needed to add a boot flag, correctly boot and then
> >>>> update again but it’s tough to say without access. You’re able to
> >>>> login? So you can see a GUI at a login?
> >>>>
> >>>>>>>>>>> I know this is not the time to say such a thing as it’s of no
> >>>> help to you now but it’s also a great place to plug using Btrfs and
> >>>> snapshots, you can have it automatically snapshot whenever you do a
> >>>> package manager command, if you destroy it, you can boot to the old
> >>>> snapshot. I recently did this while playing around with new wayland
> >>>> settings, destroyed it, couldn’t boot, went back to the last snapshot
> >>>> (taken automatically when I updated a wayland package) and I was back
> >>>> in the game. (running Arch)
> >>>>
> >>>>>>>>>>> From: Kevin Davidson
> >>>>>>>>>>> Sent: 20 September 2022 22:26
> >>>>>>>>>>> To: Edinburgh Linux Users Group
> >>>>>>>>>>> Subject: Re: [EdLUG] Kubuntu Desktop broken after 'apt-get
> >>>> dist-upgrade'
> >>>>
> >>>>>>>>>>> I think I missed the beginning of this, but if I were
> >>>> troubleshooting this, the first thing I'd try is to log in as a
> >>>> different user and see if you still have the problem, Create another
> >>>> temporary user account if you need to. If that works, then it’s not
> >>>> the software installation that’s the problem, it’s the configuration.
> >>>> Start looking through all the dot files and see what’s different
> >>>> between the config that works and the one that doesn’t. The
> >>>> .xsession-errors file ought to be a useful log of what went wrong.
> >>>>
> >>>>>>>>>>> Kevin
> >>>>>>>>>>> On 20 Sep 2022, at 21:54,
> >>>> Alistair<alistair at archerry.plus.com>  wrote:
> >>>>
> >>>>>>>>>>> I am still struggling to understand how to recover the
> >>>> desktop in a refined manner.
> >>>>
> >>>>>>>>>>> Some of the sites I have found discuss re-installing the
> >>>> display manager and/or window manager and/or the desktop environment,
> >>>> but non of them mention kde plasma explicitly.
> >>>>
> >>>>>>>>>>> (I see the kde plasma logo and spinning cog wheel when I
> >>>> issue the 'startx' command. It just stops at a black screen.)
> >>>>
> >>>>>>>>>>> Taking a "blunderbuss" approach, I have looked at simply
> >>>> re-installing the kubuntu desktop.
> >>>>
> >>>>>>>>>>> Is this an acceptable approach? Or are there further
> >>>> questions I can ask to establish the system state and what needs fixing?
> >>>>
> >>>>>>>>>>> Using the simulation option of apt-get, I can compare what
> >>>> will be installed / re-installed on the system compared to another
> >>>> working setup:
> >>>>
> >>>>>>>>>>> Broken T480:
> >>>>>>>>>>> 'sudo apt-get install -s --reinstall kubuntu-desktop
> >>>>>>>>>>> Reading package lists...
> >>>>>>>>>>> Building dependency tree...
> >>>>>>>>>>> Reading state information...
> >>>>>>>>>>> The following additional packages will be installed:
> >>>>>>>>>>> fonts-noto-unhinted haveged ibus-data kde-style-oxygen-qt5
> >>>> kgamma5
> >>>>
> >>>>>>>>>>> kubuntu-settings-desktop libhavege2 libibus-1.0-5
> >>>> liboxygenstyle5-5
> >>>>
> >>>>>>>>>>> liboxygenstyleconfig5-5 libscim8v5 libxcb-record0 plasma-desktop
> >>>>>>>>>>> plasma-desktop-data plasma-thunderbolt plasma-widgets-addons sddm
> >>>>>>>>>>> sddm-theme-breeze
> >>>>>>>>>>> Suggested packages:
> >>>>>>>>>>> ibus quota
> >>>>>>>>>>> The following NEW packages will be installed
> >>>>>>>>>>> fonts-noto-unhinted haveged ibus-data kde-style-oxygen-qt5
> >>>> kgamma5
> >>>>
> >>>>>>>>>>> kubuntu-desktop kubuntu-settings-desktop libhavege2 libibus-1.0-5
> >>>>>>>>>>> liboxygenstyle5-5 liboxygenstyleconfig5-5 libscim8v5
> >>>> libxcb-record0
> >>>>
> >>>>>>>>>>> plasma-desktop plasma-desktop-data plasma-thunderbolt
> >>>> plasma-widgets-addons
> >>>>
> >>>>>>>>>>> sddm sddm-theme-breeze
> >>>>>>>>>>> 0 to upgrade, 19 to newly install, 0 to remove and 67 not to
> >>>> upgrade.'
> >>>>
> >>>>>>>>>>> Working T450:
> >>>>>>>>>>> 'sudo apt-get install -s --reinstall kubuntu-desktop
> >>>>>>>>>>> Reading package lists... Done
> >>>>>>>>>>> Building dependency tree
> >>>>>>>>>>> Reading state information... Done
> >>>>>>>>>>> 0 to upgrade, 0 to newly install, 1 reinstalled, 0 to remove
> >>>> and 0 not to upgrade.
> >>>>
> >>>>>>>>>>> Inst kubuntu-desktop [1.398] (1.398 Ubuntu:20.04/focal [amd64])
> >>>>>>>>>>> Conf kubuntu-desktop (1.398 Ubuntu:20.04/focal [amd64])'
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Alistair
> >>>>>>>>>>> On Tuesday, 13 September 2022 21:10:09 BST Ken Robson wrote:
> >>>>>>>>>>> OK my bad .Xauthority is right one.
> >>>>>>>>>>> ⁣Ken
> >>>>>>>>>>> Get BlueMail for Android ​
> >>>>>>>>>>> On 13 Sep 2022, 19:11, at 19:11,
> >>>> Alistair<alistair at archerry.plus.com>  wrote:
> >>>>
> >>>>>>>>>>> Ken,
> >>>>>>>>>>> Thanks for the suggestion.
> >>>>>>>>>>> I cannot find a file called .xauth.
> >>>>>>>>>>> In the /home/alistair/ folder are the files:
> >>>>>>>>>>> .Xauthority and .xsession-errors.
> >>>>>>>>>>> I have 'rsync' these, and the output of 'dmesg' to another
> >>>> box so that
> >>>>
> >>>>>>>>>>> I may view them more easily.
> >>>>>>>>>>> What clues should I look for in these, or other files ?
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Alistair
> >>>>>>>>>>> On Tuesday, 13 September 2022 18:15:05 BST Ken Robson wrote:
> >>>>>>>>>>> I had a similar issue a few years ago.
> >>>>>>>>>>> Try renaming the ~/.xauth file (sudo mv ~/.xauth ~/xauth) and
> >>>> see if
> >>>>
> >>>>>>>>>>> x will load then.
> >>>>>>>>>>> ⁣Ken
> >>>>>>>>>>> Get BlueMail for Android ​
> >>>>>>>>>>> On 13 Sep 2022, 17:56, at 17:56, Alistair
> >>>>>>>>>>> <alistair at archerry.plus.com>  wrote:
> >>>>>>>>>>> azmodie,
> >>>>>>>>>>> Thanks for the prompt reply.
> >>>>>>>>>>> "sudo dpkg --configure -a"
> >>>>>>>>>>> Reports no actions.
> >>>>>>>>>>> "sudo apt-get update", followed by
> >>>>>>>>>>> "sudo apt-get dist-upgrade" or "sudo apt-get install -f":
> >>>>>>>>>>> Both Reports
> >>>>>>>>>>> "0 to upgrade 0 to newly install 0 to remove and 13 not to
> >>>> upgrade"
> >>>>
> >>>>>>>>>>> So I need to dig deeper...
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Alistair
> >>>>>>>>>>> On Tuesday, 13 September 2022 15:26:18 BST azmodie wrote:
> >>>>>>>>>>> Hi Alistar,
> >>>>>>>>>>> I'd try the usual recovery commands.
> >>>>>>>>>>> sudo apt-get update
> >>>>>>>>>>> sudo apt-get upgrade
> >>>>>>>>>>> You may need to run
> >>>>>>>>>>> sudo dpkg --configure -a
> >>>>>>>>>>> or
> >>>>>>>>>>> sudo apt-get install -f
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> azmodie
> >>>>>>>>>>> --
> >>>>>>>>>>> http://gplus.to/azmodie
> >>>>>>>>>>> "Since light travels faster than sound, people appear bright
> >>>> until
> >>>>
> >>>>>>>>>>> you hear
> >>>>>>>>>>> them speak." -- some bright spark
> >>>>>>>>>>> On Tue, 13 Sept 2022 at 14:23, Alistair
> >>>>>>>>>>> <alistair at archerry.plus.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>> Last week I updated my Thinkpad T480 (running Kubuntu 22.04)
> >>>>>>>>>>> using
> >>>>>>>>>>> the
> >>>>>>>>>>> command line. During the process the laptop crashed, and I am no
> >>>>>>>>>>> longer
> >>>>>>>>>>> able to access the desktop.
> >>>>>>>>>>> I can login to console after boot up, but when I try to start
> >>>>>>>>>>> the
> >>>>>>>>>>> desktop
> >>>>>>>>>>> with 'startx' I get a black screen. To get there it asks for a
> >>>>>>>>>>> Kwallet
> >>>>>>>>>>> password - (never previously used) and a wireless network
> >>>>>>>>>>> password.
> >>>>>>>>>>> The
> >>>>>>>>>>> mouse pointer is a black arrow with a white outline, which does
> >>>>>>>>>>> follow
> >>>>>>>>>>> movements of the trackpad but does not respond to right or left
> >>>>>>>>>>> buttons.
> >>>>>>>>>>> I tried 'apt-get dist-upgrade' with the '-f' option to no
> >>>>>>>>>>> avail.
> >>>>>>>>>>> I think it stated that several packages would be held back
> >>>>>>>>>>> before
> >>>>>>>>>>> the
> >>>>>>>>>>> update. I booted into recovery mode, ran 'fsck', 'clean',
> >>>>>>>>>>> enabled
> >>>>>>>>>>> network,
> >>>>>>>>>>> then ran 'dpkg' which updated 41 packages, but still no proper
> >>>>>>>>>>> desktop.
> >>>>>>>>>>> How do I confirm the current state of the system, and then
> >>>>>>>>>>> recover
> >>>>>>>>>>> /
> >>>>>>>>>>> repair the Kubuntu desktop?
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Alistair
> >>>>>>>>>>> --
> >>>>>>>>>>> EdLUG mailing list
> >>>>>>>>>>> EdLUG at mailman.lug.org.uk
> >>>>>>>>>>> https://lists.edlug.org.uk/mailman/listinfo/edlug
> >>
> >