Tuesday, December 24, 2013

Win32 Disk Imager - when the image is too big (Raspberry Pi)

When attempting to use Win32 Disk Imager put a 4Gb image onto a different 4Gb memory card, I got this error


"Not enough space on disk: Size 7809024 sectors Available: 7744512 sectors Sector size: 512"

So basically the 4Gb cards have a slightly different size. What I have here is a workaround, and it's definitely not guaranteed to work, but it may be worth a try. Get yourself a Ubuntu computer (I just boot a laptop from a live CD) and run these commands (changing paths where appropriate):

1) Run dd to copy as much of the image as possible to the SD card - this takes quite a while to complete, depending on the write speed of your card. I think for me it took about 15 minutes, and it prints no status until it fails.

ubuntu@ubuntu:/$ sudo dd if=/media/ubuntu/62B85E4EB85E2139/Downloads/2013-09-02-deployed\(RC3\).img of=/dev/mmcblk0
dd: writing to `/dev/mmcblk0': No space left on device
7744513+0 records in
7744512+0 records out
3965190144 bytes (4.0 GB) copied, 1914.1 s, 2.1 MB/s

2) Run fsck to see what size your physical device is.

ubuntu@ubuntu:/$ sudo fsck.ext4 /dev/mmcblk0p2
e2fsck 1.42.5 (29-Jul-2012)
The filesystem size (according to the superblock) is 960768 blocks
The physical size of the device is 952704 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes

3) Run resize2fs to change the superblock size to match the physical size (you need to replace 952704 with whatever output you got from step 2)

ubuntu@ubuntu:/$ sudo resize2fs /dev/mmcblk0p2 952704
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/mmcblk0p2 to 952704 (4k) blocks.
The filesystem on /dev/mmcblk0p2 is now 952704 blocks long.

4) You're all set - run fsck again to see a good printout, and then pop your card into your pi and it *should* boot!

ubuntu@ubuntu:/$ sudo fsck.ext4 /dev/mmcblk0p2
e2fsck 1.42.5 (29-Jul-2012)
/dev/mmcblk0p2: clean, 78371/245760 files, 622522/952704 blocks



I understand that this works by truncating the filesystem, in the blind hope that the end of the filesystem has nothing written to it, and is therefore only empty space anyway. Like I said there is the possibility for this to go wrong, YMMV.

No comments: