[Newbie] EOS script doesn't produce a working SD card; base Arch install fails as well

After Breakfast and a round of snow shoveling, I will try a few test installs. I will drag out my lap top and try an install with the uSD to SD adapter.

The uSD cards work with Manjaro, so I agree the cards should be functional.
The RPi 4b runs Manjaro, eliminates the RPi itself.

This kind of leaves the method of burning the uSD as suspect.

I assume you have to stick the uSD card into a SD card Adapter to connect to the lap top.
The SD card adapter has a switch on the side for read/write or read only. The switch should be towards the contact end of the SD adapter for read/write. Maybe operate this switch a few times to ensure a good connection. If you have more than one SD card adapter, maybe try a different one.

Get back to you later.



I went ahead and borrowed a USB-C hub with a µSD card reader from a friend and tried flashing it with that, but to no avail. The same error keeps happening: screen stays black and the green LED just flashes four times over and over. I’d be really glad if you tried it yourself, because I just don’t know any more.

There must be something I’m missing here:

  1. I downloaded an EOS ISO from here.
  2. I flashed that to a USB SSD using:
    sudo dd bs=4M if=/path/to/EOS.iso of=/dev/sdb status=progress oflag=sync
  3. Booted my laptop into the EOS live environment.
  4. Connected the USB-C hub (that thing works, as the network cable is connected to it as well and the network works, also I could access the µSDs and browse through the files that should have been my EOS ARM system).
  5. Inserted the µSD card.
  6. Launched the terminal and entered the following commands:
    6.1 mkdir Temp
    6.2 cd Temp
    6.3 git clone https://github.com/endeavouros-arm/image-install.git
    6.4 cd image-install
    (This isn’t strictly necessary, but git clone downloads the git archive as a complete folder “image-install” and puts that folder into “Temp.” There was no mention of this in the guide, but it’s not a big hiccup.)
    6.5 sudo ./install-image-V2.7.sh
  7. I then follow the instructions in the install-image script, making sure to close any other application that’s not the terminal and hitting OK.
  8. I choose “Raspberry Pi 4b 64 bit" hit the arrow right key and press OK.
  9. I enter the device I want flashed: /dev/sdb this time—when I was using the built in SD card reader it was /dev/mmcblk0.
  10. The script does its thing—downloading the Arch tarball takes a while, but after that’s done everything goes pretty quickly—and tells me it’s done.
  11. I remove the µSD card from the USB-C hub and plug it into the RPI.
  12. Everything I need is connected to RPI, so I plug in the power cable.
  13. The screen stays black, the green LED flashes four times in quick succession over and over.
  14. I’m lost.


1 Like

Your description of the install process is spot on.

I put a uSD card into an SD Adapter and inserted it into the Lap Top.
I booted my Lenovo Think Pad T430 into KDE Plasma. Note: I did NOT boot into the liveuser ISO.
Opened a terminal, and in my home directory
git clone https://github.com/endeavouros-arm/image-install.git
cd image-install
sudo ./install-image-V2.7.sh

and followed the instructions.
I put the uSD into my RPi 4b 4 GB Ram and it booted perfectly.
I put the uSD into my RPi 4b 8 GB RAM and it booted perfectly.
I put the uSD into my RPi 400 and it would not boot.

Put the uSD into my RPi 4b and ran the step 2 script and switched from the linux-aarch64 kernel to the linux-rpi kernel. The uSD now boots in the RPi 400 on the linux-rpi kernel.
That’s something I didn’t know until now. RPi 400 will not boot on the linux-aarch64 kernel, but boots fine on the linux-rpi kernel.

Next I booted the lap top into the EndeavourOS Atlantis NEO ISO. I immediately closed the installation welcome screen. Then opened a terminal and followed the process above.
The result was a uSD that booted fine in the RPi 4b.

I am stumped. The only things I can think of:

I assume you have used the same uSD card in all attempts, if so maybe the uSD is bad?
Maybe whilst handling the uSD a static charge zapped it?

How old is the RPi 4b, what is the hardware revision number. If it is old, maybe it doesn’t have the latest firmware.

My RPi 4b 4GB is hardware Rev 1.2 and I updated the VL805 firmware to 000138a1

My RPi 4b 8GB is hardware Rev 1.4 and came with VL805 - 000138a1

After that, I will have to think about it some more.



Have you tried installing a 32 Bit OS and see if that boots up.
This won’t provide the ultimate answer, but it may eliminate a few things if 32 Bit works.


1 Like

I haven’t tried a 32 bit system yet. I’ll try a few things after work today to see if the cards are still fine.

I’ll try to figure out the hardware revision number—don’t know how to do that yet—and go from there.

I could now confirm that both µSD cards are fine. I flashed Manjaro ARM xfce to the 64 GB one and Raspberry Pi OS to the 32 GB one, using the RPI Imager Bin from the AUR.

Both systems booted perfectly well on the first attempt with the cards that just wouldn’t run EOS ARM.

This tells me that the RPI is fine, as are both cards. I’m now going to check what firmware version I’m running and which revision number this thing has.

In any functional OS, such as Manjaro Arm, neofetch will display the Hardware Revision. Here is the neofetch for my RPi 4b 4GB showing it is Rev 1.2

Since the RPi 400 still today with the latest firmware won’t run the linux-aarch64 kernel but will run the linux-rpi kernel, I am betting the 32 bit OS will run on your RPi 4b. If so, I think there is a good chance that the firmware is out of date.

If your RPi 4b runs on 32 bit, then you can decide if you want to flash the firmware.
Here is how to do that, plus a couple of other tips.

sudo rpi-eeprom-update
will display the current firmware version. There are two parts of the firmware. It displays the bootloader first, then the on board VL805 firmware version. The latest on board VL805 firmware is 000138a1

You are on your own on the decision to flash or not.


Oh! I didn’t know I could do this with neofetch, I went about it in a more roundabout way, I guess:

pi@raspberrypi:~ $ cat /proc/cpuinfo
processor	: 0
CPU revision	: 3

Hardware	: BCM2711
Revision	: c03112
Serial		: 10000000b854370b
Model		: Raspberry Pi 4 Model B Rev 1.2

pi@raspberrypi:~ $ vcgencmd version
Jan 20 2022 13:56:48 
Copyright (c) 2012 Broadcom
version bd88f66f8952d34e4e0613a85c7a6d3da49e13e2 (clean) (release) (start)

As usual in Linux, there are several ways to accomplish the same goal.

Well I got to go see about breakfast and shovel more snow. I’ll check in later.


We’re making progress: Using the µSD card with Raspberry Pi OS, I updated the RPI’s firmware via rpi-eeprom-update -d -a (I think it was that) and, lo and behold, things are different now!

The 64 bit Arch installation done via the EOS ARM script now produces the same, albeit non-working, result as my manual Arch installation from above. I now have visual output. U-Boot tries to boot into Arch, but at some point, that passes by too fast for me to read, the screen just turns black and the RPI’s green LED flashes twice in quick succession: 2 flashes: The SD Card cannot be read. What the hell …

Back to the EOS live environment and flashing the 32 bit version this time around … Booting now succeeds, but I can’t follow step two, because config-update doesn’t exist.

This is something I only noticed today and I can’t say if it’s been like this from the first attempt, but when install-image-V2.7.sh finished, I got/noticed the following message:
cp: cannot stat 'config-update': No such file or directory. The script itself still finishes its thing, though.

I don’t understand what’s happening with the 64 bit version, either. The issue presenting itself now was happening even without a firmware update, when I manually flashed Arch. So something changed, but at the same time … not really.

1 Like

First, thanks for informing us about your problem, and even more thanks for sticking with us thus far. I have learned a couple of things I didn’t know before.

I think that was a large part of the problem. So we’re getting close.

When you are in the x86_64 machine getting ready to copy the image, and do the git clone into the image-install folder, it downloads all 4 of these files.

one of which is config-update. The nstall-image-V2.7.sh script does everything that the Arch Linux install tab says to do, and a few extras to make things simpler. One of the extras is to copy config-update from the image-install folder on the x86_64, to the /root directory on the RPi 4.

In the x86_64 device, it is necessary to cd into the image-install folder and run install-image-V2.7.sh from within this folder so the script can find config-update and copy it to the uSD card.
I hope that makes sense. In other words, install-image-V2.7.sh will look in the folder it was launched from for the config-update file then copy it to the uSD card.

Hopefully this will allow the 32 Bit OS to finish installing.

I am looking into providing an image to replace the Arch Linux Arm 64 Bit image, with a image which is based on the linux-rpi kernel, the Raspberry Pi Foundation kernel. We will see how that goes.


1 Like

Oh, that would be my mistake here, because for some reason, today I thought it’d be a great idea to just sudo image-install/install-image-V2.7.sh, instead of “cding” into image-install. Can’t I just take the µSD card and copy the config-update into the root file system?

I’ll try that after work tomorrow and see what happens. Sleep awaits.

Once you finished your image, I’d be happy to try it out, but then again: Now that I think about it—is there really any downside to running a 32-bit system, when the RPI only has 4 GB of RAM anyway? I might be very much misinformed about the differences between the two.

1 Like

The 32 Bit system runs a tad slower than the 64 Bit system. In my opinion, if running off a uSD card which is slower in data transfer than say a SSD, then the uSD card is more of a bottle neck than the 32 bit vs 64 bit. If running from a USB SSD, then the 64 Bit advantage comes into play more.


1 Like

I now pushed the config-update file to the µSD card manually and everything went through. I now have a working 32-bit system.

Well, that sounds a lot like I would want a 64-bit system, after all I got myself a shiny new USB SSD that’s supposed to run the system nice and fast.

1 Like

Great to see it is working for you. Thanks again for sticking with us while working on this problem. Which DE / WM did you choose. I run both a 32 Bit OS and a 64 Bit OS both on USB SSDs and both running KDE Plasma. I need both 32 and 64 Bit for when I have to compile EndeavourOS ARM packages for the EnOS repos. On architecture specific packages I have to compile it once on a armv7h 32 bit system, then again on a aarch64 64 Bit system before pushing them to github.

Out of curiosity, what was the Hardware revision on your RPi 4b? I’m guessing Rev 1.2
If your RPi 4b is Ver 1.2 it should work now with burning the 64 Bit OS. If it’s Rev 1.1 or older there is only one way to find out…

The only caveat on 64 bit the way it is now, is you have to burn the 64 Bit to a micro SD card in step one. In step 2, connect the micro SD AND the USB 3.0 SSD to the RPi. The script will state there are two kernels, then ask if you want to switch them. The default kernel will not run a USB SSD to my knowledge, so one must switch to the RPi Foundation kernel. Then later in the script it will ask if you want to copy the OS to a USB SSD. Tell it yes, then the script will create a gpt partition table, partition the SSD, and format the SSD. The script will then copy the OS from the uSD to the SSD. After completion of Step 2, remove the uSD and leave the SSD connected. Then run Step 3.

Things are easier on the 32 Bit OS. In step one you only have to connect the USB SSD to the x86_64 computer and run the script. No uSD card necessary. As you have already seen, when sript sees it’s a 32 bit, the step 1 script will ask towards the end if the target device is a uSD card or SSD. Of course choose the appropriate one. Then connect the USB SSD to the RPi 4b and away you go for the step 2 script.

But still, the absolute fastest is with a 64 Bit OS on a USB SSD.


1 Like

I’ve been looking for help, so of course I’m sticking with you! :smiley:

I went for Sway here just to try it, but I’m a Plasma user usually. Every other one of my systems runs on Plasma, but I thought for the RPI something more lightweight would be good, because Manjaro ARM KDE was a lag-fest, while Raspberry Pi OS was smooth sailing. As I’m used to Plasma, my first experience with Sway was … a bit weird.

Yup, it’s 1.2.

This is what I’m going to try after work tomorrow then, because today I’m pooped. Time for bed.

Thanks for all your help so far! :slight_smile:

1 Like

You are welcome.


One last reply to end this topic:

Installing EOS ARM 64 bit has now succeeded. I now have my EOS ARM system up and running on a USB SSD. I followed the steps in your tutorial and everything went through flawlessly this time. Thank you so much for your help and your patience.

The only little hiccup was that, for whatever reason, I couldn’t install Sway. It didn’t really return an error, but just stated that installing sway failed. So I restarted the script and chose i3 this time, which succeeded.

Now I have to set everything up to my liking and get used to i3. There are already a couple of user-space issues that want fixing—like Firefox not starting, but those I can deal with one way or another. Also … i3 is weird. Especially since I’ve been using full-blown DEs for the last 25 years.

How is that working out for you btw? As I mentioned earlier, Manjaro ARM KDE on an RPI was a sh*tshow for me. Everything was laggy and slow and even video playback was horrid. And this really pains me, because I like Plasma and I’m used to it.

1 Like

The only Desktop Manager that is officially supported by Sway is ly. Lightdm-gdk-greeter sometimes works. It is a mess. To get around this:
login as your user, then type in “sway”.

However, sway is advertised as a drop in replacement for i3 except running on Wayland instead of x11. So using i3 is basically using sway except on x11.

I just upgraded to Firefox 98 on my RPi 4b 4 GB RAM 64 bit KDE Plasma on USB SSD. It wouldn’t even launch. I had to dowgrade to Firefox.97.2 and then FIrefox worked.

I am typing this now on my 64 bit KDE Plasma on USB SSD. It works quite well actually.
It is not as snappy as my Ryzen 7 2700, but subjectively it seems snappier than my Lenovo ThinkPad T430 running Plasma on an internal SSD.

I am using Plasma on my RPi 4b because this is where I do all my development work. Once I got used to scripting on Kate, there was no going back. Also love the way that Kate and Konsole interact by pressing F4. It’s like having an IDE.


1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.