Booting into two different GNOME configurations randomly. How to investigate?











up vote
2
down vote

favorite












Short description:



I have an Ubuntu 18.04 installation and everything looks normal during boot up to and including the login screen. When I login my GNOME setup could be either:




  1. The configuration I have been using (e.g. with applications locked to launcher, startup applications, favorites in Files etc.) OR

  2. The original configuration with Amazon and Rhythmbox on the launcher as if it was before I did all the configurations.


Each time I restart the machine it could go into either of these. And after couple of attempts I can get to '1'. After than I can work without any crashes etc. Because of this I leave the machine up for weeks until I have to restart.



This 'non-deterministic' behavior puzzle me. How can I investigate this? What logs should I look in?



Confession:
I login as 'root' as it makes life easy, at least once logged into the right configuration. I can add details if that is relevant. I have done this since 12.04 without too much trouble, but it was Unity until 18.04.



Few more details:




  • The problem was there since the first installation in August.

  • System is 'Precision Tower 3620' with an NVMe SSD and OS is on the SSD.

  • Secure boot was disabled due to problems with UEFI and SSD.

  • Just after original install 'Ubuntu Software' prompted for a BIOS update which had a bug in not recognizing the SSD and was rolled back.

  • In both '1' and '2', It is the same grub entry. The root ('/') file system is the same.

  • I have looked in kern.log, boot.log and Xorg.log between the two cases and nothing jumps out.


Edit: From auth.log



Nov 29 08:25:35 JEEVES-DEV gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Nov 29 08:25:35 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Nov 29 08:25:51 JEEVES-DEV gdm-password]: pam_unix(gdm-password:session): session opened for user root by (uid=0)
Nov 29 08:25:51 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)

Nov 29 08:30:41 JEEVES-DEV gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Nov 29 08:30:41 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Nov 29 08:30:54 JEEVES-DEV gdm-password]: pam_unix(gdm-password:session): session opened for user root by (uid=0)
Nov 29 08:30:54 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)









share|improve this question




















  • 1




    Using root is not Ubuntu standard. You should be logging in as a user and using sudo. xkcd.com/149 And normal use does not need sudo, just system maintenance. Each user has their own configuration, so you must be logging in as different users. Also your hardware normally needs UEFI firmware update and SSD firmware update, but that is separate issue.
    – oldfred
    Nov 29 at 16:30










  • You really should never log in as root. Root is a completely separate user and as @oldfred said, it is only for maintenance. When you change a setting as root, your normal user can't see it and the other way arround.
    – spacelander
    Nov 29 at 17:00










  • Thanks for checking this. Both occasions the user is the same. From auth.log.
    – Jeevaka
    Nov 29 at 17:07

















up vote
2
down vote

favorite












Short description:



I have an Ubuntu 18.04 installation and everything looks normal during boot up to and including the login screen. When I login my GNOME setup could be either:




  1. The configuration I have been using (e.g. with applications locked to launcher, startup applications, favorites in Files etc.) OR

  2. The original configuration with Amazon and Rhythmbox on the launcher as if it was before I did all the configurations.


Each time I restart the machine it could go into either of these. And after couple of attempts I can get to '1'. After than I can work without any crashes etc. Because of this I leave the machine up for weeks until I have to restart.



This 'non-deterministic' behavior puzzle me. How can I investigate this? What logs should I look in?



Confession:
I login as 'root' as it makes life easy, at least once logged into the right configuration. I can add details if that is relevant. I have done this since 12.04 without too much trouble, but it was Unity until 18.04.



Few more details:




  • The problem was there since the first installation in August.

  • System is 'Precision Tower 3620' with an NVMe SSD and OS is on the SSD.

  • Secure boot was disabled due to problems with UEFI and SSD.

  • Just after original install 'Ubuntu Software' prompted for a BIOS update which had a bug in not recognizing the SSD and was rolled back.

  • In both '1' and '2', It is the same grub entry. The root ('/') file system is the same.

  • I have looked in kern.log, boot.log and Xorg.log between the two cases and nothing jumps out.


Edit: From auth.log



Nov 29 08:25:35 JEEVES-DEV gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Nov 29 08:25:35 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Nov 29 08:25:51 JEEVES-DEV gdm-password]: pam_unix(gdm-password:session): session opened for user root by (uid=0)
Nov 29 08:25:51 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)

Nov 29 08:30:41 JEEVES-DEV gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Nov 29 08:30:41 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Nov 29 08:30:54 JEEVES-DEV gdm-password]: pam_unix(gdm-password:session): session opened for user root by (uid=0)
Nov 29 08:30:54 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)









share|improve this question




















  • 1




    Using root is not Ubuntu standard. You should be logging in as a user and using sudo. xkcd.com/149 And normal use does not need sudo, just system maintenance. Each user has their own configuration, so you must be logging in as different users. Also your hardware normally needs UEFI firmware update and SSD firmware update, but that is separate issue.
    – oldfred
    Nov 29 at 16:30










  • You really should never log in as root. Root is a completely separate user and as @oldfred said, it is only for maintenance. When you change a setting as root, your normal user can't see it and the other way arround.
    – spacelander
    Nov 29 at 17:00










  • Thanks for checking this. Both occasions the user is the same. From auth.log.
    – Jeevaka
    Nov 29 at 17:07















up vote
2
down vote

favorite









up vote
2
down vote

favorite











Short description:



I have an Ubuntu 18.04 installation and everything looks normal during boot up to and including the login screen. When I login my GNOME setup could be either:




  1. The configuration I have been using (e.g. with applications locked to launcher, startup applications, favorites in Files etc.) OR

  2. The original configuration with Amazon and Rhythmbox on the launcher as if it was before I did all the configurations.


Each time I restart the machine it could go into either of these. And after couple of attempts I can get to '1'. After than I can work without any crashes etc. Because of this I leave the machine up for weeks until I have to restart.



This 'non-deterministic' behavior puzzle me. How can I investigate this? What logs should I look in?



Confession:
I login as 'root' as it makes life easy, at least once logged into the right configuration. I can add details if that is relevant. I have done this since 12.04 without too much trouble, but it was Unity until 18.04.



Few more details:




  • The problem was there since the first installation in August.

  • System is 'Precision Tower 3620' with an NVMe SSD and OS is on the SSD.

  • Secure boot was disabled due to problems with UEFI and SSD.

  • Just after original install 'Ubuntu Software' prompted for a BIOS update which had a bug in not recognizing the SSD and was rolled back.

  • In both '1' and '2', It is the same grub entry. The root ('/') file system is the same.

  • I have looked in kern.log, boot.log and Xorg.log between the two cases and nothing jumps out.


Edit: From auth.log



Nov 29 08:25:35 JEEVES-DEV gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Nov 29 08:25:35 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Nov 29 08:25:51 JEEVES-DEV gdm-password]: pam_unix(gdm-password:session): session opened for user root by (uid=0)
Nov 29 08:25:51 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)

Nov 29 08:30:41 JEEVES-DEV gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Nov 29 08:30:41 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Nov 29 08:30:54 JEEVES-DEV gdm-password]: pam_unix(gdm-password:session): session opened for user root by (uid=0)
Nov 29 08:30:54 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)









share|improve this question















Short description:



I have an Ubuntu 18.04 installation and everything looks normal during boot up to and including the login screen. When I login my GNOME setup could be either:




  1. The configuration I have been using (e.g. with applications locked to launcher, startup applications, favorites in Files etc.) OR

  2. The original configuration with Amazon and Rhythmbox on the launcher as if it was before I did all the configurations.


Each time I restart the machine it could go into either of these. And after couple of attempts I can get to '1'. After than I can work without any crashes etc. Because of this I leave the machine up for weeks until I have to restart.



This 'non-deterministic' behavior puzzle me. How can I investigate this? What logs should I look in?



Confession:
I login as 'root' as it makes life easy, at least once logged into the right configuration. I can add details if that is relevant. I have done this since 12.04 without too much trouble, but it was Unity until 18.04.



Few more details:




  • The problem was there since the first installation in August.

  • System is 'Precision Tower 3620' with an NVMe SSD and OS is on the SSD.

  • Secure boot was disabled due to problems with UEFI and SSD.

  • Just after original install 'Ubuntu Software' prompted for a BIOS update which had a bug in not recognizing the SSD and was rolled back.

  • In both '1' and '2', It is the same grub entry. The root ('/') file system is the same.

  • I have looked in kern.log, boot.log and Xorg.log between the two cases and nothing jumps out.


Edit: From auth.log



Nov 29 08:25:35 JEEVES-DEV gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Nov 29 08:25:35 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Nov 29 08:25:51 JEEVES-DEV gdm-password]: pam_unix(gdm-password:session): session opened for user root by (uid=0)
Nov 29 08:25:51 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)

Nov 29 08:30:41 JEEVES-DEV gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
Nov 29 08:30:41 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Nov 29 08:30:54 JEEVES-DEV gdm-password]: pam_unix(gdm-password:session): session opened for user root by (uid=0)
Nov 29 08:30:54 JEEVES-DEV systemd: pam_unix(systemd-user:session): session opened for user root by (uid=0)






boot gnome 18.04






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 29 at 17:13

























asked Nov 29 at 16:19









Jeevaka

1114




1114








  • 1




    Using root is not Ubuntu standard. You should be logging in as a user and using sudo. xkcd.com/149 And normal use does not need sudo, just system maintenance. Each user has their own configuration, so you must be logging in as different users. Also your hardware normally needs UEFI firmware update and SSD firmware update, but that is separate issue.
    – oldfred
    Nov 29 at 16:30










  • You really should never log in as root. Root is a completely separate user and as @oldfred said, it is only for maintenance. When you change a setting as root, your normal user can't see it and the other way arround.
    – spacelander
    Nov 29 at 17:00










  • Thanks for checking this. Both occasions the user is the same. From auth.log.
    – Jeevaka
    Nov 29 at 17:07
















  • 1




    Using root is not Ubuntu standard. You should be logging in as a user and using sudo. xkcd.com/149 And normal use does not need sudo, just system maintenance. Each user has their own configuration, so you must be logging in as different users. Also your hardware normally needs UEFI firmware update and SSD firmware update, but that is separate issue.
    – oldfred
    Nov 29 at 16:30










  • You really should never log in as root. Root is a completely separate user and as @oldfred said, it is only for maintenance. When you change a setting as root, your normal user can't see it and the other way arround.
    – spacelander
    Nov 29 at 17:00










  • Thanks for checking this. Both occasions the user is the same. From auth.log.
    – Jeevaka
    Nov 29 at 17:07










1




1




Using root is not Ubuntu standard. You should be logging in as a user and using sudo. xkcd.com/149 And normal use does not need sudo, just system maintenance. Each user has their own configuration, so you must be logging in as different users. Also your hardware normally needs UEFI firmware update and SSD firmware update, but that is separate issue.
– oldfred
Nov 29 at 16:30




Using root is not Ubuntu standard. You should be logging in as a user and using sudo. xkcd.com/149 And normal use does not need sudo, just system maintenance. Each user has their own configuration, so you must be logging in as different users. Also your hardware normally needs UEFI firmware update and SSD firmware update, but that is separate issue.
– oldfred
Nov 29 at 16:30












You really should never log in as root. Root is a completely separate user and as @oldfred said, it is only for maintenance. When you change a setting as root, your normal user can't see it and the other way arround.
– spacelander
Nov 29 at 17:00




You really should never log in as root. Root is a completely separate user and as @oldfred said, it is only for maintenance. When you change a setting as root, your normal user can't see it and the other way arround.
– spacelander
Nov 29 at 17:00












Thanks for checking this. Both occasions the user is the same. From auth.log.
– Jeevaka
Nov 29 at 17:07






Thanks for checking this. Both occasions the user is the same. From auth.log.
– Jeevaka
Nov 29 at 17:07

















active

oldest

votes











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1097169%2fbooting-into-two-different-gnome-configurations-randomly-how-to-investigate%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown






























active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Ask Ubuntu!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1097169%2fbooting-into-two-different-gnome-configurations-randomly-how-to-investigate%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Quarter-circle Tiles

build a pushdown automaton that recognizes the reverse language of a given pushdown automaton?

Mont Emei