0

To rid myself of an annoying Budgie icon during boot (leftover from when I installed and then removed the Budgie desktop environment), I issued this command : sudo update-alternatives --config default.plymouth (found on this page: "Getting back Ubunutu's default boot splash" ) and changed the image from the default Budgie icon, back to the normal Ubuntu symbol.

No problem there. So I rebooted to see how it worked. And it worked great -- until I got to the login screen, where I got yet another login loop, where I type my password, hit enter, and it brings me right back.

I'm totally clueless as to how this came about, from switching the boot logo. Thankfully, I'm still able to login using LXDE, which is what I'm using right now.
So I tried issuing the same command as before (sudo update-alternatives --config default.plymouth) and changed it back to the Budgie icon, hoping that would fix it.

No luck. I still have a persistent login loop when trying to login to the Ubuntu desktop environment.

During one reboot, I was able to get some information by pressing F2 (I think), but I don't know if this is useful at all:
enter image description here enter image description here

Any ideas as to what is causing the problem?? Help would be much appreciated.

Update: Using the LXDE desktop environment, I opened the "Logs" application, thinking there might be some useful information. The first entry looks very similar to the error that showed up on my boot screen shown in the second picture. The expanded entry farther down also looks like it could be important: LXDE 'Logs'

Does this "timed out" error have something to do with my fstab file? And if so, why would that effect the login manager??

Improve this question
7
  • If you can log in to one desktop session (LXDE) but not another (Ubuntu/gnome) the first place I would look for clues is in your ~/.xsession-errors file
    – steeldriver
    Jul 20, 2019 at 19:50
  • @steeldriver Running cat .xsession-errors returns a 'no such file or directory', and searching in the file manager doesn't come up with anything either. Apparently it doesn't exist. Is there somewhere else I should look for clues?
    – Kaleb
    Jul 20, 2019 at 20:38
  • My apologies - it seems like gdm3 no longer uses that file. Do you have a $XDG_CACHE_HOME/gdm/session.log instead?
    – steeldriver
    Jul 20, 2019 at 20:51
  • @steeldriver Trying cat $XDG_CACHE_HOME/gdm/session.log doesn't give me anything either, and no luck with the file explorer. Would attempting a login with lightdm or another login manager be a good idea?
    – Kaleb
    Jul 20, 2019 at 22:06
  • i doubt lightdm or another DE would work because the loop is something failing when setting up the user environment at login. but if i had this problem, i'd try it anyway just to see if what fails gets better environment settings that way. the chance of it working might be close to zero but it is above zero.
    – Skaperen
    Jul 21, 2019 at 2:11

1 Answer 1

Reset to default
0

It appears that I was mistaken as to the actual source of the problem: changing the boot splash, as I originally thought, had nothing to do with it. The actual cause of the problem was the application gnome-clocks that I had recently installed without giving much thought to it. After simply running sudo apt remove gnome-clocks, I was able to log back into my Ubuntu desktop without a single problem.

Therefore, BEWARE of gnome-clocks all 19.04 users!!!! Being an inexperienced Linux user, I can't say that this application is necessarily "bad", but I do know that it certainly messed things up for me.

As a side note, I also discovered an issue with my swap partition, though I don't know if that was at all related to the login loop or not. The details of that problem, and methods to solve it, I found in this post. Basically, after creating the swap space in gparted, a new UUID was somehow assigned to that partition, which didn't match the UUID in my fstab file. That is what was causing the "A start job is running for dev/disk/by-uuid... error on boot. All I had to do in this case was copy the correct UUID for my swap partition from gparted (or I could have got it from disks) and paste that into the correct place in my fstab.

Thank you everyone who posted helpful comments on this question, and once again, watch out for gnome-clocks on Ubuntu 19.04.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.