The script tries to be smart in two ways: it has you insert an SD card and triest to auto-detect the new block device, and it tries to configure the SDCARD partition to expand to fill available free space after the fixed-size boot/root/system/data/cache partitions. This works great on the linux host and two SD cards I tested. But it came out in https://github.com/raspberrypi/firmware/issues/315 that both of those are failing: 1. An sdcard created as /dev/sdc isn't detected as /dev/sdc, instead the script thinks one of its partitions, /dev/sdc1, is the new device. Obviously things blow up when it tries to partition /dev/sdc1. 2. sfdisk bungles the computation of the partition geometry for the expand-into-free-space parition: Partitioning /dev/sdc ... [...snip...] Device Boot Start End #sectors Id System /dev/sdc1 8192 110591 102400 e W95 FAT16 (LBA) /dev/sdc2 112640 122879 10240 83 Linux /dev/sdc3 124928 1148927 1024000 83 Linux /dev/sdc4 1150976 15523839 14372864 85 Linux extended /dev/sdc5 1153024 4089855 2936832 83 Linux /dev/sdc6 4091904 4194303 102400 83 Linux /dev/sdc7 4196352 15523839 11327488 c W95 FAT32 (LBA) [...snip...] end of partition 4 has impossible value for cylinders: 1021 (should be in 0-1020) sfdisk: I don't like these partitions - nothing changed. The specification for the (extended) partition 4 sent to sfdisk is 1150976,+,85 where the "+" means expand into remaining space. So sfdisk is computing an end boundary that sfdisk doesn't like! Grrr :/. (1) looks like it might be a quirk of unix |sort|, so probably easy to fix. I don't know what to do about (2). I think for now I'll roll back the smarts and just have people manually expand SDCARD using gparted (hoping that doesn't screw up the partitions either), if they need more than a few GB available on /sdcard.

How do one roll back the smarts and manually partition the cards. Here is the output from my first build on 16GB card. $ sudo fdisk -l /dev/mmcblk0 Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes 4 heads, 16 sectors/track, 486192 cylinders, total 31116288 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/mmcblk0p1 8192 110591 51200 e W95 FAT16 (LBA) /dev/mmcblk0p2 112640 122879 5120 83 Linux /dev/mmcblk0p3 124928 1148927 512000 83 Linux /dev/mmcblk0p4 1150976 31116287 14982656 85 Linux extended /dev/mmcblk0p5 1153024 4089855 1468416 83 Linux /dev/mmcblk0p6 4091904 4194303 51200 83 Linux /dev/mmcblk0p7 4196352 31116287 13459968 c W95 FAT32 (LBA)

It looks like your SD card was flashed correctly! Great :). I'd like to "dumb down" the script by making these changes - instead of trying to auto-detect a newly-inserted SD card, ls /dev before asking the user to insert their SD card, and then ls /dev again after asking them to insert it. Then the user can visually scan for their new device. - instead of trying to expand the SDCARD partition to fill available free space, just hard-code a conservative size like 1 GB. Then after the flashing script finishes, print a message telling users to run gparted or a similar program to resize their SDCARD partition if they want to.

(In reply to Chris Jones [:cjones] temporarily active; ni?/f?/r? if you need me from comment #2) > It looks like your SD card was flashed correctly! Great :). > I cheated. :) Dropped all partitions on the card before running the script.

Another problem is that one partition-naming scheme is "foopN" but another is "fooN". Sigh. Definitely need another solution.

> end of partition 4 has impossible value for cylinders: 1021 (should be in 0-1020) I'm able to reproduce something similar with another flash drive. I hate teh lunix sometimes.

https://github.com/mozilla-b2g/device-rpi/commit/398c16a2197ff995a2eec1a5d5f8e4dffdda7720 Also uploaded prebuilt image and updated docs at https://wiki.mozilla.org/Hacking_b2g_on_Raspberry_Pi#Flash_an_existing_build

(In reply to Chris Jones [:cjones] temporarily active; ni?/f?/r? if you need me from comment #2) > - instead of trying to expand the SDCARD partition to fill available free > space, just hard-code a conservative size like 1 GB. Then after the > flashing script finishes, print a message telling users to run gparted or a > similar program to resize their SDCARD partition if they want to. That sounds like a good strategy. Some distros recommend using rpi-config to resize the partition. http://elinux.org/RPi_Resize_Flash_Partitions#Raspi-config

Right --- we can't use that program directly in FFOS as far as I know, but that's the right kind of idea. Note too that FFOS's partition layout is rather different than Raspbian's.

It was getting to hairy to produce FFOS disk images, so I went and pushed a commit to hard-code the 4GB partition layout in the flashing script https://github.com/mozilla-b2g/device-rpi/commit/8f7d86369f697711cfbe99b3015938da338635d8 That means the flash.sh script should now work for any disk. But it's usually more convenient for end users to flash pre-made builds.