Read time: 10 minutes – check the Table of Contents for overview. Hint – this full article is available as well as a PDF here.
Next Step: Dual Boot vs Virtual Machine, Yocto Poky vs Manjaro ARM
Dual Boot vs Virtual Machine
About a classical dilemma nowadays: Dual boot on windows OR a Virtual Machine – which is better and / or easier?
Why I had to choose? Because my test machine is not easily portable and sometimes I may have to work on my Laptop (HP ZBOOK 15 G5, Intel Core i7 Six-Core, 16 GB RAM, 512 GB SSD).
I decided for a Virtual Machine. I chose Virtual Box (because I know it). It has great features. Installing Manjaro was super-fast and easy.
Pros – when booting to Linux you have 100% control of HW, the environment is real, not emulated, it is a bit faster. If your machine is weak in CPU and RAM – this is the better option – cause otherwise you will have to split the CPU and RAM between two simultaneously running OSes.
Cons – You need dual boot bootloader on the HDD (which provides the OS choice upon HW start). Your laptop will never be the same. In order to switch between both – you need to reboot.
Pros – We have several famous technologies around, quite fast, quite good, with speed close to the real one. If your machine CPU has more cores – you can dedicate some to the virtual machine.
Cons – It is NOT real Linux or whatever OS you run on it. Testing for real a HW Kernel Module (driver in Windows world) is I guess – hard, for some particular tests – impossible.
Poky vs Manjaro for Raspberry Pi 4 (RPI4) Model B (4GB RAM)
What is Poky? It is a sample basic pre-setup Yocto project for your HW platform, the official term is a reference distribution. In other words – Yocto with a BSP (Board Support Package) for given HW, which means you start not from scratch. For RPI4 we have this Poky project.
Yocto is with steep learning curve. And I do have some experience with Manjaro already. And Manjaro has a RPI4 compatible build. So I chose this one and as it turned out – it worked like a charm.
When I’m ready with my SW I will switch to the RPI4 Poky and Yocto.
******* ******* ******* ******* ******* ******* ******
Raspberry Pi 4 Model B and Kuman 7 inch Touchscreen HDMI LCD – specs, Manjaro ARM installation and SD cards
HW overview of RPI4, available Manjaro port and my setup
From the official documentation for RPI4 lists:
- Quad core 64-bit ARM-Cortex A72 running at 1.5GHz
- 1, 2 and 4 Gigabyte LPDDR4 RAM options (mine is with 4 GB of RAM)
- H.265 (HEVC) hardware decode (up to 4Kp60)
- H.264 hardware decode (up to 1080p60)
- Video Core VI 3D Graphics
- Supports dual HDMI display output up to 4Kp60
- 802.11 b/g/n/ac Wireless LAN
- Bluetooth 5.0 with BLE
- 1x SD Card
- 2x micro-HDMI ports supporting dual displays up to 4Kp60 resolution
- 2x USB2 ports
- 2x USB3 ports
- 1x Gigabit Ethernet port (supports PoE with add-on PoE HAT)
- 1x Raspberry Pi camera port (2-lane MIPI CSI)
- 1x Raspberry Pi display port (2-lane MIPI DSI)
- 28x user GPIO supporting various interface options:
– Up to 6x UART
– Up to 6x I2C
– Up to 5x SPI
– 1x SDIO interface
– 1x DPI (Parallel RGB Display)
– 1x PCM
– Up to 2x PWM channels
– Up to 3x GPCLK outputs
- ARMv8 Instruction Set
- Mature Linux software stack
- Actively developed and maintained
– Recent Linux kernel support
– Many drivers upstreamed
– Stable and well supported userland
– Availability of GPU functions using standard APIs
Manjaro for ARM is located here: https://manjaro.org/download/
You go there, choose from the top level menu: Editions -> ARM -> Raspberry Pi 4 ->
And you have either XFCE or KDE Plasma build.
Xfce and KDE are two different Graphical Environments for Linux. There are literally tens. For Manjaro for RPI4 we have only the aforementioned. Long story short – Xfce is keeping for years the top place on minimal usage of resources (RAM, CPU, etc.), plus is due to this many times faster. I do monitor such articles in the last 7 years. Here is an article on this matter from 2017. As Xfce keeps the first place I downloaded it:
In particular this file (the image):
I just flashed it with Rufus version 3.8.1580 on a Micro SD and it worked from scratch! For Flashing with Rufus:
- Unzip the .img.xz file from above with 7zip
- In the first menu Device – Select your flash drive (your micro sd card shall be at least 8 GB, I recommend e.g. 32 GB Video Speed Class V30 or similar – more info in the next chapter)
- With the SELECT button select the resulting file Manjaro-ARM-xfce-rpi4-20.02.img
- All the other options are automatically selected, so press simply START:
Here is one nice how to if you need some more information.
Short and clear guide with screenshots on how the installation happens (really zero issues for newbies, super simple).
— — — — — — —
My HW Configuration for reference: RPI4, HDMI connected monitor (HP, widescreen), micro SD card with the OS image, USB connected wireless keyboard and mouse Logitech. And in addition – the RPI4 7 inch usb touchscreen display with HDMI (for which I will talk later)
Few points regarding the usage of Micro SD cards in this type of setup
First I tried on a 8 GB class 6 ADATA card. It did work. But it was slow – both on flashing with Rufus and later when I booted it (i.e. the loading of Manjaro as well as some basic operations. Stay calm – Terminal was fast).
I’ve bought (specially for the purpose of playing with RPI4) two high speed cards. This time I took a SanDisk Extreme 32 GB Video Speed Class V30. This is with speed up to 100 MB/s. Rufus was few times faster. Booting was faster, everything worked better.
Here are few important points when working with Raspberry Pi and an SD card:
- It is always better to have the power of the RPI via a UPS. Reason – if power goes down while programming or working with RPI – this might corrupt the memory and you will lose all your work – there are such cases reported in the past on the internet.
- Many people report that the SD cards quality degrades fast. Hence some articles on memory say you better get an eMMC SD card if possible. Reason – some OS processes may make hundreds of reads and writes per second to HDD (our micro SD) and the SD cards are not intended for such use. That’s why this was an issue years ago, I do have two colleagues (one of them embedded developer, the other PhD in electronics) that told me of some issues like this in the past with such projects.
- On the other hand :
A). Linux nowadays is super optimized, the best OS around, and would not write files to the HDD without a reason.
B). The SD cards nowadays are better
C). It looks like the amount of articles on this issue is located in the past (googling shows posts from 2012-2015).
D). This article says, that the problem may be e.g. that with some regular usage we might wear out the micro SD for 12-18 months.
E). Good technique is to keep any logging only in RAM and transfer it to file as rarely as possible (some info here).
Digging more on this revealed that the issue is not that bad any more:
This article gives some insights on some techniques for: Single Board Revolution: Preventing Flash Memory Corruption. It cites this important article: Which SD Card To Use In A Pi?.
One project which adds permanent UPS-like power support to your Raspberry Pi is available here.
And finally: Some points on SD cards storage persistence.
Now again about my RPI4 HW platform – I have:
– 4 GB LPDDR4 SDRAM (big enough, so the SD card will not be used as additional storage due to lack of RAM).
– I currently use SanDisk Extreme 32 GB Video Speed Class V30 – this is reported to be quite good and robust in one of the articles above. Though it is only in few comments – this means some people have tested it and are satisfied with the achieved results.
– I currently use an SD card quite bigger than what I need – so this will be definitely better for me. Reason – the internal controllers of the SD cards (for keeping the degradation of it lower) will have more free space to make the new memory writes and “play around” with data distribution.
– “df -h” on the terminal gives me total 30GB on my 32 GB card, 15% used, so I’m definitely in good position.
– The only additional memory module on my Pi – RPI4 has an SPI-attached EEPROM (4MBits/512KB), which contains code to boot up the system and replaces bootcode.bin previously found in the boot partition of the SD card. So I cannot use it as OS location (Manjaro Linux is few hundred megabytes big.) This also means – currently I cannot ask for more than what I have – e.g. a big OTP, EEPROM or sth. else.
A bit more information on the booteeprom from the official RPI page is available here.
Hence the current conclusion is – I stick with the good high quality Micro SD I have, keep backups of my work, try to NEVER write too much stuff on it hundreds of times per second and we rock and roll :).
A final hint – some guys connect a fast external HDD via one of the USB 3.0 ports and use the SD card only for booting. I checked and good fast SSD based external USB3.0 drives are already available on the market. I don’t want to do this now, neither to spend those 80-100 USD on such a device. But for any of you who would like to try – this is an option :).
******* ******* ******* ******* ******* ******* ******
What to do on RPI4 after installing Manjaro
Connecting the Internet / Network via LAN
Without it pacman and pamac will not work. I did this with wired LAN connection. This version of Manjaro has a reported bug with WiFi! (That’s why it is good to take a look to some release notes 😉 )
By the way I tried the WiFi – it found my network, but didn’t connect, don’t know if it will work on your setup – I recommend trying it. As LAN works for me I will not dig deeper for how to fix this for now :).
Keyboard shortcuts for Terminal and how to search in it
Ctrl+Alt+t – Start a Terminal. By the way – you can start whatever number of instances of the Terminal. On my test PC though Ctrl+Alt+t behave a bit strange – it switches between the two started Terminals. On RPI4 it simply starts a new one.
Ctrl+Shift+t – makes a new tab in the current Terminal. Ctrl+PgUp / PgDwn switch the tabs.
Ctrl+Shift+f – Find some string in all the text currently present in the Terminal printed scrollable buffer.
I recommend not working with more than 3 Terminals or too many tabs – you might miss sth. Tabs are cool and have a drag and drop feature to take them out as a separate terminal.
The Alt+TAB though behaves strange with multiple terminals… Normally I work with max 2, so I don’t care more for now.
Basic Info about pacman
$ pacman -Qs XXXXXXX – read the version of the given package XXXXXXX
$ pacman -Syyu – Force pacman to refresh ALL the package lists – Mirrors can be out of sync and the package list from the old mirror may not correspond to the package list of the new mirror, even though the dates of the lists may suggest that they do. – After creating/editing /etc/pacman.d/mirrorlist, issue the following command: pacman -Syyu. Unless you know you need the double -y, please don’t use it. It force-downloads the package database from the package server even if the one on your system is already up to date, creating unnecessary traffic. A typical use case would be a captive portal that redirects the request to an HTML login page, or a badly configured server replying with an HTML page that says “404” (but doesn’t properly set the HTTP 404 status code).
$ pacman -Syu – update all packages
$ pacman -Syu XXXXXXX – update XXXXXXX package explicitly!
$ pacman -S XXXXXXX – install specific package
$ pacman -h – to list all options
Update the pacman mirrors to ensure fast operation
This takes few minutes, but it is definitely worth (I tried before and after – download speed increase was few times!). So in order any installation to be as fast as possible, and so that you don’t wait for minutes to download e.g. some 3 MB package:
$ sudo pacman-mirrors –fasttrack
Then to update packages:
$ sudo pacman –Syu
More information here.
Increase the Terminal backlog
This is the amount of lines it keeps buffered. So we want it big – e.g. 8000 lines. By default on RPI4 it is 1000 lines. Longer is necessary, as sometimes some operations produce a lot of output on the Terminal. And building bigger projects is one of them. Not to mention regular build/install procedures for some packages.
By one of the companies I worked for the standard build output of the project was over 3200 lines, by other over 5000 – and this is nothing out of the ordinary :).
You will often probably want to have the log on what has been done on your system during those, or the complete log of your build.
So – with the mouse open in Terminal on the top line the menu Edit -> select Preferences -> In the first tab General – > change the field Scrollback to minimum 8000.
You can later either select some portion of text and copy it to a text file, OR – right click in the Terminal and choose “Save Contents” (which will save the full log in the currently open Terminal).
Install base-devel, obligatory
In order to be able to develop, compile and so on: we need base-devel package group (it is also crucial for compiling AUR packages):
$ pacman -S base-devel –needed
The last flag here asks pacman to install only what is needed.
Add a Text Editor
As Manjaro for ARM doesn’t provide this by default – I’ve installed the Gedit simple text editor with this command:
$ sudo pacman -S gedit
I wanted also Sublime. So Sublime text – via pacman (as I don’t want snaps and other additional SW on my RPI4) install instructions are here. Unfortunately – for ARM 64 (aarch64) Sublime is not built! So it cannot be installed.
As a substitute I chose Code::Blocks and simply added it via the Add/Remove GUI from the main menu.
Colorizing Terminal and adding to $PATH permanently
It is definitely good to have some colors there. It just helps. And Manjaro ARM has less colors compared to regular Manjaro for x86. So:
— — — — — — — — —
In order to make your command line in color – in particular the:
In terminal open with sudo and gedit the .bashrc file. It is a hidden file in your home directory (where the Desktop, Downloads and so on are located). By the way – you can change the File Manager to show for you the hidden files from the menu View -> Show Hidden Files, or pressing Ctrl+h from the key board. Anyway:
sudo gedit .bashrc
In it at the end add the line (on one line!):
export PS1=”\[\e[32m\][\[\e[m\]\[\e[32m\]\u\[\e[m\]\[\e[33m\]@\[\e[m\]\[\e[32m\]\h\[\e[m\]:\[\e[36m\]\w\[\e[m\]\[\e[32m\]]\[\e[m\]\[\e[32;47m\]\\$\[\e[m\] “
Then save, exit. Restart the terminal. More information: here.
— — — — — — — — —
There are some colorizers and I have chosen to try Cope – it colorizes quite a lot of commands when it succeeds to fetch the output and execute the perl scripts it is based on.
First get the files:
[user@group: current_Directory]$ cd Downloads
[user@group: current_Directory]$ mkdir cope
[user@group: current_Directory]$ cd cope
[user@group: current_Directory]$ git clone https://github.com/yogan/cope.git
An advantage of this method is that you can easily get updates to the package via git pull.
Then as cope says:
[user@group: current_Directory]$ perl Makefile.PL
[user@group: current_Directory]$ make
[user@group: current_Directory]$ make test
[user@group: current_Directory]$ sudo make install
Then, find out where perl put the scripts: $ perl cope_path.pl
And add that to your $PATH.
— — —
My issue: perl Makefile.PL gave an error: Can’t locate inc/Module/Install.pm…..
I thought I need a package called: perl-module-install.
Interesting is that I have perl-module-install, checked with :
pacman -Qs perl
Finally simply retrying the command helped:
$ perl Makefile.PL
— — —
I did get some errors in the second and third step.
In particular the Test showed me 5 out of 67 tests failed. As far as I understood – this means some colorization would not work, but no critical issues, so I go forward.
I saved the Terminal log – it was over 1000 lines long – so that I know what have been done.
I finally called sudo make install.
And reached the final step: add the perl scripts location to path, extracting the path with this call:
$ perl cope_path.pl
— — —
Here is How to add sth. to $PATH permanently:
***** ***** *****
About environmental variables in Linux: In Linux and Unix based systems environment variables are a set of dynamic named values, stored within the system that are used by applications launched in shells or subshells. In simple words, an environment variable is a variable with a name and an associated value.
Environment variables allow you to customize how the system works and the behavior of the applications on the system. For example, the environment variable can store information about the default text editor or browser, the path to executable files, or the system locale and keyboard layout settings.
to print them:
To set your $PATH permanently you can edit your shell’s configuration file. For BASH that’s normally ~/.bashrc or ~/.bash_profile.
***** ***** *****
After reboot I do have some colorization and it is definitely helpful!
More information on colorization here, in the section for “Universal wrappers”.
Install an “AUR install helper” package
Why using a helper? Cause it saves time and makes the full compilation process for you, solving dependences and so on.
YAOURT (which I used in the past) is no longer supported and here are some other alternatives we may use.
I have chosen YAY. You can install yay by cloning the git repo and building it. Use the below commands:
$ cd Downloads
$ git clone https://aur.archlinux.org/yay.git
$ cd yay
$ makepkg -si
Searching an application through Yay in AUR:
$ yay -Ss <package-name>
Installing an application:
$ yay -S <package-name>
It is written in Go programming language, so requires the Go environment… that’s why it will require few hundred MB of space. But I’m Ok with it considering my big SD card and my potential need for AUR packages.
Some generic hints on yay you can find here.