Stability Problems with Manjaro-ARM-gnome-rpi4-22.04

The latest so called stable version of the manjaro-ARM image is not given in every situation:
1.) If you see the workspace not to 100% (for a switch for example) and a program on it open and you click DIRECTLY on the close-button (x in the top right) then the system crashes.
2.) Browsers (Firefox and another time was it the Chromium) are showing on the taskbar with a never-ending-loading and that only, because I closed it. If the program was start from the terminal it was not happening all the time.

Is there any stable workaround? Because the weekly images are not working at all if you want to install the firefox or chromium - on the restart the monitor keeps black.

Manjaro Gnome seems to be the best solution for a Raspberry Pi 4 / 8GB, from the Performance Point of View - so I’m wondering that I’m the only one with problems (found those topics nowhere discussed). So if someone could help would be fine - otherwise we have to develop our System on another Desktop (Mate was without those effects).

In most scenarios - users are running of an SD-card. This works well for running network services like a webserver, dns and dhcp.

Depending on the quality of your SD-card - doing so with a fullblown OS desktop is likely to cause performance issues - even if you are using the 8G model.

I have been using Raspberry Pi since it was marketed for the first time.

I have several 8G pi’s and to get a reasonable performance you should use an attached USB3 disk - not a pendrive - but a real disk.

To squeeze it further - you should create a customized installation - adding only the parts you need.

It is also necessary to add either heatsinks or use an enclosure with built-in cooling.

I can recommend the ArgonOne casing with the M.2 enclosure.

You are welcome abuse my setup. It is found on

For the Argon case - I have extracted the necesaary details - those are stored at

Examples

1 Like

Gnome has released many bug fixes. Perhaps you should try the unstable branch, update all the gnome related packages and reverse to stable. And try gnome-x11 vs gnome-wayland. Don’t forget to change fkms to kms. And if you want the best performance you can test mutter-dynamic-buffering and installing and tweaking gnome-shell-extension-dash-to-panel (no transparency, 0ms…)

1 Like

I don’t know if the updates will help - have lost 2 SD-cards only because of manjaro-updates (at least one loss was my fault, because it takes too long and I switched of the energy). So maybe that helps, but what is the base: A stable version where you cannot directly close an app (because it crashes or otherwise after the opening or sometimes closing the loading-circle is active all the time)!?
And where you mention the updates: It is not possible to cancel those. I select NO CHECK for updates (before the internetconnection was given) and after an installation of One App the Updates were started automatically. :frowning:
We are really uncertain if we should risk such a system for a production-environment on our customers side.

PS: The Mate-Version is more stable, but has the same Update-problematic :disappointed_relieved: And by the way: After it the mouse-reaction has a bigger delay…

This Ticket can be closed I guess, because I only want to mention it - and there seems to be no workaround for now.

@tartanpion: How can the unstable-branch be set? Haven’t found any option for that.

I have reinstalled 2 weeks ago gnome and no particular problem. Just the last bugs of gnome corrected with 42.2 in the unstable version.
And I made what i have said before. Just don’t use the unstable branch for production environnement.
Perhaps the problem is in the beginning : have you use something like rpi-imager to install the good version ? And for production don’t use a sdcard, it will be corrupted soon or later.
And it’s normal that the system update, you can block a specific update or delay a general update to make feel secure. But it’s dangerous to block all the update.

That seems unlikely

There is no system which can counteract impatience

That is correct - and you shouldn’t - you need to learn how the sync process works

You can disable - the system sync in Pamac settings - but unless you know exactly what you are doing - this is not recommended.

Read up on how you maintain a Manjaro system


So, after a new risk and 2 hours updates - the start was not able anymore (waiting for 1 hour now).
If I use the arrow up key I see this. Does anyone know what is to do?
I cannot write anything and don’t know how to close this process cleanly (to not lost this ssd-card as well)? Or can I just disconnect the energy? The Pi doesn’t seem to work on it.

Because the Updates are done without my permission (I only installed one browser and select definitely NOT TO CHECK FOR UPDATES) Manjaro seems to be not the first option for production-processes.

What type of sdcard are you using. It should not take 2 hours for an update.

Something is causing data corruption. Overclocking the cpu is one thing that can cause corruption. From reading your posts above it really sounds like you have either a bad or slow sdcard with things trying to load up.

I have pretty much installed all images we provide and have never run into the issues you describe.

1 Like

I think this is a good one: SanDisk Extreme microSDXC 64GB + SD Adapter + Rescue Pro Deluxe 160MB/s A2 C10 V30 UHS-I U3
And the download is very fast - yes, it seems that the reason are writing/calculating issues. I use no overclocking, all from ground up. File from manajaro.org and image-program “balenaEtcher-Portable-1.7.9.exe” on Windows. Without any doubt so far - until now :frowning:

And my expiriences are round about 50 images in the last month. And yes, that is strange (because it is only on manjaro) therefore the forum-entry here. But anyway, I will disconnect the energy now - no other chance.

Do a test with a sdcard no larger than 32G if you have one.

Do you use the correct img ? Manjaro-ARM-gnome-rpi4-22.04.img. The advantage of rpi-imager is that the manjaro img can be directly downloaded.

yes, I took exactly this. And like I wrote, updates seems to be not optional when I want to install something. Which update/script cause the problems I cannot say, only that over 200 packages wanted to be updated.

…and yes, the third sd-card is destroyed as well. All, because the updates are (maybe corrupt but definitely) not controllable :frowning:

That’s because partial updates are not supported on a rolling release distribution. Every package assumes that you have the newest version of it’s dependencies installed. So the GUI updater also updates your system before installing the requested package. This is by design.

If you want to risk breaking your install, you can use sudo pacman -S <packagename> to install packages without updating.

Let’s assume that manjaro was not the culprit /img was tested by me and @Darksky .
Have you made a total repair and formatage before reusing a sdcard ?
Have you tested the checksum of the img ? do you have the latest eeprom update on the rpi ? the rpi-imager can make a check after the installation, don’t know for balena.
2 ou 3 destroyed or corrupted sdcard seems to be more a material problem : power supply, usb cable, changing the usb port, microSD card reader/writer, rpi4 itself ?
Because a bad installation will not boot but don’t destroy 3 sdcard unless a brutal loss of power and very bad luck.

The term stable refers to the set of packages which - at the time of creating the image - proved to provide a stable operating system.

When packages are pushed to the stable branch - they are stable - as they do not break the OS when synced to a system running under normal circumstances.

I have both 64G and 128G Sandisk cards - cards designed to be used with surveillance cameras - and they do not give up just because the system is synced :slight_smile:

The filesystem errors you describe with the image is caused by not shutting down the system in a clean manner. If you system appear to be hanging for some reason - switch to a tty and issue the shutdown command to ensure a clean shutdown

sudo systemctl poweroff

When you write the SD card using Etcher do not pull the card when writing is done - use the eject methoed from your file manager. Pulling the card immediately may cause corruption as some files may still be in system cache waiting to be written to the destination.