The cards are from the same manufacturer, and exactly the same size.

I've tried dd and not only does it take closer to 2.5 hours instead of 10 minutes, it yields the same results.

dd if=/dev/sde of=/dev/sdf bs=8M

The only difference between a card that boots and a card that fails with `[    1.003204]  mmcblk0: unknown partition table` is the disk geometry used to create the partition table.



The duplication process is a usb hub with many card readers attached and a script that creates a fake raid 1 (/dev/md0 sans raid info) out of the cards and copies the used bytes.


Now I'm trying to figure out how `gparted` auto-detects the geometry and then modify my script to rsync the files rather than use `partimage` on the raid.

Surprisingly, there's not as much of a speed gain as I had hoped using the fake raid to duplicate all of the cards simultaneously.

AJ ONeal


On Wed, Jun 29, 2011 at 4:26 PM, Tom Gall <tom.gall@linaro.org> wrote:
If you want to avoid l-m-c which is the image creation route we
support, once you've created the first master and have it booting and
setup the way you want, and presuming all your SD cards are exactly
the same, I suspect you'd fine more success to dd from master to
create an image file and then dd from the image file to each
successive SD card.

Regards,
Tom

On Wed, Jun 29, 2011 at 5:18 PM, AJ ONeal <coolaj86@gmail.com> wrote:
>> Were you using Linaro-media-create to put things onto the SD card or
>> some other route?
>>
>
> Yes.
> created the master card using `linaro-media-create`
> booted it once and added some secret sauce to it.
> duplicated that card to 20 cards using `sfdisk` and `partimage`.
> (Half of those cards did not boot)
> used `gparted` to create a new partition table on one of the failed cards
> (the new second master)
> used `rsync` to copy the contents of the first master to a second master
> reran the duplication process
> repeated the step above for the remaining failed cards
> ended up with 3 master cards with the exact same filesystem contents and
> very nearly identical partition tables,
> but different disk geometries (head, cyl, sector).
>
> AJ ONeal
>
>> On Wed, Jun 29, 2011 at 12:48 PM, AJ ONeal <coolaj86@gmail.com> wrote:
>> > I have a few inter-related issues:
>> >
>> > Why would one kernel boot a card that another kernel can't?
>> > Why would a card's disk geometry matter for boot?
>> > Who is a good manufacturer for getting hardware-identical cards in bulk?
>> > How can I probe the actual "disk geometry" of an sd card?
>> >
>> > I bought 100 Transcend SD cards a little while ago and duplicated them
>> > with
>> > an OpenEmbedded-based filesystem (linux-2.6.36).
>> > There were a few "bad" cards that I threw out, but the success rate was
>> > acceptable.
>> >
>> > In the next round of 40 SD cards I used a Linaro-based filesystem
>> > (linux-2.6.39) and had about a 50% failure rate when testing that the
>> > cards
>> > would boot, which is absurd.
>> > There kernel reports: [    1.003204]  mmcblk0: unknown partition table
>> > However, the cards would mount and show files just fine.
>> > I reduplicated one of the non-booting cards with an OpenEmbedded
>> > filesystem
>> > and then it booted. Weird!
>> >
>> > After some investigation I found that using `gparted` (instead of
>> > `fdisk`)
>> > to create a new partition table and then `rsync`ing the contents of the
>> > original filesystem resulted in a booting Linaro card.
>> > Rinse and repeat and I ended up with 3 images which only vary by the
>> > disk
>> > geometry as reported by `fdisk -l`:
>> >
>> > 50% -- 255 heads, 63 sectors/track, 974 cylinders
>> > 40% -- 2 heads, 4 sectors/track, 1957632 cylinders
>> > 10% -- 247 heads, 62 sectors/track, 1022 cylinders
>> > 1 card still didn't boot
>> >
>> > I'm lost. Please advise.
>> > AJ ONeal
>> >
>> >
>> >
>> > Non-booting kernel message
>> > [    0.923309] Waiting for root device /dev/mmcblk0p2...
>> > [    0.957885] mmc0: host does not support reading read-only switch.
>> > assuming write-enable.
>> > [    0.982025] mmc0: new high speed SDHC card at address b368
>> > [    0.988494] mmcblk0: mmc0:b368 USD   7.46 GiB
>> > [    0.993957] mmcblk0: detected capacity change from 0 to 8018460672
>> > [    1.003204]  mmcblk0: unknown partition table
>> > [    1.036926] VFS: Cannot open root device "mmcblk0p2" or
>> > unknown-block(179,2)
>> > [    1.044433] Please append a correct "root=" boot option; here are the
>> > available partitions:
>> > [    1.053344] b300         7830528 mmcblk0  driver: mmcblk
>> > [    1.058959] Kernel panic - not syncing: VFS: Unable to mount root fs
>> > on
>> > unknown-block(179,2)
>> >
>> > Booting kernel message
>> > [    1.122070] mmc0: host does not support reading read-only switch.
>> > assuming write-enable.
>> > [    1.146087] mmc0: new high speed SDHC card at address b368
>> > [    1.152557] mmcblk0: mmc0:b368 USD   7.46 GiB
>> > [    1.158020] mmcblk0: detected capacity change from 0 to 8018460672
>> > [    1.166351]  mmcblk0: p1 p2 p3
>> > [    1.259674] EXT3-fs: barriers not enabled
>> > [    1.265411] kjournald starting.  Commit interval 5 seconds
>> > [    1.271331] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data
>> > mode
>> > [    1.278686] VFS: Mounted root (ext3 filesystem) readonly on device
>> > 179:2.
>> > _______________________________________________
>> > linaro-dev mailing list
>> > linaro-dev@lists.linaro.org
>> > http://lists.linaro.org/mailman/listinfo/linaro-dev
>> >
>> >
>>
>>
>>
>> --
>> Regards,
>> Tom
>>
>> "We want great men who, when fortune frowns will not be discouraged."
>> - Colonel Henry Knox
>> Linaro.org │ Open source software for ARM SoCs
>> w) tom.gall att linaro.org
>> w) tom_gall att vnet.ibm.com
>> h) tom_gall att mac.com
>
>



--
Regards,
Tom

"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com