Hi there!
I have downloaded and tested both, desktop and server images for RPi 4b. As I do with Raspbtian images, I burned them with
xz -d -c enosLinuxARM-rpi-latest.img.xz | sudo dd bs=4M status=progress of=/dev/sda
Unlike with Raspbian, the RPi 4b won’t boot. The green led blinks in sets of 4, which according to documentation means “start*.elf not found”.
I have tried fixing the gpt table, but that doesn’t seem to be the problem.
Any guess?
Here is what I just did to see if I could reproduce your situation.
The following process can be done on a x86_64 machine, or a aarch64 machine. It should work either way.
On a x86_64 computer with EndeavourOS installed, I downloaded the latest image from here
https://github.com/endeavouros-arm/images/releases/tag/rpi-4b-image
I then used gnome-disk-utility to burn this image to a u-SD card.
When plugged into a RPi 4b 8 GB RAM device, it booted as expected, and finished the installation including a Cinnamon Desktop Environment,
Next I went back to the x86_64 machine. After fixing a typo, burned the image to a u-SD card with your command
xz -d -c enosLinuxARM-rpi4-latest.img.xz | sudo dd bs=4M status=progress of=/dev/sdb
I changed enosLinuxARM-rpi-latest to enosLinuxARM-rpi4-latest and changed the target device to /dev/sdb
It also booted as expected, and finished the installation including a KDE Plasma Desktop Environment.
So if you truly had
enosLinuxARM-rpi-latest.img.xz
which did not have the rpi4, you did not have the latest image.
Let me know how things go.
Pudge
First of all, thank you for replying and offering some help.
Second of all, yes, it was a typo.
Third, my tests. FYI my device is a RPi 4b 4GiB from 2018 (in fact, I have two of’em). For each of the tests, I have zeroed the start and end of the u-SD cards I’ve used.
I downloaded, checked and dd’ed the Raspian image on a 32 GiB u-SD.
xz -d -c 2025-05-06-raspios-bookworm-arm64-lite.img.xz | sudo dd bs=4M of=/dev/sda
The device boots properly: strong red-green lights, rainbow color screen and normal boot.
Then I rechecked and dd’ed the EOS desktop image on a 64 GiB u-SD.
xz -d -c enosLinuxARM-rpi4-latest.img.xz | sudo dd bs=4M of=/dev/sda
The device won’t boot: after the initial strong red-green lights, the green one starts to blink in short groups of 4, nothing on the screen. The same happens if I restore the image with Gnome’s Disk Utility, as well as if I dd the EOS server image on the 32 GiB u-SD.
Any clue?
First, thank you for the “reaction” on github. Much appreciated.
Your tests point to a problem with the EnOS RPi4 image. I have no idea what it could be at this point.
The current github image is kind of stale. My day is full, but this evening after supper I will create a fresh RPi4 image and release it on github. Hopefully this will eliminate the problem, or eliminate the image as being the problem.
I also have multiple RPi 4b’s, multiple RPi 5’s, and a RPi 400.
Two RPi 4b 4 GB devices, one is my Web Server and the other is my LAN server, NAS, or whatever you want to call it. Also one RPi 4b 8 GB that I use for RPi 4b image testing.
Ooops, I am wandering off topic.
Hopefully we can figure this out.
Pudge
pls forgive my jump in. i see this thread in Rss feed while i do few thing on RPI4 . It be while i no look at endeavouros on Rpi so i think i try see if i get same problem.
From OP " I have downloaded and tested both, desktop and server images for RPi 4b. "
i do few server install like 1st post on 4GB Rpi 4 +32GB u-SD on a 2560X1600 display
1st i do way Mr Pudge say " gnome-disk-utility "
2nd i do xz -d -c enosLinuxARM-server-rpi-latest.img.xz | sudo dd bs=4M status=progress of=/dev/sdd
both time boot fine + install process clean, straight forward + smooth. After reboot only problem was usr no have sudo Perm’s ( possible that is by design ? ) if no by design it prob be a sudo package update that mess thing up.. easy for usr to fix “su” then ( + usr to wheel group + use Visudo un # part in config, save reboot)
only other problem was large 4k display (50") rpi4 no like that.. it boot fine but zero output on display
[eos@test /]$ neofetch
./o. eos@test
./sssso- --------
`:osssssss+- OS: EndeavourOS Linux aarch64
`:+sssssssssso/. Host: Raspberry Pi 4 Model B Rev 1.4
`-/ossssssssssssso/. Kernel: 6.12.27-1-rpi
`-/+sssssssssssssssso+:` Uptime: 34 mins
`-:/+sssssssssssssssssso+/. Packages: 236 (pacman)
`.://osssssssssssssssssssso++- Shell: bash 5.2.37
.://+ssssssssssssssssssssssso++: Terminal: /dev/pts/1
.:///ossssssssssssssssssssssssso++: CPU: ARMv8 rev 3 (v8l) (4) @ 1.800GHz
`:////ssssssssssssssssssssssssssso+++. Memory: 169MiB / 7819MiB
`-////+ssssssssssssssssssssssssssso++++-
`..-+oosssssssssssssssssssssssso+++++/`
./++++++++++++++++++++++++++++++/:.
`:::::::::::::::::::::::::------``
[eos@test /]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 29.7G 0 disk
├─mmcblk0p1 179:1 0 512M 0 part /boot
└─mmcblk0p2 179:2 0 29.2G 0 part /
[eos@test /]$ ls
bin dev home lost+found opt root sbin serverbkup sys usr
boot etc lib mnt proc run server srv tmp var
[eos@test /]$ sudo rpi-eeprom-update -a
[sudo] password for eos:
BOOTLOADER: up to date
CURRENT: Tue Feb 11 05:00:13 PM UTC 2025 (1739293213)
LATEST: Tue Feb 11 05:00:13 PM UTC 2025 (1739293213)
RELEASE: default (/usr/lib/firmware/raspberrypi/bootloader/default)
VL805_FW: Using bootloader EEPROM
VL805: up to date
CURRENT: 000138c0
LATEST: 000138c0
[eos@test /]$
hope this help in small way
EDit…
also try on same device for desktop .. XFCE4
i use same both way , boot +install fine
i use (rpi 4b image April 3, 2025 ) on EOS github
[eos2@test2 /]$ neofetch
./o. eos2@test2
./sssso- ----------
`:osssssss+- OS: EndeavourOS Linux aarch64
`:+sssssssssso/. Host: Raspberry Pi 4 Model B Rev 1.4
`-/ossssssssssssso/. Kernel: 6.12.27-1-rpi
`-/+sssssssssssssssso+:` Uptime: 3 mins
`-:/+sssssssssssssssssso+/. Packages: 800 (pacman)
`.://osssssssssssssssssssso++- Shell: bash 5.2.37
.://+ssssssssssssssssssssssso++: Resolution: 2560x1600
.:///ossssssssssssssssssssssssso++: Terminal: /dev/pts/0
`:////ssssssssssssssssssssssssssso+++. CPU: ARMv8 rev 3 (v8l) (4) @ 1.800GHz
`-////+ssssssssssssssssssssssssssso++++- Memory: 787MiB / 7819MiB
`..-+oosssssssssssssssssssssssso+++++/`
./++++++++++++++++++++++++++++++/:.
`:::::::::::::::::::::::::------``
[eos2@test2 /]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 29.7G 0 disk
├─mmcblk0p1 179:1 0 512M 0 part /boot
└─mmcblk0p2 179:2 0 29.2G 0 part /
[eos2@test2 /]$ ls
bin boot dev etc home lib lost+found mnt opt proc root run sbin srv sys tmp usr var
[eos2@test2 /]$ sudo rpi-eeprom-update -a
BOOTLOADER: up to date
CURRENT: Tue Feb 11 05:00:13 PM UTC 2025 (1739293213)
LATEST: Tue Feb 11 05:00:13 PM UTC 2025 (1739293213)
RELEASE: default (/usr/lib/firmware/raspberrypi/bootloader/default)
VL805_FW: Using bootloader EEPROM
VL805: up to date
CURRENT: 000138c0
LATEST: 000138c0
[eos2@test2 /]$
YRW. I would reacted to the rpi-server, but I don’t know how to react to a release to whom nobody has reacted yet. I see no dedicated button.
I have the exact same one with the RPi 4/5 server image. Although you might have built them in the same manner (if that is the problem).
No rush. Let me know and I’ll give it a try on both my RPi’s.
Thanks for your time, duly appreciated.
In the Archlinux ARM world, there are two differences between the Raspberry Pi 4b and the Raspberry Pi 5 operating systems.
an adjustment for the newer Graphics on the RPi 5. Since the RPi 4b/RPi 5 server image is headless, the Graphics never come into play.
In the RPi 5 Desktop Environment, the adjustment is to add this config file (99-vd3.conf):
https://github.com/endeavouros-arm/image-build-script/blob/main/99-vd3.conf
to /mnt/etc/X11/xorg.conf.d/
The other difference is the RPi 4b only has a memory page capability of 8 KB while the RPi 5 can handle up to a 16 KB memory page. To enable this larger memory page requires an adjustment to the kernel. Archlinux ARM offers two kernels:
linux-rpi which only handles a memory page of 8 KB for RPi 4b or RPi 5
linux-rpi-16k which is used to enable the full 16 KB memory page size in the RPi 5 only
The RPi 4/5 server image doesn’t need nor probably benefit from a 16k memory page so in this use case 8 KB will work for either one.
I Hope my ramblings makes sense.
Pudge
I have been thinking about this. One thing I came up with is:
I assume you were using Raspbian at one time. While using Raspbian, did you or Raspbian ever run a script that modified the contents of the SPI eeprom that exists in hardware on the RPi 4b itself ?
Pudge
easy way to check is spam or hold down " space bar" while boot if no get rpi boot menu it on older eeprom
No, I simply used Raspbian for testing purposes since it is the oficial distro. I always used Arch. I won’t say I haven’t modified contents of the SPI eeprom, but I can’t recall doing so. How could I check? On the other hand, the other RPi 4b is an Arch headless server in which, for sure, I haven’t touched the SPI eeprom, and I won’t boot EOS either.
I am having trouble with the new RPi server image. When it boots up, after creating pacman keys, it tries to “Synchronizing package databases…”. endeavouros syncs up, then it stalls for quite some time. Eventually it continues on and finishes the install.
@vitaminace33 Is this the problem you are experiencing?
If not, try to give me the last successful command on the screen and any error messages after that.
EDIT:
There are new RPi 4b, RPi 5, and RPi server images released in github.
See if they help or not.
Pudge
No. In my case, boot won’t even start. The boot starting rainbow-color screen does not appear.
I tried them but the problem persist 
I’ll try with other distros to see what happens. I’ll let you posted.