Document resizing and/or rebuilding 8GB image for 16GB/32GB variants

[Till Kamppeter]

I have Raring on my Nexus 7, manually flashed from the daily builds. The Nexus 7 has 16 GB and according to gnome-disks the partition with the root file system has ~14 GB, but the file system has only around 6 GB:

till@till-nexus7:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p9 6.1G 4.1G 2.0G 68% /
udev 485M 4.0K 485M 1% /dev
tmpfs 195M 808K 194M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 486M 724K 486M 1% /run/shm
none 100M 8.0K 100M 1% /run/user
till@till-nexus7:~$

Online resizing does not work:

till@till-nexus7:~$ sudo resize2fs /dev/mmcblk0p9
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mmcblk0p9 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/mmcblk0p9 to 3525888 (4k) blocks.
resize2fs: Invalid argument While trying to add group #49
till@till-nexus7:~$

This needs to get fixed in the install procedure.

How can I make use of the full memory of my Nexus 7 without reinstalling?

[Dimitri John Ledkov (xnox)]

Currently we only build 8GB (highest common denominator) images on daily basis.
You can use android-tools-fsutils to rebuild 8GB image into a 16/32GB images, but they may fail to flash due to increased total size of the image.

[Till Kamppeter (till-kamppeter)]

It would be also great if the ubuntu-nexus7-installer rebuilds the image for the actual storage capacity of the target Nexus 7.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dimitri John Ledkov (xnox)]

There are multiple nexus7 sizes, but the generate image contains pre-formatted fixed size filesystem (as required to flash it using android tools).

The problem is that we don't want to generate 3 images (expensive buildtime, download size, qa efforts).
On the other hand we do want to maximize and use all available space.

To automatically achieve this we can do one of the following:

* Repack the images client-side (may fail to generate or to flash)
* Resize on-boot (may fail, proven to be unreliable with precise)
* Bite the bullet & publish multiple images (by repacking images server side)

We should establish which direction to go & then implement it.

[Robert Bruce Park (robru)]

If we published images in all three sizes, would the larger sizes just be zero-filled to make up the space? that would be quite compressible, wouldn't it? Seems you could just have 16gb.iso.gz that would be not much larger than 8gb.iso.

[Francesco Mateotti (fmateotti)]

How eaxactly would one go about using android-tools-fsutils to resize the image?

[Oliver Grawert (ogra)]

as dimitrijs listed above, the plan as discussed at UDS was to have usb-creator do the repackaging, i would have started to work on this already but had to burn my annual vacation days ;)
work on this will start soon.

[Oliver Grawert (ogra)]

for the manual repackaging, you use simg2img to convert the file into a proper img, then mount the img file, copy the tarball from the mount into a temporary dir and use make_ext4fs from the package to create one using this temporary dir as input for an image of the appropriate size.

[Simon Elmir (nerd65536)]

Why does the resize2fs operation fail? It the root filesystem defective in some way?

[Oliver Grawert (ogra)]

not defective but built in a special way using the android-fsutils which create a sparse filesystem that gets turned into a "kind of normal" ext4 filesystem during flashing

[zefie (rkuchiki)]

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.

[Ian Lantzy (ianlantzy)]

This is probably a stupid question but where did you get simg2img and make_ext4fs?