[EdLUG] Kubuntu Desktop broken after 'apt-get dist-upgrade'
Roy
roy at crossford.net
Tue Sep 27 18:18:42 UTC 2022
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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.edlug.org.uk/pipermail/edlug/attachments/20220927/d3ae690a/attachment-0001.htm>
More information about the EdLUG
mailing list