I installed WSL (Ubuntu 22.04) and Ansible via PIP (2.17.9) and no jobs will run

Get Help
1

When running the test.yml from the install documentation, I am expecting “Ansible Works” but I get the following message

msg: No fact modules available and we could not find a fact module for your network OS (None), try setting one via the `FACTS_MODULES` configuration.

No other jobs work as well. The CPU is a snapdragon and I have an identical machine using the same configuration with the same install process and it works fine. Any Ideas? Google has failed me.

2

Looks like you have some connection configured other than ssh, so that you should have a network os. Can you post the playbook you’re trying to run, as well as your Ansible configuration?

$ ansible-config dump

3

playbook

  • hosts: localhost
    tasks:
    • debug: msg=“Ansible works!”
      …

Dump:
ACTION_WARNINGS(default) = True
AGNOSTIC_BECOME_PROMPT(default) = True
ALLOW_WORLD_READABLE_TMPFILES(default) = False
ANSIBLE_CONNECTION_PATH(default) = None
ANSIBLE_COW_PATH(default) = None
ANSIBLE_COW_SELECTION(default) = default
ANSIBLE_COW_WHITELIST(default) = [‘bud-frogs’, ‘bunny’, ‘cheese’, ‘daemon’, ‘default’, ‘dragon’, ‘elephant-in-snake’, ‘elephant’, ‘eyes’, ‘hellokitty’, ‘kitty’, ‘luke-koala’, ‘meow’, ‘milk’, ‘moofa>
ANSIBLE_FORCE_COLOR(default) = False
ANSIBLE_NOCOLOR(default) = False
ANSIBLE_NOCOWS(default) = False
ANSIBLE_PIPELINING(default) = False
ANSIBLE_SSH_ARGS(default) = -C -o ControlMaster=auto -o ControlPersist=60s
ANSIBLE_SSH_CONTROL_PATH(default) = None
ANSIBLE_SSH_CONTROL_PATH_DIR(default) = ~/.ansible/cp
ANSIBLE_SSH_EXECUTABLE(default) = ssh
ANSIBLE_SSH_RETRIES(default) = 0
ANY_ERRORS_FATAL(default) = False
BECOME_ALLOW_SAME_USER(default) = False
BECOME_PLUGIN_PATH(default) = [’/home/devops/.ansible/plugins/become’, ‘/usr/share/ansible/plugins/become’]
CACHE_PLUGIN(default) = memory
CACHE_PLUGIN_CONNECTION(default) = None
CACHE_PLUGIN_PREFIX(default) = ansible_facts
CACHE_PLUGIN_TIMEOUT(default) = 86400
COLLECTIONS_PATHS(default) = [‘/home/devops/.ansible/collections’, ‘/usr/share/ansible/collections’]
COLOR_CHANGED(default) = yellow
COLOR_CONSOLE_PROMPT(default) = white
COLOR_DEBUG(default) = dark gray
COLOR_DEPRECATE(default) = purple
COLOR_DIFF_ADD(default) = green
COLOR_DIFF_LINES(default) = cyan
COLOR_DIFF_REMOVE(default) = red
COLOR_ERROR(default) = red
COLOR_HIGHLIGHT(default) = white
COLOR_OK(default) = green
COLOR_SKIP(default) = cyan
COLOR_UNREACHABLE(default) = bright red
COLOR_VERBOSE(default) = blue
COLOR_WARN(default) = bright purple
COMMAND_WARNINGS(default) = True
CONDITIONAL_BARE_VARS(default) = True
CONNECTION_FACTS_MODULES(default) = {‘eos’: ‘eos_facts’, ‘frr’: ‘frr_facts’, ‘ios’: ‘ios_facts’, ‘iosxr’: ‘iosxr_facts’, ‘junos’: ‘junos_facts’, ‘nxos’: ‘nxos_facts’, ‘vyos’: ‘vyos_facts’}
COVERAGE_REMOTE_OUTPUT(default) = None
COVERAGE_REMOTE_WHITELIST(default) = *
DEFAULT_ACTION_PLUGIN_PATH(default) = [‘/home/devops/.ansible/plugins/action’, ‘/usr/share/ansible/plugins/action’]
DEFAULT_ALLOW_UNSAFE_LOOKUPS(default) = False
DEFAULT_ASK_PASS(default) = False
DEFAULT_ASK_VAULT_PASS(default) = False
DEFAULT_BECOME(default) = False
DEFAULT_BECOME_ASK_PASS(default) = False

4

Hi @dpflick,

I generally tell Ansible that the connection is local when using localhost. Example:

- hosts: localhost
  connection: local
  tasks:
    - name: Ansible test
      debug:
        msg: "Ansible Works!"

Best regards,

Joe

5

I get the same error even with connection local and none of my other playbooks run. They all get the same error whether using local connections, ssh or httapi

6

Interesting, for kicks, try turning fact gathering off:

- hosts: localhost
  connection: local
  gather_facts: false
  tasks:
    - name: Ansible test
      debug:
        msg: "Ansible Works!"

Best regards,

Joe

7

Works with fact gathering off for the test but all other jobs are still failing.

I have an IDENTICAL machine where it works with fact gathering so something is off. I just can’t figure out what. I think I am going to try the APT install instead of PIP and see if there are any changes.

8

Sounds good, curious on what the issue is. I’m running WSL 2 with Ubuntu 22.04, Ansible 2.17.2 and python 3.10.12. Had to go back in my history and it looks like I used the APT method of installing it.

Best regards,

Joe

9

Using connection: local is almost always wrong, it won’t break normally but people make incorrect assumptions on how it works and/or interacts with localhost.

10

@bcoca do you happen to have a link to a doc that explains the “connection: local” functionality? We’ve been using it for a while now but that sounds like more of our ignorance/luck then it being correct. I don’t want to hijack dpflick’s thread so I can start a new one if needed. Thanks!

Best regards,

Joe

11

connection: local was mostly used in very old version of Ansible for networking modules, since they didn’t really execute on the target and it didn’t matter much that being ‘slightly incorrect’ they would still work as you would not manipulate the ‘python interpreter’ for those targets. This becomes a problem in heterogeneous contexts in which you are targeting execution with normal modules, which do take the interpreter into account.

1 Like
12

FIXED
Soooo, for my ARM64 issue, it was not architecture at all! 2 issues total. Issue 1, 2.17.9 is broken with get facts. Known issue and rolled back to 2.17.7. Second issue of all things was an errant /t in the group_vars\all.yml. It has been there for years but Ansible >2.17.7 blows up spectacularly.

1 Like