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

[Alistair]

Roy

Thanks for your help.
This morning I searched for the location of logs for kubuntu-desktop. The results pointed to pattern searches within 'journalctl' (part of systemd?).
This text file is 40+MB on my older box.
I can see where I did the apt-get updates, and me powering off after it crashed, but I cannot see why / how it lost the desktop.
I opted to just reinstall kubuntu-desktop. I think it was about 100MB of files to install.

Success!

I have rebooted directly into a working desktop.
I would have liked to understand what happened before doing anything, but istead I will try to do some diagnostics on the hardware.

Again, thanks to all who responded.

Regards,
Alistair

On Tuesday, 27 September 2022 20:29:23 BST Roy wrote:
> Alistair,
> 
> As KDE is broken both of you and a new user, it sounds like something 
> went wrong with the KDE-plasma install.
> 
> Run the KDE-plasma part of the install again. Its odd that it will not 
> start for a new user.
> 
> I expect that plasma has its own logs somewhere but as a MATE user, I 
> don't know what I'm looking for.
> 
> Regards,
> 
> Roy Bamford.
> 
> 
> 
> On 27/09/2022 20:16, Alistair wrote:
> > 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
> >
> >
> >
> >
> 
>