When we started in 2019, we had a close community helping and cheering us on to get EndeavourOS up and running out of the ashes of Antergos.
One of those community members was Pudge, who enthusiastically joined us initially from the sideline by giving us tips. When the project started, he created a script to make EndeavourOS compatible with the ODROID N2, ODROID XU4 and Raspberry Pi 4 ARM devices.
From Discovery article to official ARM branch
Originally, Pudge created the scripts to turn them into an article for our, then-Discovery magazine. But after Joe Kamprad had tested the script for ODROID, we persuaded him to join the team and launch it as an official EndeavourOS branch.
Pudge’s enthusiasm grew and in almost five years, EndeavourOS ARM grew steadily with the addition of community member Sradjoker to our team, the project added support for the PineBook Pro and Raspberry PI 5 and also a Calamares install method as an option, next to the install scripts.
The end of the road
As Linux and DEs went forward on x86_64 devices, the development of ARM devices kept behind. This often became a struggle for Pudge, especially when Sradjoker couldn’t help out as much as before.
EndeavourOS is a project on the side for everyone involved and enthusiasm is key to making it roll forward. With the upstream changes making the gap between ARM and X86_64 bigger, Pudge’s enthusiasm turned into frustration. With no help from the outside and the fact he recently replaced most of his ARM hardware with x86_64, made him decide that he had reached the end of the road for EndeavourOS ARM.
Even though we are saying goodbye to the project with pain in our hearts, we completely understand Pudge’s decision. We thank both Pudge and Sradjoker for their enthusiasm and hard efforts in keeping EndeavourOS ARM in orbit for the past four years.
We are still open for anyone who wants to jump in and pick up where EndeavourOS ARM left off. Our ARM GitHub page is still out there.
What actually needs to happen to get this going again?
There are several issues, upstream Arch ARM support needs to be updated. There are issues with QT6, Wayland and Calamares not being compatible with ARM.
Perhaps use a CLI or something rather then Calamares to start with? I was looking at this projects as I hate not having pre-built ISO/IMG files like Arch (ALARM) currently has.
I think any user who is comfortable using the comand-line for installation, would just as soon use Arch, anyways. I mean, you have to ask yourself, what makes EndeavourOS, EndeavourOS? Right now with BlackArch (the black sheep of the Arch family lol), “In order to install BlackArch on an ARM platform, follow the install instructions for your device on archlinuxarm.org and install BlackArch as an unofficial user repository.” To be fair, you can do with with Arch for x86_64, and they do have plans to release a full ARM distro. The main point of B.Arch might be to have the collection of tools, anyways. But I have a hard time imagining that set-up for Endeavour
We also had a cli install next to Calamares which had a similar instruction. As I already explained, there was just one dev for ARM and he fell out of love doing it.
What are problems?
QT6 for Wayland seems to be available on Arch:
https://archlinuxarm.org/packages/aarch64/qt6-wayland
KDE and Calamares do not “just work” on top of that?
Umm, this isn’t great. I run EndeavourOS on an M1 Mac under UTM (QEMU w/native cpu) as my daily driver! I even have the AUR widevine stuff built and installed so I can see media content.
What do you mean there is a problem with QT6 and Wayland? I’m running it just fine every day. I installed from UTM’s base ARCH linux image for ARM64, since no UEFI ARM64 install image exists.
Man, I invested so much customization into this, too. Frick!
Your set up shouldn’t be affected by this decision, since you built it yourself. The issues I mentioned earlier were affecting the hardware Pudge had to his disposal and the Mac M1 wasn’t one of them. Just to be clear in general, Pudge gave up on developing and maintaining the ARM project because his enthusiasm faded and with that our sole developer for ARM quit. Nobody in the team is getting paid for their work and they do it all for the love of doing it. When that love turns into frustration, it is time to stop what you’re doing.
Perhaps someone or a group of people with a fresh view on things can carry on or redesign the project, we didn’t close the door on the project for good.
I mean, you set yourself up for this- though, it won’t directly affect you as Bryanpwo outlined a few times for you.
This is the price you pay for a fringe setup without contributing, meaning an uber unique distro with an entirely niche setup on an M1 mac of all things. You were and are destined to hit some type of complication. I question your ability to match hardware with software.
Maybe it would be easier not to stick the aims too high. EndeavourOSARM must not reach the level of x86_64…
It has to do with upstream ARM development not going up with DE and Linux mainstream changes.It’s hard for one person to maintain it on different ARM devices.
Maybe we can start with just one or devices and go from there? I would help test on the X13s if we pick a laptop as well as the Pi 4 and/or 5.
Working with another distro like Armbian might be good as well.
We could, if there is a developer available with such hardware. That is the heart of the problem, there are no developers available who are willing to jump in.
Qemu – All the driver issues go away if you develop for QEMU running native arm64 processor (no emulation), as you get standardized i/o drivers, UEFI boot, simple SPICE 3D support. Everyone can run Qemu native on their various ARM64 devices… as I do on my M1 mac as a daily driver (UTM, a nice bundling of Qemu for mac).
sad sad 🙁 but the truth is that there are to many downsides with ARM devices in detail and the Software on the other hand.. In general from my long term testing on the Odroid N2 + these boards are not usable as general Desktop devices. be it issues with audio or graphics or even network, the missing power button, or support for suspending. The only thing i can think of is special use cases like PI-Hole or Backup Server also others testing these boards for NAS usage conclude that it is way to much afford to get this working and maintained compared to solutions you can buy special for that.
Has anyone tried using a K.I. to help solve the problems or to automate things?
I am really sad that there will not be development for ARM anymore. I used it with the official pi screen display and the raspberry pi4, and then the pi5. It runs really fast on the pi5.
I was amazed to be able to use it as a Linux tablet, read some e-books with Foliate and surf the web on Firefox. I even found a repository for Firefox that enabled gestures (firefox-wayland-mode-hook) and native keyboard support. This was my best Linux tablet experience so far. (Thanks to the developers, though 🙂
I hope someone will peek this up (T.T)
Sad to see this happen. Of course, getting and keeping maintainers is arguably one of the hardest parts of community Linux projects, especially if it’s only a few people. Hopefully some passionate folks will pick it up later, but if not, it was a great ARM port and I appreciate the effort.