Installation of "Desktop Applications" breaks BQ Phones

[Marius Quabeck]

If you install "Desktop Applications" from the store on a BQ E4.5 or E5 HD it breaks the installation. The click is about ~600 MB big which is not the problem but it tries to uncompress it to the root partition after downloading and the files are ~1,5 GB big while the root partition on the BQ phones is 2 GB big and usually filled up to 75%.
Therefore the installation will fail but the root partition stays full and the user cant download any more apps or install OTA's and has to reflash the phone.

Yes the app description says "we recommend that owners of these devices do not install the Desktop Applications click package" but it should be more specific.

[John McAleely (john.mcaleely)]

I have just tried installing this desktop applications click onto a factory-fresh vegetahd. My phone is now in a loop trying to start the 'scopes' screen, and restarting.

[John McAleely (john.mcaleely)]

A reboot of the handset, and it is now working. It doesn't look like any of the partitions are full, so it's not clear what the cause of the issue is:

$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 484932 4 484928 1% /dev
tmpfs 97460 324 97136 1% /run
/dev/mmcblk0p7 12243756 199988 11421872 2% /userdata
/dev/mmcblk0p6 2076276 1719668 251136 88% /
/dev/loop0 145328 143528 1800 99% /android/system
none 4 0 4 0% /android
tmpfs 487284 4 487280 1% /etc/fstab
/dev/disk/by-path/platform-mtk-msdc.0-part5 705512 17100 652572 3% /android/cache
none 4 0 4 0% /sys/fs/cgroup
tmpfs 487284 24 487260 1% /tmp
cgmfs 100 0 100 0% /run/cgmanager/fs
none 5120 0 5120 0% /run/lock
none 487284 112 487172 1% /run/shm
none 102400 0 102400 0% /run/user
tmpfs 487284 0 487284 0% /media
tmpfs 487284 0 487284 0% /var/lib/sudo
tmpfs 97460 40 97420 1% /run/user/32011
tmpfs 97460 0 97460 0% /run/user/0

(andrdoid/system is expected to be full - that's it's normal state)

That said, it doesn't look like the click has installed at all after the reboot.

[John McAleely (john.mcaleely)]

My handset is running: ubuntu-touch/rc/bq-aquaris.en #42

[John McAleely (john.mcaleely)]

OK, so re-installing the click and waiting patiently for a few mins after the store page shows '100%' for the installer, and my handset started rebooting the 'scopes' page again.

df this time reveals:

$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 484932 4 484928 1% /dev
tmpfs 97460 324 97136 1% /run
/dev/mmcblk0p7 12243756 200740 11421120 2% /userdata
/dev/mmcblk0p6 2076276 1719668 251136 88% /
/dev/loop0 145328 143528 1800 99% /android/system
none 4 0 4 0% /android
tmpfs 487284 4 487280 1% /etc/fstab
/dev/disk/by-path/platform-mtk-msdc.0-part5 705512 17100 652572 3% /android/cache
none 4 0 4 0% /sys/fs/cgroup
tmpfs 487284 487280 4 100% /tmp
cgmfs 100 0 100 0% /run/cgmanager/fs
none 5120 0 5120 0% /run/lock
none 487284 112 487172 1% /run/shm
none 102400 0 102400 0% /run/user
tmpfs 487284 0 487284 0% /media
tmpfs 487284 0 487284 0% /var/lib/sudo
tmpfs 97460 40 97420 1% /run/user/32011
tmpfs 97460 0 97460 0% /run/user/0

I assume it is the full /tmp which is causing the problem, and that explains why it clears with a reboot

[John McAleely (john.mcaleely)]

We'll need to confirm, but I think the o/p is incorrect to believe these files are being written to the / partition. As a user-installed click, these will be going to the userdata partition.

[John McAleely (john.mcaleely)]

Note that the click has been removed from the store while we investigate this bug. (it was removed yesterday, but this bug was not updated then with that news)

[Jean-Baptiste Lallement (jibel)]

There are 2 issues there:
1. installing a huge click fills /tmp and installation fails, the device recovers with a reboot
2. installing a huge click can fill /userdata and the device subsequently fails to boot (bug 1600756)

[Jean-Baptiste Lallement (jibel)]

1. doesn't happen if the app is sideloaded and installed with pkcon instead of click. You can also install the libertine scope and run xapps on krillin this way if there is enough space in the user partition.

[dobey (dobey)]

@jibel But we don't use "click" to install packages from the scope either. We use pkcon install-local /path/to/downloaded.click to do the install. So either this assumption is not quite true, and both methods can fill up /tmp, or it's completely false, and something else is filling up /tmp (which is not actually disk space, but RAM as I understand, as it's a tmpfs file system).

[dobey (dobey)]

It looks like what is causing the issue with /tmp here is the signature verification unpacking the signed data to /tmp, in order to verify the signature.

I'm not sure what to do about this. It will be an issue on any device for any click of sufficient size.

[John McAleely (john.mcaleely)]

does it simply unpack the whole click to /tmp to check the signature?

If so, that's busted. There will always be less RAM than free 'disk' storage, and this will not be the last large click.

[dobey (dobey)]

I don't know the specifics of how the signatures and signature validation are implemented.

Indeed, the issue is certainly not limited to this click, and it doesn't even require a large click to be a problem, or little physical RAM. Even on a device with lots of RAM, one could have enough applications opened, or enough data cached in a directory such as /tmp or /run that is backed by RAM, to cause problems.

[dobey (dobey)]

So, it seems that it's not necessarily unpacking the data into /tmp, but is perhaps streaming it (there's a socket created in TMPDIR).

I'm not quite sure what's going on here, and I don't think I know enough about internals of click/dpkg to go any further, but it seems that even if I use TMPDIR=${XDG_CACHE_HOME} when installing a signed click package, it still uses about as much memory as the size of the package is, I can watch the /userdata usage increase, even if I already have the click installed, and the amount of disk I/O created from having so many files in a package, makes the system unusable for quite a while as it installs.

[dobey (dobey)]

OK, mvo suggested that debsig-verify had /tmp hardcoded, and that this is fixed in the newer version from xenial. However, after having built and installed it on my phone, i don't see any difference in behavior. I don't see any files getting created in TMPDIR beyond a simple domain socket, which is presumably coming from click or something else, which gets destroyed after a package is finished installing. There are no other files appearing in TMPDIR while watching it with "watch ls -la $TMPDIR" yet the "used" memory count displayed in top, seems to increase to roughly the size of the click being installed.

I don't know where this is coming from exactly, but it seems it's not actually debsig-verify that is the problem here.

[dobey (dobey)]

I've added click to this bug report now, as from what I can tell, the core issue seems to be somewhere deep in there.

[Marcel Hörz (marzel)]

I don't know, if this belongs to this bug, (If not, just comment and I will delete it ;) )
but I tried to install xserver and a vncserver on ubuntu. But this used so much space on a partition, that it was not possible to purge this, because there was no space left to load the dependencies. But I cannot say, which partition it was... :/ Hope, that can help a little bit!

[Launchpad Janitor (janitor)]

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

[kevin gunn (kgunn72)]

related to bug 1413583