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.
I’ve narrowed down the problem: my RPi 4B won’t boot your images because they’re partitioned with GPT, or so it seems. To fix this, instead of dd’ing directly the latest image, I partitioned my SD card with MBR/DOS using the same geometry as the image and then dd’ed each partition.
$ LANG=en fdisk -l enosLinuxARM-rpi4-latest.img
Disk enosLinuxARM-rpi4-latest.img: 8.5 GiB, 9126805504 bytes, 17825792 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1EE32F38-1454-4E46-9F00-5DD30124A456
Device Start End Sectors Size Type
enosLinuxARM-rpi4-latest.img1 4096 1052671 1048576 512M Microsoft basic data
enosLinuxARM-rpi4-latest.img2 1052672 16777215 15724544 7.5G Linux filesystem
$ LANG=en sudo fdisk -l /dev/sda
Disk /dev/sda: 59.48 GiB, 63864569856 bytes, 124735488 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x76cbd1e1
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1050623 1048576 512M c W95 FAT32 (LBA)
/dev/sda2 1050624 16775167 15724544 7.5G 83 Linux
It is not necessary to format anything on your target RPi micro SD, or USB 3 SSD. Formatting is part of the image.
Simply download the image, use gnome-disk-uitility to restore disk image to burn the image to your RPi 4b storage device. Of course there are other image burners, but I have been using gnome-disk-utility on both GTK and QT Desktops for decades with no problems.
In gnome-disk-utility your burned image should look like this
The default for disk format is ext4. If you want btrfs, you have to create your own image.
Not as difficult as it seems. See here:
Pudge
???
Who said nothing about formatting?
I acknowledge your answer, but I think you are not understanding the problem and are confusing formatting with partitioning, or I haven’t made myself clear. The problem is the GPT table. Burning the image with gnome-disk-utility instead of dd won’t change anything. To solve it I had to PARTITION my SD card with MRB (aka DOS) table and burn each partition individually. Surely there is more elegant ways to do so, but anyways the solutions is to have a MBR partition table and not a GPT one.
For full transparency: The script we use for creating the images are located here.
In script script-image-build.sh lines 42 to 49 is the function that is used to partition RPi 4b and RP 5.
_partition_RPi4() {
parted --script -a minimal $DEVICENAME \
mklabel gpt \
unit MiB \
mkpart primary fat32 2MiB 514MiB \
mkpart primary 514MiB $DEVICESIZE"MiB" \
quit
}
and yes GPT is being used.
lines 242 to 246 is the section that formats BOOT_ENOS (fat32) and ROOT_ENOS (ext4)
PARTNAME1=$DEVICENAME"p1"
mkfs.fat -n BOOT_ENOS $PARTNAME1
PARTNAME2=$DEVICENAME"p2"
mkfs.ext4 -F -L ROOT_ENOS $PARTNAME2
The above has been in use for literally years now with no problems at all. Here is github image download data for the RPi 4b image from 2025-08-09 to 2025-08-27
Release Info
Author: @endeavouros-arm
Downloads: 327
Download Info
enosLinuxARM-rpi4-latest.img.xz (1243.63 MiB) - downloaded 292 times.
Last updated on 2025-08-09
enosLinuxARM-rpi4-latest.img.xz.sha512sum (0.00 MiB) - downloaded 35 times.
Last updated on 2025-08-09
Now all of a sudden you are saying " The problem is the GPT table", and “you are not understanding the problem and are confusing formatting with partitioning”?
So I guess “** I haven’t made myself clear**” is the appropriate statement.
Pudge
In my previous post I said…
I never mentioned anything about filesystem formatting, nor is it mentioned anywhere in the thread until you brought it up in your reply.
So I was actually quite clear about what seems to be the problem. Perhaps you didn’t read carefully what I wrote, but it does seem you confused formatting with partitioning.
If my wording came across as offensive in any way (English is not my first language), please accept my apologies. I truly appreciate your help, and my only intention is to figure out where or what exactly is going wrong.
With that out of the way, let’s cut to the chase and focus on the real issue.
Thanks for pointing me to the script. I can now conclusively state that the issue I’m facing is due to GPT partitioning. To test it, I simply burned the image using:
xz -d -c enosLinuxARM-rpi-latest.img.xz | sudo dd bs=4M status=progress of=/dev/sda
As mentioned earlier, my RPi 4B won’t boot. However, if I run the following script:
#!/bin/bash
DEVICENAME=/dev/sda
DEVICESIZE=8192
parted --script -a minimal $DEVICENAME \
mklabel msdos \
unit MiB \
mkpart primary fat32 2MiB 514MiB \
mkpart primary 514MiB ${DEVICESIZE}MiB \
quit
–which is essentially the same script you use for partitioning, but with MBR/DOS instead–then my RPi 4B boots normally and I can complete the EOS setup.
From what I’ve read across several pages, the EEPROM bootloader didn’t support GPT until around 2020(?). I’ve also read that GPT is only supported by the bootloader when booting from USB… strange. Anyway, I guess the best way to proceed is to update the EEPROM.
UPDATE: I’ve updated the EEPROM and now my RPi successfully boots from GPT… from both, SD and USB!
Now, looking closely at the _partition_RPi4() function you referred to, it’s clear that it was originally designed for msdos partition tables. In fact, the function is flawed. The primary keyword is reserved for msdos partition tables, so parted interprets it twice as a partition name when used with GPT. Also, since the unit command is used, specifying MiB in the subsequent lines is no longer necessary. I would recommend to choose between using unit or being explicit. Finally, instead of using quotes for concatenation (which should be reserved for escaping and such), it’s better to use braces: ${DEVICESIZE}MiB.
My bad. It has been so long ago that I updated the EEPROM that it never entered my mind. I assume you know about rpi4-eeprom in the Archlinux ARM repos.
With the latest EEPROM version, GPT works fine on a micro SD card. When I create fresh images, I burn the images to a micro SD and do test installs before releasing them on github.
When it comes to coding, I am at best a hobbyist. Never had any formal training or coded professionally. So I am sure the scripts could use some cleaning up. But they serve their purpose.
Pudge
I’ve updated the EEPROM and now my RPi successfully boots from GPT… from both, SD and USB!
I’ve spent so many hours on this and the solution was so close at hand! Well, let’s continue 