DEV Community: Izhar Firdaus

The best practice method to install VirtualBox on Fedora 32/33 (and later)

Izhar Firdaus — Mon, 22 Feb 2021 14:55:00 +0000

In any linux distribution, there will be multiple methods to achieve a certain goal. You might have encountered many guides out there on how to install VirtualBox on Fedora, however, please take note, many of them uses intrusive methods which can be difficult to maintain in long run, and would likely to break after a kernel update.

Everytime I caught a new team member following those guides, I tend to get annoyed, so I think I should write up the best practice method of doing this, which I have practiced on my Fedora installation for years now.

Installing RPMFusion Repository

Packages governed in Fedora official repositories are subject to several legal and technical guideline. This mean, many software which are not 100% FOSS or not patent-encumbered would not be available in the official repositories because they would open the sponsors of Fedora to legal liability under the laws of United States.

Unfortunately, many free/open source software are patent incumbered, but while they might be illegal to distribute in the United States, they are perfectly legal to distribute in other countries.

Many of such packages are available in RPMFusion Repositories. Unlike many 3rd party repositories out there, RPMFusion contains the highest quality packages as its contributor also consist of people who package official RPMS in Fedora, and I generally recommend any new users of Fedora to install RPMFusion, especially if they are not US residents.

To install and enable RPMFusion on Fedora, you can install the release package using following command which will install both the free and nonfree repositories:

sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
    https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Installing VirtualBox

Once you have RPMFusion installed, you can then install VirtualBox from it. VirtualBox in RPMFusion is very well maintained, would remain functional after kernel updates through an automatic kernel module builder (akmods), and generally carry the latest version of VirtualBox.

sudo dnf install VirtualBox
sudo akmods
sudo modprobe vboxdrv

And you are done and can now launch VirtualBox from the application menu. Please take note however, VirtualBox does not go well together with libvirtd. If you havelibvirtd installed, it is suggested for you to disable it using:

sudo systemctl stop libvirtd
sudo systemctl disable libvirtd

Hope this guide will help you in installing VirtualBox in a less intrusive and more maintainable method.

Creating XDG custom url scheme handler

Izhar Firdaus — Thu, 18 Feb 2021 14:49:00 +0000

If you develop system tools or desktop software on Linux that also have an accompanying web application, you might want to have a way for the web application to launch the tool with some parameters specified through a web based link. For example, a link with dnf://inkscape as url, might be used to launch Gnome Software, and display the description of Inkscape, so that user may choose to install it or not.

In Linux, registering a custom URL handler can be done using XDG desktop file, of which it is configured to open x-scheme-handler MimeType.

To achieve this, you can simply create a .desktop in ~/.local/share/applications/, or/usr/local/share/applications, and configure it with MimeType=x-scheme-handler/<your-custom-proto>.

For example, if you have a script dnfurl which takes dnf://<package-name> as its first parameter and launch Gnome Software with the package name, you can create a .desktopfile with this content:

[Desktop Entry]
Version=1.0
Type=Application
Name=dnfurl
Exec=dnfurl %U
Terminal=false
NoDisplay=true
MimeType=x-scheme-handler/dnf

After installing the .desktop file, do run update-desktop-database to update the related indexes/cache. If you installed the .desktop file in ~/.local/share/applications/, you will have to run update-desktop-database ~/.local/share/applications. If nothing went wrong with the setup, you should be able to open links with the custom url protocol afterwards.

If you interested with the example dnfurl program above, you can check it out at this git repository: github.com/kagesenshi/dnfurl. Or if you are in Fedora, you can install it from copr by running:

dnf copr enable izhar/dnfurl
dnf install dnfurl

Have fun~.

How to get ILI9486 Raspberry Pi 3.5” LCD to work with Fedora ARM

Izhar Firdaus — Wed, 17 Feb 2021 06:29:00 +0000

Fedora ARM provides a full fledged Linux distro with rich ecosystem of server packages available for the ARM ecosystem.

However, ever since Fedora released an official ARM spin, specialized Fedora derivative for Raspberry Pi such as Fedberry and Pidora pretty much went out of development, and getting Rpi accessories to work with Fedora ARM, especially those that does not work with upstream Linux.org kernel, is not quite obvious,

In this tutorial, we would go about in getting ILI9486/XPT2046 3.5” LCD, which I bought from Lazada to work with Fedora ARM on Rpi3, up until the point where a framebuffer device is available for attaching CLI console to the display. The process provided by this tutorial in theory should also work with several other LCD devices, but because I only have this 3.5” LCD, so I can only test against it.

Installing Fedora ARM with downstream Raspbian Kernel

To start, you will need to use dwrobel’s spin of Fedora ARM image instead of the main official image. This image basically replaced the default Fedora kernel which is from upstream Linux.org kernel, to a kernel provided by Raspberry Pi Foundation. It is important for you to use this kernel to get the LCD to work, because a lot of kernel modules required to work with Rpi accessories are not yet available in upstream kernel for various reasons.

You will notice that the image download page splitted the file into two, fedora-server-aarch64-f33-20201230-sda.raw.xz.aaand fedora-server-aarch64-f33-20201230-sda.raw.xz.ab. You will need to merge these files into a single image before you can work with it:

# merge files
cat fedora-server-aarch64-f33-20201230-sda.raw.xz.aa \
    fedora-server-aarch64-f33-20201230-sda.raw.xz.ab \
    > fedora-server-aarch64-f33-20201230-sda.raw.xz

# verify checksum
sha512sum -c fedora-server-aarch64-f33-20201230-sda.raw.xz.sha512sum

After successful merging, you can then copy this image into your sdcard. Please take note, Fedora ARM Image Installer does not quite work correctly with this image.

# decompress
xz -d fedora-server-aarch64-f33-20201230-sda.raw.xz 

# dd into sdcard
dd if=fedora-server-aarch64-f33-20201230-sda.raw of=/dev/mmcblk0

Afterwards, you may want to resize the root partition to make use of the whole sdcard, to do this, disconnect and reconnect the sdcard to reload, and then lets run parted.

umount /dev/mmcblk0* # just to be sure
parted /dev/mmcblk0

Then use resizepart to resize the btrfs partition.

[root@chihaya ~]# parted /dev/mmcblk0                                     
GNU Parted 3.3
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print free                                                       
Model: SD SN64G (sd/mmc)
Disk /dev/mmcblk0: 63.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number Start End Size Type File system Flags
        1024B 4194kB 4193kB Free Space
 1 4194kB 516MB 512MB primary fat16 boot, lba
 2 516MB 3016MB 2500MB primary btrfs
        3016MB 63.9GB 60.8GB Free Space

(parted) resizepart 2                                                     
End? [3016MB]? 63.9GB                                                    
(parted) q
Information: You may need to update /etc/fstab.

[root@chihaya ~]#

The btrfs partition can now be mounted for adding your SSH key, for remote network access, which can be added using the following steps.

# mount
mkdir /tmp/disk
mount /dev/mmcblk0p2 /tmp/disk/

# add ssh key
mkdir /tmp/disk/root/root/.ssh/
cat /path/to/ssh/public/key > /tmp/disk/root/root/.ssh/authorized_keys
chmod og-rwx -R /tmp/disk/root/root/.ssh/

# remove root password 
sed -i 's/root:x:/root::/' /tmp/disk/root/etc/passwd

Static network IP can be configured using

cat > /tmp/disk/root/etc/sysconfig/network-scripts/ifcfg-eth0 << EOF
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DNS1=8.8.8.8
DNS2=8.8.4.4
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME="Default"
ONBOOT=yes
IPADDR=10.42.0.210
PREFIX=24
GATEWAY=10.42.0.1
EOF

Finally, unmount the sdcard.

umount /tmp/disk

If nothing went wrong with the steps, you can now hook up your Rpi to the network, boot it up and connect to it.

Setting up LCD framebuffer device

To setup the LCD device, you will need to install additional device tree overlays for the LCD. The LCD-show github repository from goodtft provides the necessary files, however, the script provided by the repo is designed to work only on raspbian based platforms. In Fedora ARM, we’ll have to do this manually with the following steps.

SSH into the Rpi

ssh 10.42.0.210 -l root

In /boot/config.txt, you will need to add the following lines before [pi4] section of the config (implicit [all] section).

hdmi_force_hotplug=1
dtparam=i2c_arm=on
dtparam=spi=on
dtoverlay=tft35a:rotate=90

Download the 3.5” LCD overlay:

wget https://github.com/goodtft/LCD-show/raw/master/usr/tft35a-overlay.dtb \
   -O /boot/efi/overlays/tft35a.dtbo

Reboot the device.

With the steps above, it should be enough to get the LCD working with a framebuffer device at /dev/fb1. The LCD should be showing black screen after the reboot.

You can then use this framebuffer device either to run a console, or to use with your PyGame application, or to run X server.

To test the framebuffer device, you can run the following command, and the screen should be showing random black and white dots.

cat /dev/urandom > /dev/fb1

You can also, configure the LCD device as the default kernel console output adding fbcon=map:10 fbcon=font:ProFont6x11 to the kernel boot option in /boot/efi/cmdline.txt, and reboot the device.

I have yet to try getting X GUI running on this, but I will definitely share once I got time to try and figure it out.

Hope this guide would be helpful to those who own such LCD and do share if you found this guide useful.

Is CentOS Dead? The reports of its demise are greatly exaggerated.

Izhar Firdaus — Tue, 16 Feb 2021 13:31:00 +0000

End of last year, CentOS project announced that they are shifting their focus to CentOS Stream.

Not surprisingly, this triggered a major outlash from users worldwide, especially from those who barely understand the change, and merely react to perception raised by various online media, who are not even contributors to the Fedora nor CentOS project. The general tone is, “RedHat have killed CentOS”, “CentOS is dead”, and similar perception.

However, this is far from truth. The focus to CentOS Stream is primarily:

an announcement that CentOS will no longer release point releases (8,1, 8,2, 8,3..)
smoothen out the flow for community contributions (“community” in this sense are people who work on improving CentOS, such as fixing bugs, who are not Red Hat employees)

No more point release

Historically, CentOS tracks RHEL, of which a new CentOS release is created, after a new RHEL release is launched. This make sense at the early days of CentOS, where it is primarily a rebranded rebuild of RHEL. But take note, the point releases of RHEL recent years, are primarily a snapshot of a specific state of the RHEL updates repositories, akin to a mid-release Fedora respin. This allows sysadmin to create a new installation with latest set of packages with latest bugfixes from the start, rather than installing an old point release, and yum update afterwards. A legacy from the era where internet was a fraction of the speed available today.

If you are a sysadmin that regularly run yum update on your server, basically nothing will change for you. If you use containers and always ensure you containers runs yum update during build, nothing will change for you too. If you only enable security updates, you too, will continue to have the same experience.

Empowering the Community in C(ommunity)Ent(erprise) Linux

This is something which I believe many users would barely appreciate, but is something very important to us who involve in Open Source OS level development, or involve in supporting our clients commercially. The traditional CentOS is not that open to community, because it is trying to keep bug-to-bug compatibility to RHEL. This is a problem when:

If you found a bug in a package coming from CentOS, and you want to contribute fixes to the bug, in the traditional flow, you would have to get this bug fixed upstream in RHEL, as it could not be accepted in CentOS.
If you created some packages, and want these packages to be part of the main distribution channels (eg: AppStreams), there are no clear way for this.

While majority of users who involve in application deployment, or userspace application development barely have any use case for above flow, for those who are involved with large enterprises and large projects that work closely with RHEL/CentOS ecosystem would face frustrations in the processes. This is especially true for projects such as OpenStack, OKD, oVirt, and companies such as Intel and Facebook, who uses, fix bugs and improve CentOS. The new change of project governance now would make it easier to the community to get involved.

Remember here, a “community” in an Open Source project are people who contributes to a project, which can be as doing something as simple as promoting the project, supporting/helping others in using the project in community forums, or something more complex such as fixing bugs and building new features. A user who only consume, while some may argue is part of the community, barely holds currency in influencing the direction of the project. One could not expect a consumer-first direction like what can be seen in commercial softwares, because in commercial softwares, the consumers are contributing back in the form of payment to the organization that produce the software, and that is a big influence. When the threshold of contributors drop in an Open Source project, or start to be mainly handled by a single person or organization, a project is more likely to die, or to turn to proprietary model in order to sustain itself.

Stability

Some argue that the switch to rolling release model of CentOS Stream would imply CentOS would now no longer be stable. But what exactly is “stable”?. In software development, the word “stable” can mean different things. To a consumer, “stable” is usually mean something would not crash, nor have issues. However, to developers, “stable” means a state of no changes nor updates.

Being “stable” in the sense of no updates, may not translate to “stable” of no issues. Modern software development usually applies agile methodology to develop software. An initial version of a software may not be issue-proof in its early releases, and would require constant updates to be rolled out to fix issues. However, constant updates would mean, the software is not “no-changes stable”. Traditional CentOS and RHEL is very resistant to changes due to its approach of minimizing updates, however, this results in an ecosystem where new bugfixes to softwares could not be easily rolled out, and also create an environment that is difficult to work with for modern agile developers who may require latest version of components, which carry latest bugfixes and improvements. Unlike the old days where software were developed in very slow waterfall model, modern application development demands faster adoption of updates, and there is a need to address this requirement.

Having said that, “no change stable” is also important, however, not in the sense of barely having changes. There can be changes, but changes are managed to minimize service distruption. How software developers traditionally manage this stability is through good release engineering which splits software releases into major and minor release. Within a major release, users of a software can expect no changes in the public interfaces of the software, and that all other software that depend on it would continue working, across all minor releases of the software. Minor releases would only be doing bugfixes, and new feature introduction, without breaking existing functionalities.

Circa 2013, there was an initiative in Fedora in creating a better, and more agile Fedora, called the Fedora.next Initiative. One of the result of that is Fedora Modularity, which is a new architecture where Fedora would have a base OS layer, which are maintained on its own stream, and “modules” where users may choose a specific major release of a software component, and only receive updates related to that major release. CentOS/RHEL AppStream repositories, introduced in RHEL8/CentOS8, was born from this initiative.

With AppStreams, you can now choose to, for example, enable only PostgreSQL 9 and subscribe to its updates and bugfixes, without risking your system updating to PostgreSQL 12, which is also available in the modularity repos. This create a platform that would allow better “issue-proof stability”, while keeping balance with “no-changes stability”.

With fixes landing in CentOS first before going into RHEL, it also opens up better opportunity for the community to receives fixes early, and bugfix contributions from the community would be easier to be accepted. Additionally, Fedora still play a role in ensuring stability of CentOS/RHEL, because introduction of new major features and major component versions will still land in Fedora first, instead of CentOS. Fedora still serve as the development ground for the next major release of CentOS/RHEL, through the Fedora ELN (El-nino / Enterprise Linux Next, whichever you fancy), Buildroot.

One might think that with CentOS receive fixes first before RHEL, CentOS is now a beta for RHEL, however, this is nonsense. Under that analogy, would the traditional setup where RHEL receives fixes first before CentOS, make RHEL a beta version of CentOS?. We all know that is false.

What’s with the EOL?

The announcement from CentOS of EOL-ing traditional CentOS is mainly about that they are stopping the effort to produce point-releases of CentOS 8. CentOS 8 will still continue to be supported until RHEL 8 full-support EOL, which is until 2024. CentOS 9 will still be released alongside RHEL 9, and that too, will be supported until RHEL 9 full-support EOL.

Hope this clears up the FUD about CentOS Stream that have been going around for a while now. You may also check out this presentation for additional information.

Don’t worry, CentOS will still continue to be a great Community-driven Enterprise Linux distribution.