I have 2 issues with F37 (upgraded from F35), which I can’t seem to solve, and are getting in my way. One is that F37 (XFCE4) refuses to suspend or hibernate from the GUI because it can’t lock the screen. I get a somewhat cryptic message:
I’ve spent lots of time chasing down the usual suspects and suggestions from Google, etc. Everything looks to be in order. And it locks and suspends just fine from the command line. I can uncheck the box which says to lock the screen on suspend or hibernate, which allows it to successfully suspend and hibernate from the GUI. But I want it to lock the screen, so…
I’ve run the relevant programs from the CL, which doesn’t give anything useful when it fails.
$ xfconf-query -c xfce4-session -p /general/LockCommand gives:
xfce4-screensaver-command --lock
If I run ‘xfce4-screensaver-command --lock’ from the command line, it locks just fine, as expected.
The other problem is that the Online Accounts don’t work any more. All my accounts have exclamations next to them. If I click on one of the accounts that I previously set up, it shows:
Clicking Sign In just freezes the window. No SW should be written like this.
Opening the window from the CL, I get:
Can’t mkdir parents for /run/systemd/resolve/stub-resolv.conf: Read-only file system
Is it some SE linux permissions thing? Maybe behind both problems?
It seems Linux has become very fragile. I don’t say this lightly, as I’ve been using it almost exclusively since the mid-90s. Back in the day it was rock-solid, even when using the GUI. Nowadays, reboots and lockups are as frequent as with MS Windows. It’s really a bummer that robustness isn’t a priority in Linux any more, not, at least, with the Workstation versions… <rant off (for now)>
It is a simlink, please read the header of stub-resolv.conf
cat /run/systemd/resolve/stub-resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
It is not just Linux, 25 years back the Freezer, TV and a lot of other devices have not been connected to the internet. This made it necessary to protect Linux with additional software. And the growing demand makes also necessary that the kernel has to be adapted much faster. If It is to fast for you how Linux, in especial Fedora Linux grows, you might have to go with a LTS kernel.
Thanks! I can’t see how this has anything to do with my issue, however.
“Can’t mkdir parents for /run/systemd/resolve/stub-resolv.conf: Read-only file system” doesn’t sound like a DNS problem. It sounds like a can’t mkdir parents of a configuration file for DNS (stub-resolv.conf) problem, though I don’t know why it’s trying to do that when all I want to do is to be able to mount my damn G-drive under pcmanfm. So I have no idea what that error or warning actually means. I do know that it just freezes the screen, which is obviously a bug.
DNS seems to work just fine. I can go anywhere on the net and all systems are go. resolve.conf has:
nameserver 127.0.0.53
options edns0 trust-ad
search .
I guess if I were a good boy, I’d report it to the developers, and I may… I was just wondering if anyone on AskFedora had encountered that issue before.
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
When it is in the context with the change I mentioned, you don’t need to report. You just need to take a bit time to read about the changes and keep up with them.
But I do disagree with you about the bug. There are 2 problems, as I see it. One is whatever the problem is which makes the GOA helper process fail. The other is the response to the first problem. It simply isn’t acceptable to just freeze. I had to figure out what the process was and kill it from the CL, or I could use XKill, or something like that. The SW (GOA helper) needs to fail gracefully and give the user a useful message and a way to Cancel, or OK, or whatever. So there’s definitely a bug, either with /usr/libexec/gnome-control-center-goa-helper or with an underlying library (IMHO).
Check your boot-log with sudo sed $'s/\^\[/\E/g' /var/log/boot.log for erros and then look for them in journalctl when you find something please grep -B5 -A5 them from the journal. So we can see what happens short before and after.
You can also check the same way for the GOA helper process etc. We definitely need more information to investigate what really happens.
After much Googling, I found a workaround. Opening gnome-control-center with the environment variable WEBKIT_FORCE_SANDBOX=0 set allows the online account sign in to work. I’ve filed a bug report here:
