in my quest to create a very cost effective and energy-saving office-work station that still runs somewhat smoothly, I wanted to switch my Raspberry Pi’s OS from Manjaro ARM KDE (I know, probably not the best choice for what I want) to a more lightweight EndeavourOS ARM with i3 or something light and customizable like that. So much for the prologue. Now regarding my issues and the device itself:
I’m using a Raspberry Pi Model 4B 4 GB of RAM with the officially supplied PSU. It’s been running with Manjaro so far, so I can assume that both SD cards, that I tried, are functionally fine.
My issues:
I tried using the scripts supplied here, but to no avail.
On both SD cards, 32 GB and 64 GB, the script succeeded in installing base Arch. At least that’s what it told me. I then proceeded to insert the SD card into the RPI and tried to boot it. On all attempts of flashing base Arch onto the SD cards the RPI failed to boot, giving me an error code via the green LED: 4 quick flashes, i.e. 4 flashes: start.elf not launched. (See here.)
I was not able to fix or circumvent this and I have no idea what’s going on. I tried re-flashing Manjaro onto one of the cards to check if they were still fine, but my internet is rubbish and I decided to let the ISO download run overnight instead.
Instead of that, though, I tried manually installing base Arch by following the installation instructions on the Arch ARM site. This got me a little farther than before, alas, still not into a bootable, much less usable, system!
I now have graphical output on my display, instead of just the error code via green LED. I get the U-Boot menu and I can actually interact with it. I can cancel the boot by hitting a key and I can issue commands to U-Boot. In any case, U-Boot tries to boot Arch and everything looks promising:
I get a little “Welcome to Arch ARM” message (or something like that) and a whole lot of [OK]s, but after a bunch of lines, the screen just turns black and it stays like that.
At this point the RPI’s green LED starts flashing again, this time around though, it just flashes twice, instead of four times, which apparently lets me know that: 2 flashes: The SD Card cannot be read. (Again, see here.)
And here I am, fresh out of ideas and I’d be really grateful for any help and kind pointers.
One thing I should mention: I’m not using a USB SD card reader to flash the card, but the built in SD card reader from my laptop. I cannot imagine, why that would make a difference, but I wanted to mention it, as it seems that the Arch site only considers USB card readers.
Nope, doesn’t make a difference between USB SD reader and the built in SD reader.
The topic you referenced, is way out of date. The problem with a forum is Topics and their posts hang around forever. The EndeavourOS Arm web site provides better instructions
If you selected RPi 4b 64 Bit in step 1, when config-update is run the script will offer to switch from the linux-aarch64 kernel to the linux-rpi kernel. I strongly recommend switching to the linux-rpi kernel. It will also ask if you want to copy the OS to a USB SSD, say no for a uSD card. See more kernel information here in this post.
I am so sorry for the confusion, I linked the wrong URL!
I was actually following the Instructions from the EndeavourOS ARM site that you linked. That was the script I was referring to! The thing is that this didn‘t produce a bootable SD card.
I can‘t do step 2, if step 1 fails for me.
Just to make sure, I now tried following the instructions for step 1 again, but to no avail. The screen connected to the RPI stays black and the green LED flashes four times in quick succession, indicating the above-mentioned start.elf not launched.
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.
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.
I flashed that to a USB SSD using: sudo dd bs=4M if=/path/to/EOS.iso of=/dev/sdb status=progress oflag=sync
Booted my laptop into the EOS live environment.
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).
Inserted the µSD card.
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
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.
I choose “Raspberry Pi 4b 64 bit" hit the arrow right key and press OK.
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.
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.
I remove the µSD card from the USB-C hub and plug it into the RPI.
Everything I need is connected to RPI, so I plug in the power cable.
The screen stays black, the green LED flashes four times in quick succession over and over.
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.
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.
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.
Then
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.
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.
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.
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.
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.
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.
I’ve been looking for help, so of course I’m sticking with you!
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.
