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

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

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.

mount error

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.


[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 <device>
    e2fsck -b 32768 <device>

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.

  • 1
    I ran into a similar issue with image push on first run failing but not on the second run it's fine. I noticed that if the partition you push the image too wasn't formatted bigger than the image partition size when it was created with the same format, that it needed done twice. I thought it was building parts of the partition on the first run so the image push failed and on the second run it seems everything is set on the partition it's being pushed too and works. Jul 25, 2016 at 2:48
  • I ended up formatting the whole disk to the file system format I needed (one large partition) and then pushed the image, you may need to create a partition though for sure larger than the partition the image was on when it was created and that may work too. Jul 25, 2016 at 2:49
  • I tried doing a sudo parted --script $(SDX) mkpart primary ext4 5G before running the flash. Ineffective. I'll play around with it more later if I have time; for now I guess I have to be content with flashing twice each time.
    – tsbertalan
    Jul 26, 2016 at 14:33
  • To image and card size match or is the card larger?
    – dronus
    Aug 17, 2016 at 21:19
  • 1
    Is your problem the same when you invoke commands by hand (without make)? Do you use GPT with the card? "if I properly eject the whole card reader and then reinsert it, one of the two partitions from the image fails to mount". Fails to mount in what way? Have you tried with another card reader? or another card? Have you tried reading back from the card and comparing to the original image (like by cmp)? If so, is the difference always at the same byte? Aug 29, 2016 at 10:29

1 Answer 1


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

The filesystem header is corrupt. Definitely open a bug with the maintainers of the auto-resize tool.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .