@Beton If the above works for you, then please mark this post as resolved. Thanks.

@Beton OK, it should be fixed now and you shouldn't have to change anything. Just use ubports.chat as you originally were. Apologies for the loss of service.

@Beton There was a DNS issue that needed to be resolved and an upgrade has also been performed during the downtime. Please use the following workaround for the time being: for the homeserver, append :8448 to the URL. So ubports.chat:8448 instead of ubports.chat.

@Flohack All working well since. Just found another couple of logs that are still "unhandled":

- Unhandled push type:  "CHAT_MESSAGE_GIF"
- Unhandled push type:  "PINNED_TEXT"

Command to delete all of those files:

phablet@ubuntu-phablet:~$ rm ~/.cache/upstart/untrusted-helper-*

This has worked for numerous users: https://forums.ubports.com/post/13645.

I've found running these commands works more reliably from fastboot mode.

@obacht This has come up a few times in the UBports Telegram groups. The last example was only yesterday:

Tom Rhodes, [07.04.19 14:06]
Hey does anyone know why a fresh install is taking up 29.6Gb of a nexus 7 (flo)?

Tom Rhodes, [07.04.19 14:11]
[ Photo ]

Tom Rhodes, [07.04.19 14:12]
29.5 to be exact

Rodney, [07.04.19 14:14]
You had about that much space used up under Android? And didn't select wipe option in installer?

Tom Rhodes, [07.04.19 14:15]
nope i had wipe selected

Tom Rhodes, [07.04.19 14:15]
doing an erase and reset from the OS to see if it can clean up

Tom Rhodes, [07.04.19 14:17]
that seemed to work

Tom Rhodes, [07.04.19 14:18]
I now have 26Gb free

Tom Rhodes, [07.04.19 14:18]
wipe was selected on the installer, but it dropped the connection when pushing once, about halfway through, then it restarted, so maybe that might have somethign to do with it

So reinstalling with wipe selected should do the trick. If you've got any more concerns, it's probably best to join the Welcome and Install group on Telegram and ask there: https://t.me/WelcomePlus.

@lduboeuf Maybe @kugiigi can be more specific but I know he was working on this recently. Probably:

• https://github.com/kugiigi/palitan-app

Good work! We need to get @nanu-c on here to get some more comparisons...

I removed all bookmarks from all folders

@wartburgritter So you want to clear all bookmarks and start over? If so, a direct way of doing that is by deleting (or renaming) ~/.local/share/morph-browser/bookmarks.sqlite. When you reopen Morph, bookmarks will be reset to the default.

@unisuperbox Fantastic, detailed explanation -- appreciate you taking the time to go through that.

• The system-image-server does not have a diff from the image you are using to the new image (you've skipped a few updates, for example I went from devel 2018-12-21 to 2018-12-28 today and had to download the full image)

This leaves me with some food for thought since it appears that I've increased my risk of this happening by switching to the dev channel.

This is why I said that ubports-qa should disable system-image updates. After you've changed your system image, it is no longer in a known good state and may behave in unexpected ways.

Is there a simple way of testing this out in the meantime?

@wartburgritter A little more info here, a "workaround" but unfortunately no direct solution.

@circ is right about the location. To be specific, bookmarks are collected in ~/.local/share/morph-browser/bookmarks.sqlite. But that's not very useful for solving your problem.

There doesn't appear to be a way to delete or even rename a bookmark folder. Nor a method to move bookmarks between folders. Because a workaround is if all bookmarks are removed from a folder, then the folder itself is removed. Unfortunately, this would only be practical if the folder has a small number of bookmarks that you are happy to delete (by right-swiping).

Beyond this, my suggestion is opening an issue on the Morph browser repo.

One strange experience to share about extending rootfs after switching the release channel. Following the instructions above, using 6000 worked fine for the rc channel. However, after switching to the dev channel, I couldn't get this to work for that value, no matter how many times I resized and rebooted. I did manage to get other sizes to work, though. Ultimately, I settled for 6144 (6 * 1024) to get 6.0GB, i.e.:

dd if=/dev/null of=/userdata/ubuntu.img bs=1M seek=6144 count=0

Apologies to all for the mass call-outs used in this post -- I wouldn't usually do this. I've encountered a situation where extending rootfs and all subsequent customisations are lost. I'm sharing this as a warning for those who have already resized, a caveat for those considering to do so, and as a discussion point for how to move forwards.

Switching the release channel loses the extended rootfs

With hindsight, there's nothing surprising about this since the process of switching channels replaces /userdata/ubuntu.img.

@haveaniceday above:

Of course, this will probably break OTA updates...

@UniSuperBox above:

The image file can be resized, and I'm considering ways to make ubports-qa do this in case the user would prefer to use apt and turn off system-image upgrades.

I never had any issues with OTA updates, even after some fairly extensive hacking and customisations. Other than switching the channel, what other system-image upgrades could lead to this outcome?

Moving forward

@haveaniceday above:

I'll just repeat the steps for each release.

Essentially, this is all that can be done. But I managed to do some decent testing and found that this reconfiguration process can be made much easier. In my case, I made promising progress with SaltStack configuration management. Solutions involving tools such as this become viable once rootfs has been extended (in that the necessary packages can be installed). It wouldn't be too difficult to have a repo for collecting formulas that help automate this.

@vandys @arubislander @doniks Since you all appear to have gone through the resizing process, I hope you don't mind me drawing your attention to this post.

When it comes to testing on the device itself, the one thing I'd add is taking advantage of clickable --dirty.

http://clickable.bhdouglass.com/en/latest/commands.html?highlight=dirty:

A dirty build without cleaning the build dir can be achieved by running clickable --dirty.

This saves a lot of time at that stage of testing.

@hummlbach You're welcome.

The theme switcher is now available in v0.4.8 so no longer need to manually install the .click. Here's hoping that SuruDark gets more love over time.

GSettings values:

$ gsettings list-recursively com.ubuntu.touch.sound
com.ubuntu.touch.sound incoming-call-sound '/usr/share/sounds/ubuntu/ringtones/Ubuntu.ogg'
com.ubuntu.touch.sound incoming-message-sound '/usr/share/sounds/ubuntu/notifications/Rhodes.ogg'
com.ubuntu.touch.sound silent-mode false

@mymike Thanks for the additional info. Both ways are useful, since some users will be working with files via. the terminal, e.g. over SSH.

Note, received files will be available under the ~/.cache/ubtd.fourloop2002 directory.

Some caveats about this, quoting from the UBOF Telegram group:

Marius Gripsgard, [20.11.18 21:47]
[In reply to myii]
thats the old one that wraps here

Marius Gripsgard, [20.11.18 21:48]
"here maps"

Marius Gripsgard, [20.11.18 21:50]
[In reply to myii]
that has been removed, since here requre licensing

Marius Gripsgard, [20.11.18 21:52]
we are hopefully moving away from ubuntu location service and just use geoclue and qtlocation, and use the hybris platform

myii, [20.11.18 21:52]
Is it OK to use espoo in the meantime?

Marius Gripsgard, [20.11.18 21:52]
[In reply to myii]
yeah should be ok

Marius Gripsgard, [20.11.18 21:53]
[In reply to myii]
that will just use gps though, no agps support

Key points:

1. espoo uses HERE Maps, which requires licensing
2. Lacks AGPS