lvm is not reproducible on master (be0aac691404b75fcae2a0dec831c48adff17ea2)

[tlaurion]

When testing master (be0aac6)

user@heads-clean:~/heads$ HASHES1=build/x86/qemu-coreboot-fbwhiptail-tpm2-hotp/hashes.txt 
user@heads-clean:~/heads$ wget -q https://output.circle-artifacts.com/output/job/e425a5ce-f12d-4776-9287-2dfeb22b4313/artifacts/0/build/x86/qemu-coreboot-fbwhiptail-tpm2-hotp/hashes.txt -O master
user@heads-clean:~/heads$ 
user@heads-clean:~/heads$ egrep '^[0-9a-f]{64}' $HASHES1 | while read line; do HASH_REF=$(echo $line|awk -F " " {'print $1'}); FILE_REF=$(echo $line|awk -F "/" {'print $NF'}); if ! grep -q "$HASH_REF" $HASHES2; then echo "$FILE_REF doesn't match";fi; done
tools.cpio doesn't match
config doesn't match
lvm doesn't match
initrd.cpio.xz doesn't match
heads-qemu-coreboot-fbwhiptail-tpm2-hotp-v0.2.0-2433-gee8d1d9.rom doesn't match

[tlaurion]

Cannot be right. Will investigate.

diffoscope of initrd.cpio.xz, both supposed to be be0aac6 for /etc/config

│ ├── etc/config
│ │ @@ -12,11 +12,11 @@
│ │  export CONFIG_ENABLE_FUNCTION_TRACING_OUTPUT="y"
│ │  export CONFIG_LINUX_USB_COMPANION_CONTROLLER="y"
│ │  export CONFIG_LINUX_VERSION="6.1.8"
│ │  export CONFIG_PRIMARY_KEY_TYPE="ecc"
│ │  export CONFIG_TPM="y"
│ │  export CONFIG_TPM2_CAPTURE_PCAP="y"
│ │  export CONFIG_TPM2_TOOLS="y"
│ │ -export GIT_HASH='be0aac691404b75fcae2a0dec831c48adff17ea2'
│ │ +export GIT_HASH='ee8d1d9ae84fb1b97f51f8aff8b48bad88d97588'
│ │  export GIT_STATUS=clean
│ │  export CONFIG_BOARD=qemu-coreboot-fbwhiptail-tpm2-hotp
│ │  export CONFIG_BRAND_NAME=Heads

For lvm, its more complicated.

[tlaurion]

docker -> lvm is configured differently if called from CircleCI, with detected run dir being either in /var/run locally vs /run over CircleCI.

Testing lvm2 configure fix build at tlaurion@1a07bf7

[tlaurion]

Not sure why only lvm2 suffered from this dynamic rundir chosen at configure step, #1858 fixes it.

For prosperity, diffoscope html dir generated with --html-dir repro
lvm2_repro_failed_rundir_before.tar.gz

Found by comparing config.log between logs from CI and local, but still can't say why. Other modules don't have this behavior.