I also experience this problem (also +/-1GB of data). I used to copied
the tarball to the sdcard and unpacked it from adb cause I could not
get /sdcard to mount in the recovery until I found it I needed:
run_program("/sbin/mount","/ext/sdcard");
and not
run_program("/sbin/mount","/sdcard");
/ext/sdcard is in turn symlinked to /sdcard so it's the same for the
install script.
Don't know how this is with other phones that have internal and
external sdcards.
I think the data partition is usually better at handling small files
so unpacking to the /sdcard and copying it might be slow (but I see
you unpack to /data so never mind).2013/7/2 Florian Will <florian.w...@gmail.com>: > [Resending because my earlier mail was probably rejected due to using a > bad mail address] > > > Hi everyone, > > I know this is probably not a priority with the development currently > mainly focused on getting features ready. And in the future, it might > even be less important because devices will have more storage capacity. > So I'm prepared for answers like "Nope, sorry!". > > But still, I'm currently testing Ubuntu Touch on my old smartphone, and > the /data partition of that device is only 1gb. The default way of > installing the root file system on /data fails with that device, because > the extracted rootfs and the tarball don't fit within /data at the same > time. I have posted a merge request for the tarball creation scripts [1] > that fixes this problem by storing the .tar.gz on /sdcard, maybe this > can be used as the default for future tarballs? It would definitely make > life easier for anyone aiming to provide images for older devices with > small /data. > > > Another problem is that /data quickly reaches a point where it has > almost no free space left when using the device (because of logs etc.). > A few problems I've had were actually caused by this, like some > networking tools (wpa_supplicant? network manager?) refusing to connect > to wifi when df shows that there is less than 100mb storage capacity > available on /data. > > I've looked through the rootfs.tar.gz and noticed a few "low-hanging > fruits" for trimming down the size. There are probably more. Do you > think it's worthwile to care about them? Or is it considered a very low > priority, as long as it is okay on the officially supported devices? > > Examples that are probably free of negative side-effects: > * /var/log: 9mb lastlog and other logs that could be rm-ed before the > tarball is created > * /etc/apt/sources.list: Disable the source package archive, so there > are fewer big files in /var/lib/apt/lists (I don't think there are a lot > of use-cases where this needs to be enabled, also speeds up apt-get > updates I guess) > * /usr/share/icons: Not sure if the Humanity icons are needed at all > (14mb). I guess the svg icons for Ubuntu Touch are required, otherwise > they could be removed to save another 10mb. > > Example that has negative effects on performance: > * Disable binary apt caches and delete /var/cache/apt/*.bin as > described in [2]. Performance for apt operations will suffer, but it > reduces rootfs size by almost 50mb. > > Of course, after installing the rootfs, a whole lot of space can be > reclaimed by uninstalling the demo-* packages. These are probably > supposed to be included with the official rootfs though. :-) > > Cheers, > Florian > > [1] > https://code.launchpad.net/~florian-will/touch-preview-images/phablet-build-scripts-extract-from-sdcard/+merge/172300 > [2] https://wiki.ubuntu.com/ReducingDiskFootprint#Disable_apt_caches > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
