EOS installer hangs just after servers speed ranking


I’m developing MiniArch (https://github.com/warpme/miniarch) project which is Archlinux bootstrap SD card images for H6/H616/RK3399/RK3566/RK3568/S912/SM1/G12/RPI3/RPI4 based SBC/TVboxes

It seems to work ok for basic ArchLinux ARM - so I started to play with EOS install and…EOS installer hangs for me just after servers speed ranking.

Code i’m using to start EOS install is like this:

su root -c " \
        pacman -S git ; \
        cd /root ; \
        git clone https://github.com/endeavouros-arm/install-script.git ; \
        cd /root/install-script ; \
        chmod 774 endeavour-ARM-install-V*.sh ; \
        ./endeavour-ARM-install-V*.sh ; \

Is there any way to debug this issue?
Or maybe i’m doing something wrong?

Hi and welcome to EnOS’ community @warpme!
And good luck with resolving your issue!

Also please have a look at the install instructions at:

PS. moved to ARM:installation

1 Like

Hi and welcome to :enos: forums. Best person to answer would be @dalto.

Welcome to :enos: forums!!

Thanks for trying out :enos: ARM.

As @pebcak says our latest install method is given here:

The script you are using is our old script for devices we don’t directly support. For using that script, you have to have archlinux arm installed first then run the script in the repo.

I’ve tried this script after looking at your post and I can verify that it is working on a chroot. I’ve not verified it to a a separate storage device.

Is there is an error in servers speed ranking, then the issue might be with the mirrors. Is the script hanging after the mirrors are being ranked or before?

It would be great we can see the terminal output of the screen when it hangs. If text output can’t be done, a screenshot would suffice.

This means my issue is result of different system state (installed pkgs) of my system vs. yours.
Im installing on pure https://archlinuxarm.org/platforms/armv8/generic on rpi4
I see installer skips installing libnewt on rpi4 devices.
This results with fail when user is using https://archlinuxarm.org/platforms/armv8/generic on rpi4

Now installer traps like on attached picture.
IMHO this is definitely missing dependency issue as restarting install again not reports this issue anymore (it seems at first installer run missing dependency was satisfied so second installer run not reports issue anymore).
Im not sure what is missing in .py packages on https://archlinuxarm.org/platforms/armv8/generic on rpi4 - but this breaks eos install :frowning:

1 Like

Can you provide the entire log in a text bin?

I think the issue now is the endeavouros core packages like eos-packagelist are not installed.
You can see that the mirrorlist wasn’t downloaded properly. I think this is again a mirror issue and or github issue.

Because archlinuxarm doesn’t have :enos: mirrorlist and keyring, we download it in our script from github and manually install it. That step is in the beginning of the script. If it fails, everything else will.

sorry editing my post. i’m a bit further with issue - see my post update…

1 Like

Im again a bit further with this: after multiple reruns of installer script i got state when system boots with black screen and blinking cursor.

Logging as root and examining logs shows me xorg server failed to start due:

AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (libicuuc.so.71: cannot open shared object file: No such file or directory)

This looks to me like mesa is built against icu71 while system already has icu72.
(the same issue i see for gtk-pixbuf2, gtk-query-immodules, etc)

This install nightmare leads me to Q: is archlinuxarm rolling packages updates dependency tracking still working?

Looking on:

  • py trap (shown in pic) in this thread (seems to be result of missing openssl pkg)
  • missing libcrypto1.1 effectively breaking system after openssl update (just when user does pacman -Syu on vanilla https://archlinuxarm.org/platforms/armv8/generic)
  • outdated icu71 dependency in mesa, gtk-*


Amount of issues currently happening to me are simply prohibitive to overcome by casual user…

btw: i have another issue with failing gnome-shell. What is most preferable way reporting such issue?
(GitHub issue, here, another forum category, etc)

Did you try to install the rpi4 image instead of the generic arch?

Most of the packages we have are coming from arch Linux arm. So the issues you are facing have to be reported to arch Linux arm.

I think these issues will be resolved soon if you report it there. I face these issues infrequently, but they generally get resolved.

@Pudge could you look into the missing dependencies in the install script? Nice to see that it’s working with minimal maintenance from our side

Oh no - as this is not what i want to achieve.

Im developing https://github.com/warpme/miniarch

target: user downloads image, burns on SD card, inserts into SBC, updates from Internet and installs EOS. All should be as easy as possible.

So far I got it working (with some fixes for archlinux arm image + oes install script) for all my supported sbc/tvboxes (https://github.com/warpme/minimyth2#current-status).

KDE desktop variant seems work ok.
Gnome fails (due issues within current archlinux arm packages i think)
other DE not tested yet…

If you can give us a list of packages which needs to be installed (which is currently missing from the install script and causing the script to not run) it would be really great. I’ll add them to the script.

Yes, that’s why I was testing the script. This was the old method and currently the supported method for devices we don’t officially support. Thanks for looking at our work. Even though this script is minimally maintained, I was pleasantly surprised to see that it still works. I think we can make it better with your input.

I think script needs some love in 3 areas:

  1. fixes: pls see https://github.com/endeavouros-arm/install-script/issues/21

  2. deps: using current https://archlinuxarm.org/platforms/armv8/generic i discover missing pkg are: openssl libnewt

  3. improvements: currently - if user has (by any reason) pacman conflicting mods in rootfs breaking eos packages installing - script will end with failure (as pacman fails) and leaves system in half modified state (worse: in my case it was state where rerun of script returned additional errors). This i call “fail & exit on discrepancy” strategy. I would propose “overwrite on discrepancy” strategy - where pkgs install will continue and overwrite discrepancies. This is less worse strategy (imho) - as usually - when user starts eos install - user is rather expecting successful install - even with risk of overwrites (I assuming proper pkg is NOT overwriting user data - so such pacman done overwrites are not issue imho).

im using currently following hack to successfully install eos on https://archlinuxarm.org/platforms/armv8/generic:

su root -c " \
        pacman --needed -S git openssl libnewt ; \
        cd /root ; \
        git clone https://github.com/endeavouros-arm/install-script.git ; \
        cd /root/install-script ; \
        chmod 774 endeavour-ARM-install-V*.sh ; \
        sed 's|MACHINEMODEL=|#MACHINEMODEL=|g' -i endeavour-ARM-install-V*.sh ; \
        sed 's|--needed - < base-addons|--needed --overwrite \\\* - < base-addons|g' -i endeavour-ARM-install-V*.sh ; \
        ./endeavour-ARM-install-V*.sh ; \

First off, for the RPi 4 model B we don’t use the generic AArch64 Installation as it installs the

We use the
kernel. Which is the “RPi Foundation patched Linux kernel and modules”.

So basically there is the linux-aarch64 Generic kernel, and the linux-rpi kernel which comes from the RPi Foundation itself with all modules that the RPi Foundation has set up.

We tried the generic linux-aarch64 kernel and found that it did not do what we wanted it to do.

If using the generic linux-aarch64 kernel is a requirement for miniarch then you will need to rework your script to accommodate your needs.

You might want to take a look at

build-server-image-eos.sh downloads the RPi 4 image from archlinux-arm.

the build-server-image-eos.sh script then does an arch-chroot to
which uses this script to perform changes to the actual image being created. Which includes removing the linux-aarch64 kernel and uboot then adding the linux-rpi RPi Foundation kernel with the appropriate firmware.

Perhaps you can check these out and maybe find something useful.


1 Like

Thx for good explanations!

Im fully aware dualizm: world kernel vs. rpi kernel

My motivation (with my project) is to offer choice: users can go with dedicated kernel per group of devices (example is rpi) or go with universal kernel (this is what i want to offer).

In ideal world - if api/abi of dedicated kernel conforms with mainline - we should be ok.
But even with that - rpi is not a case (e.g. h264 stateful video decoder offered by rpi kernel works only with rpi private ffpmeg. the same with hevc state-less).

You may say - what the problem?

Well - incompability at api provider (kernel) usually triggers req. for consumer variants (e.g. rpi ffmpeg).
Then potential ver. mismatch at system ffmpeg vs. rpi ffmpeg triggers multiple versions of ffmpeg consumers (apps) (i.e KODI or mythtv etc…)

Model i’m developing solves this issue (as we have single mainline kernel).
It is not free: mainline will almost always offer less full hw support compared to vendor kenrel.

Q is where is break even point to move away form vendor toward mainline?
Imho probably best criteria is devel. effort: if lower maintenance/devel but less hw support by unified kernel outweighs extra time/effort of keeping multiple ver. of sw components with vendor kernels for better hw support - we should go with mainline. I’m already on this route.
(imho corner cases where rpi covers and mainline not is all the time deceasing while rpi kernel incompatibilities are still pains and growing: hevc decoder is example)

Summarising: i’m looking for:
-not mutually exclusive choice: mainline vs. vendors
equally good preparation for 2 options.

that’s all

1 Like