[ A Call to ARMs ] new images need testing

EndeavourOS ARM images for RPi 4b and Odroid N2 were broken. The perfect storm of situations and problems had things in disarray. With a little help and encouragement from my admin friends, the problem is almost fixed.

Good News

The good news is that new images for the ddimg files for RPi 4b and Odroid N2 have been created and need testing.

Bad News

The rootfs files are still not working correctly. Hopefully that will be resolved in a few days.

Testing the new images

To test the ddimg files, go to
and use Method 2 to download the images then burn the image to a uSD, eMMC, or USB SSD.

The Tags to look for are
ddimg-rpi-20231001 for RPi 4b
ddimg-odroid-n2-20231001 for Odroid N2 & N2+

Click on the appropriate tag then click on the ddimg file and the ddimg file sha512sum to download them.

In a terminal window, navigate to the folder containing the images and check the sha512sum

sha512sum -c enosLinuxARM-rpi-latest.img.xz.sha512sum


sha512sum -c enosLinuxARM-odroid-n2-latest.img.xz.sha512sum

Then use your favorite media burner to install the image to a target storage device.

Things to note

One problem was rp-pppoe had version conflicts. This is now fixed.

Another problem was at the beginning of Calamares, the display showed

0 % initialize pacman... Copy pacman mirrorlist and keyring to target

for twenty minutes until it timed out. In my testing of the new images, this is now taking 1 to 2 minutes. So far I have not seen the twenty minute delay at all. Hopefully that is fixed.

I think this also fixes the python problem.

My testing so far is as follows:

RPi 4b - Samsung EVO 128 GB micro SD and installed Gnome. Installed OK

RPi 4b - Samsung T5 500 GB portable SSD and installed BSPWM. Installed OK

Odroid N2+ - SanDisk Ultra 16 GB micro SD and installed KDE Plasma. Installed Ok
but monitor came up with the proper resolution, but at 300 % scale. Changed to 100 % and
all was good.

Odroid N2+ - eMMC 32 GB card and installed Sway. Installed OK.

Tips if you test install.
Be sure to check the partitions on the Target storage device to make sure the partition 2 ext4 partition was resized to include the free space left during the image burn.

If you install KDE Plasma and it is a bit laggy, try disabling baloo indexing.

Firefox does not play well out of the box on ARM devices. One thing to help that is as follows
In a terminal window

$ sudo nano /etc/profile

At the end of the file, add the following lines

# Force mozilla variable for x11
export MOZ_X11_EGL=1
# Force mozilla variable for wayland

The above is for x11 and Firefox. To switch to Wayland and Firefox switch the commented and uncommented export statements.

If you do an install of the above images, please report here with your results.

Thank you for your patience on this matter.



This basic test worked for me.

I used Rufus to burn the image to a 32GB micro SD card, booted the RPi 4b from the SD card, and successfully installed Cinnamon.

So far I have not seen the twenty minute delay at all.

Same here: the installation is noticeably quicker.

I think this also fixes the python problem.

If ‘python problem’ refers to the showstopper I encountered (undefined symbol: _PyModule_Add), then yes it’s fixed.

make sure the partition 2 ext4 partition was resized to include the free space left during the image burn

Yes, it was resized.

So thank you very much for such a prompt fix.

Two further questions:-

I’d like to try with a portable SSD, and I’d like to use dd in stead of Rufus. But I’m a bit confused about the arguments for dd. Should it copy to the device or to the partition? Should it copy the *.img.xz, or should I extract the *.img first?
Assuming my SSD is /dev/sda, could you suggest a suitable dd command line?

And I’d like to install using btrfs in stead of ext4: am I right in thinking that this will be handled by the rootfs images when they are available?

Thank you for the install and the feedback. :beers:

If your RPi 4b was manufactured BEFORE May 2021, the EEPROM physically located on the RPi 4b board itself, may not be the latest version and doesn’t support USB Boot. If your board is newer than that, booting from a USB SSD will work. Your RPi 4 is probably newer than that so it should work.

To see the eeprom version do the following

sudo pacman -Syu rpi4-eeprom

Then in a terminal, run

$ sudo rpi-eeprom-update
[sudo] password for don: 

BOOTLOADER: up to date
   CURRENT: Wed Jan 11 05:40:52 PM UTC 2023 (1673458852)
    LATEST: Wed Jan 11 05:40:52 PM UTC 2023 (1673458852)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138c0
    LATEST: 000138c0

The VL805_FW EEPROM should be 000138c0 for USB booting support. If it is lower than that, rerun

 rpi-eeprom-update -a

the -a option will update the EEPROM. As usual, burning a EEPROM update is at your own risk.

It has been a very long time since I used dd to burn an image. I recommend using gnome-disk-utility. I have used it for over a decade and never had a problem.

That is correct.

Thanks again.


Thanks for the heads-up about rpi-eeprom. This RPi4 reports CURRENT=000138c0.

And thanks for suggesting gnome-disk-utility – pretty easy once I’d worked it out.
But I was looking for something I can run from a command-line (ie something scriptable).

FWIW, here's what I came up with:
# my device is /dev/sda
# using enosLinuxARM-rpi-latest.img extracted from *.xz
dd bs=4M if=enosLinuxARM-rpi-latest.img of=/dev/sda conv=fsync oflag=direct status=progress

(from Arch: USB flash installation medium):

Tried both methods, both successfully:-

  • RPi 4b - WD Green 480 GB SSD and installed Cinnamon. Installed OK.

One thing I noticed is that this setup seems to idle at 2-3°C cooler than an almost identical setup on another RPi4, the main difference being that this setup uses ext4 and the other (from the old image) uses btrfs.

So I look forward to testing the rootfs image, to see whether the new image also runs cooler under btrfs.

Thanks again for all your good work.

1 Like

After failing to install on my Pi4 with the latest ISO (method 1) I came along this forumpost, so
just tried ddimg-rpi-20231001 and works so far :grinning: , but I’d rather have btrfs for my rootfs as well. So have to wait when that one is available.
Thanks for the support!

1 Like

Thanks for that, Pudge.

I can confirm that the install has worked on an RPi 4B, Crucial 480GB SSD, using Openbox as a DE. The partition resize seems to have worked without issue.

Brand new to EnOS so I’m not sure what else I should be looking out for, but I now have a working system which is a start!

1 Like

Well, wait no more. The rootfs tar files are available for both RPi 4b and Odroid N2.

Method 1 or Method 3 can be used for installation. The installer will automatically choose the latest tag for the image to be downloaded. When the installer starts downloading the image, there should be a CYAN colored line stating which tag was chosen. It should be one of the two following.


If not I need to know.

The rootfs images also need as much testing as possible.

Thank you for your patience.


In keeping with KISS, I edited the instructions for Method 3 on the EnOS ARM website.
If you happen to use that method please give feedback on readablilty, if it’s understandable, and if it doesn’t work, etc.

1 Like

Call to ARMs. . .

I can’t believe I just got that. Very well played @Pudge

1 Like

Darn you’re quick! :grinning:

Tested it on a crucial MX300 525GB SSD; no desktop; re-partitioned so I have some space for a luks partition…all went smooth!

Tested it again on a Samsung shield T7 2TB; no desktop; re-partitioned how I want it and all went smooth!

Thanks for the quick fix!

1 Like

Hey there,

I just stumbled upon this after trying to install endeavour OS onto my pinebook pro. I tried to install it from SD to EMMC using method 3. the download and flashing works, but when rebooting into the emmc and choosing the version to install it complains about " Boost.Python error in job \”packages\” while downloading the packages.

Is there anything i can do to make it work or help testing?

1 Like

Thank you for the feedback. :smiley:
All feedback is helpful.


The Pinebook Pro image needs to create a new image. I haven’t done that yet as I don’t have a PineBook Pro to test on.

I appreciate the offer to help testing.
I will create a new image, and give you access to it and you can then do test installs.


I took a look at this and it will involve more than I originally thought and might take a couple of days to fix. Plus tomorrow my Internet Service Provider is updating their infrastructure in my area. They said there would be outages (rather vague) during the day. Ouch.

This is still on my to do list and I am shooting for this weekend maybe.

Ok, thank you for your work and fast replys!

I dont really use my PBP very often so I could test a new image any time, but no hurries!

1 Like

To @llytaii and anyone else with a PineBook Pro laptop who is willing to do some test installs.

New images are available, and can be installed with any of the three Methods described here.


The new images are

When using the rootfs image, when the installer starts to download the image, a line of blue text should be above the progress bar which will list which image is being used. Please verify.

I do not have a PineBook Pro for testing, so I am not sure these images will work 100% :crossed_fingers:


Just installed https://github.com/endeavouros-arm/images/releases/download/ddimg-rpi-20231001/enosLinuxARM-rpi-latest.img.xz with Plasma-Desktop.
Thanks for fixing!

1 Like

Hi @Pudge,

it looks like the new images work very well, here is what i did:

  1. Flash ddimg-pbp-20231006 to an SD-Card from my PC (using PopOS), booted it via the PBP and installed the official KDE Edition onto it.
  2. Rebooted my PBP into KDE and used Method 3 to download and install the rootfs-pbp-20231006 (I verified the version) onto the EMMC Storage. Rebooted to EMMC and installed the sway community edition which I will use as the main system.

Both installs just worked and so far I also didnt encounter any issues while using the system at all.

Thanks for your fast work!

If there is anything else I can test just @ me.

1 Like

@llytaii and @holzboa

Thank you both for testing the new images. I’m glad it went well.

Thanks for testing both the ddimg and the rootfs.

Thanks again to both of you. It is appreciated. :pray:
Wanting to pitch in and help where needed. That is the great thing about the EndeavourOS Community,


I still haven’t tested it, but has anyone tried installing with btrfs on pinebook? All my past attempts always led to a blank screen when booting.

I know it used to work because @sradjoker definitely had it working.

If you want to use brtfs, you will need to use the rootfs tar image. Brtfs is not supported in the ddimg.

Let us know how it turns out.


Does that mean I have to use one particular method of the 3?