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:
- The configuration I have been using (e.g. with applications locked to launcher, startup applications, favorites in Files etc.) OR
- 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
add a comment |
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:
- The configuration I have been using (e.g. with applications locked to launcher, startup applications, favorites in Files etc.) OR
- 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
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
add a comment |
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:
- The configuration I have been using (e.g. with applications locked to launcher, startup applications, favorites in Files etc.) OR
- 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
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:
- The configuration I have been using (e.g. with applications locked to launcher, startup applications, favorites in Files etc.) OR
- 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
boot gnome 18.04
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
add a comment |
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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