I built a custom ArchLinux ARM image using my fork of arch-image-builder
It actually boots and most things already work.
I’m not sure how should I fix pgp issues (pacman says that my pgp signature is invalid) though. But it appears to work after pacman-key --init && pacman-key --populate.
What would it take to get EOS ISO up and running?
After the image for a supported platform has been burned to a uSD card, USB SSD, etc. On first boot this script is run to do configs, theming, choose a Desktop Environment, etc.
https://github.com/endeavouros-arm/image-build-script/blob/main/config-eos.sh
Lines 521 to 525 are how ARM devices handle pgp
pacman-key --init
pacman-key --populate archlinuxarm endeavouros
pacman-key --lsign-key EndeavourOS
pacman-key --lsign-key builder@archlinuxarm.org
pacman -Syy
You might want to eliminate the line 2 endeavouros reference, and eliminate line 3 with the EndeavourOS reference.
I hope this helps.
If you get an image that meets our requirements, we can see about getting it on EnOS github
If you have a RPi 4b, RPi 5 available (even a friend to borrow one from) and do an installation you will see how we do things.
If you have any questions, let me know.
Pudge
After image was built, I flashed it onto USB SSD and just booted my laptop from it. After that pacman wasn’t working and I had to run pacman-key --init && pacman-key --populate.
So is this normal and just handled by the install script on EndeavourOS? Or did I mess up the image creation or my keyring package somehow?
Well, I built ArchLinux ARM image just today, not sure what would it take to build EnOS as well. Can I use the same arch-image-builder?
I actually do have a RPi 4, but why can’t we have the same installation process as on x86-64 (that is, with Calamares)? It kind of makes sense on these laptops.
Here’s my image for anyone who is interested: t14s-alarm.img.zst
@anonymix
Wow … if this laptop wasn’t so expensive for me I’d like to get one. Always been a big believer in Arm hardware. The specs are great but at almost $2700 Cdn is a little more than i would want to put out. But, would be nice. 
I do have the Pi 400 for slightly less money. 
I’ll be watching to see how this ISO building works out. I’m intrigued.
Edit: The price is with tax here also and they only show one model available.
It’s actually quite cheaper (~1,365 USD on Amazon), but I got it for ~1950 because of shipping and customs fee. TBH it is a bad deal: screen is only 60 Hz, CPU is the lowest end model. But OLED is certainly a no-go for a laptop. Maybe I’ll just buy 120 Hz IPS panel and replace the stock one.
There doesn’t seem to be much configuration for this laptop. Only screen seems to be configurable in some regions. In future there probably also be 5G and 64GiB models, but these aren’t that necessary for me personally.
Correct.
A little tip, if the pacman gpg’s get messed up, delete this directory
/etc/pacman.d/gnupg
sudo pacman -rf /etc/pacman.d/gnupg
Then for Archlinux ARM redo
pacman-key --init
pacman-key --populate archlinuxarm
pacman-key --lsign-key builder@archlinuxarm.org
pacman -Syy
The above is for pacman gpg’s only.
Pudge
We were doing that at one time, and it ended up being a convoluted mess.
Calamares has C++ code and python in it, so an aarch64 version of calamares had to be compiled. Eventually, the aarch64 calamares would no longer compile properly and was abandoned by EnOS ARM team.
As far as I know, one cannot create a live bootable Joliet ISO that will boot on an ARM device then install an OS on another storage device such as for x86_64. For ARM an image had to be created that would bring up a full graphical Desktop Environment on which to run calamares. In this case KDE Plasma was the DE used. So, Plasma and calamares had to be on the distribution image just for the purpose of setting language, keyboard config, time zone, hostname, username, passwords, etc. When completed, all calamares files had to be deleted. If any DE was chosen other than Plasma, then Plasma had to be deleted and the desired DE installed. It just wasn’t practical and a nightmare to maintain.
Currently, an image is burned to a storage device with a base install ready for a DE, with just the most simple kernel modeset graphics. Then on first boot, a script is run using a curses type dialog to enter all the information for setting up the final EnOS build.
And lastly. Anyone used to using other install methods such as Raspberry PI OS, Ubuntu, Debian, and so on, would say “Why can’t EnOS just offer an image that is simply burned to a uSD or other storage device like everybody else?” So give the people what they want.
HTH
Pudge
Why is that? Once again, for these laptops such an iso kinda makes sense. I’m currently just booting from USB SSD (though any USB drive would work the same), but if I were to install it to the internal NVMe, I’d expect for archinstall or calamares to “just work” since this is just an ordinary UEFI laptop and the only difference is CPU architecture.
My image already includes plasma, just like an installer would do in this case.
Lfortran and Lpython compilers developed by Mr. ondrej certik and his team are doing good.
https://ondrejcertik.com. Just in case if their work can be of use for calameras on ARM.
Python can be at its best. Faster like C code.
Rust is also gaining popularity these days.
In oder for you to play around with this, I tried to compile a aarch64 version of calamares. The compile failed at
33%] Linking CXX shared library ../../libcalamares.so
/usr/bin/ld: warning: -z pack-relative-relocs ignored
collect2: error: ld returned 1 exit status
make[2]: *** [src/libcalamares/CMakeFiles/calamares.dir/build.make:981: libcalamares.so.3.3.7] Error 1
make[1]: *** [CMakeFiles/Makefile2:4199: src/libcalamares/CMakeFiles/calamares.dir/all] Error 2
make: *** [Makefile:166: all] Error 2
make: Leaving directory '/home/don/Documents/src/build'
==> ERROR: A failure occurred in build().
Aborting...
[don@Radxa-5B ]$
I guess the next thing would be for you to see about getting aarch64 calamares compiled.
Pudge
This is the exact reason why I hate all these overcomplicated build systems (including CMake). One workaround would be to use the following wrapper for ld:
#!/bin/bash
args=()
for arg in "$@"; do
if [[ $arg != *"--fatal-warnings"* ]]; then
args+=($arg)
fi
done
/usr/bin/ld.real "${args[@]}"
I used this PKGBUILD with 'hwinfo' dependency removed and the build succeeded.
That is the exact PKGBUILD I used and it failed. However:
I was using a Radxa ROCK 5B device for the compile, and I also changed:
arch=('any')
to
arch=('aarch64')
When I get a chance, I will try again without the architecture change and use ‘any’
Pudge
I also changed architecture, but what actually helped is that ld wrapper script. You may try to rename /usr/bin/ld to /usr/bin/ld.real and save that script as /usr/bin/ld (and chmod +x, of course).
Yup, followed your instructions and the Radxa ROCK 5B compiled it in 9 minutes 10 seconds.
==> Finished making: calamares 24.06.1.2-1 (Fri 23 Aug 2024 04:59:30 PM MDT)
real 9m10.308s
user 51m44.652s
sys 5m3.767s
I would have never come up with that on my own.
Now, would you like to have the package here ?
https://github.com/endeavouros-team/repo/tree/master/endeavouros/aarch64
Pudge
Wow, it is much faster for me:
==> Finished making: calamares 24.06.1.2-1 (Sat 24 Aug 2024 04:00:32 AM EDT)
real 0m45.450s
user 1m20.916s
sys 0m15.924s
Yes, it would be great to have this package there and whatever configuration files it needs (and it certainly needs some).