Update: UBports CI now spits out a recovery ramdisk for Halium 10.0 and up. Select your Halium generation and download the ramdisk here: https://ci.ubports.com/job/UBportsCommunityPortsJenkinsCI/job/ubports%252Fporting%252Fcommunity-ports%252Fjenkins-ci%252Fgeneric_arm64/

Good news: Now that Ubuntu Touch 24.04-1.2 is out, you are able to install Docker without --devmode!

Kernel 4.19 has an opportunity to receive fscrypt v2 support by backporting it as per docs: https://docs.ubports.com/en/latest/porting/configure_test_fix/Fscrypt.html

You can ask your port maintainer to do that.

@pdgf Building a UBports recovery for the stand-alone porting method requires a ramdisk-recovery.img file to be placed in the device tree's root directory. Currently one has to fetch it from a different device tree in GitLab, but I've proposed changes so that it's available as an artifact on our Jenkins CI instance. Will update this once the recovery ramdisk is downloadable from Jenkins.

@glowingscrwdrvr if encryption has been set up (presumably by Android?) for subdirectories only, then this should work. File-based encryption (ext4 & f2fs) works on a per-directory basis. But I would first confirm that this is the case.

I have pushed 4.19.265 to the repos, daily images should pick it up any moment now.

We're getting closer!

Best you can do is update to the daily channel of your current baseline Ubuntu Touch version, and not update it for a while. It would have been to risky including the workaround that late in the release process. But yeah, the problem has been identified as being partially caused by opportunistic auto suspend of the phone.

Good news, the xtables-enabled Docker Snap is now available in the edge channel. I've updated the How to section with the new install commands. If you want to refresh: sudo snap refresh docker --edge --devmode

@fair For the Fairphone 5 I've implemented something which should help you, it's available in latest daily channels. The change is here: https://gitlab.com/ubports/porting/reference-device-ports/android11/fairphone-5/fairphone-fp5/-/commit/13884b434abf95f643f41f04c62b22e73be9fe1c

What it does is keep the device awake once Waydroid starts. That means it won't opportunistically autosuspend anymore while Waydroid is running.

For those wanting to try clickable with the new docker snap, or wanting to build other images on your devices, I noticed a serious performance hit in creating clickable images with the new Docker 29.0.0 which is due to the containerd-snapshotter feature. You can disable it easily though, restoring snapshot creation to a previous codepath. You'll just have to edit your /var/snap/docker/current/config/daemon.json configuration:

$ cat /var/snap/docker/current/config/daemon.json
{
    "log-level":        "error",
    "features": {
        "containerd-snapshotter": false
    }
}

Make sure to restart your Docker daemon afterwards: sudo snap restart docker

@projectmoon overlayfs not being available is a kernel problem, for which you should contact your device maintainer.

Hello again.

Some things happened since I posted the original post above. I've gone ahead and added automatic detection for xtables vs nftables to the Docker Snap, which was received quite positively by the maintainers. Here's the PR for those who are interested: https://github.com/canonical/docker-snap/pull/329

You can install the Snap via:

sudo snap install docker --channel=edge/pr-329

If you've already installed the test package from the Downloads link above, you will have to instead run:

sudo snap refresh docker --channel=edge/pr-329 --amend

When this lands it will first land in the edge channel before promotion to a more "stable" channel, so keep that in mind once you see the PR merged.

@nparafe That device's kernel is too old for using cgroupv2 and eBPF to mediate device access, it's advised in the port to set the kernel cmdline systemd.unified_cgroup_hierarchy=0 and recompile the kernel image. Please tell your device maintainer about this.

@uxes IIRC with fscrypt in place, just replacing shadow breaks the protectors of fscrypt, leaving the system with a broken state. Also that's the dog biting it's tail: decrypting based on the password while the file containing the password is locked, that doesn't work.

Regarding bluez data: that would break bluetooth at the greeter, which might be required for some usecases.

@ikoz Encrypting apps would prevent tampering with executables and replacing them with malicious ones by evil actors.

I want to start a discussion about encrypting more data stored in the /userdata partition, for extra security/paranoia.

Right now we have /home/phablet encrypted when done so via system-settings, but there's room for improvement. I would like to also encrypt:

• Wifi settings
• Apps
• Potentially more which I don't see yet

For apps I have created a script which does the encryption in an easy-to-follow manner. This will require a device with policy version 2 support. It's available here: https://gist.github.com/fredldotme/696ab1e22bec4ed296caee471aa89a87

ATTENTION: Don't try to force the script to run on a system which only supports v1 policies, this will break app installation and uninstallation.

The script keeps the unencrypted original in /userdata/system-data/opt/click.ubuntu.com-bak which you will have to remove manually after rebooting.

Encrypting data which is usually accessed by non-phablet users will require v2 policy suppport, so keep that in mind when coming up with ideas.

Any input?

I've updated the kernel to 4.19.242 now locally, will test further and merge this ASAP.

Some hours, 4 cans of XL energy drink, and some patience later and I upgraded the kernel to 4.19.198. That's 41 patch versions fresher than before!

I will do these updates in stages. First I'll update until I feel comfortable with it, test it for a day, then merge it into the release branch. Also I've been able to catch some discrepancies I wouldn't have been able to catch otherwise if I just merged the latest upstream git into our kernel. Leaves me some peace of mind.

Hello there!

I am using the Fairphone 4 as my daily driver at the moment, and I want to ensure good security of the device. Henceforth I am updating the kernel from 4.19.157 to the last stable release 4.19.325 from December 2024. While no major update this will ensure added patches to known CVEs.

Please be aware that this is a tedious process, taking incremental patches from upstream kernel.org, applying them, checking conflicts, building them and testing them on the device. It will take some time until we reach 4.19.325, so please be patient.

If you think that's a worthwhile thing to do, please leave a donation (I could really need it). Links below in my signature.

@gpatel-fr I agree your approach using overlayfs is better, puts the file in the same place we would regularly put our customizations.