Unable to Use azure-chroot to Build VM-Templates with LVM-Enabled Boot-Disks

[ferricoxide]

Posted a usage-help message on the community forums in case this isn't a technical gap. Also didn't know whether to file this as a bug or a feature request, so I chose "bug". At any rate…

Overview of the Issue

Does not seem to be a way to use the azure-chroot builder to generate VM-templates with LVM-encapsulated boot-parittions.

Attempts to use the azure-chroot builder to create VM-templates with LVM-encapsulated boot-parittions fail when the Mounting the root device... build-phase is reached. The builder only seems to support standard disk-partitions (e.g., /dev/sdc1) with no ability to either specify an device-mapper (LVM) path that hosts the / filesystem. All attempts to work around (e.g., using mount_partition overrides with or without using chroot_mounts) result in failures like:

==> azure-chroot.minimal-rhel-9-image: Pausing after run of step 'StepPreMountCommands'. Press enter to continue.
==> azure-chroot.minimal-rhel-9-image: Mounting the root device...
==> azure-chroot.minimal-rhel-9-image: error mounting root volume: exit status 32
==> azure-chroot.minimal-rhel-9-image: Stderr: mount: /mnt/packer-azure-chroot-disks/sdc: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error.
==> azure-chroot.minimal-rhel-9-image:
==> azure-chroot.minimal-rhel-9-image: error mounting root volume: exit status 32
==> azure-chroot.minimal-rhel-9-image: Stderr: mount: /mnt/packer-azure-chroot-disks/sdc: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error.
==> azure-chroot.minimal-rhel-9-image:
==> azure-chroot.minimal-rhel-9-image: Step "StepMountDevice" failed
==> azure-chroot.minimal-rhel-9-image: [c] Clean up and exit, [a] abort without cleanup, or [r] retry step (build may fail even if retry succeeds)?

Reproduction Steps

1. Launch a RHEL 9 VM in Azure
2. Install Packer and supporting tools
3. Create a packer HCL file with azure-chroot build-definitions
4. Execute packer
5. Let run until it fails at the "mounting root volume" phase (see error-snippet above)

Plugin and Packer version

Packer and its plugins are distinct binaries.

The Packer version can be found in the packer CLI using the version command packer version.

# /usr/bin/packer version
Packer v1.13.1

Installed plugins can be found by running packer plugins installed.

# /usr/bin/packer plugins installed
/root/.config/packer/plugins/github.com/hashicorp/amazon/packer-plugin-amazon_v1.3.9_x5.0_linux_amd64
/root/.config/packer/plugins/github.com/hashicorp/azure/packer-plugin-azure_v2.3.3_x5.0_linux_amd64
/root/.config/packer/plugins/github.com/hashicorp/openstack/packer-plugin-openstack_v1.1.2_x5.0_linux_amd64
/root/.config/packer/plugins/github.com/hashicorp/vagrant/packer-plugin-vagrant_v1.1.5_x5.0_linux_amd64
/root/.config/packer/plugins/github.com/hashicorp/virtualbox/packer-plugin-virtualbox_v1.1.2_x5.0_linux_amd64

Packer will use the latest version of an installed plugin unless a different version is specified in the required_plugins block. Refer to [Specifying Plugin Requirements] (https://developer.hashicorp.com/packer/docs/templates/hcl_templates/blocks/packer#specifying-plugin-requirements) for more details.

You can also find the version of the plugin using the plugin binary itself.
Find the path to the plugin in the output of a build by setting the environment variable PACKER_LOG=1.

Then invoke that binary with the describe command, for example

$ PACKER_LOG=1 packer build template.pkr.hcl
[...]
/home/elbaj/.packer.d/plugins/github.com/hashicorp/docker/packer-plugin-docker_v1.0.11-dev_x5.0_linux_amd64: plugin process exited

From this, I have the path to the plugin executed for the build. I can then execute that binary with the describe command to find the version of the plugin.

$ /home/elbaj/.packer.d/plugins/github.com/hashicorp/docker/packer-plugin-docker_v1.0.11-dev_x5.0_linux_amd64 describe
{"version":"1.0.11-dev","sdk_version":"0.5.4-dev","api_version":"x5.0","builders":["-packer-default-plugin-name-"],"post_processors":["import","push","save","tag"],"provisioners":[],"datasources":[],"protocol_version":"v2"}

Calling describe on a plugin binary provides the most accurate version information, as plugin binaries can be easily be renamed for testing purposes.

Issues posted without these versions often slows down responses, and may require more upfront work from maintainers to identify the cause of the issue.

Simplified Packer Buildfile

Please include a simplified build file that reproduces this error, try and remove extranaeous information from the template.

source "azure-chroot" "base" {
  client_id                              = var.azure_client_id
  client_secret                          = var.azure_client_secret
  cloud_environment_name                 = var.azure_cloud_environment_name
  os_disk_size_gb                        = 64
  image_resource_id = "/subscriptions/<ACCT_ID>/resourceGroups/<RES_GRP_ID>/providers/Microsoft.Compute/images/test-{{timestamp}}"

  from_scratch                           = true
  pre_mount_commands                     = [
    "CHROOTDEV={{.Device}} VGNAME=ROOTVG bash -x scripts/disk-setup_azure.sh",
  ]
  mount_partition                        = ""
  chroot_mounts                          = [
    ["xfs", "/dev/mapper/${var.root_vg_name}/rootVol", "/"],
  ]
  subscription_id                        = var.azure_subscription_id
  use_azure_cli_auth                     = true
}

If the file is longer than a few dozen lines, please include the URL to the
gist of the log or use the Github detailed
format
instead of posting it directly in the issue.

Testing config-file is longer, but it has not been pushed to a repository, yet, and the repository it lives in is private.

Operating system and Environment details

OS, Architecture, and any other information you can provide about the environment.

# cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.6 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.6"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.6 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
BUG_REPORT_URL="https://issues.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_BUGZILLA_PRODUCT_VERSION=9.6
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.6"

Log Fragments and crash.log files

Include appropriate log fragments. If the log is longer than a few dozen lines,
please include the URL to the gist of the log or
use the Github detailed format instead of posting it directly in the issue.

Set the env var PACKER_LOG=1 for maximum log detail.

Log-fragment included in "Overview" section.

[ferricoxide]

Bump?

---

@JenGoldstrich/@lzandman:

Noticed you two had the most-recent commits to this builder, so figured I'd tag you in since this project doesn't seem to be configured for monitoring by any kind of triage-bots

[lzandman]

Bump?

---

@JenGoldstrich/@lzandman:

Noticed you two had the most-recent commits to this builder

I just contributed some code. Otherwise not involved with the project. @JenGoldstrich might be able to help.

[ferricoxide]

@lzandman said:

@JenGoldstrich/@lzandman:
Noticed you two had the most-recent commits to this builder

I just contributed some code. Otherwise not involved with the project. @JenGoldstrich might be able to help.

Ah. Thank you. Like I say, just reaching out based on recent commit-history. Didn't see any @hashicorp or @microsoft.com contributor email addresses that were recent enough that I had confidence they would still be involved (given all the layoffs and other generic-turnover at both companies).