I'm not sure what the -J flag does on make_ext4fs but I've found it created a smaller rootfs.img which allowed me to flash. I have 100% failure rate using sparse, so I needed a file less than 700MB. Here was my process for my 32GB Nexus 7.
simg2img raring-preinstalled-desktop-armhf+nexus7.raw tmp.img sudo mount -o loop tmp.img tmp mkdir build cp tmp/rootfs.tar.gz build sudo umount tmp make_ext4fs -J -s -l 27G raring-preinstalled-desktop-armhf+nexus7_32G.raw build/ rm -rf tmp.img build/ Of interesting note, the original "raring-preinstalled-desktop- armhf+nexus7.raw" is 675MB, and my 32GB modified version is 583MB. It worked fine. zefie@zefie-n7:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=13.04 DISTRIB_CODENAME=raring DISTRIB_DESCRIPTION="Ubuntu 13.04" zefie@zefie-n7:~$ df -h / Filesystem Size Used Avail Use% Mounted on /dev/mmcblk0p9 27G 1.8G 25G 7% / zefie@zefie-n7:~$ Other thoughts: Passing make_ext4fs the -z flag rather than the -J flag created a slightly smaller image, and it flashed, but was not mountable by the kernel. Also, if you are reflashing after an existing install, reflash the boot image. It seems the installer does something to modify the boot.img. This is probably known by the devs, but may not be known by end-users. Reflashing the boot image provided from the cdimage website will allow the installer to properly handle the rootfs.tar.gz. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1091220 Title: Document resizing and/or rebuilding 8GB image for 16GB/32GB variants To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1091220/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
