You are not logged in.
Pages: 1
Gemini 4.4. I have noticed on a number of occasions that Gemini will hang on login if I log off after making a change via System settings, or running updates.
System: Host: mopsie Kernel: 5.10.0-5-amd64 x86_64 bits: 64 Desktop: KDE Plasma 5.20.5 Distro: Q4OS 4.4.1-n1
Machine: Type: Desktop System: Dell product: OptiPlex 7040 v: N/A serial: <superuser required>
Mobo: Dell model: 0HD5W2 v: A01 serial: <superuser required> UEFI [Legacy]: Dell v: 1.11.1 date: 10/10/2018
CPU: Info: Quad Core model: Intel Core i5-6500 bits: 64 type: MCP L2 cache: 6 MiB
Speed: 800 MHz min/max: 800/3600 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800
Graphics: Device-1: Intel HD Graphics 530 driver: i915 v: kernel
Display: x11 server: X.Org 1.20.10 driver: loaded: modesetting unloaded: fbdev,vesa resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa Intel HD Graphics 530 (SKL GT2) v: 4.6 Mesa 20.3.4
Audio: Device-1: Intel 100 Series/C230 Series Family HD Audio driver: snd_hda_intel
Sound Server: ALSA v: k5.10.0-5-amd64
Network: Device-1: Intel Ethernet I219-LM driver: e1000e
IF: enp0s31f6 state: up speed: 100 Mbps duplex: full mac: 50:9a:4c:4c:b1:c8
Device-2: Ralink MT7601U Wireless Adapter type: USB driver: mt7601u
IF: wlx00e02d3c967a state: down mac: 00:e0:2d:3c:96:7a
Drives: Local Storage: total: 685.61 GiB used: 6.7 GiB (1.0%)
ID-1: /dev/sda vendor: Samsung model: SSD 860 PRO 256GB size: 238.47 GiB
ID-2: /dev/sdb type: USB vendor: SanDisk model: SSD PLUS 480GB size: 447.13 GiB
Partition: ID-1: / size: 14.32 GiB used: 6.4 GiB (44.7%) fs: ext4 dev: /dev/sdb1
ID-2: /home size: 423.66 GiB used: 307.8 MiB (0.1%) fs: ext4 dev: /dev/sdb6
Swap: Alert: No Swap data was found.
Sensors: System Temperatures: cpu: 40.5 C mobo: 29.8 C
Fan Speeds (RPM): N/A
Info: Processes: 172 Uptime: 15m Memory: 7.66 GiB used: 1.63 GiB (21.3%) Shell: Bash inxi: 3.3.01
I have seen the same happen in VM as well, but this is a hard install. It gets from the login screen to the splash screen and then sits with the progress bar at 50% for up to 3 minutes. Switching to a console log in I can see that much of the normal plasma stuff is just not loaded. Eventually it does and all is well.
Logoff and logon without having made any changes is usually fine. At this stage I'm not sure where to start looking. It is worrying that I have seen this with other Plasma versions on Debian and Ubuntu bases including Quark.
EDIT:- I normally flip between console and UI while this is happening and just now I caught a prompt for admin password for SMART monitoring. Switched it off in Services and problem goes away. I have a vague memory that smartctl requires admin access to the drive to work so that may be the problem.
-----------
EDIT by Admin:
This report has been registered at the official bug tracker https://sourceforge.net/p/q4os/tickets/158/
-----------
Last edited by q4osteam (2021-04-29 12:37)
Offline
A bit of further testing and experimenting. I think the SMART thing is a red herring. I am able to reproduce this by going to Settings and adding a new splash screen. Log out - which is a bit slow - then log in and wait...........
I think other changes I have made in settings have had similar results - definitely fonts.
On log out it looks like X reloads.
Offline
We are not able to reproduce in Virtual machine so far. The testing procedure:
- Fresh Q4OS 4.4 Gemini installation q4os-4.4-x64-testing.r1.iso in Virtualbox
- Full Apt update and dist-upgrade
- Run System-settings > Startup and shutdown > Splash screen > Get new splash screens button > install the first "Iota splash" > Close button > select the "Iota-splash" > Apply button > close System settings window
- Log out, Log in works fine
We will continue to investigate, would you suggest anything for us to reproduce the issue ?
Offline
Hi bin
And there is nothing interesting in the system logs (daemon.log, debug, messages etc)?
Offline
OK - after a long weekend testing various versions of plasma based distros I have decided to call it a day with Plasma.
The hanging behaviour is completely absent in Quark and anything based on Ubuntu 20.04 or earlier. On the upcoming Hirsute Hippo it happens, and on Bullseye based Debian stuff it happens.
It is related to how X responds to kde5 being stopped at logout. When it happens in a VM the CPU usage drops to 0 for the couple of minutes it takes to sort itself out.
Not unduly bothered. As some folks may recall I do have mixed feelings about Plasma, and I have a very nice TDE system with which to continue.
Offline
A pause in work can happen in any Linux. This is usually associated with waiting for a response from a device previously registered in the system.
For example, they pulled out a USB flash drive without unmounting.
In any case, to localize the cause, you need to look at the logs. It is possible to observe the lines running across the screen, especially when the computer is turned off, when the reason is clearly visible.
But everyone has their own preferences ...
Offline
A pause in work can happen in any Linux. This is usually associated with waiting for a response from a device previously registered in the system.
For example, they pulled out a USB flash drive without unmounting.
In any case, to localize the cause, you need to look at the logs. It is possible to observe the lines running across the screen, especially when the computer is turned off, when the reason is clearly visible.
But everyone has their own preferences ...
I am well aware of the huge range of factors that can affect what goes on in any system, and have identified a couple of potential points of interest in the prolific splurge of rubbish that plasma writes out - esp .xsession-errors
Shutdown is not a problem, it is related to the transition out of the current session and consequently hard to trap. I even tried running a screen recorder to see if I could pick up the content as X is dropped after hitting the logout OK and before SDDM re-loads. I haven't tried replacing SDDM as a final thought, but may do so to see if that is the source.
Offline
I haven't tried replacing SDDM as a final thought, but may do so to see if that is the source.
Yes, that could be a clue.
Offline
While I don't have the same issue, I do face a situation where sometimes reboot/poweroff will take a bit longer than expected, it doesn't happen all the time and it seems that has something to do with how many processes should be killed/terminated, at least that's what I think since when the system is idle rebooting or powering off happens quickly. I'm not sure whether it's a kernel or systemd related thing, and while searching for some clues as to how to troubleshoot, I found this https://freedesktop.org/wiki/Software/s … eventually it says to create a script
#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /
Name it debug.sh, move it to /usr/lib/systemd/system-shutdown/ and make it executable. Then boot with the following options
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0
What I'm not sure about is where exactly those options go, /etc/default/grub ? Then it says to "Look for timeouts logged in the resulting file shutdown-log.txt and/or attach it to a bugreport." I'd like to try if someone can confirm where those options need to be added.
I'm not sure if this may or may not help with your issue, but it might be worth a try.
Last edited by Tolkem (2021-04-19 17:05)
Offline
Pages: 1