Upgrading from Debian 11 Stable to Debian 11 testing. Recompiling Retropie. Moving to bigger SD card.

Here's the short note on what has been done with my project over the last couple of months.

Upgraded from Debian 11 Stable to Debian 11 Testing

This was a piece of cake job. It's well documented in the official Debian documentation. 

Before I did that, I wanted to have an option to rollback, if things go wrong. For that I decided to use Timeshift to create a full backup of my system utilizing a spare 256 GB SD card I had. The tricky thing is, the GUI frontend of Timeshift is not fully functioning in Debian 11 Stable and it looks like it's a known bug. Hopefully the Timeshift CLI was functioning so I was able to make that backup.

The upgrade itself was long and boring and included quite a number of manual interventions, especially for the purposes of merging my modified config files from /etc to align them to what was in Debian 11 Testing. Do not worry, it's not something that you'll have to know about in advance - the apt will warn you when you need to review and make a decision on what to don, when you get there.

As a result of this upgrade, I have eventually got what I wanted - more fresh packages and a rolling-style of release. But subjectively the Xorg (or KDE) is working less stable on Testing - so no surprise it was a price to pay. I'd wish to give myself an advice to not upgrade (or roll back) but it is too late already and I'm lazy one :)

Recompiling Retropie (actually emulationstation, retroarch and libretro cores)

The first thing I have noticed after upgrading to Debian 11 Testing, is that RetroPie part of my distribution stopped working. 

This is how it is supposed to work and worked before I went with  upgrade: when I turn on or reboot my Orange Pi 4 LTS, Linux is booted into systemd' multi-user.target where I do have Retropie scripts started. These scripts run EmulationStation, which acts as a nice UI dashboard with different themes. It is working upon SDL library in a framebuffer mode, so no Xserver is invovled at this point, as it's just not existing in RetroPie distribution. From the EmulationStation you chose a platform (NES, SNES, PSX - you name it) and a game to play. When you click on a game, the EmulationStation runs a Retrorch and passes it a bunch of CLI parameters, which include a selected libretro core and the game ROM file location. You usually don't see Retroarch UI, unless you invoke in-game overlay menu, and for you it looks like you have just started the game directly from EmulationStation, which is off course is not true :) 

So in my case, when I tried to start the game, EmulationStation attempted to start Retroarch but then it was immediately returning back to EmulationStation, like Retroarch was failing to start. It wasn't a surprise for me, given the number of underlying libraries have changed because of aforementioned Debian 11 Stable -> Testing upgrade in my case. 

The solution was to go and recompile all "core components" of Retropie, using their own scripts ~pi/RetroPie-Setup/rertropie_setup.sh as I was hoping they should pick up all the latest libraries that are there in the system.

"Core components" here are:
* EmulationStation itself
* Retroarch
* Libretro cores

The tricky thing in there, is that I managed to install quite a number of additional Debian packages since this whole project started (like X11, hehe), but given:
- RetroPie, as a project, is bit behind from its "core components", which are independent projects, in terms of code base and patches
- RetroPie is probably relying on a particular version of OS (like Debian 11 Stable) and appropriate set/versions of libraries to be there - so they didn't care to accept a lot of patches from their upstream projects, like EmulationStation or Retroarch
- I have significantly changed versions fo all those packages in my system, with my upgrade to Debian 11 Testing
... it wasn't surprise that all of that started to fall apart and I wasn't able to finish the build successfully without manual intervention.

The intervention I'm speaking about was quite simple - just follow the below steps. The main idea is that you run the default script to recompile everything, wait for it to fail,  then deal with a failure, and then attempt to build that thing again. Exactly in this order:

1. Run a script to attempt to build for the first time
$ sudo ~pi/RetroPie-Setup/rertropie_setup.sh

2. In the CLI menu, select "Manage packages" -> "Core" -> "Update all installed packages"

This will run another script that does git clone (or git pull) and then running ./configure and make of all RetroPie "core components", one-by-one. 

The build will be happening in ~pi/RetroPie-Setup/tmp/build/ folder - you'll see different folders for different "core components" will be appearing in there, as the build progresses.

Build logs are put to ~pi/RetroPie-Setup/logs folder.

3. When you see the build fails, don't panic. Go and investigate the log, where exactly it failed. In my case the very first issue I had was:

In file included from /home/pi/RetroPie-Setup/tmp/build/emulationstation/es-core/src/components/DateTimeComponent.h:5,
                 from /home/pi/RetroPie-Setup/tmp/build/emulationstation/es-core/src/components/DateTimeComponent.cpp:1:
/home/pi/RetroPie-Setup/tmp/build/emulationstation/es-core/src/utils/TimeUtil.h:41:37: error: field ‘mTimeStruct’ has incomplete type ‘tm’
   41 |                         tm          mTimeStruct;
      |                                     ^~~~~~~~~~~

The very first hit from google where Arch people were discussing the same issue happening recently for their AUR package was exactly the fix I took. You'll need to go and modify ~pi/RetroPie-Setup/tmp/build/emulationstation/es-core/src/utils/TimeUtil.h file to add this include statement to the top:

#include <time.h>  <----- this one

#include <string>

Then you can repeat points 1 and 2 again (run the script and select an option to update all core packages) to see where it fails now.

4. Next issue was awaiting for me in a form of ffmpeg package I had installed to my system for my own needs. For some reason retroarch build scripts were trying to use it in one if Retroarch "drivers" (?) to record screen while playing a game I guess. This is the feature I don't use so I won't be missing it much. In terms of build log error it looked like this:

make: *** [Makefile:206: obj-unix/release/record/drivers/record_ffmpeg.o] Error 1
make: *** Waiting for unfinished jobs....
cores/libretro-ffmpeg/ffmpeg_core.c: In function ‘libretro_ffmpeg_retro_init’:
cores/libretro-ffmpeg/ffmpeg_core.c:243:4: warning: implicit declaration of function ‘av_register_all’ [-Wimplicit-function-declaration]
  243 |    av_register_all();
      |    ^~~~~~~~~~~~~~~
cores/libretro-ffmpeg/ffmpeg_core.c: In function ‘init_hw_decoder’:
cores/libretro-ffmpeg/ffmpeg_core.c:991:82: error: ‘AVStream’ has no member named ‘codec’
  991 |    struct AVCodec *codec = avcodec_find_decoder(fctx->streams[video_stream_index]->codec->codec_id);
      |                                                                                  ^~
cores/libretro-ffmpeg/ffmpeg_core.c: In function ‘select_decoder’:
cores/libretro-ffmpeg/ffmpeg_core.c:1101:49: error: ‘AVStream’ has no member named ‘codec’
 1101 |       format = fctx->streams[video_stream_index]->codec->pix_fmt;
      |                                                 ^~
cores/libretro-ffmpeg/ffmpeg_core.c: In function ‘open_codec’:
cores/libretro-ffmpeg/ffmpeg_core.c:1135:62: error: ‘AVStream’ has no member named ‘codec’
 1135 |    AVCodec *codec = avcodec_find_decoder(fctx->streams[index]->codec->codec_id);
      |                                                              ^~
cores/libretro-ffmpeg/ffmpeg_core.c:1142:31: error: ‘AVStream’ has no member named ‘codec’
 1142 |    *ctx = fctx->streams[index]->codec;
      |                               ^~
cores/libretro-ffmpeg/ffmpeg_core.c: In function ‘open_codecs’:
cores/libretro-ffmpeg/ffmpeg_core.c:1233:47: error: ‘AVStream’ has no member named ‘codec’
 1233 |       enum AVMediaType type = fctx->streams[i]->codec->codec_type;
      |                                               ^~
cores/libretro-ffmpeg/ffmpeg_core.c:1248:54: error: ‘AVStream’ has no member named ‘codec’
 1248 |                   && !codec_is_image(fctx->streams[i]->codec->codec_id))
      |                                                      ^~
cores/libretro-ffmpeg/ffmpeg_core.c:1283:54: error: ‘AVStream’ has no member named ‘codec’
 1283 |                AVCodecContext *ctx = fctx->streams[i]->codec;
      |                                                      ^~

I spent quite a time, trying to figure it out, how to overcome it. I tried to uninstall the ffmpeg package, but that wasn't helping. I tried to play around with configure and various generated define scripts - but that also didn't help. What eventually helped is to modify this script - ~pi/RetroPie-Setup/tmp/build/retroarch/qb/config.params.sh

In there you'll need to modify couple of parameters, to change their values from auto to no:

HAVE_FFMPEG=no

And then you're again free to go and repeat points 1 and 2.

5. The last build error I've got was this one:

(something X11-related cannot remember what exactly)

Knowing that RetroPie shouldn't be using any of X11 as it's running on top of SDL library in a framebuffer mode, we want to keep it as is. So go ahead to modify config.params.sh file again to change the value of HAVE_X11 parameter to no:

HAVE_X11=no

... and run the build again (repeat steps 1 and 2). This time it went just fine. 

 

Migrating everything to a bigger SD card

Initially for this project I bought 128 Gb SD card. It sounded about right, until I realized how big PlayStation 1 games could be. And I also wanted my SBC to host backup of my photos from my Android Phone and some movies. It wasn't long until I ordered another, 256 Gb SD card, but it was just lying around as a spare one.

So now the time has come and I need to move everything from one SD card to another. For that we need:

1. To boot our SBC out of its internal EMMC, which also has Linux flashed by manufacturer. It will just make things easier. For that we'll need to power off the device and eject the SD card and power it back on. 

2. Once Linux is boot up, we'll insert the SD card back and also will use a small USB SD card reader to insert our second SD card.

3. With using lsblk we figure it out, what is the name of our block device (under /dev/). In my case it was /dev/mmcblk1 and /dev/sda

4. With using dd we clone the entire disk, using block size of 4 Mb like this:

dd if=/dev/sda of=/dev/mmcblk1 bs=4M

This is where I started to get errors. dd was complaining it cannot read from source device (smaller SD card) after reading few tens of Gb from it. I run e2fsck / badblocks / some other utilites against it number of times, but all of them were  keep complaining and complaining, finding issues and not actually fixing them. 

I gave up and rebooted the system, using different power adapter and gave it another try. It went just fine this time, the only difference was that I cloned partition (i.e. /dev/sda1 to /dev/mmcblk1) instead of clonning the whole disk. After cloning was successfully finished, I ran the parted CLI partition manager to extend the fresh partition to span all 100% of disk and then tried to upsize the filesystem with resize2fs. This is where I started to see some issues again. I rebooted again, ran e2fsck and badblocks - none of them found anything, so I ran resize2fs again and this time it went fine. 

I'm guessing all these issues had something to do with the cheap USB SD card reader I had.

Retropie Rearm.It edition - quick guide to make it bit more useful for something different, than retrogaming

In my previous post I tried to summarize all the quirks and issues I hit while trying to make RetroArch (and partially Higan) work in Orange PI OS 3.0.0 and Armbian. The long story short - I failed and stopped trying. The reason for that is lack of my own experience at that time and misunderstanding, of what was actually wrong.

But I discovered a much more straightforward way to do that, thanks to a youtube channel I found which lead me to this website - ReARM.it and this discord channel. In a short, the wonderful guy, Arnaldo Valente is keeping a number of github repos, from which he builds images of batocera and retropie for a large number of ARM SBC boards, like the one I have.

I downloaded the fresh image of RetroPie for my Orange Pi 4 LTS board, flashed it to a SD card with Balena Etcher and off we go - everything went smoothly from there. Many retroarch cores are there and working.

Given I needed not only the gaming distro but also something I could use for more generic purposes I went few steps further and installed a number of packages on a top of it (also had my chance to play with nala):

# install nala, so we could potentially easily "undo" all the additional packages I'm about to install
echo "deb https://deb.volian.org/volian/ scar main" | sudo tee /etc/apt/sources.list.d/volian-archive-scar-unstable.list
wget -qO - https://deb.volian.org/volian/scar.key | sudo tee /etc/apt/trusted.gpg.d/volian-archive-scar-unstable.gpg > /dev/null
sudo apt update
sudo install nala-legacy

# install KDE + few extra packages I want to play withnala install task-kde-desktop neofetch kde-full systemsettings /
kwin-x11 kscreen plasma-nm kitty chromium mesa-utils plasma-discover /
 locate konq-plugins libkf5khtml-bin ksysguard bluedevil /
kde-config-sddm kde-config-systemd kde-config-screenlocker

Just few words on why this list is so crazy long. 

At first I just installed task-kde-desktop and was very surprised to see that my KDE Plasma was missing all stuff in the world, even the companion application to configure itself. I tried to fix that by installing kde-full on a top of that, but that alone didn't help. The help came in form of installing systemsettings package.

Another very unexpected issue I've got, is that in KDE all the application windows were created in a top-left corner of the screen and they were missing usual window decorations, like a maximize/minimize/close buttons, window captions - all that stuff. I can't imagine what geniuses decided to call a metapackage kde-full with that -full prefix, given it was missing a window manager. So I had to add the kwin-x11 to the list and start it manually once. 

Small update here: later on I figured it out, that lots of recommended / suggested packages were not installed by default because the distro was disabling this in /etc/apt/apt.conf.d/71-orangepi-no-recommends file
I realized It actually makes a lot of sense, as it allows to install just bare minimum amount of packages, and whatever you find is missing - you just install that and only that

konq-plugins was required for Konqueror so it won't be that barefooted and have all the normal options and configurations like all the other browsers do. The libkf5khtml-bin package was also needed for Konqueror to enable KHTML "engine" (you can switch them in "View" -> "View mode"). The default "Web Engine" of Konqueror doesn't react on Proxy settings and all of the Konqueror plugins were written for KHTML.

ksysguard is a KDE System Monitor app, nice to have all this plots in front of your eyes during your first steps with weighty KDE on such a measly SBC as Orange PI 4 LTS, to see what exact your UI actions are causing system to freak out.

bluedevil is a KDE frontend for bluez (Bluetooth)

plasma-nm - I was  missing the wifi / bluetooth notification icons in a KDE taskbar. This package brought it.  

kde-config-sddm is a KDE' systemsettings plugin (aka KCM - KDE Configuration Module) which allows you to manipulate with sddm settings directly in "System Settings'. Off course you can always go and edit/create config files in /etc/sddm/sddm.conf.d/ I used it to enable autologin for pi user and hide users with UIDs under 3000 (I was experimenting with nix as package manager and it created a lot of extra users which were shown in sddm-greeter)

 

kde-config-systemd and kde-config-screenlocker are two KCMs to play with systemd and to configure timeout and rest settings for screenlock

Making X to start after EmulationStation quits

I wanted my system to follow this behavior:
- by default it should boot into EmulationStation, as most of the time it will be hooked to TV and I'll be only using bluethooth gamepads
- if I quit EmulationStation it should start X.Org with KDE (if I need to do something bigger than gaming)

For that I changed the default systemd target to do not start X at system startup:

sudo systemctl set-default multi-user.target

... so it will launch EmulationStation. But if I quit ES, I want  to launch KDE - so I also modified /etc/profile.d/10-retropie.sh (this script is chain-called while booting into multi-user.target) to change the systemd target on a fly:







$ cat /etc/profile.d/10-retropie.sh  
# launch our autostart apps (if we are on the correct tty and not in X)
if [ "`tty`" = "/dev/tty1" ] && [ -z "$DISPLAY" ] && [ "$USER" = "pi" ]; then
    bash "/opt/retropie/configs/all/autostart.sh"
    sudo systemctl isolate graphical.target
fi

Probably later on I'll add some simple login menu with a timeout so I would be able to  bypass ES start and boot directly into KDE

Fixing some small bugs

Removing splash

There was just one thing which worried, me - is that the idiotic orangepi splash screen was showing up occasionally (when ES was launching RetroArch), so I disabled it at all  in /boot/orangepiEnv.txt

verbosity=1
bootlogo=false
overlay_prefix=rockchip
fdtfile=rockchip/rk3399-orangepi-4-lts.dtb
rootdev=UUID=30ae6b8c-ad3f-46b2-b323-4b9a05653ba9
rootfstype=ext4
extraargs="video=HDMI-A-1:1920x1080@60e"
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

After all that was done, I noticed that there was a very high CPU usageby sddm-greeter, which is a welcome/login app which flashes up the first in the X session, where you can select what desktop environment to choose. Looks like it's a well known issue, probably related to missing MESA drivers (they were installed by distro creator to some local location), so I fixed it with using this first hit from google, e.g. added this line to /etc/security/pam_env.conf

QT_QUICK_BACKEND DEFAULT=software

Reinstall SDL2

There's also one more thing I found, the SDL2 library which was coming with the distro was compiled without X11 support, so whatever linux native games I tried to start in KDE (like openttd) were requiring it, were firing up "Error: Couldn't find any suitable video driver".

The easiest thing would be to make a backup of that lib (just in case if it breaks something in RetroPie) and install the version from the repo. First check what version is available out there:

apt list libsdl2-2.0-0 -a

And then make a backup of current lib and install the version from repo on a top:

cp /lib/aarch64-linux-gnu/libSDL2-2.0.so.0.18.2 /lib/aarch64-linux-gnu/libSDL2-2.0.so.0.18.2.bak
apt-get download libsdl2-2.0-0=2.0.14+dfsg2-3+deb11u1
dpkg -i ./libsdl2-2.0-0_2.0.14+dfsg2-3+deb11u1_arm64.deb 
cd /lib/aarch64-linux-gnu/
unlink libSDL2-2.0.so.0
ln -s libSDL2-2.0.so.0.14.0  libSDL2-2.0.so.0

The above is lame. Don't do that. I'll update it. You don't want to hack apt cache with "downgrading" just a single package. You want to properly switch to normal SDL2 from debian repo, as I already tested that and it doesn't break "retropie" part of a distro. It might only break some of the linux ports in retropie, but I don't care, since I now have full-fledged desktop environment.

 

getting rid of connect-bluetooth.service

After installing the bluez from repo, apt created a proper bluetooth.serivce fo systemd. In the same time we have a connect-bluetooth.service which was coming as a part of retropie. In order for these two guys to not clash one into another and complaining about that to dmesg and journald

So it's better to disable the service which was coming with RetroPi:

systemctl disable connect-bluetooth.service

Don't you worry, your bluetooth gamepads, keyboards and whatever else stuff will be still working in EmulationStation, they'll be just served by default bluetooth.service. In the worst case scenario, you can always enable it back.

Tweaking KDE to debloat it a bit

Even with this the abovementioned apt setting in place to not install any recommended / suggested packages, KDE brings a lot of extra stuff with it, which is started together with the desktop environment. Like I found I do have a mysql database running as a part of KDE, lol. It was needed for Akonadi. If you don't want that to start automatically (like you're not using messangers on KDE all the time) you can get it disabled it in ~/.config/akonadi/akonadiserverrc

[Debug]
Tracer=null

[%General]
Driver=QMYSQL

[QMYSQL]
Host=
Name=akonadi
Options="UNIX_SOCKET=/run/user/1000/akonadi/mysql.socket"
ServerPath=/usr/sbin/mysqld
StartServer=false

Speaking of myself, I don't have any plans to use any messengers on this system at all, so I just removed these Akonadi packages altogether:

apt remove akonadiconsole akonadi-server

Also I disabled a number of KDE services from starting up automatically. Go to System Settings -> Startup and shutdown -> Background services and figure it out yourself which you don't need. I disabled:

• ColorCorrect Geolocation Updater (and these ppl are telling me Windows is full of bloatware?)
• Free Space Notifier (I'm able to watch after free space myself)
• KScreen2 (for this I just didn't find any reasonable description at all)
• KSysguard (I don't need a fucking deamon to lunch KSysguard! I can lunch it myself)  
• Remote URL change notifier
• Search Folder Updater (I'm an oldfag still using locate) 
• Touchpad (I don't have it).

If you're alike me and hate this modern trend of all operation systems (iOS, Android, Windows, Linux) to splash a whole bulk of alerts / notifications on you, then go to System Settings -> Startup and shutdown -> Autostart and disable KAlert

I also went to System Settings -> File Search and disabled it, as I'm more love to decide it myself when I want to run updatedb to reindex all files for my occasional uses of locate. 

It's kind of strange that the same file indexing option is appearing in two places on System Settings. Might be a UX bug. Will raise it

Go to System Settings -> Workspace behaviour -> Desktop effects and turn as much effects as you can. 

Go to System Settings -> Windows management -> Kwin scripts and disable all scripts   

System Settings ->Display and monitor -> Compositor select XRender until we fix OpenGL drivers

How to debloat your system even further

What I really love about Linux, is that you can configure or fix here almost everything and you really should develop this kind of skills into yourself.

Like in my case, when I brought the KDE I knew what kind of contract with devil I'm signing, with all it's zillion of modules, binaries an apps. But really I don't want  to spend hours understanding them all and carefully select only the ones I need and remove the rest ones. My favorite approach is - bring the default, and then fine tune it.  So what you can do is to make periodical manual system monitoring lookups to see what is running on your machine and what is consuming resources.  

The easiest way to to that is with using KSysGuard or htop. It makes sense to look at the list of running processes, sort them by memory and investigate top ones. Then sort them by CPU time used and do the same. If you find something odd there, lookup to see what package brought that binary.

I'll give you this simple example: I saw some odd cnf-update-db process was spinning on CPU a lot. I decided to see what package brought it to my system. For that it's better to have to update the locate' internal database first and then to find that file in our filesystem: 

$ updatedb
$ locate cnf-update-db
/usr/lib/cnf-update-db
/usr/share/command-not-found/cnf-update-db
$ ls -la /usr/lib/cnf-update-db 
lrwxrwxrwx 1 root root 40 Jan  6  2021 /usr/lib/cnf-update-db -> ../share/command-not-found/cnf-update-db
$ ls -la  /usr/share/command-not-found/cnf-update-db
-rwxr-xr-x 1 root root 683 Jan  6  2021 /usr/share/command-not-found/cnf-update-db

So you see, the first is just a symlink for the second. What package brought the actual file? 

$ dpkg -S  /usr/share/command-not-found/cnf-update-db
command-not-found: /usr/share/command-not-found/cnf-update-db

What other files this package brought?

$ dpkg -L command-not-found
/.
/etc
/etc/apt
/etc/apt/apt.conf.d
/etc/apt/apt.conf.d/50command-not-found
/etc/zsh_command_not_found
/usr
/usr/bin
/usr/lib
/usr/sbin
/usr/share
/usr/share/command-not-found
/usr/share/command-not-found/CommandNotFound
/usr/share/command-not-found/CommandNotFound/CommandNotFound.py
/usr/share/command-not-found/CommandNotFound/__init__.py
/usr/share/command-not-found/CommandNotFound/db
/usr/share/command-not-found/CommandNotFound/db/__init__.py
/usr/share/command-not-found/CommandNotFound/db/creator.py
/usr/share/command-not-found/CommandNotFound/db/db.py
/usr/share/command-not-found/CommandNotFound/util.py
/usr/share/command-not-found/cnf-update-db
/usr/share/command-not-found/command-not-found
/usr/share/command-not-found/command_not_found-0.3.egg-info
/usr/share/doc
/usr/share/doc/command-not-found
/usr/share/doc/command-not-found/README.Debian
/usr/share/doc/command-not-found/README.md
/usr/share/doc/command-not-found/changelog.Debian.gz
/usr/share/doc/command-not-found/copyright
/usr/share/locale
/usr/share/locale/de
/usr/share/locale/de/LC_MESSAGES
/usr/share/locale/de/LC_MESSAGES/command-not-found.mo
/usr/share/locale/fr
/usr/share/locale/fr/LC_MESSAGES
/usr/share/locale/fr/LC_MESSAGES/command-not-found.mo
/usr/share/locale/pl
/usr/share/locale/pl/LC_MESSAGES
/usr/share/locale/pl/LC_MESSAGES/command-not-found.mo
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/update-command-not-found.8.gz
/usr/share/python3
/usr/share/python3/runtime.d
/usr/share/python3/runtime.d/command-not-found.rtupdate
/var
/var/lib
/var/lib/command-not-found
/usr/bin/command-not-found
/usr/lib/cnf-update-db
/usr/lib/command-not-found
/usr/sbin/update-command-not-found

What this package is about?

$ apt show command-not-found
Package: command-not-found
Version: 20.10.1-1
Priority: optional
Section: admin
Maintainer: Julian Andres Klode <jak@debian.org>
Installed-Size: 105 kB
Depends: apt-file (>= 3.0~exp1~), lsb-release, python3-apt, python3:any
Suggests: snapd
Tag: implemented-in::python, interface::shell, role::program, scope::utility
Download-Size: 26.2 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.debian.org/debian bullseye/main arm64 Packages
Description: Suggest installation of packages in interactive bash sessions

Reading all that I can make quite a precise educated guess what was happening. Do you need this kind of courtesy of bash to give you the package you need to install, when you type some bullshit? If you're new to Linux then probably, in my case - I just better drop that package altogether, so it won't start its reindexing process when I don't expect it.

In some cases you might want to investigate it bit deeper, like some packages might be just buggy and overconsuming resources when they should not. Every case is unique, but the common approach is above. 

 

At the end of the day I'm having a nice looking desktop and together with all other services I'm running (like tor, ) it takes just below 500 Mb of RAM. I think it's kinda nice. 

We can always go beyond and switch KDE to something more light-weight, like dwm, bspwm or even awesome

Debloat it all!

Read a continuation of this story in another post - https://orange-pi-4-lts.blogspot.com/2022/08/debloating-your-linux-even-further.html

From it, you'll learn what important things you need to do, so the SD card you put into your SBC won't die in next year or so.

Some useful links

- Display manager - ArchWiki (archlinux.org)

- Updating RetroPie - RetroPie Docs and FAQ - RetroPie Docs