-
Notifications
You must be signed in to change notification settings - Fork 24k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ansible_distribution for Arch changed in ansible 2.4 #30600
Comments
What do the other distribution facts end up as? ansible_distribution (Or a copy of the entire system facts output from 'ansible $THAT_ARCH_HOST -m set' would also be useful). |
Same problem here: ansible 2.4.0.0 "ansible_distribution": "Arch Linux", |
@ykuksenko If you are running ansible from a source checkout, could you also run 'ansible/hacking/tests/gen_distribution_version_testcase.py' on the arch box and include the output? |
@shakeme What are the contents of '/etc/os-release' ? |
and/or /etc/arch-release? |
Content of /etc/os-release is: NAME="Arch Linux" |
/etc/arch-release is empty. |
Contents of /etc/os-release and the requested variables is the same for me as @shakeme. This one is the same in checkout and 2.3.2.0: /tmp/ansible/hacking/tests/gen_distribution_version_testcase.py:
|
full dump of facts:
|
Wondering if this is dependent on which order the distribution file based code runs, since it seems to be falling back to using /etc/os-release (where 'Arch Linux' comes from) instead of choosing 'ArchLinux' because it found a (possibly empty) /etc/arch-release. If the os-release runs first and finds something, it wouldn't continue, but need to dig into why/if it could be a different order. |
arch-release is probably only populated on older Arch machines, we should support both but os-release will be the one most often populated. |
@ykuksenko Thanks for the test data. Running that test data the chosen name ends up being 'Arch Linux'. |
Nope, not that. missing case for breaking on a match with allow_empty, working on pr |
Need to add a special case for Arch with no arch-release but with a os-release. Current code will fallback to os-release in that case, but the name in os-release is 'ArchLinux' vs 'Archlinux' that a hit on /etc/arch-release triggers. |
@shakeme @ykuksenko pr #30723 has a proposed fix for this if y'all want to test it out. |
@alikins It's working but some of the variable from above are vanished. I don't need them, just for information. Thank you. $ ansible -m setup localhost | grep -E "_os|_distrib" $ ansible --version |
Not sure if you want me to confirm or not. I got the same results as @shakeme
ansible --version
|
Same issue here. The space added between "Arch" and "Linux" breaks lots of modules.
The content of /etc/os-release:
The Ansible version (installed from the Arch Linux repositories):
|
As far as I know, this is expected for Arch. If there is a good way to get useful info there, a pr to add it would be great. |
* Fix 'distribution' fact for ArchLinux Allow empty wasn't breaking out of the process_dist_files loop, so a empty /etc/arch-release would continue searching and eventually try /etc/os-release. The os-release parsing works, but the distro name there is 'Arch Linux' which does not match the 2.3 behavior of 'Archlinux' Add a OS_RELEASE_ALIAS map for the cases where we need to get the distro name from os-release but use an alias. We can't include 'Archlinux' in SEARCH_STRING because a name match on its keys but without a match on the content causes a fallback to using the first whitespace seperated item from the file content as the name. For os-release, that is in form 'NAME=Arch Linux' With os-release returning the right name, this also supports the case where there is no /etc/arch-release, but there is a /etc/os-release Fixes #30600 * pep8 and comment cleanup
Allow empty wasn't breaking out of the process_dist_files loop, so a empty /etc/arch-release would continue searching and eventually try /etc/os-release. The os-release parsing works, but the distro name there is 'Arch Linux' which does not match the 2.3 behavior of 'Archlinux' Add a OS_RELEASE_ALIAS map for the cases where we need to get the distro name from os-release but use an alias. We can't include 'Archlinux' in SEARCH_STRING because a name match on its keys but without a match on the content causes a fallback to using the first whitespace seperated item from the file content as the name. For os-release, that is in form 'NAME=Arch Linux' With os-release returning the right name, this also supports the case where there is no /etc/arch-release, but there is a /etc/os-release Fixes #30600 * pep8 and comment cleanup (cherry picked from commit 3eab636)
Fixed in stable-2.4 in 2149d10 |
* Fix 'distribution' fact for ArchLinux Allow empty wasn't breaking out of the process_dist_files loop, so a empty /etc/arch-release would continue searching and eventually try /etc/os-release. The os-release parsing works, but the distro name there is 'Arch Linux' which does not match the 2.3 behavior of 'Archlinux' Add a OS_RELEASE_ALIAS map for the cases where we need to get the distro name from os-release but use an alias. We can't include 'Archlinux' in SEARCH_STRING because a name match on its keys but without a match on the content causes a fallback to using the first whitespace seperated item from the file content as the name. For os-release, that is in form 'NAME=Arch Linux' With os-release returning the right name, this also supports the case where there is no /etc/arch-release, but there is a /etc/os-release Fixes ansible#30600 * pep8 and comment cleanup
'distribution' facts were being set after checking the existence of the dist file, and then being set again with more detail after they were succesfully parsed. But if the dist file was not succesfully parsed and matched the required names, the loop continues without resetting the earlier set facts. This is how 'Mandriva' would end up being the 'distribution' file for unrelated cases (it would find /etc/lsb-release, set distro to 'Mandriva', then fail to parse/match and continue the loop. If no other checks worked, 'Mandriva' would stick). * parse_dist_file_NA should check 'name' not distro for NA parse_distribution_file_NA was checking the incoming 'distribution' fact to be 'NA', but the fact itself can be specific at that point ('KDE Neon', for ex) but the check is really if the 'name' it was passed is NA. * for matches on OS_RELEASE_ALIAS (ie, 'Archlinux') do not continue if the dist file content doesn't match. Previously it had to because of the 'Mandriva' bug mentioned above. This is a more general fix for #30693 than #30723 Fixes #30693 Related to #30600
* Fix 'distribution' fact for ArchLinux Allow empty wasn't breaking out of the process_dist_files loop, so a empty /etc/arch-release would continue searching and eventually try /etc/os-release. The os-release parsing works, but the distro name there is 'Arch Linux' which does not match the 2.3 behavior of 'Archlinux' Add a OS_RELEASE_ALIAS map for the cases where we need to get the distro name from os-release but use an alias. We can't include 'Archlinux' in SEARCH_STRING because a name match on its keys but without a match on the content causes a fallback to using the first whitespace seperated item from the file content as the name. For os-release, that is in form 'NAME=Arch Linux' With os-release returning the right name, this also supports the case where there is no /etc/arch-release, but there is a /etc/os-release Fixes ansible#30600 * pep8 and comment cleanup
'distribution' facts were being set after checking the existence of the dist file, and then being set again with more detail after they were succesfully parsed. But if the dist file was not succesfully parsed and matched the required names, the loop continues without resetting the earlier set facts. This is how 'Mandriva' would end up being the 'distribution' file for unrelated cases (it would find /etc/lsb-release, set distro to 'Mandriva', then fail to parse/match and continue the loop. If no other checks worked, 'Mandriva' would stick). * parse_dist_file_NA should check 'name' not distro for NA parse_distribution_file_NA was checking the incoming 'distribution' fact to be 'NA', but the fact itself can be specific at that point ('KDE Neon', for ex) but the check is really if the 'name' it was passed is NA. * for matches on OS_RELEASE_ALIAS (ie, 'Archlinux') do not continue if the dist file content doesn't match. Previously it had to because of the 'Mandriva' bug mentioned above. This is a more general fix for ansible#30693 than ansible#30723 Fixes ansible#30693 Related to ansible#30600
In the meantime, |
I'm still seeing this bug in 2.6.2 |
ISSUE TYPE
COMPONENT NAME
Facts
ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
On Arch controling Arch
SUMMARY
As of Ansible 2.4 (I believe commit 45a9f96) the
ansible_distribution and ansible_os_family facts changed for Arch Linux breaking multiple modules.
STEPS TO REPRODUCE
EXPECTED RESULTS
ACTUAL RESULTS
There is now a space and a capital L in the distribution name for Archlinux.
The text was updated successfully, but these errors were encountered: