Posting into this thread, because I am having a “similar” problem with my TW “log in” window and problems getting the “suspend” and other options to show up . . . happening slowly would be the similar condition. Don’t have too much time today to trouble shoot, but weekly updates to TW MATE DE on my '12 Mac Pro with Nvidia 780 card . . . multi-boot, problems not happening in the other systems.
Did not switch graphic cards as the OP did, can’t recall if last week there were a bunch of “firmware” upgrades. Today the log in window appeared quickly, typed the password and then it just went to the log in manager wallpaper image and just sat there with a cursor, but no tool bar for over a minute. I logged into t a TTY and ran a zypper, got 155 packages to upgrade, rebooted and back into the same thing . . . not sure which log in manager I’m using now, but the second time I could see how the password window disappeared into the wallpaper image and then this time I waited for two minutes and noticed the toolbar slowly appeared with nothing in it. Then a couple minutes later the MATE menu appeared . . . I clicked on browser and nothing happened, etc. Tried a few times, then it finally worked.
Then when I tried to suspend the machine the MATE menu “works” to show “log out” . . . clicking on suspend brings a spinning beachball, then “poof” it disappears, nothing happens. Second time, same process brings the “suspend” option and it “works.”
I’m still using X11 in this machine, I kind of was narrowing it down to “mate-session” seems to be “slow” or problematic . . . something isn’t up to par, etc. It’s “slow” to log in, not fast, and that’s the question with the OP, if he waited for a couple of minutes could he log in? That would be the “similarity” in the Tale from Two Different Systems . . .
I wasn’t trying to “hijack” the thread, didn’t have time to see whether it was a perfect fit, somebody else mentioned “Is anybody else experiencing this problem” and you have provided an almost similar title . . . as the first one . . . “Log in problems” . . . ??? I posted my experience with “logging in” . . . in a thread that was talking about . . . problems “logging into the GUI”???
Seems like a similar thread . . . “hijacked” or not . . . ??? Non-critical whether in another thread or here . . . .
Best to start your own thread (with a suitable descriptive title), and then include a link to any similar thread that you think may be related. However, I don’t think the thread you originally posted in is related - likely different underlying causes.
Cool. I logged in to post my own thread, but then saw the similar issue title and saw the similarities rather than the areas that were different.
So, OK, new thread . . . the problem is likely still happening, what I didn’t post happened after I had reported my issue . . . when “reviving” from suspend the “mate-session” “suspend” “shut down” etc window was still loaded in the GUI window . . . which then “logged out” to the log in window . . . along with this, needing to go through the “suspend” process two times for it to work . . . .
Overalll system slowness in those tasks . . . but bouncing around the web seemed OK.
So, for the scientific comparison, same machine, today is Debian Sid day . . . boots fast, logs in fast, gets around the net fast, except for IG keeps logging me out for multi-booting . . . otherwise, all systems “go” in mr Sid.
Today is Leap 15.6 day . . . Leap . . . lept into service . . . lept through the log in and GUI population . . . . All is well in 15.6 . . . for today.
Today is Gecko rolling MATE day, so essentially the ¨same" system as TW, on the same machine . . . system booted in a timely manner and Firefox booted up quickly. The only problem that Gecko has is this ḧarfuzz ümlaut"instead of a quotation and the spacebar not moving up the space after the second quotation . . . .
Otherwise it seems like the issue of slow boot, slow log in, slow launching of FF is an exclusive TW issue???
@non_space run systemd-analyze to see what is slow… I see a backup-rpmdb.service running on last boot that ran for 15 odd seconds… Generally a slow boot indicates some maintenance going on, maybe trim, purging kernels etc…
Thanks for the hint on it, Iĺl check on that in a bit. This was beyond ¨slow" and was IMHO similar to the other thread, where the GUI didn´t load at all and I had to go to a TTY to see if running zypper would change the situation. Admins said it was änother problem". . . after running the zypper I could get to GUI log in but it was much longer than a blink of a 15 second delay, and then other functional issues continued, etc.
Iĺl post back when Iǘe had a chance to run that command.
@non_space yes, there seems to be some folks having login issues…
For me all good (which doesn’t help ) I have a good mixture here, TW and GNOME with Nvidia on X11, MicroOS with Aeon (Wayland) and Intel, MicroOS with Aeon (Wayland) and AMD (CPU and GPUs) and MicroOS with Hyprland (sway) and Intel (this just logs in from the tty)…
Hmm . . . yes, it definitely is a “log in” issue. I just rebooted into TW and got to the log in window in fairly good order timewise, but after clicking “go” on the password I literally sat there for 2 or 3 minutes . . . with just the wallpaper and the cursor showing. I finally moved the mouse around vigorously and a few seconds later the outline of the toolbar showed up . . . and then a few seconds later the full desktop GUI loaded. Clicking on terminal to run the command wasn’t exactly zippy . . . and same with launching FF, slow to load the gmail tab . . . .
ran the command, and I’d have to say it is quite “optimistic” in its self-assessment.
# systemd-analyze
Startup finished in 1.049s (kernel) + 3.425s (initrd) + 6.784s (userspace) = 11.258s
graphical.target reached after 6.783s in userspace.
@non_space So I would suggest a couple of things, boot to multi-user target and see how long the graphical target takes, then do the same and set autologin of your user from the same and see how it goes;
su -
systemctl set-default multi-user.target
systemctl reboot
On restart, login as root user and run;
systemctl isolate graphical.target && exit
How does that go? Then set autologin and reboot and run the above command…
To return to booting to graphical target;
su -
systemctl set-default graphical.target
Next reboot will boot to the graphical environment.
Alrighty, have to jump out of the house for a bit, but I just ran a zypper dup -l installing 104 packages plus new kernel . . . on reboot, the issue prevailed. Lots of “whack” behaviors from the GUI, still needing to launch twice to get to an app, etc.
Second round of upgrades in the same day . . . first one went to 6.5.2 kernel and the second one to 6.5.3 and an upgrade on systemd-254.3 . . . and same problems with slow log in and strange, launch/crash/launch on apps like terminal . . . .
Stuff to do before I mess with Malcolm’s suggestions, but ran the systemd-analyze again and similar, but perhaps slower??
sudo systemd-analyze
[sudo] password for root:
Startup finished in 1.137s (kernel) + 2.895s (initrd) + 8.007s (userspace) = 12.040s
graphical.target reached after 8.007s in userspace.
Forum doesn’t seem to show quotation of data when replying . . . so I ran through the change to multi-user and the second command to “isolate && exit” and got back to log in window and everything worked in reasonable speed.
So I skipped the “set autologin” step and just ran the last command to change back to “graphical.target” and . . . the problems are back . . . .
It’s not just the “log in” but the slowness of getting content to browser tabs that is part of the problem. Did “we” learn anything, or, I should repeat the steps through the “re-set autologin” (which is where? in YaSt???) and then try again?? Might not have the time for it until later.
) I have a good mixture here, TW and GNOME with Nvidia on X11, MicroOS with Aeon (Wayland) and Intel, MicroOS with Aeon (Wayland) and AMD (CPU and GPUs) and MicroOS with Hyprland (sway) and Intel (this just logs in from the tty)…