Score:2

Not able to get swap partition UUID after creating it with Parted ansible's module

cn flag

I have to create a new partition in a fresh disk on a VM. I use the parted module in order to create the partition. In a future task (in the same playbook), I need to use the UUID of the device partition (not the partition UUID, but the device UUID of the partition, present for example in /dev/disks/by-uuid/)

The problem is that : I don't find a way to get the UUID of the partition in a task after the parted module archieved the job. I'm sure that the parted module works fine because the partition exists after the run.

Let's take a look of what I tried :

Creating the partition with the parted module
Re-launch facts with the setup module (with and without filtering on ansible_devices) in order to use the ansible_devices.sdX.partitions.sdXY.uuid --> return void
Use the blkid -s UUID -o value /dev/sdXY throught the shell module --> return void
Use the ls -l /dev/disk/by-uuid/ | grep sdXY | awk '{print $9}' throught the shell module --> still return void

The terrible fact is that : if I launch the same task (like 2, 3 or 4) in another playbook, I'm able to get results. But in the same playbook of the parted module : I can't.

Here's my full playbook :

---
- hosts: all
  become: yes
  gather_facts: "yes"
  tasks:

   - name: Check actual swap quantity
     debug:
       var: ansible_swaptotal_mb
     failed_when: ansible_swaptotal_mb > 1999


   - name: Add a 2Gb disk
     shell: pwsh ./add_disk_vm.ps1 -vm {{ ansible_hostname }} -diskspace 2
     delegate_to: localhost


   - name: Scan for new disks
     shell: for i in $(ls /sys/class/scsi_host/); do echo "- - -" > /sys/class/scsi_host/$i/scan ; done

   - name: Get letter of the new disk
     shell: 'dmesg | grep "sd\w.*2.00 GiB)$" | grep -o "sd\w" | tail -1'
     register: diskletter


   - name: Create new partition
     community.general.parted:
       device: /dev/{{ diskletter.stdout }}
       fs_type: linux-swap
       label: gpt
       name: swap
       number: 1
       state: present
     register: parted


   #here the task who should work, but returning nothing
   - name: Get UUID
     shell: blkid -s UUID -o value /dev/{{ diskletter.stdout }}1
     register: uuidinfo

I don't mentionned it before, but the last task works fine on an other playbook OR even directly in SSH on the VM. The command doesn't return anything only during the playbook execution context.

Here's some other informations about my setup:

ansible-playbook 2.9.27 python version = 2.7.17 Ubuntu 18.04 (where ansible is installed AND the target server) community.general collection (version 3.7.0)

If someone have any ideas about this ; thanks for all !

Score:1
ca flag

As far as I understand the scenario and know from own experience, the behavior seems to be intended. The OS must be "forced" to re-read the partition table once changes have been done and before one will be able to get the new device information.

Further links

cn flag
Hi, thanks for answer ; I tried to use partprobe or partx in order to reload the disk info, but without success : the UUID is still unvailable. I'll use 2 playbooks execution instead of only one
Score:0
cn flag

Ok finally I found the solution.

The problem is that when the partition is not mounted, it have no UUID. When working with data partitions like xfs, extX, etc... The partition is directly mounted by the system, so the partition is getting direclty an UUID.

It's not the case for a swap partition, you must first enable it with mkswap for the system can mount the Swap partition.

That's why I was able to get the UUID value in a second playbook execution : I reached the UUID value before enabling the swap in the playbook. So the partition wasn't mount and haven't UUID.

If it can help someone

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.