EOS installer hangs just after servers speed ranking

warpme · January 9, 2023, 9:09am

Hi,

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?

pebcak · January 9, 2023, 10:40am

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

s4ndm4n · January 9, 2023, 2:27pm

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

sradjoker · January 9, 2023, 4:07pm

Welcome to forums!!

Thanks for trying out 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.

warpme · January 9, 2023, 7:53pm

Good.
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

sradjoker · January 9, 2023, 9:07pm

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 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.

warpme · January 9, 2023, 9:32pm

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

warpme · January 10, 2023, 8:46am

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-*

ough

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)

joperfi · January 10, 2023, 12:01pm

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

sradjoker · January 10, 2023, 12:35pm

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

warpme · January 10, 2023, 2:28pm

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…

sradjoker · January 10, 2023, 3:38pm

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.

warpme · January 10, 2023, 4:27pm

Sure.
I think script needs some love in 3 areas:

fixes: pls see https://github.com/endeavouros-arm/install-script/issues/21
deps: using current https://archlinuxarm.org/platforms/armv8/generic i discover missing pkg are: openssl libnewt
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 ; \

Pudge · January 11, 2023, 2:07am

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

We use the
linux-rpi
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
build-server-image-chroot.sh
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.

Pudge

warpme · January 11, 2023, 8:54am

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
but
equally good preparation for 2 options.

that’s all