Images too large? - Printable Version +- PINE64 (https://forum.pine64.org) +-- Forum: General (https://forum.pine64.org/forumdisplay.php?fid=1) +--- Forum: Getting Started (https://forum.pine64.org/forumdisplay.php?fid=21) +--- Thread: Images too large? (/showthread.php?tid=1683) |
Images too large? - kikootwo - 07-07-2016 Hello! I am trying to burn some rooted DD images of android from http://wiki.pine64.org/index.php/Pine_A64_Software_Release#Android_5.1.1_Image_.28HDMI_Video_Output.29_Release_20160505 I bought two 64gb sd cards from amazon from this link: https://www.amazon.com/gp/product/B00IVPU7AO/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1 When I try to use Win32DiskImager to burn the 64gb images to the SD cards I get this error: http://imgur.com/fvVRSCG Any idea on why the heck this is happening? RE: Images too large? - Ghost - 07-07-2016 (07-07-2016, 06:44 PM)kikootwo Wrote: Hello! Different brands of microSD of the same size report different actual storage capacities - thus what is '64GB' for a Samsung may not be the same as for a SanDisk, or a PNY or whatever. More all-encompassing dd images are in works, last I heard. Until then, your best option is to choose an image one size down - so for you that would mean choosing the 32GB image. Not ideal, I know, but at least then you can get up and running. The alternative is to try and use the PhoenixCard software and a PhoenixCard image and burn things that way. This method has its own issues, but should be ok provided you don't try and burn a dd image with PhoenixCard. It won't work and you will get a 'script not found' error. RE: Images too large? - ViperVi - 07-11-2016 I had the similar issue with a 64GB card I had bought for my Pine and then I swapped it with the 32GB in my phone and no issues with that dd image. RE: Images too large? - BigBear59 - 07-12-2016 You could do this on a Linux system, if the image is slightly to big. cd /tmp wget http://files.pine64.org/os/android/android-ver5.1.1-20160505-pine64-64GB.zip #Download the ZIP to the Linux system unzip android-ver5.1.1-20160505-pine64-64GB.zip # Unzip it to android-ver5.1.1-20160505-pine64-64GB.img fdisk -l android-ver5.1.1-20160505-pine64-64GB.img # Get the IMG partition info omitting empty partition (14) Disk android-ver5.1.1-20160505-pine64-64GB.img: 63.3 GB, 63282610176 bytes, 123598848 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 label type: dos Disk identifier: 0x00000000 Device Boot Start End Blocks Id System android-ver5.1.1-20160505-pine64-64GB.img1 5251072 123596798 59172863+ b W95 FAT32 android-ver5.1.1-20160505-pine64-64GB.img2 * 73728 139263 32768 6 FAT16 android-ver5.1.1-20160505-pine64-64GB.img3 1 5251072 2625536 85 Linux extended android-ver5.1.1-20160505-pine64-64GB.img5 139264 172031 16384 83 Linux android-ver5.1.1-20160505-pine64-64GB.img6 172032 204799 16384 83 Linux android-ver5.1.1-20160505-pine64-64GB.img7 204800 3350527 1572864 83 Linux android-ver5.1.1-20160505-pine64-64GB.img8 3350528 3383295 16384 83 Linux android-ver5.1.1-20160505-pine64-64GB.img9 3383296 3448831 32768 83 Linux android-ver5.1.1-20160505-pine64-64GB.img10 3448832 5021695 786432 83 Linux android-ver5.1.1-20160505-pine64-64GB.img11 5021696 5054463 16384 83 Linux android-ver5.1.1-20160505-pine64-64GB.img12 5054464 5087231 16384 83 Linux android-ver5.1.1-20160505-pine64-64GB.img13 5087232 5251071 81920 83 Linux Partition table entries are not in disk order Got the 73728 from the START col of .img2, would use 139264 for .img5, yada, yada, yada echo "73728 * 512" | bc # Calculate the offset 37748736 mkdir /mnt/from_part mkdir /mnt/to_part Use FDISK & MKFS to duplicate your Slightly small SD card to match the fdisk from the IMG. Here partition 1 should end up a bit smaller, normally this smaller partition would be the last, but that's not how this one came out. # Mount your SD card onto /mnt/to_part, I'll let you figure this out mount -o loop,owner,offset=37748736 /tmp/android-ver5.1.1-20160505-pine64-64GB.img /mnt/from_part/ # Mount the IMG partition #2 ls -l /mnt/from_part/ # Ouh see the Magic , see what is on IMG partition #2 total 1358 drwxr-xr-x. 2 root root 2048 Dec 31 1979 bat -rwxr-xr-x. 1 root root 681774 Dec 31 1979 bootlogo.bmp -rwxr-xr-x. 1 root root 0 Dec 31 2009 data.notfirstrun -rwxr-xr-x. 1 root root 344813 Dec 31 1979 font24.sft -rwxr-xr-x. 1 root root 357443 Dec 31 1979 font32.sft -rwxr-xr-x. 1 root root 512 Dec 31 1979 magic.bin cd /mnt/from_part/ tar -cf - . | ( cd /mnt/to_part; tar -xpvf - )./ # copy the files from the IMG partition to the SD ./font24.sft ./bat/ ./bat/bat9.bmp ./bat/bat7.bmp ./bat/bat2.bmp ./bat/bat5.bmp ./bat/bootlogo.bmp ./bat/bat0.bmp ./bat/bat8.bmp ./bat/low_pwr.bmp ./bat/battery.bmp ./bat/bat1.bmp ./bat/bat3.bmp ./bat/bempty.bmp ./bat/bat6.bmp ./bat/battery_charge.bmp ./bat/bat10.bmp ./bat/bat4.bmp ./bootlogo.bmp ./font32.sft ./magic.bin ./data.notfirstrun tar: .: implausibly old time stamp 1969-12-31 16:00:00 ls -l /mnt/to_part/ # look they match total 1368 drwxr-xr-x. 2 root root 4096 Dec 31 1979 bat -rwxr-xr-x. 1 root root 681774 Dec 31 1979 bootlogo.bmp -rwxr-xr-x. 1 root root 0 Dec 31 2009 data.notfirstrun -rwxr-xr-x. 1 root root 344813 Dec 31 1979 font24.sft -rwxr-xr-x. 1 root root 357443 Dec 31 1979 font32.sft -rwxr-xr-x. 1 root root 512 Dec 31 1979 magic.bin umount /mnt/from_part umount /mnt/to_part # Rinse, Repeat for each partition in the IMG Good luck, BigBear RE: Images too large? - KPhillisJr - 07-17-2016 I also ran into this issue when attempting to write the 16GB image to an 16 GB microsd card using Win32DiskImager. I was using a Samsung 16GB PRO MicroSD Card ( Model: MB-MG16EA/AM ) that I purchased on Newegg. System Specs:
RE: Images too large? - jimwrey - 07-17-2016 This images done for DD cannot be used with the Win32 Diskimager. Select the "Phoenix Card image:" from further down on the list of images. Then Win32 Imager seems to work. RE: Images too large? - Ghost - 07-18-2016 (07-17-2016, 11:24 PM)jimwrey Wrote: This images done for DD cannot be used with the Win32 Diskimager. This is incorrect information. PhoenixCard images cannot be burned in Win32DiskImager, DD images cannot be burned using PhoenixCard. Only images labelled as being for PhoenixCard can be burned using the PhoenixCard software. Images labelled as being DD can be burned through a variety of applications, including Win32DiskImager and via a command line terminal. RE: Images too large? - jimwrey - 07-18-2016 (07-18-2016, 01:11 AM)Ghost Wrote:(07-17-2016, 11:24 PM)jimwrey Wrote: This images done for DD cannot be used with the Win32 Diskimager. Thanks, it appeared to burn okay ... but did not boot. When trying to burn it with the PhoenixCard is says "script missing" ... So, I won't chime in again ... RE: Images too large? - Ghost - 07-18-2016 (07-18-2016, 02:06 PM)jimwrey Wrote:(07-18-2016, 01:11 AM)Ghost Wrote:(07-17-2016, 11:24 PM)jimwrey Wrote: This images done for DD cannot be used with the Win32 Diskimager. By all means chime in again. Everyone has an opinion and a right to share it. Even if wrong, as in this case, it helps to create a discussion and someone else reading this can say 'hey, that's what I thought too, glad these guys talked about it first and found out some stuff.' Regarding this particular topic, it's one that I'm on the lookout for - trying to prevent confusion arising over different images and different burning options. RE: Images too large? - jimwrey - 07-19-2016 (07-18-2016, 03:16 PM)Ghost Wrote:(07-18-2016, 02:06 PM)jimwrey Wrote:(07-18-2016, 01:11 AM)Ghost Wrote:(07-17-2016, 11:24 PM)jimwrey Wrote: This images done for DD cannot be used with the Win32 Diskimager. Thanks I appreciate the help. There was another post (I think) from another poor lost soul that stated that you could only burn an Image with the DD from the command line ... I will go back and try the DD file with Win32DiskImager ... as a former tech writer of manuals picking through the how to posts and pages has been painful as they all seem to make assumptions that the read knows what they are doing. I am proof that that is often NOT the case. :>) |