Created attachment 1811729 [details] journalctl Description of problem: When Automatic Time Zone is enabled, both the Login window and logged in time is +2h from correct in the GUI. Occasionally timedatectl reports the correct timezone, but even when it's correct the GUI is wrong. I'm guessing time zone is not being set correctly early enough, or at all, and even when it is eventually set correctly gnome-shell isn't updating the information. Version-Release number of selected component (if applicable): gnome-settings-daemon-40.0.1-2.fc35.x86_64 geoclue2-2.5.7-4.fc35.x86_64 selinux-policy-34.14-2.fc35.noarch How reproducible: Always Steps to Reproduce: 1. Fedora-Workstation-Live-x86_64-Rawhide-20210806.n.0.iso plus updates 2. Settings -> Date & Time -> enable Automatic Time Zone 3. Actual results: The time is not updated to the correct time. Expected results: It should be updated to the correct time. Additional info: In most cases, timedatectl reports Time zone: America/New_York (EDT, -0400), which is incorrect. The time zone should be America/Denver (MDT, -0600). In one case, timedatectl reported America/Denver but the GUI still had the wrong time displayed (+2 hours).
Could be related: Aug 06 22:40:29 wpa_supplicant[1020]: wlp3s0: Trying to associate with f8:a0:97:6e:c7:e8 (SSID='altitude' freq=5745 MHz) Aug 06 22:40:29 NetworkManager[964]: <info> [1628304029.3794] device (wlp3s0): supplicant interface state: disconnected -> associating Aug 06 22:40:29 wpa_supplicant[1020]: wlp3s0: Associated with f8:a0:97:6e:c7:e8 ... Aug 06 22:40:32 gnome-shell[1123]: Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation Aug 06 22:41:31 geoclue[1182]: Service not used for 60 seconds. Shutting down.. ... Problem persists with enforcing=0
This was reliably working on Fedora 34 on this same hardware and network, so it seems to be a regression.
Proposed as a Blocker for 35-beta by Fedora user chrismurphy using the blocker tracking app because: "All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test." "system settings" is listed and it does seems like if we're going to offer Automatic Time Zone, it needs to work.
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
Discussed at 2021-08-30 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2021/fedora-blocker-review.2021-08-30-16.01.html . We punted on this as a Final blocker as there's some disagreement and desire to see if there are any more significant consequences of the bug, but we did decide to take it as a Beta freeze exception, as it definitely seems worth fixing for Beta if we can, it looks quite bad even if it's mostly 'cosmetic'.
Discussed at 2021-09-06 blocker/FE review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2021/fedora-blocker-review.2021-09-06-16.00.html . We punted again as no new information has been provided yet.
Currently traveling, and experiencing this now. Traveled from Denver to Palm Springs (Los Angeles time zone), and yet it still says timezone Denver even after being on wifi for hours. So it's a real problem and I have no idea how to diagnose.
Created attachment 1822225 [details] latest journal
I don't see anything else interesting in the logs. "gnome-shell[1123]: Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation" seems the most promising.
I tried to test this today. When I just boot a LiveCD, enable location services and enable automatic time zone, the displayed time (or reported by timedatectl) is not changed. I'm not sure if it is the same bug or just something relevant to the live environment. So I installed both F34 and latest F35 into VMs, to compare. My local timezone was detected correctly by anaconda as Europe/Prague, but I changed it to Australia/Sydney to test automatic timezone afterwards. In the installed system, both in F34 and F35, the behavior was the same. geoclue.service was running. The error "Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation" was present. After I enabled location services and automatic timezone, nothing happened, even after a reboot and 30+ minutes of waiting. So this seems broken both in F34 and F35. Note: Enabling location services in F35's initial-setup isn't applied, and it's disabled in the system. You need to enable it manually. I'll file a separate bug about it.
For the record, this was discussed at the 2021-09-13 meeting - https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2021-09-13/f35-blocker-review.2021-09-13-16.00.html - and accepted based on votes in the ticket - https://pagure.io/fedora-qa/blocker-review/issue/389 .
Hi David! Are you aware of/working on this? just checking in as it's an F35 Final blocker and we're coming up on the dates for that fairly soon. Please let us know if you need any help with it. Thanks!
(In reply to Adam Williamson from comment #12) > Hi David! Are you aware of/working on this? just checking in as it's an F35 > Final blocker and we're coming up on the dates for that fairly soon. Please > let us know if you need any help with it. Thanks! I am not personally working on it yet, but I saw a discussion go by yesterday that it might be related to gnome-shell not being an application, and not having geolocation permission (the error message is apparently from the permission store).
Do you remember where that discussion was, by any chance?
Internal IRC: Me: Does https://bugzilla.redhat.com/show_bug.cgi?id=1991075#c9 look familiar? Matthias: its an error message from the permission store, I believe Me: So... gnome-shell is not an application, therefore it does not have geolocation permission and its D-Bus call gets rejected? Matthias: thats ... a lot of guesses Me: Yes, a lot of guesses Nobody has investigated it yet, unfortunately.
So, hum, I'm not sure that's it. If you search around that error, you find it showing up commonly, in old and unrelated logs. For instance, it's here: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2478 and here: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3081 and here: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1933 I suspect that error message is due to the stuff discussed in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2647 and https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/805 (which, in fact, also mentions this error message). Which would mean either that this bug has been around for a while (Chris, do you see it on F34?), or that the 'geolocation' permission error isn't the cause of this bug.
To follow the trail a bit further, it looks like those upstream issues I referred to resulted in this MR for geoclue: https://gitlab.freedesktop.org/geoclue/geoclue/-/merge_requests/70 which was backported to Fedora: https://src.fedoraproject.org/rpms/geoclue2/c/593f978a595539e49f4407388d07c72e9ef0a798?branch=rawhide but then upstream merged some *different* changes intended to address the same thing: https://gitlab.freedesktop.org/geoclue/geoclue/-/commit/14d5e71ab16d9f5675d3c7d3f92a7766c8f1d06f https://gitlab.freedesktop.org/geoclue/geoclue/-/commit/12445fb134ee4fe288d02d73ea50c39355e3d42f (I think) and rejected #70. When we bumped to 2.5.7 downstream, with those upstream changes included, we dropped the backport of MR #70. It looks like F34 had geoclue 2.5.7, though, so even if somehow the change from the MR#70 backport to the upstream 'fixes' is the issue here, the bug should happen in F34 too..
so I tried this a few times myself, though I don't think my situation is quite the same as Chris' as my geolocated timezone is correct (Pacific time). To try and test, I installed the system, set the timezone to something wrong (like British time), then toggled auto timezone on. On both F34 and F35, for me, this doesn't "work" - my timezone is not reset to Pacific immediately, or after a reboot. However, I'm wondering if there might be an issue of 'working as intended' here. Is the timezone only supposed to change if the *geolocated position* changes? i.e. it won't change the setting from whatever it is, even if it seems 'wrong', if your computer doesn't move? The "Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation" error is present in the logs on both F34 and F35.
Fedora 35 Sep 28 20:52:26 fovo.local gnome-shell[1654]: Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation Fedora 34 Sep 28 20:49:24 fovo.local gnome-shell[1789]: Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation The way I revert to Fedora 34, I have read-only snapshots before every update, and abandoned F34 on Aug 30. I was in Denver then. So... btrfs sub snap root34.20210830 root34 And then reboot with a grub edit to kernel params, so that rootflags=subvol=root34, and within ~10 seconds of login, I see the time change from Mountain/Denver time to Eastern/New York. So the error message above doesn't seem related to the problem. What I do see with Fedora 34 that I don't see with Fedora 35: Sep 28 20:50:17 fovo.local systemd-timedated[2743]: Changed time zone to 'America/New_York' (EDT).
> i.e. it won't change the setting from whatever it is, even if it seems 'wrong', if your computer doesn't move? At least in my case, I'm really geographically moving.
ah, OK. I guess I'd need to find out how to lie to geoclue in order to test that.
I played with this a bit today and the thing that tripped me up immediately was that the IP geolocation seemed to be busted and only wifi based geolocation worked. I suspect this is what most people here are running into since this pretty much breaks the testing in VM's -- virtual machines usually have a virtual wired card and not a wifi card. This seems to be already fixed upstream. Let me go and backport the fix and then it would be nice if Chris and others affected could re-test it.
FEDORA-2021-532f05d2e3 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-532f05d2e3
FEDORA-2021-65eaf25c77 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-65eaf25c77
FEDORA-2021-532f05d2e3 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-532f05d2e3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-532f05d2e3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-65eaf25c77 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-65eaf25c77` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-65eaf25c77 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I'm only on baremetal laptop with wifi.
Installed geoclue2-2.5.7-6.fc35.x86_64.rpm, changed time zone to Denver (manually), rebooted, enabled automatic time zone - no change in time. I'm in Eastern Daylight TZ (New York). So it's still not working. Location Services is enabled, but it also says: No applications have asked for location access.
OK, hm. That's exactly how I tested it as well and it worked for me and updated the time zone in the test VM. I updated geoclue2-libs as well but I don't think that should play a role here. Can you do the following please to debug this: 1) Disable automatic time zone in Settings and switch to a wrong time zone manually. 2) on terminal, type: killall gsd-datetime /usr/libexec/gsd-datetime -v 3) enable automatic time zone in Settings 4) copy-paste the gsd-datetime output from terminal to me here
$ /usr/libexec/gsd-datetime -v (gsd-datetime:6452): GLib-DEBUG: 20:26:59.534: unsetenv() is not thread-safe and should not be used after threads are created (gsd-datetime:6452): datetime-plugin-DEBUG: 20:26:59.534: Starting datetime manager (gsd-datetime:6452): GLib-GIO-DEBUG: 20:26:59.535: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’ (gsd-datetime:6452): dconf-DEBUG: 20:26:59.535: watch_fast: "/org/gnome/desktop/datetime/" (establishing: 0, active: 0) (gsd-datetime:6452): datetime-plugin-DEBUG: 20:26:59.536: Automatic timezone disabled (gsd-datetime:6452): datetime-plugin-DEBUG: 20:26:59.536: Registered client at path /org/gnome/SessionManager/Client28 (gsd-datetime:6452): datetime-plugin-DEBUG: 20:26:59.538: bus_acquired_cb: acquired bus 0x564609723090 for name org.gnome.SettingsDaemon.Datetime (gsd-datetime:6452): dconf-DEBUG: 20:26:59.538: watch_established: "/org/gnome/desktop/datetime/" (establishing: 1) (gsd-datetime:6452): datetime-plugin-DEBUG: 20:26:59.538: name_acquired_cb: acquired name org.gnome.SettingsDaemon.Datetime on bus 0x564609723090 (gsd-datetime:6452): dconf-DEBUG: 20:27:39.782: change_notify: /org/gnome/desktop/datetime/automatic-timezone (gsd-datetime:6452): datetime-plugin-DEBUG: 20:27:39.782: Automatic timezone enabled (gsd-datetime:6452): datetime-plugin-DEBUG: 20:27:39.782: Starting timezone monitor (gsd-datetime:6452): dconf-DEBUG: 20:27:39.853: watch_fast: "/org/gnome/system/location/" (establishing: 0, active: 0) (gsd-datetime:6452): datetime-plugin-DEBUG: 20:27:39.853: Timezone monitor enabled, starting geoclue (gsd-datetime:6452): dconf-DEBUG: 20:27:39.854: watch_established: "/org/gnome/system/location/" (establishing: 1) ^C $ timedatectl Local time: Thu 2021-10-07 20:28:23 MDT Universal time: Fri 2021-10-08 02:28:23 UTC RTC time: Fri 2021-10-08 02:28:23 Time zone: America/Denver (MDT, -0600) System clock synchronized: yes NTP service: active RTC in local TZ: no
OK, gnome-settings-daemon datetime plugin nicely picks up the setting change done in gnome-control-center and asks geoclue for location, but geoclue doesn't seem to return anything. It doesn't look like geoclue is returning an error either (it would be printed out as a g_warning in that case). What do you get if you install geoclue2-demos and run /usr/libexec/geoclue-2.0/demos/where-am-i ?
I tried this twice. First time: $ /usr/libexec/geoclue-2.0/demos/where-am-i ** (where-am-i:16940): CRITICAL **: 08:06:17.050: Failed to connect to GeoClue2 service: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: 'geoclue-where-am-i' disallowed, no agent for UID 1000 Oops, I had geolocation permission disabled! I post it here anyway because that is a bug: misuse of g_critical(), which indicates programmer error in the application, not to be used for indicating a problem with a D-Bus call. Anyway, I tried again with geolocation enabled, and it just hung for 30 seconds then printed nothing at all: $ /usr/libexec/geoclue-2.0/demos/where-am-i Chris, is that what you are seeing too?
I am seeing exactly the same thing as in comment #30 and #32. This issue is still present.
>Chris, is that what you are seeing too? Yes.
Hm, 30 seconds sounds like a dbus timeout. We've had other issues this cycle with selinux blocking various dbus calls. Do you all have selinux enabled? It all works fine in my VM, but I'll test this and try to reproduce on real hardware on Monday.
I don't think it's selinux because I don't see any related warnings in my journal. All I see is this: Oct 09 11:53:42 chargestone-cave geoclue[9243]: Failed to create query: No WiFi devices available (I actually do have WiFi on this computer, but it's turned off.)
(In reply to Michael Catanzaro from comment #36) > I don't think it's selinux because I don't see any related warnings in my > journal. All I see is this: > > Oct 09 11:53:42 chargestone-cave geoclue[9243]: Failed to create query: No > WiFi devices available This one should be already fixed in https://bodhi.fedoraproject.org/updates/FEDORA-2021-532f05d2e3
(In reply to Kalev Lember from comment #37) > (In reply to Michael Catanzaro from comment #36) > > I don't think it's selinux because I don't see any related warnings in my > > journal. All I see is this: > > > > Oct 09 11:53:42 chargestone-cave geoclue[9243]: Failed to create query: No > > WiFi devices available > > This one should be already fixed in > https://bodhi.fedoraproject.org/updates/FEDORA-2021-532f05d2e3 Indeed. When I manually set my computer to wrong time zone, the computer was not able to detect the correct zone, when the automatic zone was then switched on. With this update, the zone updates accordingly, so I believe this is verified.
I'm not sure it's VERIFIED. I also see a timeout in /usr/libexec/geoclue-2.0/demos/where-am-i. The 30 seconds timeout is the default one configured in where-am-i, see it with --help. If I do `/usr/libexec/geoclue-2.0/demos/where-am-i -t 120`, then it waits 120 seconds, and prints nothing. However, I experimented with VMs, and it seems to be working there: F33 VM: geoclue2-2.5.6-3.fc33.x86_64 -> where-am-i works F34 VM: geoclue2-2.5.7-2.fc34.x86_64 -> where-am-i times out geoclue2-2.5.7-6.fc34.x86_64 -> where-am-i works F35 VM: geoclue2-2.5.7-5.fc35.x86_64 -> where-am-i times out geoclue2-2.5.7-6.fc35.x86_64 -> where-am-i works But on my F35 laptop, even with geoclue2-2.5.7-6.fc35.x86_64, where-am-i still times out.
I compared behavior in my F35 VM and on my laptop. VM: gnome-maps: shows a blue point with my current location, can center to it gnome-weather: in the location drop-down, there's "Automatic Location" toggle enabled Laptop: gnome-maps: there's no blue point with my current location, the "Go to current location" button in the menu bar is disabled gnome-weather: in the location drop-down, there's no "Automatic Location" toggle, it only says "Locating..." forever I also noticed perhaps just a gnome-shell glitch, or perhaps something related, which occurs on both machines: If you start an application using your current location, the location icon doesn't appear in the top bar's right corner (as it should, I believe). But once you start two such applications (maps + weather), and the close one of them, the location icon appears in the top bar. However, if you open the user menu in the top right, it says "Location Disabled". That is incorrect, because I have Location Services enabled in the control center. Once you close the second app, the location icon disappears.
I'm seeing Maps claim I'm 300km from my actual location; but automatic time zone is working in this moment. However, I'm not sure how consistently it's working. I haven't updated anything since the last comment, when it wasn't working.
(In reply to Kalev Lember from comment #37) > This one should be already fixed in > https://bodhi.fedoraproject.org/updates/FEDORA-2021-532f05d2e3 You're right. With that update applied, /usr/libexec/geoclue-2.0/demos/where-am-i tells me that I am within 25 km of Ottawa, Canada. That's not anywhere close to me, and it's the wrong timezone, but likely it's an unrelated bug. I've never had much luck with geoclue since it uses the wrong network interface for geoip and likes to report the location of VPN services rather than where I actually am, but Ottawa just seems completely random (my Wireguard server is hosted in New Jersey, not in Canada, and its IP address has not changed in several months), so I wouldn't consider the bogus results to be a release blocker. (In reply to Chris Murphy from comment #41) > I'm seeing Maps claim I'm 300km from my actual location; but automatic time > zone is working in this moment. However, I'm not sure how consistently it's > working. I haven't updated anything since the last comment, when it wasn't > working. Do you have the geoclue2-2.5.7-6.fc35 update installed? What does /usr/libexec/geoclue-2.0/demos/where-am-i say?
Chris did already say back in comment #28 that the update did not fix the problem for him at the time it came out.
OK and now it's not working again, and I see what kparal sees in Maps, the location icon on the far left is grayed out. I have geoclue2-2.5.7-6.fc35.x86_64, and /usr/libexec/geoclue-2.0/demos/where-am-i just hangs for 30s, then I get $ prompt with no other output.
On my laptop, T580: rpm -qa geoclue2 returns geoclue2-2.5.7-6.fc35.x86_64 /usr/libexec/geoclue-2.0/demos/where-am-i returns Client object: /org/freedesktop/GeoClue2/Client/3 New location: Latitude: 49.228136° Longitude: 16.579447° Accuracy: 160.467603 meters Speed: 99.161326 meters/second Heading: 307.540695° Timestamp: Thu 14 Oct 2021 08:59:31 AM CEST (1634194771 seconds since the Epoch) Maps show the current location and the button is not disabled. Weather allows Automatic location and this one is correctly found. /me shrugs
I also tested this with Live ISO 20211013 where the older (7-5) version is available and realized that, when I switched the Location abilities on, the Current location button in Maps remained greyed out and could not be used. However, when I updated geoclue2 using `dnf update geoclue2 --enablerepo updates-testing` and switched Location off and on again, the button went to black and could be used. The location pointed to Mokrá Horákov which is about 10 miles from the actual computer location. This happened on one of our desktop testing machines in the Brno office. Will see, what it does post-install.
And the version used in comment #46 was the latest 7-6 we have been discussing.
I feel like people are forgetting what we established earlier in the bug :) We already know the update fixes a problem with geoclue2, that's why it exists, but Chris reported it does not seem to fully resolve this problem. Even with the fixed geoclue2, automatic timezone adjustment is not working reliably for him.
Kamil also. But yeah I don't know what else to check why location services appears to not be working (usually).
OK, I figured out what is going on here. It's new NetworkManager 1.32 in F35 that broke glib's network connectivity detection code, which in turn broke geoclue. I've posted https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2296 upstream with the fix and going to kick off new glib2 builds in a bit.
FEDORA-2021-14f2ed62fd has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-14f2ed62fd
Note that I'd pull in the geoclue2 build (https://bodhi.fedoraproject.org/updates/FEDORA-2021-532f05d2e3) as well, in addition to the new glib2 build in order to fix the virtual machine without any wifi cards case.
Isn't that the same problem as https://bugzilla.redhat.com/show_bug.cgi?id=2013742 ?
yeah, it is...funny we wound up at that same bug from two different blocker/FE bugs :D
FEDORA-2021-14f2ed62fd has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-14f2ed62fd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-14f2ed62fd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-14f2ed62fd has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
Reopening because I think we should pull in the geoclue2 update as well: This fixes geolocation in VMs and for other computers that don't have wifi.
With geoclue2-2.5.7-6.fc35.x86_64 glib2-2.70.0-5.fc35.x86_64 the apps and where-am-i now works even on my laptop.
I also tested Automatic Time Zone in a VM. Configured Australia time zone, rebooted, and then toggled Auto Time Zone on in Settings. Almost immediately that adjusted to Prague timezone, which is correct. (This didn't work previously with the older geoclue2 build). So this is VERIFIED by me (not sure about Chris), but the geoclue2 update must get pushed stable as well.
Works for me now too, I gave karma to glib2
FEDORA-2021-532f05d2e3 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-65eaf25c77 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.