Install postmarketOS on Android phone and use Docker as a home server(crackoverflow.com)
crackoverflow.com
Install postmarketOS on Android phone and use Docker as a home server
https://crackoverflow.com/docs/system_administration/containerization/install-docker-natively-on-android-phone-and-use-it-as-a-home-server/
119 comments
> Then yes, you have a regular Linux (although based on musl, instead of usual glibc) on which you can install Docker.
The OnePlus 6/6T are also supported by Mobian [0], which is just regular glibc-and-systemd based Debian, and so a pretty familiar Linux server experience.
> it might indeed be a good idea to avoid Android
It's a good idea to avoid Android because of kernel security as well. Old Android devices always use out of date Linux kernels even when using custom ROMs, and when running (containerized) network services you really depend on the security of your Linux kernel to keep those things properly isolated. Both PostmarketOS and Mobian do bring current mainline Linux support to these devices, so you can be quite a bit more confident in your kernel that way.
It's a shame PostmarketOS and Mobian don't really support many newer devices well. Last I checked the OnePlus 6(T) were still the highest performance devices that had okay support. The Snapdragon 845 - a 2018 flagship SoC - in the Oneplus 6/6T made them real high performance device to repurpose for a long time. In 2024 though it's now beaten in performance by the Raspberry Pi 5 or RK3588 based Armbian based devices. Those SBCs of course already have much better I/O and more straightforward ways to get a supported Linux running on them (and don't require disconnecting the battery with custom soldering). So you need to be really committed to reusing your old hardware to go down this route.
[0]: https://wiki.debian.org/Mobian/Devices
The OnePlus 6/6T are also supported by Mobian [0], which is just regular glibc-and-systemd based Debian, and so a pretty familiar Linux server experience.
> it might indeed be a good idea to avoid Android
It's a good idea to avoid Android because of kernel security as well. Old Android devices always use out of date Linux kernels even when using custom ROMs, and when running (containerized) network services you really depend on the security of your Linux kernel to keep those things properly isolated. Both PostmarketOS and Mobian do bring current mainline Linux support to these devices, so you can be quite a bit more confident in your kernel that way.
It's a shame PostmarketOS and Mobian don't really support many newer devices well. Last I checked the OnePlus 6(T) were still the highest performance devices that had okay support. The Snapdragon 845 - a 2018 flagship SoC - in the Oneplus 6/6T made them real high performance device to repurpose for a long time. In 2024 though it's now beaten in performance by the Raspberry Pi 5 or RK3588 based Armbian based devices. Those SBCs of course already have much better I/O and more straightforward ways to get a supported Linux running on them (and don't require disconnecting the battery with custom soldering). So you need to be really committed to reusing your old hardware to go down this route.
[0]: https://wiki.debian.org/Mobian/Devices
> It's a good idea to avoid Android because of kernel security as well.
Well it's "just" a matter of updating the kernel, right? Those linux projects like PostmarketOS do a lot of mainlining, which benefits custom Android ROMs.
I agree that if the goal is to use the device as an RPi, then it's better to avoid Android. But I wouldn't say that Android is less secure than Linux in general (on the contrary, Android has an interesting security model).
Well it's "just" a matter of updating the kernel, right? Those linux projects like PostmarketOS do a lot of mainlining, which benefits custom Android ROMs.
I agree that if the goal is to use the device as an RPi, then it's better to avoid Android. But I wouldn't say that Android is less secure than Linux in general (on the contrary, Android has an interesting security model).
It's not "just" the kernel. The bigger issue is the firmware - Android devices have a ton of closed-source low-level firmware bits, and you really shouldn't expose them to the Internet after the device has reached end-of-support.
But if you're only using it for limited projects as an RPi replacement, then it's probably alright if you're also putting a firewall in front of it, or having it in an isolated network segment with a reverse proxy.
But if you're only using it for limited projects as an RPi replacement, then it's probably alright if you're also putting a firewall in front of it, or having it in an isolated network segment with a reverse proxy.
> Android devices have a ton of closed-source low-level firmware bits
Can you elaborate on that? You seem to be suggesting that there are low-level firmwares on Android devices that are exposed to the Internet and do not receive updates. Which ones? And do they receive updates with Linux on mobile OSes? And if yes, why couldn't alternative AOSP-based systems use those firmware updates?
Can you elaborate on that? You seem to be suggesting that there are low-level firmwares on Android devices that are exposed to the Internet and do not receive updates. Which ones? And do they receive updates with Linux on mobile OSes? And if yes, why couldn't alternative AOSP-based systems use those firmware updates?
The important ones - from a security and privacy standpoint - are the baseband (cellular stack), WiFi, Bluetooth, NFC, camera, mic, bootloader and the Trusted Execution Environment. Then there's also minor firmware bits for the sensor hub (accelerometer, ambient light sensor etc), touch controller, audio etc.
You can imagine the consequence if there was a vulnerability in say the WiFi firmware or the microphone. The Bluetooth stack is especially vulnerable, with it being an attack vector many times in the past.
On Android devices, only Android has been able to deliver updates to those firmware blobs. This is mainly because these are closed source binary blobs, and are provided by the OEM (often in conjunction with the respective chipset manufacturer, covered by a license agreement).
AOSP and unofficial Linux based OSes like PostmarketOS do not have a license to obtain and distribute these firmware. But even if they did, it means nothing if the support agreement from the chipset maker has ended. Being closed source bits, you can't do anything about it if the respective manufacturer refuses to provide updated firmware.
Ocassionally, some Android custom ROM makers may extract these blobs from more recent devices having the same chipset but running newer firmware, and of course, it doesn't always work (well), not to mention, it's technically illegal. And of course, an official project like PostmarketOS or LineageOS would never do something like redistribute proprietary firmware bits. Projects like these conveniently ignore the firmware issue, and leave it as an exercise for the end user.
You can imagine the consequence if there was a vulnerability in say the WiFi firmware or the microphone. The Bluetooth stack is especially vulnerable, with it being an attack vector many times in the past.
On Android devices, only Android has been able to deliver updates to those firmware blobs. This is mainly because these are closed source binary blobs, and are provided by the OEM (often in conjunction with the respective chipset manufacturer, covered by a license agreement).
AOSP and unofficial Linux based OSes like PostmarketOS do not have a license to obtain and distribute these firmware. But even if they did, it means nothing if the support agreement from the chipset maker has ended. Being closed source bits, you can't do anything about it if the respective manufacturer refuses to provide updated firmware.
Ocassionally, some Android custom ROM makers may extract these blobs from more recent devices having the same chipset but running newer firmware, and of course, it doesn't always work (well), not to mention, it's technically illegal. And of course, an official project like PostmarketOS or LineageOS would never do something like redistribute proprietary firmware bits. Projects like these conveniently ignore the firmware issue, and leave it as an exercise for the end user.
Thanks for the insights, that's super interesting!
> (on the contrary, Android has an interesting security model).
Which doesn't really apply to a server use case, does is?
Which doesn't really apply to a server use case, does is?
You can run these commands to turn that kill behavior off:
setprop persist.sys.fflag.override.settings_enable_monitor_phantom_procs false
/system/bin/settings put global settings_enable_monitor_phantom_procs false
Termux as an example supports several services that run forever. Works great, sshd and crond don't get killed for example. https://wiki.termux.com/wiki/Termux-services
Battery wise you can use this app to keep it in a healthy range and temperature indefinitely: https://github.com/VR-25/acc
setprop persist.sys.fflag.override.settings_enable_monitor_phantom_procs false
/system/bin/settings put global settings_enable_monitor_phantom_procs false
Termux as an example supports several services that run forever. Works great, sshd and crond don't get killed for example. https://wiki.termux.com/wiki/Termux-services
Battery wise you can use this app to keep it in a healthy range and temperature indefinitely: https://github.com/VR-25/acc
For having a sshd server on my phone I do really like this magisk module https://gitlab.com/d4rcm4rc/MagiskSSH
This let me ssh into the real android instead of inside termux, which might be preferable depending on the use case
This let me ssh into the real android instead of inside termux, which might be preferable depending on the use case
10 years ago I worked at a company which had a fleet of phones to test mobile browser games we were making and the batteries were in noticeably worse shape after a few months of near constant use.
Nowadays in most phones you can limit charging to e.g. 80%, which is much lighter on the battery.
Additionally, the battery works as a heat sink (or heat store really considering it's just a solid slab of dense material) so expect more throttling when it's not there.
Nowadays in most phones you can limit charging to e.g. 80%, which is much lighter on the battery.
Additionally, the battery works as a heat sink (or heat store really considering it's just a solid slab of dense material) so expect more throttling when it's not there.
If you have an old phone that would otherwise go to garbage, likely its battery is not in a great shape anyway, and server-like loads are mostly incompatible with being battery-powered. I suppose it's going to be permanently attached to a USB power source.
Thanks for the heads-up about the thermal inertia of the battery! Maybe a stationary phone in the server role could use a glue-on passive radiator.
Thanks for the heads-up about the thermal inertia of the battery! Maybe a stationary phone in the server role could use a glue-on passive radiator.
The problem isn’t the performance of the battery but the safety. A dead battery for this always-connected use case is probably a non-issue. A swollen battery that could explode or catch fire is definitely an issue.
You could take it out but many phones won’t work without a battery so you need to find a way to trick them into thinking one is installed.
You could take it out but many phones won’t work without a battery so you need to find a way to trick them into thinking one is installed.
> (although based on musl, instead of usual glibc)
For those who never used musl and Alpine Linux (which PostmarketOS is based on), the list of supported architectures and software ported over is quite large; here's a list:
https://pkgs.alpinelinux.org/packages
Alpine is my distro of choice for very small systems and VMs once I make sure there are no compatibility issues with what I need to install/build, which can happen sometimes but is really rare. The amount of saved resources (CPU, storage) is significant, making it ideal for VMs.
For those who never used musl and Alpine Linux (which PostmarketOS is based on), the list of supported architectures and software ported over is quite large; here's a list:
https://pkgs.alpinelinux.org/packages
Alpine is my distro of choice for very small systems and VMs once I make sure there are no compatibility issues with what I need to install/build, which can happen sometimes but is really rare. The amount of saved resources (CPU, storage) is significant, making it ideal for VMs.
the main issue i see is musl: they have an history of not acknowledging bugs and disregarding standards
last big issue i remember is they not implementing fallback-on-tcp when getting large dns record replies, so some dns record resolution would fail. the standard clearly says to switch to tcp under certain conditions, but they did not.
the bug was reproduced and reported, they refused to acknowledge it and kept the issue for a lot of people for a long time (at least one year iirc). they eventually relented and and implemented the correct behaviour.
call glibc what you want, but at least they don't have such dumb issues and that attitude.
last big issue i remember is they not implementing fallback-on-tcp when getting large dns record replies, so some dns record resolution would fail. the standard clearly says to switch to tcp under certain conditions, but they did not.
the bug was reproduced and reported, they refused to acknowledge it and kept the issue for a lot of people for a long time (at least one year iirc). they eventually relented and and implemented the correct behaviour.
call glibc what you want, but at least they don't have such dumb issues and that attitude.
Is it just that one example? And the situation now is they "relented"?
call glibc what you want, but at least they don't have such dumb issues and that attitude.
I... Don't know what to say. You really can't think of one decision that the glibc maintainers have made that caused a lot of pain for users? Pretty sure the musl author has/had a blog post full of them. You don't write c library for no reason at all.
call glibc what you want, but at least they don't have such dumb issues and that attitude.
I... Don't know what to say. You really can't think of one decision that the glibc maintainers have made that caused a lot of pain for users? Pretty sure the musl author has/had a blog post full of them. You don't write c library for no reason at all.
You can always install incus and glibc. Went with musl for voidlinux, and for using certain appimage, I needed to have glibc. It was seemless to install incus, a debian image, and you have unlimited deb packages at your disposal.
> The amount of saved resources (CPU, storage) is significant, making it ideal for VMs.
Depends on the workload. Running anything which relies on C libraries under the hood is a minefield. E.g. Python's C libraries are often not compiled for musl, so each Python package installation requires compilation.
Depends on the workload. Running anything which relies on C libraries under the hood is a minefield. E.g. Python's C libraries are often not compiled for musl, so each Python package installation requires compilation.
I've heard that it's a terrible idea with the battery still in. Curious why this is a non-issue for a UPS -- is it the scale, type of battery (lithium ion vs lifepo4), quality, charge cycle, a bit of all of the above?
UPSs still typically use lead acid batteries. These don't particularly mind being at ~100% SoC for years at a time (they like staying charged), which is very good for this application.
And it's easy to keep them at around 100%. For instance: For a nominal 12v battery, one can very nearly just feed it 13.8v (plus or minus some temperature compensation) and have results that are actually pretty good and close-enough to 100%.
And when things go very wrong, lead acid batteries tend not to catch on fire.
It's a natural fit for UPS duty.
The lithium batteries in cell phones are a different thing. They hate being at 100% SoC and degrade fairly quickly in that state.
They can be pretty happy at around 50% SoC, but it's hard to actually keep them there because of the way the voltage ramps [don't] work with lithium chemistries: It's almost flat through the middle of the curve.
And cell phones don't let us do that anyway: It'd be great if there was a "Compute mode: Just do your best to keep this battery near 50%" setting to click on, but there is not. (And we could hack that in, except: We don't own our phones.)
And when things go wrong, they can become exothermic in ways that are not exactly ideal for an unattended device sitting on a shelf.
And it's easy to keep them at around 100%. For instance: For a nominal 12v battery, one can very nearly just feed it 13.8v (plus or minus some temperature compensation) and have results that are actually pretty good and close-enough to 100%.
And when things go very wrong, lead acid batteries tend not to catch on fire.
It's a natural fit for UPS duty.
The lithium batteries in cell phones are a different thing. They hate being at 100% SoC and degrade fairly quickly in that state.
They can be pretty happy at around 50% SoC, but it's hard to actually keep them there because of the way the voltage ramps [don't] work with lithium chemistries: It's almost flat through the middle of the curve.
And cell phones don't let us do that anyway: It'd be great if there was a "Compute mode: Just do your best to keep this battery near 50%" setting to click on, but there is not. (And we could hack that in, except: We don't own our phones.)
And when things go wrong, they can become exothermic in ways that are not exactly ideal for an unattended device sitting on a shelf.
I use a chargie device which is a hardware level charge limiter
Cute. I didn't know those existed, and they do make sense.
It's only solving part of the problem though: Sure, it can keep the charge at around a self-reported 50%. But the device itself doesn't necessarily have a good idea of what 50% even means, especially as the months and years tick by and cells age, unless it is allowed go closer to the extremes (closer to 0 and closer to 100, sometimes).
The reasons for this get weird. Near the edges of the curves (0 and 100), the BMS can use voltages to figure out where things are. This works well.
In the middle of the curve, voltages are damn near flat and cease to be an indicator of state-of-charge, so the BMS counts coulombs instead. This works too (for awhile).
Except they're not ideal batteries. They age even if they're not being used at all, and shit happens just as it does for any other non-ideal entity. So on a long-enough timeline, even a perfect coulomb counter doesn't necessarily have any way to accurately report state of charge.
The way that this problem is dealt with on a phone that actually gets used like phones get used is that the BMS can reset the coulomb counter during the peaks and dips of a normal charge cycle, based on voltage.
But charge cycling doesn't happen even with a Chargie-equipped phone sitting on a shelf and running Docker containers, does it?
It's only solving part of the problem though: Sure, it can keep the charge at around a self-reported 50%. But the device itself doesn't necessarily have a good idea of what 50% even means, especially as the months and years tick by and cells age, unless it is allowed go closer to the extremes (closer to 0 and closer to 100, sometimes).
The reasons for this get weird. Near the edges of the curves (0 and 100), the BMS can use voltages to figure out where things are. This works well.
In the middle of the curve, voltages are damn near flat and cease to be an indicator of state-of-charge, so the BMS counts coulombs instead. This works too (for awhile).
Except they're not ideal batteries. They age even if they're not being used at all, and shit happens just as it does for any other non-ideal entity. So on a long-enough timeline, even a perfect coulomb counter doesn't necessarily have any way to accurately report state of charge.
The way that this problem is dealt with on a phone that actually gets used like phones get used is that the BMS can reset the coulomb counter during the peaks and dips of a normal charge cycle, based on voltage.
But charge cycling doesn't happen even with a Chargie-equipped phone sitting on a shelf and running Docker containers, does it?
You can add custom charge cycling on a schedule if using the Chargie app. One could for example have it normally stay at 50% but do a full charge/discharge cycle weekly.
Overall though, it would probably make the most sense to physically remove the battery from any phone used as a dedicated webserver, and then have it connected to an external UPS instead.
Overall though, it would probably make the most sense to physically remove the battery from any phone used as a dedicated webserver, and then have it connected to an external UPS instead.
Also cute. That's pretty excellent. I think I'd like to bring such a rig down to 10% and up to 90% once a month or so, based on what I think I know.
And yes, agreed absolutely: It safer to pull the battery, and not particularly difficult or detrimental to do so for the kinds of applications I'm envisioning here that involve a disused phone doing server-ish stuff.
And yes, agreed absolutely: It safer to pull the battery, and not particularly difficult or detrimental to do so for the kinds of applications I'm envisioning here that involve a disused phone doing server-ish stuff.
Put a wall plug timer on it, charge it 50% of the time.
You should definitely add a /s lest anybody take this seriously. It's quite funny though. Especially recommended if you're hoping to burn your house down.
For people that didn't know, this is probably the fastest and riskiest way to destroy your battery quickly
For people that didn't know, this is probably the fastest and riskiest way to destroy your battery quickly
No.
If you're going to do this be sure you swap between charging and discharging as often as possible, go as low as your timer will allow. 30 minutes charging, 30 minutes discharging should allow you to reach house fire in less than a month.
Like your comments.
Question. How does a BMS count coulombs?
I mean what is the technology used?
Q = ∫idt, so you just need something that regularly samples the current (typically measured via a shunt resistor) and accumulates it over time. This is typically done by a dedicated low power chip with an integrated differential amplifier for reading out the sense resistor, ADC, and nonvolatile memory - these are often referred to as "gas gauge" chips. This functionality can also be found on higher end all-in-one battery management chips.
Great. Thanks.
I think some devices can now be configured to just charge partially (or come that way by default and then tell you that the partial charge is 100%). So this may not be a an issue in all cases, but...
I dedicated an Nvidia shield K1 to be a Sonos interface. Just mounted it to a monitor arm and left it plugged in for something like four years. The mount was this beefy metal thing, a little steel cage for the tablet, but as soon as I unscrewed it enough to remove the tablet from the mount the tablet undramatically exploded. It ballooned to a width that was thrice the original thickness of the tablet, pushed the plastic apart, and it was clear that the case was never going to come back together again. I was afraid to touch it, lest it rupture.
It seems like it would only be a terrible idea beyond a certain scale. The pillowing battery is just assisted disassembly. And now it's easy to get the battery out.
I dedicated an Nvidia shield K1 to be a Sonos interface. Just mounted it to a monitor arm and left it plugged in for something like four years. The mount was this beefy metal thing, a little steel cage for the tablet, but as soon as I unscrewed it enough to remove the tablet from the mount the tablet undramatically exploded. It ballooned to a width that was thrice the original thickness of the tablet, pushed the plastic apart, and it was clear that the case was never going to come back together again. I was afraid to touch it, lest it rupture.
It seems like it would only be a terrible idea beyond a certain scale. The pillowing battery is just assisted disassembly. And now it's easy to get the battery out.
Well, surprisingly. You actually need to swap the battery in UPS about every 3 years. Or the monitor feature in UPS is going to complain _loudly_.(I have one broken a few months ago) So there is not much difference here.
Although swapping battery of ups is surprisingly easy. Buy a new one from online store with a few dollar. Disconnect the connection to old battery.(a REALLY important step). Remove old one. Slap the new one in. Connect the wire. And pre-charge it for a few hours. Then it can just go back online like a new one.
Although swapping battery of ups is surprisingly easy. Buy a new one from online store with a few dollar. Disconnect the connection to old battery.(a REALLY important step). Remove old one. Slap the new one in. Connect the wire. And pre-charge it for a few hours. Then it can just go back online like a new one.
It’s not a non-issue. UPS batteries have a rather short lifespan.
That's surprising. My laptop battery is like 10 years old and still fine. Light usage and mild storage conditions. Surely UPS batteries are similar.
My UPS manual says 3 years. They have a different chemistry than phone batteries. On the other side, they should be quite similar to car batteries which could live much longer that 3 years, but they spend most of their time waiting in a parking slot and then a few starts per day or less. An UPS doesn't work like that.
A good UPS will perform regular load tests to gauge battery performance/degradation. They switch over to battery power around once a week and measure voltage before, during, and after. So even if the power goes out, they are still being exercised _somewhat_.
Can you link to one of these on Amazon or your preferred vendor which you recommend for home office use?
Eaton Ellipse Pro is great.
UPS batteries tend to have lead acid batteries, and the lifespan on those is generally between 3-5 years. Lithium batteries in laptops _can_ last quite a bit longer if made well and under the right care.
[deleted]
Really? I plugged my old phone some days ago and set up a ssh daemon on it, just to see if it stays connected. Should I be worried?
Yes, it's potentially hazardous in the long run. You can hope that it only kills the battery fast, and that it doesn't make it swell or something.
(absolutely not an expert, though, this is why I asked for experiences :-))
(absolutely not an expert, though, this is why I asked for experiences :-))
It usually take a few years for the battery to swell, but it will happen. I have a phone as GSM modem to send and recieve SMS for automatic tasks. I've had 3/3 batteries on two different phones swell so far.
This post links to a previous post from the same author concerning removing the battery and running the device without one:
https://crackoverflow.com/docs/system_administration/contain...
Ah, nice. I had skimmed the article and didn't read the intro. This is pretty cool.
I could be interested in using my PinePhone like this. Its battery is removable and the phone can be started without it, but the Wi-Fi / Bluetooth module won't run without it. I had the idea of faking the battery like this, but I don't have the skills to handle hardware like this.
I could be interested in using my PinePhone like this. Its battery is removable and the phone can be started without it, but the Wi-Fi / Bluetooth module won't run without it. I had the idea of faking the battery like this, but I don't have the skills to handle hardware like this.
You could just plug the phone into a small usb-c hub and plug some usb wifi dongel or ethernet cord into it. Not sure if that would solve your use case.
Yep, it could work, and I happen to have such a hub (it came with the PinePhone). I think the PinePhone is able to receive power AND do USB OTG at the same time, to be confirmed.
To be completely honest, what I had in mind was to use it as a Bluetooth receiver to play music using my dumb speakers. I don't have a Bluetooth receiver and at this point if I have to buy something I might be better off buying some off the shelf device to do this. So the status quo is to just plug a laptop the times I want to play music in this room because I don't care that much about it.
To be completely honest, what I had in mind was to use it as a Bluetooth receiver to play music using my dumb speakers. I don't have a Bluetooth receiver and at this point if I have to buy something I might be better off buying some off the shelf device to do this. So the status quo is to just plug a laptop the times I want to play music in this room because I don't care that much about it.
With the upcoming Android 16 Terminal VM powered by the Android Virtualisation Framework (AVF), it should also be possible to run Docker in an Aarch64 Debian VM similar to WSL2 or ChromeOS crostini.
However, this may still be constrained by OEMs restricting access to AVF or by battery enhancements that make it virtually unusable.
However, this may still be constrained by OEMs restricting access to AVF or by battery enhancements that make it virtually unusable.
This is one of the things that may make me serious consider another Android tablet (especially one with a nice keyboard+touchpad accessory connected via e.g.: Pogo pins). It would definitely be a game changer, and a high-end Android device could completely replace my current hybrid Chromebook.
Isn't google merging chromeOS and android anyways?
How close would this be to native performance? Will it use any hardware features to reduce the emulation overhead if both the host and the guest use the same architecture?
how aggressive the OOM killer can be with background apps
This drives me nuts.
This drives me nuts.
[deleted]
Had very old android phone (redmi go) with sim running 24/7 to forward sms OTPs for a month or two
Sms forwarder app + tailscale on phone, python script on server that forwarded incoming sms to telegram bot (probably could use webhook to avoid this step though). Worked perfectly with 100% uptime
Sms forwarder app + tailscale on phone, python script on server that forwarded incoming sms to telegram bot (probably could use webhook to avoid this step though). Worked perfectly with 100% uptime
Ok, we changed the title in the hope of making that clearer.
I guess the idea is that you'd do this with an old phone and already-dying battery. It's like having a small raspberry pi style server + builtin UPS.
You have to play by Android rules. If you start your daemons from an app that runs a foreground service, I believe this protection would spread to the app's child processes too. Or if you root your phone, you can bypass the activity manager entirely.
>I thought it was about installing Docker on Android, but it's about installing postmarketOS on a phone.
That makes the whole thing a lot less interesting. Install linux on a small computer and do linux stuff with it probably wouldn't get clicks.
That makes the whole thing a lot less interesting. Install linux on a small computer and do linux stuff with it probably wouldn't get clicks.
It could be about reusing hardware that would otherwise sleep forever in a drawer. This would be commendable.
Removing the battery is ok
For those looking for cheap portable servers, the majority of the Motorola G series phones with Android 14 including models under 120 USD have a battery charge limiter down to 60% adjustable.
At 60%, the battery will drop to 45% percent before recharging to the specified percentage for coulomb counter drift compensation.
Most lithium UPS avoid this by using LiFePO4.
Moto G04 with 128GB Storage (UFS - 400MB/s read/write), 4GB RAM and 2TB capable SDcard UHS-I slot is just 90 USD.
ZRAM is enabled by default at 2GB and 2GB storage swap, it's adjustable under "RAM boost" setting.
Disabling the app background killer is one toggle away for Termux.
No root required.
Wi-Fi does around 350Mbit with no buffer bloat, and supports simulatenous softAP and station mode with a dedicated DHCP by enabling hotspot without mobile data. This is useful for out of band management, e.g if Wi-Fi AP goes down, there is a small hiccup though.
You can combine Speedify and Tailscale (for NAT) to have 99% uptime with seamless failover since there is a mobile modem in there. ;)
The Type-C port is dual role and will charge from a powered hub in host mode. However connected devices power is disrupted for a split second if the charger is removed, so the phone isn't really a UPS for external peripherals unless you don't mind the brief reconnection.
I do hope a Pi A+ or something similar and popular exist in the future at a reasonable price, considering that we have phones that are cheaper than the Pis while missing GPIO but adding camera, speaker, screen, case, charger, LTE, and a headphone jack which was also removed on the Pi 5 (USB DACs aren't consistent with pipewire).
Mini PCs vary and they aren't really portable, hard to setup headless, especially projects utilizing an easy DIY approach like the Pi-hole or kit/pre-flashed SDcards.
For comments comparing a new Pi with used PC: used Pis exist and are a lot cheaper after shortage.
At 60%, the battery will drop to 45% percent before recharging to the specified percentage for coulomb counter drift compensation.
Most lithium UPS avoid this by using LiFePO4.
Moto G04 with 128GB Storage (UFS - 400MB/s read/write), 4GB RAM and 2TB capable SDcard UHS-I slot is just 90 USD.
ZRAM is enabled by default at 2GB and 2GB storage swap, it's adjustable under "RAM boost" setting.
Disabling the app background killer is one toggle away for Termux.
No root required.
Wi-Fi does around 350Mbit with no buffer bloat, and supports simulatenous softAP and station mode with a dedicated DHCP by enabling hotspot without mobile data. This is useful for out of band management, e.g if Wi-Fi AP goes down, there is a small hiccup though.
You can combine Speedify and Tailscale (for NAT) to have 99% uptime with seamless failover since there is a mobile modem in there. ;)
The Type-C port is dual role and will charge from a powered hub in host mode. However connected devices power is disrupted for a split second if the charger is removed, so the phone isn't really a UPS for external peripherals unless you don't mind the brief reconnection.
I do hope a Pi A+ or something similar and popular exist in the future at a reasonable price, considering that we have phones that are cheaper than the Pis while missing GPIO but adding camera, speaker, screen, case, charger, LTE, and a headphone jack which was also removed on the Pi 5 (USB DACs aren't consistent with pipewire).
Mini PCs vary and they aren't really portable, hard to setup headless, especially projects utilizing an easy DIY approach like the Pi-hole or kit/pre-flashed SDcards.
For comments comparing a new Pi with used PC: used Pis exist and are a lot cheaper after shortage.
There is a Russian meme that instantly comes to my mind: https://images.fineartamerica.com/images-medium-large-5/brea...
The translation: “With the help of simple tools, a loaf of white (or rye) bread can be turned into a trolleybus…
But WHY?!”
The label on the wrench says: “Skillful hands.”
The translation: “With the help of simple tools, a loaf of white (or rye) bread can be turned into a trolleybus…
But WHY?!”
The label on the wrench says: “Skillful hands.”
I mean, in this case I can actually think of two reasons.
1) A lot of people, particularly people who would be in the mindset to install PostmarketOS, probably have an old Android phone lying around, or at least know someone who has a phone they'd give up for free because it's currently living in a desk drawer or something. This means you can get a home server for free. Android phones aren't exactly the fastest thing in the world, but they're probably fast enough for a lot of servery things, and even a relatively small 128GB internal disk can still stream a fair number of movies if they're generously compressed with H264 or something.
2) Power consumption. My phone charger that I'm using right now peaks at 20W, and idles at considerably less than that when the phone is fully charged. That's getting into "guilt-free" territory; you can leave this plugged in and not really have to worry about your bill spiking as a result.
1) A lot of people, particularly people who would be in the mindset to install PostmarketOS, probably have an old Android phone lying around, or at least know someone who has a phone they'd give up for free because it's currently living in a desk drawer or something. This means you can get a home server for free. Android phones aren't exactly the fastest thing in the world, but they're probably fast enough for a lot of servery things, and even a relatively small 128GB internal disk can still stream a fair number of movies if they're generously compressed with H264 or something.
2) Power consumption. My phone charger that I'm using right now peaks at 20W, and idles at considerably less than that when the phone is fully charged. That's getting into "guilt-free" territory; you can leave this plugged in and not really have to worry about your bill spiking as a result.
This is silly. It's quite simple to install Docker on any stock Android using Termux.
https://github.com/cyberkernelofficial/docker-in-termux
I've done it successfully a few times and it works just fine.
https://github.com/cyberkernelofficial/docker-in-termux
I've done it successfully a few times and it works just fine.
Termux is an option but using pmOS is far from silly.
Android and Termux have their limitations. Granted, I was running a full KDE session in Termux on a 2016 phone, but I saw Android OOM-kill random processes in Termux. You probably don't have a swap partition on your Android phone. Android apps are designed to be killed when in background, and Android avoids killing the app at the foreground, but Android doesn't know some processes running in Termux shouldn't be killed. This could happen if something on your server suddenly uses more RAM than anticipated.
On a regular Linux distro, you can have a swap file and/or teach the OOM to not kill some critically important services, like ssh for instance.
Android and Termux have their limitations. Granted, I was running a full KDE session in Termux on a 2016 phone, but I saw Android OOM-kill random processes in Termux. You probably don't have a swap partition on your Android phone. Android apps are designed to be killed when in background, and Android avoids killing the app at the foreground, but Android doesn't know some processes running in Termux shouldn't be killed. This could happen if something on your server suddenly uses more RAM than anticipated.
On a regular Linux distro, you can have a swap file and/or teach the OOM to not kill some critically important services, like ssh for instance.
This is for running inside qemu, the OP says "Install Docker Natively", I don't think it's silly, not really the same thing
Considering that part of the point is being able to use end-of-life devices, it's doing this in Termux that would be silly, don't run an OS which isn't getting security patches.
This is barely related to the article but what is the status of Linux phone operating systems? Last time I used one, you could make calls and that was more or less it.
Everytime someone mentions linux on mobile, I mourn the death of Maemo.
The Nokia N900 was an incredible phone, and having a native linux command line and package manager on it felt like the future to me. Shame the industry went in completely the opposite direction.
For having used a PinePhone for a year as a main phone, I would say that the biggest limiting factor for me is the hardware. I want something reliable that has good autonomy and good and reliable call quality. I would not want the phone to leave me behind in an emergency for instance.
But the PinePhone is none of this: terrible phone quality, the modem on my device is unreliable, the autonomy is okayish. I also had a PinePhone Pro that died: big improvement except the autonomy was much worse and it would strongly eat. I believe that's what killed it, actually.
With good hardware, I would be happy with a Linux mobile OS. But I don't use WhatsApp, I don't have a banking app, I don't pay with my phone, and have no proprietary app in general.
Things like Wi-Fi calling would probably not work neither, but I don't have this with my old Android phone neither.
You will have to hope mobile alternatives to Signal will work well enough for you too (and I guess that requires liking some adventure, but if that works, you also win on not being limited to one phone per Signal account).
But the PinePhone is none of this: terrible phone quality, the modem on my device is unreliable, the autonomy is okayish. I also had a PinePhone Pro that died: big improvement except the autonomy was much worse and it would strongly eat. I believe that's what killed it, actually.
With good hardware, I would be happy with a Linux mobile OS. But I don't use WhatsApp, I don't have a banking app, I don't pay with my phone, and have no proprietary app in general.
Things like Wi-Fi calling would probably not work neither, but I don't have this with my old Android phone neither.
You will have to hope mobile alternatives to Signal will work well enough for you too (and I guess that requires liking some adventure, but if that works, you also win on not being limited to one phone per Signal account).
> With good hardware, I would be happy with a Linux mobile OS.
You mention autonomy a lot, and I agree. I don't think it's a question of hardware: I can install Android on my PinePhone and see that it uses much less battery than a Linux system.
Android was built for that: it is extremely optimized for battery usage. I think it will be very hard to beat that with Linux.
You mention autonomy a lot, and I agree. I don't think it's a question of hardware: I can install Android on my PinePhone and see that it uses much less battery than a Linux system.
Android was built for that: it is extremely optimized for battery usage. I think it will be very hard to beat that with Linux.
It is also hardware: the 2800mAh battery is limited and the modem is a separate SoC wired on USB. And everything is heavy for the limited main SoC, so takes more time and more power and so the phone is not sleeping for longer for the same tasks.
But I'm willing to believe that Linux mobile can improve a lot.
> I can install Android on my PinePhone and see that it uses much less battery than a Linux system
Did you and what did you manage to achieve? I could reach 1.5-2 days of light use with mobian.
But I'm willing to believe that Linux mobile can improve a lot.
> I can install Android on my PinePhone and see that it uses much less battery than a Linux system
Did you and what did you manage to achieve? I could reach 1.5-2 days of light use with mobian.
Your last paragraph reminded me that I had to set up Waydroid so I could install Telegram(Android). Just so I could create an account, so I could then use the already installed Telegram desktop that came by default with like any mobile distribution I tried.
On Signal it is way easier thanks to signal-cli [1].
[1] https://github.com/AsamK/signal-cli
[1] https://github.com/AsamK/signal-cli
There are cool projects looking into that (e.g. PostmarketOS, which is the system used in the article).
While I think it is cool, I am really wondering if there is a future with the idea. If the goal is to run Android apps through Waydroid, then I may as well run Android. If the goal is to be more private... well I think AOSP-based systems like GrapheneOS are in a better position because they get the Android security model.
The cool thing about running Linux is the freedom, but honestly I generally don't need that on my phone. On my phone I want the mainstream apps that allow me to connect with friends and family (yes, that includes WhatsApp and Signal). It quickly ends up being a fancy RPi with a screen and battery (and tons of sensors that probably won't be useful), but then I can actually go with an RPi and SSH from my laptop (I think such server projects suggest removing the battery anyway).
This said, I truly admire all the mainlining work that the PostmarketOS contributors are doing. This really helps everybody, including the AOSP-based Android alternatives.
While I think it is cool, I am really wondering if there is a future with the idea. If the goal is to run Android apps through Waydroid, then I may as well run Android. If the goal is to be more private... well I think AOSP-based systems like GrapheneOS are in a better position because they get the Android security model.
The cool thing about running Linux is the freedom, but honestly I generally don't need that on my phone. On my phone I want the mainstream apps that allow me to connect with friends and family (yes, that includes WhatsApp and Signal). It quickly ends up being a fancy RPi with a screen and battery (and tons of sensors that probably won't be useful), but then I can actually go with an RPi and SSH from my laptop (I think such server projects suggest removing the battery anyway).
This said, I truly admire all the mainlining work that the PostmarketOS contributors are doing. This really helps everybody, including the AOSP-based Android alternatives.
I read Hacker News every day on my Pinephone. Calls and texts(mms included) 80-99% work. Youtube.com worked/still does but very badly. I'll just blame the really cheep SoC. When I tried to get GPS working it looked like 90% of it was there. Had modem getting locks on sats and a maps app, but locks took forever, and the inter process communication didn't work so I'm not sure if the cords I saw in terminal we're actally accurate. The pluging it into a lapdock and using it like a laptop works if your paitent (blames cheep SoC agian). GIMP did manage to load but small screen and slow cpu resulted in that not getting reinstalled next disto hop.
If you want to ask more questions and this site has some way to message me with notifications feel free! I've been using this Pinephone for at least over a year or 2. Random aside: Don't use an SD card as a boot/main drive. I got a 256 & 128 gb SD card that are read only now..
If you want to ask more questions and this site has some way to message me with notifications feel free! I've been using this Pinephone for at least over a year or 2. Random aside: Don't use an SD card as a boot/main drive. I got a 256 & 128 gb SD card that are read only now..
I'm daily driving a Sony Xperia 10 III with SailfishOS. It works as a phone, has a small selection of native apps available and runs many Android apps using LXC based solution called Android AppSupport. It's really not bad at all.
Sailfish licensing is unfortunate.
Unless you have one of their handful of (obsolete) blessed phones and pay them money for the privilege, you can't use their stuff.
I get that they're effectively a startup spun out of Nokia, and that they'd rather sell value than give it away. Still, non-Android Linux for touchscreens is in a sad state. Having one of the only options locked up where few people can try it and nobody can contribute to it makes the ecosystem worse.
There's gotta be a better solution to raise all the boats than get a handful of enthusiasts with old Sonys to pay them $30 each.
Unless you have one of their handful of (obsolete) blessed phones and pay them money for the privilege, you can't use their stuff.
I get that they're effectively a startup spun out of Nokia, and that they'd rather sell value than give it away. Still, non-Android Linux for touchscreens is in a sad state. Having one of the only options locked up where few people can try it and nobody can contribute to it makes the ecosystem worse.
There's gotta be a better solution to raise all the boats than get a handful of enthusiasts with old Sonys to pay them $30 each.
Until an update destroys android support and nobody can help (: (my state)
Sorry to hear that. If you are on one of the Xperias, you should be able to at least reflash the OS if nothing else really helps.
Genuinely interesting: what's the benefit of using a non-Android OS if you end up running Android apps anyway?
Instead of going all-in on Android, you get to choose the apps that are most important to you and otherwise minimize your exposure to the privacy-grab. For example, if you'd really prefer to avoid using Android but do want mobile banking on your phone, just get the app for that and skip everything else.
Personally I like having Linux on the phone a lot for other reasons as well. For example, last summer I was backpacking in North America for several weeks. At some point I realized that I'd really hate to lose the photos on the memory card of my DSLR. Instead of getting another card and hiding the first one somewhere "theft-proof" in my belongings, I just went to BestBuy, got a memory card reader, plugged that into the phone, mounted the memory card filesystem and rsynced the files home over my vpn - which is exactly what I would have done if I had my laptop with me. Sure, I probably could have figured out a way to achieve something similar on Android as well, but having all the familiar tools available made it so much easier.
Personally I like having Linux on the phone a lot for other reasons as well. For example, last summer I was backpacking in North America for several weeks. At some point I realized that I'd really hate to lose the photos on the memory card of my DSLR. Instead of getting another card and hiding the first one somewhere "theft-proof" in my belongings, I just went to BestBuy, got a memory card reader, plugged that into the phone, mounted the memory card filesystem and rsynced the files home over my vpn - which is exactly what I would have done if I had my laptop with me. Sure, I probably could have figured out a way to achieve something similar on Android as well, but having all the familiar tools available made it so much easier.
You could probably have done something similar using Android with Termux, yes. I use rsync in Termux to move files to or from my phone all the time. Android is a complete mess when it comes to app permissions and the file system, so I would not dare to guess if it would be possible to access a USB drive from within Termux or not.
I preferred SailfishOS on my Jolla Phone (and my Jolla Tablet) as the experience is much better with how you can access files on the file system etc. But for various reasons (including a cracked phone screen) I went back to Android several years ago.
I preferred SailfishOS on my Jolla Phone (and my Jolla Tablet) as the experience is much better with how you can access files on the file system etc. But for various reasons (including a cracked phone screen) I went back to Android several years ago.
I'm using Librem 5 as a daily driver. The most limiting is the battery life (4-5 hours of screen time), otherwise it works sufficiently well for me. Fortunately I can take another battery with me just in case.
I'm curious to know if there is a good way to do this on a phone with a broken screen. I have accumulated a few phones with 3+ gig of RAM, a decent number of moderately good ARM cores, but with broken screens.
Essentially this means all control with the device has to be on the few buttons, and the USB, and all feedback must be through USB (or maybe audio)
How transplantable are screens between phones? Assuming no geometric fit is required, are the connectors/interfaces standardised inside enough to bodge a temporary screen long enough to set-up a remote interface.
Essentially this means all control with the device has to be on the few buttons, and the USB, and all feedback must be through USB (or maybe audio)
How transplantable are screens between phones? Assuming no geometric fit is required, are the connectors/interfaces standardised inside enough to bodge a temporary screen long enough to set-up a remote interface.
Switching to pmOS may be bit hard but can run Docker containers on Android. (Although steps differ.)
About Android, if a device got adb enabled, can use scrcpy to display and control the device from PC. Considering this, the problem is reduced in enabling adb.
If the device supports HDMI-out, can use a USB-C hub to have output and PC connection. If the device supports OTG, can use scrcpy's OTG mode (or attach a mouse via an adapter) and enable adb by doing the required steps manually. If no HDMI out, have to do them blindly. But should be possible using an automation/input tool (like xdotool) to script them. (This procedure can also be used to OEM unlock if want to install pmOS.)
If the device is blessed with unlocked bootloader, can `fastboot boot` a TWRP IMG (almost every device has a TWRP port) that has adb enabled by default. From PC can then set persist enable to true and push authorization keys. If cannot run a custom recovery but the device allows 3rd-party OTA updates in stock recovery, can flash an UPDATE.ZIP that does the same.
Flashing pmOS is also done via fastboot. But probably need to install a custom pmOS IMG to account for the broken screen. Like pre-enabling ssh, similar to how you will do installing Linux to a remote server.
About Android, if a device got adb enabled, can use scrcpy to display and control the device from PC. Considering this, the problem is reduced in enabling adb.
If the device supports HDMI-out, can use a USB-C hub to have output and PC connection. If the device supports OTG, can use scrcpy's OTG mode (or attach a mouse via an adapter) and enable adb by doing the required steps manually. If no HDMI out, have to do them blindly. But should be possible using an automation/input tool (like xdotool) to script them. (This procedure can also be used to OEM unlock if want to install pmOS.)
If the device is blessed with unlocked bootloader, can `fastboot boot` a TWRP IMG (almost every device has a TWRP port) that has adb enabled by default. From PC can then set persist enable to true and push authorization keys. If cannot run a custom recovery but the device allows 3rd-party OTA updates in stock recovery, can flash an UPDATE.ZIP that does the same.
Flashing pmOS is also done via fastboot. But probably need to install a custom pmOS IMG to account for the broken screen. Like pre-enabling ssh, similar to how you will do installing Linux to a remote server.
How old are they? I was surprised to discover that plugging my 2019-era Samsung device into a thunderbolt 3 dock (to charge, I assumed) lit up the monitors as external displays and enabled control with a keyboard and mouse.
I believe it's not a common android behavior but Samsung's S-line thing
I've always wondered if we'll ever see a paradigm shift toward services being hosted on our phones. Not feasible now due to battery life concerns, but these are little Linux computers with redundant (wifi plus cellular) network connections that are always turned on. Some battery advancement and more efficient E cores and we're there, no?
From what I think I understand, a big difference between a Linux distro and Android (apart from the security model) is the battery optimization.
A mobile phone is very different from a Linux server in that it's idling most of the time. But if you run a server and prevent the system from optimizing the battery, then it won't last very long.
A mobile phone is very different from a Linux server in that it's idling most of the time. But if you run a server and prevent the system from optimizing the battery, then it won't last very long.
Historically, some people thought it was a cool idea to run phones as servers with a built in UPS (I looked into it myself) but the problem is phone batteries have a nasty habit of exploding
Habit? It's been known to happen on rare occasion, but a habit?
They tend to turn into those inflated pillows (and perhaps even rupture?) when connected to power all the time. You could disassemble the phone, remove the battery, and reassemble and use it without it (if it boots and is stable).
A simple solution might be to put the charger on a timer.
So just encase it in a lead box...
Oh, wait...
Oh, wait...
Interesting only if have free time and already own a compatible phone.
Otherwise, wouldn't be better to invest time and money in a mini-pc with storage and power capabilities better suited for server use?
Otherwise, wouldn't be better to invest time and money in a mini-pc with storage and power capabilities better suited for server use?
Absolutely, this is for hardware reuse. I wouldn't buy a phone specifically for this, there are better options.
Yes, the title is slightly misleading. It is more like "How to flash PostmarketOS on your unused Android phone with unlocked bootloader" than the Docker thing
The ability to run ethernet and power over the same usb port is handy for static reuse of phones, not sure there's a list of who supports it though
Wdym by "list of who supports it"
Charging while in host mode and native USB-Ethernet card support are both not universally implemented features
I used a Samsung Galaxy, as in the first Samsung Galaxy phone, as a home server maybe 15 years ago. No Docker, or PostmarketOS needed.
I so wish I could do this with my old iPhone 8. Has anyone attempted this, successfully?
Has anyone attempted that successfully?
My ideal would be to run *nix on with a web server and NAS. I don't care about borked camera or bluetooth, just wifi would be fine.
Has anyone attempted that successfully?
My ideal would be to run *nix on with a web server and NAS. I don't care about borked camera or bluetooth, just wifi would be fine.
Not sure about iPhone 8 specifically but that are many efforts available depending on your iOS version. https://ipadlinux.org/
thanks! to my knowledge iSH is too limited for my use case (it's more of an emulated linux environment). I might give UTM another shot. I can see that there's a "proper" distro but for iPhone 7 though!
btw if you're into this kind of stuff, check out MacPaint on iPad via UTM. It looks lovely! I can't find the link now, but check out Matt Sephton's blog for that:
https://blog.gingerbeardman.com/2023/10/21/list-of-vintage-j...
(ps I write about this stuff occasionally too https://untested.sonnet.io/notes/til/weekly/58/#h-interestin...)
btw if you're into this kind of stuff, check out MacPaint on iPad via UTM. It looks lovely! I can't find the link now, but check out Matt Sephton's blog for that:
https://blog.gingerbeardman.com/2023/10/21/list-of-vintage-j...
(ps I write about this stuff occasionally too https://untested.sonnet.io/notes/til/weekly/58/#h-interestin...)
Back in the day I used an iPhone 4 as a Transmission torrent server with Cydia.
It had only 32GB storage but it was a fun idea, worked great.
It had only 32GB storage but it was a fun idea, worked great.
Cydia! Oh man, that brings back some memories. I still fondly remember not being able to use Skype and log in to my bank xd
I had this chronic disease where every year I'd turn my PC into a hackintosh and my iPhone into a jailbreaked version of it. Recovery took about a week on average.
I had this chronic disease where every year I'd turn my PC into a hackintosh and my iPhone into a jailbreaked version of it. Recovery took about a week on average.
I would be so proud to be able to use my iPhone 3G again :)
This looks remarkably similar to my post :)
https://blog.denv.it/posts/pmos-k3s-cluster/
That is an excellent suggestion. I have a few mobile devices that could be effectively utilized as a home server. And with Docker, we can deploy a multitude of applications.
what is the phone with the best specs currently that supports linux with external display?
If you are going to setup a server on a phone, it might indeed be a good idea to avoid Android, mainly because of how aggressive the OOM killer can be with background apps.
On Android, killing a background app is not so much of an issue (caveat: [1]), they are designed for this. But you don't want your service or even your ssh deamon to be killed by Android.
Now, I don't know how running the phone 24/24 7/7 plugged in is going to last in the long run, especially concerning the battery. Has someone tried this?
[edit: see below comments, the post actually advises removing the battery]
[1] https://dontkillmyapp.com/