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
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
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
On 29 June 2011 23:40, AJ ONeal coolaj86@gmail.com wrote:
The cards are from the same manufacturer, and exactly the same size.
Is the ID of the card as reported by /sys/class/mmc_host/mmc0/mmc0:0001/manfid and oemid (adjust path to your SD card interface) the same for the cards that work and the cards that don't?
(If you haven't seen it you might also look at the table on:
https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey
)
Dave
On 30 June 2011 04:10, AJ ONeal coolaj86@gmail.com wrote:
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
<Though I don't think it will solve the problem if Tom's suggestion didn't already help. But still a few points to note>
This bs=8M doesn't seem the best/useful option. Also we need to remember 'dd' runs beneath the file-system layer and will copy bytes from image to the disk. Most of which(as per 2.5hours/10min) seems non-relevant data in this case.
Assuming you create only primary partitions and you have the working 'master-copy' in /dev/sde, maybe you could try $ dd if=/dev/sde of=master_mbr.img bs=512 count=1 Then 'burn' only the good master mbr on all cards. $ dd if=master_mbr.img of=/dev/sdf //and other cards
Once you unplug->plug the cards, it should be possible to have a script that formats the newly detected partitions(albeit malformed[*]) and do rysnc to copy the load. Btw, there just might be a way to emulate 'soft' unplug->plug of storage over USB using sysfs or somthing, that I am not aware of, which could make the whole process scripted.
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.
If I had money to burn I would bet this scripted raid + usb hub thing has unveiled some bug that fails the almighty dd method.
[*] It might be prudent to also script the capture first sector of each partition of the 'master' card. And burn them respectively after the unplug-plug of 'copy' cards.
Rgds, -j
Hi,
I am trying to script out creating of android partitions on different size of sdcard. While going through android-media-create scripts, I found the following:
return '%s,%s,%s,*\n%s,%s,L\n%s,%s,L\n%s,-,E\n%s,%s,L\n%s,,,-' % ( boot_start, boot_len, partition_type, system_start, _system_len, cache_start, _cache_len, userdata_start, userdata_start, _userdata_len, sdcard_start)
The scripts itself has calculate the alignment through the start/len of the different partition. However, the first logical partition created under the extended partition has the same starting sector. If I do a test using sfdisk, I get an bad parition start for the logical partition.
Anyone has any advice on this?
with best regards, Hock.
On Fri, Jul 8, 2011 at 10:27 PM, Jaswinder Singh jaswinder.singh@linaro.org wrote:
On 30 June 2011 04:10, AJ ONeal coolaj86@gmail.com wrote:
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
<Though I don't think it will solve the problem if Tom's suggestion didn't already help. But still a few points to note>
This bs=8M doesn't seem the best/useful option. Also we need to remember 'dd' runs beneath the file-system layer and will copy bytes from image to the disk. Most of which(as per 2.5hours/10min) seems non-relevant data in this case.
Assuming you create only primary partitions and you have the working 'master-copy' in /dev/sde, maybe you could try $ dd if=/dev/sde of=master_mbr.img bs=512 count=1 Then 'burn' only the good master mbr on all cards. $ dd if=master_mbr.img of=/dev/sdf //and other cards
Once you unplug->plug the cards, it should be possible to have a script that formats the newly detected partitions(albeit malformed[*]) and do rysnc to copy the load. Btw, there just might be a way to emulate 'soft' unplug->plug of storage over USB using sysfs or somthing, that I am not aware of, which could make the whole process scripted.
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.
If I had money to burn I would bet this scripted raid + usb hub thing has unveiled some bug that fails the almighty dd method.
[*] It might be prudent to also script the capture first sector of each partition of the 'master' card. And burn them respectively after the unplug-plug of 'copy' cards.
Rgds, -j
-- Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#%21/linaroorg - http://linaro.org/linaro-blog
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 12 August 2011 09:47, Bee Hock Goh beehock@gmail.com wrote:
I am trying to script out creating of android partitions on different size of sdcard. While going through android-media-create scripts, I found the following:
return '%s,%s,%s,*\n%s,%s,L\n%s,%s,L\n%s,-,E\n%s,%s,L\n%s,,,-' % ( boot_start, boot_len, partition_type, system_start, _system_len, cache_start, _cache_len, userdata_start, userdata_start, _userdata_len, sdcard_start)
The scripts itself has calculate the alignment through the start/len of the different partition. However, the first logical partition created under the extended partition has the same starting sector. If I do a test using sfdisk, I get an bad parition start for the logical partition.
Hi Ben,
I believe that having the boot partition aligned to 4MB boundaries can cause problems with old x-loaders, so by default the Linaro media create scripts only align the non-boot partitions to 4MB boundaries. You can override this by adding --align-boot-part to your linaro-android-media-create line. If my reading of the code is correct by default boot partitions will be aligned on sector 63 unless they are a Snowball, Mx5 or Samsung board, which all have their own requirements for where a boot partition should be and ignore the align-boot-part flag.
Hope this helps,
James
-
AJ ONeal -
Bee Hock Goh -
David Gilbert -
James Tunnicliffe -
Jaswinder Singh -
Tom Gall