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

[Roy]

Alistair,

I'm pleased its fixed. Its unlikely you will find out what happened.

For an educated guess, kubuntu-desktop will be lots of small pieces. 
When your system crashed during the update, you had a part old and part 
new kubuntu-desktop installed and the pieces did not work together. 
That's expected. Thus the reinstall fixed it as it gave you a set a 
matching pieces.

Fixing it beats a reinstall.

All the best,

Roy Bamford.


On 28/09/2022 10:44, Alistair wrote:
> 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
>>>
>>>
>>>
>>
>
>
>
>