Fedora Atomic for mobile devices. Contribute to pocketblue/pocketblue development by creating an account on GitHub.
Read the original article
Comments
This is a really cool project, and IMHO the most important new-comer in the #MobileLinux distro space in a long time, as it takes a model proven on desktop, building upon a well-run distribution (Fedora) and applies it to mobile.
I have yet to attempt daily-driving it, but just trying it and easily switching mobile shells (e.g., from Plasma Mobile to Phosh) so easily[0] without have weird side-effects from the previous environment has been quite exciting!
[0]: https://pocketblue.github.io/devices/oneplus-sdm845/#images-...
By nikodunk 2026-02-1522:36 Updating without worries has made it much more daily-drivable for me on a Oneplus 6 (ie. it has rollbacks and image-based updates), despite being so new. It's fun that image-based OSs - which were arguably popularlized by phones - are now coming back to phones on the Linux side too.
This is based on bootc (bootable containers), so note that the OS build is described in a normal Dockerfile: https://github.com/pocketblue/pocketblue/blob/main/Container... which is then run by the Github action (or locally).
Very similar to how Universal Blue, Bazzite, Bluefin etc. build at https://github.com/ublue-os/bazzite (see their Containerfile), but for mobile.
Has a similar mission to https://postmarketos.org, but with a different build system AFAICT
By exceptione 2026-02-169:191 reply
nitpick: Containerfile. I mention it because people still think container==docker. I am sure the Fedora people focus on podman, as part of the Red Hat ecosystem. For a better dev experience they offer podman-bootc¹, which you will miss when using Docker. Personally I am convinced that we should steer people to podman instead of Docker.> Dockerfile1. https://docs.fedoraproject.org/en-US/bootc/getting-started/
Red Hat obviously wants to change people's vocabulary but "Dockerfile" is basically an industry-standard generic term by this point.
By exceptione 2026-02-1611:541 reply That is true, the same for "to google" if people mean "to search". It does bury the generality of the concept though. Like I said, a nitpick.
By Conan_Kudo 2026-02-1615:53 I think it's also worth noting that the Dockerfile format is still driven by Docker, and there have been zero extensions to the format by Podman folks, so Containerfile==Dockerfile.
Are we really bringing OCI to freaking OS builds? Nothing about OCI is pleasant. A list of Tarballs is the most backwards boot format I can think of. Terrible for reproducibility. Terrible for security.
Boot images should be Dm-verity protected EROFS images. We should not be building new things on OCI. It's really mind-blowing to me that this is a new direction people who are supposed to be top of class OS builders are moving to as a direction.
They took the CoreOS dream and threw everything in the trash
By looperhacks 2026-02-169:382 reply How is OCI terrible for reproducibility and security? They are certainly more reproducible than what we had before. I haven't heard "Works on my machine for a long time". If you're talking about reproducible builds, there aren't any hard issues either that are directly caused by OCI images - except setting the clock correctly.
> Boot images should be Dm-verity protected EROFS images
Maybe I'm misunderstanding you - I gather that you think the boot images are distributed as OCI images? That's not the case, bootc is more about building the image, updating it and the overall structure. Booting an image built with bootc does not involve any container infrastructure (unless you start services that depend on containers, I guess - but that's deep in userspace). There's technically nothing preventing this from using verified read-only images.
By arianvanp 2026-02-1810:42 > I gather that you think the boot images are distributed as OCI image
Yes? That's literally the sales pitch on the website. Am I missing something?
Quote from https://bootc-dev.github.io/ tells me that bootc is using OCI as a delivery format for bootable images.
Transactional, in-place operating system updates using OCI/Docker container images.
Motivation The original Docker container model of using "layers" to model applications has been extremely successful. This project aims to apply the same technique for bootable host systems - using standard OCI/Docker containers as a transport and delivery format for base operating system updates
By saltamimi 2026-02-1614:20 For the record, bootc supports and has workflows for verity images.
By exceptione 2026-02-169:221 reply
First time I hear about it. Playing the devils advocate: how does it improve over checksums + tarballs?> Dm-verity protected EROFS imagesBy curt15 2026-02-1612:51 checksums + tarballs don't help with runtime integrity verification. You'll need additional technologies for that like dm-verity or fs-verity; see composefs.
By traverseda 2026-02-170:52 If you're thinking about actually using it, please not it only supports redhat distros.
This is good to see. The concept of immutable OS and fallback boots is going to be much more common. I think there are similar concepts being explored in postmarketOS such as https://gitlab.postmarketos.org/postmarketOS/duranium
I've tried the silverblue desktop version of this and while I'm not convinced that a mix of OS/Brew/Flatpak/Containers is making things more approachable it's interesting to see these concepts progress and the tools improve.
By zozbot234 2026-02-1616:53 Immutable OS is just a glorified liveCD with "persistent" user storage, it's really nothing new as far as the concept itself goes. Only the implementation differs.
