Summary

On certain systems, the submodule wrongly reports some btrfs filesystems as unmounted although they are mounted. This is due to inconsistencies between the block device inferred by btrfs filesystem show (in my case, /dev/mapper/luks-<uuid>) and what is reported by findmnt (in my case, /dev/dm-X). Even if the entries in /dev/mapper are in the end symlinked to their corresponding /dev/dm-X entries.

This eventually leads to the following exception in get_matching_filesystem of class BtrfsFilesystemsProvider, which had to be made visible manually with print since it is normally supressed in BtrfsSubvolumeModule.run.

Found 0 filesystems matching criteria uuid=None label=None device=/dev/dm-X

...which in turn makes creating subvolumes using this module impossible, as BtrfsSubvolumeModule.__filesystem is still None and unusable for further operation.

Issue Type

Bug Report

Component Name

btrfs_subvolume

Ansible Version

$ ansible --version

Community.general Version

# /home/user/.ansible/collections/ansible_collections
Collection        Version
----------------- -------
community.general 12.1.0

Configuration

No response

OS / Environment

WSL Ubuntu 24.04

Steps to Reproduce

# The partition in question is LUKS-encrypted, but made available in cleartext using a device mapper
- name: Ensure btrfs subvolume for service directory is present
  become: true
  community.general.btrfs_subvolume:
    filesystem_device: "/dev/mapper/luks-{{ root_uuid }}"
    name: /srv/volume

Expected Results

That things just work :)

Actual Results

{"failed": true, "exception": {"event": {"msg": "'NoneType' object has no attribute 'get_subvolume_by_name'", "__ansible_type": "Event"}, "__ansible_type": "ErrorSummary"}}

The "NoneType" object here is the result of get_matching_filesystem not returning anything.

Code of Conduct

• I agree to follow the Ansible Code of Conduct