Last partition is not consistently grown even when target_image_size is set

[brianthedavis]

When running the packer-builder-arm out of a Docker container (Jan 25 release on MacOS, which shouldn't matter), the second image partition is inconsistently resized. My json file specifies the target_image_size properly and it seems like every 3rd or 4th build the image resizes. Otherwise, the Growing partition to 4096 M step is completely skipped (which results in running out of space in the image when I perform an apt-get dist-upgrade). I've included the output of two different attempted builds - both run with the exact same command.

Here's the builder snippet from my packer json file:

    "builders": [
      {
        "type": "arm-image",
        "iso_url": "/mnt/image/2020-02-13-raspbian-buster-lite.zip",
        "target_image_size": 4294967296,
        "iso_checksum_type": "sha256",
        "iso_checksum": "12ae6e17bf95b6ba83beca61e7394e7411b45eba7e6a520f434b0748ea7370e8"
      }
    ],

Here's the output when the partition doesn't get expanded:

==> arm-image: Copying source image.
==> arm-image: Image is a zip file.
==> arm-image: Unzipping 2020-02-13-raspbian-buster-lite.img
    arm-image: Speed:   47.23 MB/s
    arm-image: Progress: 38.30%
    arm-image: Speed:   36.32 MB/s
    arm-image: Progress: 67.76%
    arm-image: mapping output-arm-image/image
==> arm-image: kpartx -s -a -v output-arm-image/image

vs when the partition growing actually gets invoked:

==> arm-image: Copying source image.
==> arm-image: Image is a zip file.
==> arm-image: Unzipping 2020-02-13-raspbian-buster-lite.img
    arm-image: Speed:   48.89 MB/s
    arm-image: Progress: 39.66%
    arm-image: Speed:   39.17 MB/s
    arm-image: Progress: 71.41%
==> arm-image: Growing partition to 4096 M (4294967296 bytes)
    arm-image: mapping output-arm-image/image
==> arm-image: kpartx -s -a -v output-arm-image/image

[drluckyspin]

Just confirming, I am also seeing this problem on macOS. Does not happen when I run on Debian or Ubuntu.

[yuval-k]

i am using fedora and wasnt able to reproduce this as well.. any more info to help debug this is appreciated

[denravonska]

Edit: Moving this to a new issue

I'm trying this on a Debian image. It consistently claims to resize the image:

==> arm-image: Growing partition to 6144 M (6442450944 bytes)
    arm-image: mapping output-arm-image/image
==> arm-image: losetup --show -f -P output-arm-image/image
==> arm-image: partitions: [/dev/loop33p1 /dev/loop33p2 /dev/loop33p3]
==> arm-image: partitions: [/dev/loop33p1 /dev/loop33p2 /dev/loop33p3]
    arm-image: Mounting: /dev/loop33p3
    arm-image: Mounting: /dev/loop33p2
    arm-image: Mounting: /dev/loop33p1

But when I check df afterwards I get

/dev/loop33p3                    2,0G  1,4G  492M  74% /tmp/armimg-1998442362
/dev/loop33p2                    300M  4,0K  300M   1% /tmp/armimg-1998442362/boot/efi
/dev/loop33p1                     16M  3,0K   16M   1% /tmp/armimg-1998442362/config

2GB is what's in the original image.