Description of problem: since upgraded to F18 (almost 10 days ago), I just noticed that my regulatory domain no longer get get to GB - now it defaults to world. Version-Release number of selected component (if applicable): crda-1.1.2_2011.04.28-3.fc18.x86_64 How reproducible: Always. Steps to Reproduce: 1. Just boot up, watch dmesg 2. 3. Actual results: Only: [29839.573489] cfg80211: Calling CRDA to update world regulatory domain [29840.292326] cfg80211: World regulatory domain updated: ... Expected results: Should show: [32275.315375] cfg80211: Calling CRDA for country: GB [32277.522811] cfg80211: Regulatory domain changed to country: GB Additional info: first line of: /etc/wpa_supplicant/wpa_supplicant.conf COUNTRY=GB calling crda always fails: # COUNTRY=GB crda Failed to set regulatory domain: -22 but doing so via iw works: # iw reg set GB [32275.315375] cfg80211: Calling CRDA for country: GB After setting via iw, it fails with a different error: # COUNTRY=GB crda Failed to set regulatory domain: -114 BTW, the error message is very unhelpful... anyway, I started looking at this only because I have an kernel WARNING after suspend/resume, which is more serious and I'll file.
The last f17 kernel I booted, with mostly f17 bits, 3.6.10-2.fc17.x86_64, seems to set the regulatory domain correctly.
Which kernel version is it that is failing?
was 3.6.11-3.fc18.x86_64 . But regulatory domain does not appear to have get set since I upgraded to f18, which means all of these: 3.6.9-4.fc18.x86_64 3.6.10-5.fc18.x86_64 3.6.11-3.fc18.x86_64 (as well as the 3.6.10-2.fc17.x86_64 3.6.9-2.fc17.x86_64 which I tried to look at the suspend/resume problem).
I put the COUNTRY=XX in the /etc/sysconfig/network-scripts/ifcfg-Auto_SSID which is created by NetworkManager I guess. It works here on 3.6.10-4.fc18.x86_64.
(In reply to comment #4) > I put the COUNTRY=XX in the /etc/sysconfig/network-scripts/ifcfg-Auto_SSID > which is created by NetworkManager I guess. It works here on > 3.6.10-4.fc18.x86_64. None of my /etc/sysconfig/network-scripts/ifcfg-Auto_* have COUNTRY=... inside; AFAIK I only have in /etc/wpa_supplicant/wpa_supplicant.conf a COUNTRY=GB line, and I don't remember how it got there - it has been that way for years. Anyway, I see two issues: - COUNTRY=XX crda should work according to the documentation but it does not, - from the dozen /etc/sysconfig/network-scripts/ifcfg-Auto_* I have over the years - various hotels and other locations in UK, Belgium, US, France, China, Hong Kong, - I see that the regulatory domain should indeed be a per SSID setting, rather than a per device setting. So it seems that I have always had it set in the wrong place :-(. So it would appear that the F17 behavior was wrong, and F18 is correct to ignore per-device settings - it should be a per SSID setting. (I don't remember NetworkManager ever asked what country am in, when I try to get a hotel's etc SSID is, though!).
The ways this was designed to work in Fedora was for /sbin/setregdomain to be run by /usr/lib/udev/rules.d/85-regulatory.rules (i.e. by udev). I haven't got an F18 box here, so I apologize if I'm unaware of what might have changed. If you run /sbin/setregdomain, does that set the regulatory domain? Or does it produce any output? Do you have an /etc/sysconfig/clock or /etc/sysconfig/regdomain file? The idea of setregdomain is to use your timezone setting to deduce your regulatory domain, or to let you override that with the regdomain file. I know that systemd has changed lots of things, so maybe setregdomain needs to rely on something else for that info now...?
I don't know about any specific changes here. But /etc/sysconfig/clock is no longer used by the glibc rpm logic, the file should not exist on recent systems. It's not really related to systemd, in general the actual timezone should be determined by reading the /etc/localtime symlink, the data glibc actually uses on the system. It's more reliablethan making guesses about distribution specific and possibly outdated config files and data.
OK, it looks like you are talking about the same thing as in bug 858735. It looks like there should now be an /etc/timezone file with the info I was getting from /etc/sysconfig/clock...? I built a test crda package, with an updated setregdomain script: http://koji.fedoraproject.org/koji/taskinfo?taskID=4846315 Could someone give that a try and post the results here? Thanks!
There is no /etc/timezone file. It was considered for a while, but the idea dropped, as it is just another source of duplication and possible outdated and irrelevant data. Glibc reads only /etc/localtime, so today it is all encoded just in the target of the symlink of /etc/localtime. It always reflects what the system actually uses, not some "dead" data in distribution configuration. (On older systems /etc/localtime could be a copy of the zoneinfo file, and not a neccessarily a symlink, but we enforce the symlink format now)
OK, I was hoping to limit the ugliness of the hack that is setregdomain... :-) Please disregard the build from comment 8. Please test this one instead: http://koji.fedoraproject.org/koji/taskinfo?taskID=4846715 Note that I was too lazy to change the version between those scratch builds. So, please be sure that you are using the correct version when testing!
(In reply to comment #10) > OK, I was hoping to limit the ugliness of the hack that is setregdomain... > :-) > > Please disregard the build from comment 8. Please test this one instead: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4846715 > > Note that I was too lazy to change the version between those scratch builds. > So, please be sure that you are using the correct version when testing! setting by hand still does not work: (is it supposed to? the man page seems to imply it should - maybe the doc needs to be updated) # COUNTRY=GB crda Failed to set regulatory domain: -114 # COUNTRY=US crda Failed to set regulatory domain: -22 But just suspending/resuming now set the regulatory domain to GB for me, so that's an improvement; I suppose this would apply to reboot also.
(In reply to comment #6) <snipped> > If you run /sbin/setregdomain, does that set the regulatory domain? Or does > it produce any output? Do you have an /etc/sysconfig/clock or > /etc/sysconfig/regdomain file? <snipped> I have neither /etc/sysconfig/clock nor /etc/sysconfig/regdomain . /etc/localtime is sym-linked to ../usr/share/zoneinfo/Europe/London "/etc/timezone" does not exist either. /sbin/setregdomain would have worked (I haven't tried, since since suspend/resume to trigger the udev rule does it), from using /etc/localtime . It is just curious and confusing that "iw reg set XX" works on the command line but "COUNTRY=XX crda" does not.
I'm not sure what is left to be done here. It seems like if this were a general problem then there would be a lot more complaining? I'm going to close this for now...
Just noticed this problem coming back (possibly with upgrading to fc20 over Christmas?) # rpm -qf /sbin/setregdomain crda-1.1.3_2013.02.13-4.fc20.x86_64 # rpm -qf /usr/share/zoneinfo/zone.tab tzdata-2013i-2.fc20.noarch no /etc/sysconfig/regdomain, /etc/localtime symlink to London. # ls -l /etc/localtime lrwxrwxrwx. 1 root root 35 Dec 22 2012 /etc/localtime -> ../usr/share/zoneinfo/Europe/London # ls -l /etc/sysconfig/regdomain ls: cannot access /etc/sysconfig/regdomain: No such file or directory # /sbin/setregdomain Could not determine country! Unable to set regulatory domain. I don't have any logs beyond 4 weeks, but grep through says it has always been 'world regulatory domain' for at least a month.
There was a typo in setregdomain that may be causing this for you. Please update to crda-1.1.3_2013.11.27-3.fc20.x86_64 when it becomes available. Or, install it from Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=493391 Does that resolve the issue?
(In reply to John W. Linville from comment #15) > Does that resolve the issue? No. [root@localhost ~]# rpm -q crda crda-1.1.3_2013.11.27-3.fc20.x86_64 [root@localhost ~]# /sbin/setregdomain Could not determine country! Unable to set regulatory domain.
It's working here. Please add a 'set -x' line near the top of /sbin/setregdomain, run it again, and post the output here...thanks!
Created attachment 864763 [details] output of set -x /sbin/setregdomain Output of /sbin/setregdomain >& /tmp/1 after adding set -x near the top.
I've had similar reports from some users in bug 806221. I'm not sure what /etc/localtime is a relative path link on some systems but a direct path link on others.
The symlink is quite old, but not as old as the machine itself - it is the same machine since 2008 so had gone through a few upgrades. I don't think I created that by hand. # ls -ld /etc/localtime lrwxrwxrwx. 1 root root 35 Dec 22 2012 /etc/localtime -> ../usr/share/zoneinfo/Europe/London I just checked the date is a few weeks before fc18. I think I may have been impatient and upgraded to fc18 rcX when I upgraded from fc 17. (fc18 was delayed for rather longer than usual).
Hello, symlink is still created "relative" with f20 installer for sure, as I did not update it manually on a brand new fresh install. I reported this issue through https://bugzilla.redhat.com/show_bug.cgi?id=806221 along with another bug inside setregdomain. Since latest crda-1.1.3_2013.11.27-3.fc20 fix does not handle localtime with relative symlink, the bug is still there.
The Gnome3 Date & Time app seems to use the relative pathnames for the /etc/localtime symlink too. That seems really wierd to me, but whatever...
crda-1.1.3_2013.11.27-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/crda-1.1.3_2013.11.27-4.fc20
Package crda-1.1.3_2013.11.27-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing crda-1.1.3_2013.11.27-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-3303/crda-1.1.3_2013.11.27-4.fc20 then log in and leave karma (feedback).
(In reply to Fedora Update System from comment #24) > Please go to the following url: > https://admin.fedoraproject.org/updates/FEDORA-2014-3303/crda-1.1.3_2013.11. > 27-4.fc20 > then log in and leave karma (feedback). Works okay & left karma.
crda-1.1.3_2013.11.27-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
$ ls -l /etc/localtime lrwxrwxrwx 1 root root 35 Sep 25 15:24 /etc/localtime -> ../usr/share/zoneinfo/Europe/Berlin $ readlink /etc/localtime ../usr/share/zoneinfo/Europe/Berlin $ readlink -f /etc/localtime /usr/share/zoneinfo/Europe/Berlin You should really change /sbin/setregdomain to ZONE=$(readlink -f $LOCALTIME) or use ZONE=${ZONE#*/zoneinfo/}