linux - dd always fails to write one partition on first try; succeeds on second

For a robotics project, I've assembled a make target that uses dd (actually dcfldd) to write a Raspbian Jessie image to SD card. This way, I can be assured that my environment is reproducible from scratch any time I want it.

The make target is just

flash:
    sudo dcfldd bs=4M if=$(IMGPATH) of=$(SDX)
    sync

where $(SDX) is /dev/sdc, and is meant to be preceded by a script which mounts the image at /mnt/img, makes some modifications, calls sync, and than unmounts it.

The process seems to be working fine, except that I always need to call the make target twice--the first time, if I properly eject the whole card reader and then reinsert it, one of the two partitions from the image fails to mount, and, if I try to boot the Raspberry Pi from it, I get a kernel panic.

After trying the flash the card (with the Make target or manually in the terminal), ejecting with Ubuntu's "Eject parent drive" launcher context menu option, removing and re-inserting the reader, the boot partition opens in Nautilus, but I get the following dialog, and no main partition.

The last hundred or so lines of dmesg are here. Probably the relevant ones are

[100640.545190] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

and

[101082.691558] EXT4-fs (sdb2): bad geometry: block count 3894272 exceeds size of device (964096 blocks)

As the first suggests, I do sudo fsck /dev/sdb, and get the following.

fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
fsck.ext2: No medium found while trying to open /dev/sdb

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 
or
    e2fsck -b 32768 

If I do

sudo dcfldd bs=4M if=/dev/sdb of=/tmp/from-sd-card.img count=1024
cmp /tmp/from-sd-card.img /home/tsbertalan/workspace/gunnar/2016-05-27-raspbian-jessie.img

I get

/tmp/from-sd-card.img /home/tsbertalan/workspace/gunnar/2016-05-27-raspbian-jessie.img differ: char 4194342, line 1

and if I do

cmp -b --verbose /tmp/from-sd-card.img /home/tsbertalan/workspace/gunnar/2016-05-27-raspbian-jessie.img

I get

4194342   1 ^A     0 ^@
70255618  72 :    257 M-/
70255619  35 ^]     3 ^C
70255622 375 M-}  266 M-6
70255623 166 v     16 ^N
70255625  34 ^\   114 L
70255626 345 M-e  274 M-<
70255627   4 ^D     0 ^@
70255629  77 ?     14 ^L
70255630 371 M-y  176 ~
70255631 144 d      1 ^A
70255633 326 M-V  200 M-^@
70255634 256 M-.  252 M-*
70255635  32 ^Z     1 ^A
70255661 373 M-{  114 L
70255662 123 S    124 T
70255665 105 E    120 P
70255666 132 Z    124 T
70255669  24 ^T     2 ^B
70255754   0 ^@   155 m
70255823 352 M-j  353 M-k
70255993 125 U    201 M-^A
70255994 323 M-S  343 M-c
70255995 257 M-/   71 9
1815085083  72 :      0 ^@
1815085084 103 C    132 Z

That 4194342 does seem to be consitent.

I am only able to reproduce the problem if I insert a properly flashed card into the RPI, boot it and then shut it down. After this, it takes two attempts to flash the card properly. I now strongly suspect that the auto-resize which Raspbian performs on first boot might be part of this problem. If this question would be a better fit for the Raspberry Pi stackexchange site, it could be moved there.

What's going on here? Is there some other way I should be writing this image so that it works on the first try? I don't want to be burning my limited SD card write cycles needlessly.

I only have one card reader to test this with, but I've tried with both a 16GB Samsung EVO micro SDHC, a 8GB SanDisk Ultra micro SDHC, and a 32GB SanDisk Ultra micro SDHC, with the same results on all.