this note is not to pick on a particular SD card image for the xM,
it's to share one way to check on an image's validity and make sure
i'm not doing anything silly.
from yesterday, i was suggesting that the SD card image you get from
the 4_25 zip file here:
http://circuitco.com/support/index.php?title=BeagleBoard-xM
seems corrupt in some way. after unzipping, one gets the alleged
image file:
-rw-rw-r-- 1 rpjday rpjday 3948134400 2012-01-17 23:38 xMc_4_25.img
(is that the same size others are getting for the image file?)
i still get an unzipping error:
$ unzip xMc_4_25.zip
Archive: xMc_4_25.zip
inflating: xMc_4_25.img bad CRC 13edfed2 (should be 729c69cf)
$
so i thought i'd take a look inside the image file at the component
filesystems.
$ fdisk -l xMc_4_25.img
Disk xMc_4_25.img: 3948 MB, 3948134400 bytes
255 heads, 63 sectors/track, 480 cylinders, total 7711200 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
xMc_4_25.img1 * 63 240974 120456 c W95 FAT32 (LBA)
xMc_4_25.img2 240975 7132859 3445942+ 83 Linux
$
that looks reasonable, and it's what i would expect. now i can use
the mount "loop" option and offset to mount, say, the first
filesystem.
from "bc", i get that 63 sectors * 512 bytes = 32256, so i should be
able to mount that FAT filesystem thusly (at some temporary directory
"m"):
$ sudo mount -o loop,offset=32256 xMc*img m
and, sure enough, the mount works and i can see the contents of that
filesystem:
$ ls -l m
total 3421
-rwxr-xr-x 1 root root 22232 2011-04-19 17:24 MLO
-rwxr-xr-x 1 root root 284788 2011-04-19 17:24 U-BOOT.BIN
-rwxr-xr-x 1 root root 134 2011-04-19 15:31 uEnv.txt
-rwxr-xr-x 1 root root 3194256 2011-04-19 17:24 UIMAGE
$
now i *should* be able to unmount that filesystem and do the same
with the second one (offset = 512 * 240975 = 123379200):
$ sudo mount -o loop,offset=123379200 xMc*img m
mount: /dev/loop0: can't read superblock
$
ok, that doesn't look good. is there any reason that shouldn't
work? if i do the same thing with the older 3_30 zip file and image
from that same page, the mount works just fine (same offsets in that
older image):
$ ls -l m
total 72
drwxr-xr-x 2 www-data www-data 4096 1969-12-31 20:01 bin
drwxr-xr-x 2 www-data www-data 4096 2011-03-29 09:31 boot
drwxr-xr-x 2 www-data www-data 4096 2011-03-29 09:29 dev
drwxr-xr-x 54 www-data www-data 4096 2011-03-29 10:31 etc
drwxr-xr-x 3 www-data www-data 4096 2011-03-29 09:26 home
drwxr-xr-x 5 www-data www-data 4096 1969-12-31 20:53 lib
drwx------ 2 root root 16384 2011-03-29 09:36 lost+found
drwxr-xr-x 12 www-data www-data 4096 1969-12-31 19:00 media
drwxr-xr-x 2 root root 4096 2011-03-29 15:55 mmc
drwxr-xr-x 2 www-data www-data 4096 2011-03-29 09:26 mnt
-rw-r--r-- 1 www-data www-data 0 2011-03-29 09:37 narcissus-was-here
drwxr-xr-x 2 www-data www-data 4096 2011-02-20 14:13 proc
drwxr-xr-x 2 www-data www-data 4096 1969-12-31 20:01 sbin
drwxr-xr-x 2 www-data www-data 4096 2011-02-20 14:13 sys
lrwxrwxrwx 1 root root 8 1969-12-31 22:22 tmp -> /var/tmp
drwxr-xr-x 12 www-data www-data 4096 2010-11-05 10:38 usr
drwxr-xr-x 9 www-data www-data 4096 2011-02-09 06:18 var
$
at this point, unless someone can suggest something i've done
stupidly, i'm fairly convinced that that 4_25 image is damaged with
respect to the linux filesystem. and, besides, i really want the 4_26
image that's shipping with current xMs anyway.
rday