Review of freshly installed Fedora 39 Workstation (Gnome GUI)

After Install Fedora Workstation 39 (Gnome GUI) – the look and feel of the GUI (Gnome – version 45.0).

  • Xorg X11 server – 1.20.14 and Xorg X11 server XWayland 23.2.2 is used by default
  • GNOME (the GUI) – 45.0
  • linux kernel – 6.5.6

The idea of this tutorial is just to see what to expect from Fedora 39 Workstation – the look and feel of the GUI, the default installed programs, and their look and how to do some basic steps with them. Here the reader finds more than 259 screenshots and not so much text the main idea is not to distract the user with much text and version information and 3 meaningless screenshots , which the reader cannot see anything for the user interface, but these days the user interface is the primary goal of a Desktop system. Only for comparison there are couple of old versions reviews, too – Review of freshly installed Fedora 38 Workstation (Gnome GUI), Review of freshly installed Fedora 37 Workstation (Gnome GUI), Review of freshly installed Fedora 36 Workstation (Gnome GUI) and more.
For more details about what software version could be installed check out the Software and technical details of Fedora Server 39 including cockpit screenshots. The same software could be installed in Fedora 39 Workstation to build a decent development desktop system.

For all installation and review articles, real workstations are used, not virtual environments!

SCREENSHOT 1) Fedora Linux (6.5.-300.fc39.x86_64) 39 (Workstation Edition)

main menu
grub 2.06 entry boot

Keep on reading!

Install Fedora Workstation 39 (Gnome GUI)

This article will show the simple steps of installing a modern Linux Distribution like Fedora 39 Workstation Edition with Gnome for the graphical user interface. First, it is offered the basic steps for installing the Operating system and then there are some screenshots of the installed system and its look and feel. Soon another article will show more screenshots of the installed and working Fedora 39 (Gnome and KDE plasma) – so the user may decide which of them to try first.
This is the most straightforward setup. One hard disk device in the system is installed, which is detected as sda and the entire disk will be used for the installation of Fedora Workstation 39. All disk information in sda disk device will be permanently deleted by the installation wizard!

The Fedora 39 Workstation comes with

  • Xorg X11 server – 1.20.14 and Xorg X11 server XWayland 23.2.2 is used by default
  • GNOME (the GUI) – 45.0
  • linux kernel – 6.5.6

Check out our review article about what GUI software is included in – Review of freshly installed Fedora 39 Workstation (Gnome GUI).

There are previous installations howto articles for the older Fedora 38Install Fedora Workstation 38 (Gnome GUI), Install Fedora Workstation 37 (Gnome GUI), Review of freshly installed Fedora 36 Workstation (Gnome GUI), Install Fedora Workstation 31 (Gnome GUI), Install Fedora Workstation 30 (Gnome GUI).

The following ISO is used for the installation process: https://download.fedoraproject.org/pub/fedora/linux/releases/39/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-39-1.5.iso
It is a LIVE image so you can try it before installing. The easiest way is just to download the image and burn it to a DVD disk (or make a bootable USB flash drive) and then follow the installation below.
The simplest way to make a bootable USB drive is to just use the Linux command dd. First, download the ISO file above and then plug the USB drive into the computer and find out the device name, it should be something of /dev/sda or /dev/sdb or /dev/sdc (execute the dmesg command in the console and check the last lines for the USB drive detection and its device name like /dev/sd?). After knowing the USB device name issue the dd command to overwrite it with the ISO. Note, all data will be lost if you use the following command with the device name mentioned in the command line.

myuser@mydesktop ~ # dd if=/mnt/media/OS/Fedora/Fedora-Workstation-Live-x86_64-39-1.5.iso of=/dev/sdc bs=8M status=progress oflag=direct
2013265920 bytes (2.0 GB, 1.9 GiB) copied, 17 s, 118 MB/s2129752064 bytes (2.1 GB, 2.0 GiB) copied, 17.9778 s, 118 MB/s

253+1 records in
253+1 records out
2129752064 bytes (2.1 GB, 2.0 GiB) copied, 18.0187 s, 118 MB/s

The USB flash drive should have at least 4G space. Using dd command will overwrite the data on the USB drive without warning or confirmation!

The user can check what device name the just-plugged USB Drive has with dmesg console command:

myuser@mydesktop ~ # dmesg|tail -n 17
[90470.220142] usb 2-1: new high-speed USB device number 7 using xhci_hcd
[90470.361406] usb 2-1: New USB device found, idVendor=1f75, idProduct=0888, bcdDevice= 0.15
[90470.361411] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[90470.361413] usb 2-1: Product: IS888 USB3.0 to SATA bridge
[90470.361414] usb 2-1: Manufacturer: Innostor Technology
[90470.361415] usb 2-1: SerialNumber: 088810000000
[90470.364298] usb-storage 2-1:1.0: USB Mass Storage device detected
[90470.364427] scsi host5: usb-storage 2-1:1.0
[90471.387214] scsi 5:0:0:0: Direct-Access     KINGSTON  SNV425S2128GB        PQ: 0 ANSI: 0
[90471.387439] sd 5:0:0:0: Attached scsi generic sg2 type 0
[90471.387649] sd 5:0:0:0: [sdc] 250069680 512-byte logical blocks: (128 GB/119 GiB)
[90471.387970] sd 5:0:0:0: [sdc] Write Protect is off
[90471.387974] sd 5:0:0:0: [sdc] Mode Sense: 03 00 00 00
[90471.388288] sd 5:0:0:0: [sdc] No Caching mode page found
[90471.388290] sd 5:0:0:0: [sdc] Assuming drive cache: write through
[90471.395432]  sdc: sdc1 sdc2
[90471.395543] sd 5:0:0:0: [sdc] Attached SCSI disk

The just-plugged USB drive is attached to the system with the device name /dev/sdc.

SCREENSHOT 1) Boot from the UEFI USB device.

It is the same as the CD/DVD removable drive. Choose the UEFI USB drive to boot the live installation.

main menu
UEFI BIOS USB device boot

Keep on reading!

LXC with SELinux and NFS share result in kernel: SELinux: inode_doinit_use_xattr: getxattr returned 2 for dev=0:43 ino=

After staring a new LXC container, the syslog program (Syslog-ng) began to throw thousands of errors with this kind of message:

Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-6977140995289226736
Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-6551465724643968476
Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-5980833553552494142
Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-8820947409424952637
Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-8270463809263745561
Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-7923279144252216900
Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-6181977668994943343
Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-7585065875445167421
Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-7923279144252216900
Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-5826517164673898101
Dec  1 10:50:36 srv kernel: SELinux: inode_doinit_use_xattr:  getxattr returned 2 for dev=0:43 ino=-7585065875445167421
Dec  1 11:01:01 h3 rsyslogd[1147]: imjournal: 3871493 messages lost due to rate-limiting (20000 allowed within 600 seconds)

These messages were logged in thousands. The same time, the NFS statistics showed a strange peak of using getattr. Something was calling getattr thousands times per second. Despite there were no SELinux blocks in audit.log as the dmesg suggested the SELinux might be blamed.
The LXC container is an application container, which has mound bind directory from the host server. The very same directory is an local NFS share (using NFS-Ganesha) of a GlusterFS volume and the PHP files are situated there.

main menu
kernel SELinux inode_doinit_use_xattr getxattr returned 2 nfsstat getattr graph

So the LXC container reads the PHP files from this NFS share. There were no issues to access the files and the application LXC worked just fine.
The problem disappeared when the NFS share was remounted with SELinux permissions using the context word:

node3:/VOL1 /mnt/nfs/VOL1 nfs defaults,hard,noexec,nosuid,_netdev,fsc,noatime,context="system_u:object_r:httpd_sys_rw_content_t:s0" 0 0

All the files are of SELinux label httpd_sys_rw_content_t and after restarting the LXC container there were no SELinux lines in the dmesg and the syslog logs. The administrator should configure the right SELinux permissions to the LXC bound directories. More on why SELinux sometimes does not report on blocks in the audit.log here – Selinux permission denied and no log in audit.log.

Degraded ext4 performance with millions files because of high system time in ext4_mb_good_group (100% kworker/u32+flush)

A strange behavior has been monitored in a storage server holding more than 20 millions of files, which is not a really big figure, because we have storage with more than 300 millions of files. The server has a RAID5 of 4 x 10T HGST Ultrastar He10 and storage partition formatted with ext4 filesystem with total of 27T size. Despite the inodes are only 7% and the free space is at 80%, the server began to experience high load averages with almost no IO utilization across the disks and the RAID device.
So the numbers are:

  • 20% free space.
  • 93% free inodes.
  • no IO disk utilization above 10-20% of any of the disks. In fact, the IO above 10% is very rear.
  • really high loads above the number of the server’s cores. The server has 8 virtual processors under Linux and the loads are constantly above 10-14.
  • no Disk Sleep blocked processes or Running to justify the high load.
  • the top command reports one or two kernel processes with 100% running – kworker/u32:1+flush-9:3 (so flushing the data takes so many time?)

If the problem were related to the disks or hardware, it would probably have been seen a high utilization across the disks, because the physical operations would need more time to execute. The high IO utilization across any disk, in deed, may result in a high system time (i.e. kernel time). Apparently, there is no high IO utilization across the disks and even no Disk Sleep blocked processes.
The FlameGraph tool may help to suggest the area where the problem related to.
First, install the git and perf tool (there are two interesting links about it with examples – link1 and link2):

dnf install -y perf git perl-open
git clone https://github.com/brendangregg/FlameGraph

Save a sample 60 second data with:

[root@srv ~]# perf record -F 99 -a -g -- sleep 60
[ perf record: Woken up 24 times to write data ]
[ perf record: Captured and wrote 7.132 MB perf.data (35687 samples) ]

And generate a SVG image of all the function, which are executed during this time frame of 60 seconds. It will give a good picture of what has been executed and how much time it took in the kernel and user space.

[root@srv ~]# cd FlameGraph
[root@srv FlameGraph]# ./stackcollapse-perf.pl ../out.perf > out.folded
[root@srv FlameGraph]# ./flamegraph.pl out.folded > kernel.svg

The SVG are shared bellow. It turned out most of the time during this sample period of 60 seconds, the Linux kernel was in ext4_mb_good_group, which is related to the EXT4 file system.
What fixed the problem (for now) – By removing files it was noticed the system time went down and the load went down, too. Then, after removing approximately a million files, the server performance returned to normal as the average other storage server (this one has unique hardware setup). So by removing files, i.e. INODES from the ext4 file system, the load average and the server ext4 performance were completely different from what it had been before.
The interesting part the inodes never went above 7% (around 24 million of 454 million available) and the free space never went down 20%, but when a good deal of files were removed, the bad ext4 performance disappeared. It still could be related to the physical disks or some strange ext4 bug, but this article is intended to report this behavior and to propose a some kind of a solution (even though a workaround).

SCREENSHOT 1) The kernel process running at 100% – kworker/u32:2-flush-9:3.

main menu
kernel process running at 100%

SCREENSHOT 2) Almost half of the time was spent at ext4 related calls.

main menu
ext4 and ext4_mb_good_group half of the time spent

Keep on reading!

Software and technical details of Fedora Server 39 including cockpit screenshots

main menu
cockpit overview on Fedora Linux 39

This article is for those of you who do not want to install a whole new operating system only to discover some technical details about the default installation like disk layout, packages included, software versions, and so on. Here we are going to review in several sections what is like to have a default installation of Fedora 39 Server using a real not virtual machine!
The kernel is 6.2.15 it detects successfully the Threadripper 1950X AMD and the system is stable (we booted in UEFI mode).
The installation procedure uses default options for all installation setups – Minimal network installation of Fedora 39 Server.

Software

With Fedora Server 39 you can have

  • linux kernel – 6.5.10-300 (6.5.10-300.fc39.x86_64)
  • System
    • linux-firmware – version: 20231030, release: 20231030-1.fc39.
    • libc – 2.38 (2.38-10.fc39)
    • GNU GCC – 13.2.1 (13.2.1-4.fc39)
    • OpenSSL – 3.1.1 (3.1.1-4.fc39) and 1.1.1q (1.1.1q-5.fc39)
    • coreutils – 9.3 (9.3-4.fc39)
    • yum – Depricated and replaced with dnf
    • dnf – 4.18.0 (4.18.0-2.fc39). The dnf5 is available, too (5.1.5-1.fc39)
    • rsyslog – 8.2310.0 (8.2310.0-1.fc39)
    • NetworkManager – 1.44.2 (1.44.2-1.fc39)
  • Servers
    • Apache – 2.4.58 (2.4.58-1.fc39)
    • Nginx – 1.24.0 (1.24.0-4.fc39)
    • MySQL server – 8.0.34 (8.0.34-2.fc39)
    • MariaDB server – 10.5.22 (10.5.22-1.fc39)
    • PostgreSQL – 15.4 (15.4-1.fc39)
  • Programming
    • PHP – 8.2.12 (8.2.12-1.fc39)
    • python – The default is 3.12.0 (3.12.0-1.fc39) and many more available – 3.13.0 (3.13.0~a1-1.fc39), 3.11.6 (3.11.6-1.fc39), 3.10.13 (3.10.13-1.fc39), 3.9.18 (3.9.18-1.fc39), 3.8.18 (3.8.18-1.fc39), 3.7.17 (3.7.17-3.fc39), 3.6.15 (3.6.15-20.fc39) and also includes the older 2.7.18 (2.7.18-35.fc39)
    • perl – 5.38.0 (5.38.0-501.fc39)
    • ruby – 3.2.2 (3.2.2-181.fc39)
    • OpenJDK – the latest 21 – 21.0.0.0.35 (21.0.0.0.35-1.rolling.fc39) and also includes 17.0.8.0.7 (17.0.8.0.7-1.fc39), 11.0.20.0.8 (11.0.20.0.8-1.fc39) and 1.8.0.382.b05 (1.8.0.382.b05-2.fc39)
    • Go – 1.21.3 (1.21.3-1.fc39)
    • Rust – 1.73.0-1.fc39 (1.73.0-1.fc39)
    • llvm – the latest 17.0.3 (17.0.3-1.fc39), 16.0.6 (16.0.6-5.fc39), 15.0.7 (15.0.7-4.fc39), 14.0.5 (14.0.5-6.fc39), 13.0.1 (13.0.1-5.fc39), 12.0.1 (12.0.1-9.fc39), 11.1.0 (11.1.0-11.fc39), 8.0.1 (8.0.1-5.fc39) and 7.0.1 (7.0.1-7.fc39.8)
    • Subversion – 1.14.2 (1.14.2-20.fc39)
    • Git – 2.41.0 (2.41.0-2.fc39)

Note: Not all of the above software comes installed by default. The versions above are valid as of November 2023, these are the minimum versions you get with Fedora Server 39 now, and updating it after the initial date may update some of the above packages with newer versions.
Installed packages are 682 occupying 1.7G space:. Note, this is Fedora Server Install, not minimal install. The server install includes the web console – cockpit version 254.

root@srv:~# dnf list installed|wc -l
682
root@srv:~# df -h /
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/fedora-root   15G  1.7G   14G  12% /

Keep on reading!

Minimal network installation of Fedora 39 Server

This article will show the simple steps of installing a modern Linux Distribution Fedora 39 Server edition. Fedora line offers many bleeding-edge Linux technologies than the more enterprise CentOS of the same RPM Linux family.

In fact, if the user needs a server with the latest Linux stable software Fedora server is the right and easy choice for a server!

It is interesting to compare to the other big rival Ubuntu Server, which has the latest software and upgrade path to the future release.
Here are some basic data from the default installation setup settings:

  1. Installed packages – ~682 occupying 1.7G of space.
  2. 3 partitions when using automatic partition layout – boot efi, boot and lvm.
  3. xfs used for the root and the boot partitions.

The Fedora 39 Server comes and updates to the latest stable Linux:

  • Linux kernel : 6.5.10.
  • Python : 3.12.0
  • GLibc : 2.38
  • OpenSSL : 3.1.1
  • systemd : 254.5

More detailed software overview here – Software and technical details of Fedora Server 39 including cockpit screenshots.

Of course, one can expect the latest version of GCC (13.2.1), PHP (8.2.12), GO (1.21.3), MySQL Server (8.0.34), PostgreSQL (15.4), NGINX (1.24.0), Apache (2.4.58) and so on. Almost all of them are the latest stable version on their Internet sites.
Just be careful, the Fedora life cycle is 13 months from the release to the EOL (End of Life)! Of course, a dist-upgrade is supported and indeed, it has been flawless for years!

We used the following ISO for the installation process from https://getfedora.org/en/server/download/:

https://download.fedoraproject.org/pub/fedora/linux/releases/39/Server/x86_64/iso/Fedora-Server-netinst-x86_64-39-1.5.iso

It is not a LIVE image so you cannot try it before installing it. The easiest way is to download the image and burn it to a DVD or USB stick disk and then follow the installation below (a USB flash drive could be also created from this ISO). The netinstall installation is as simple as having a good Internet connection to download the packages, the installation wizard automatically detects the closest mirror, from which it will download the packages. Essentially, the network does not differ from the ordinary installation except it expects to download the packages from the Internet. The good thing f network installation is that the bootable ISO is just 686Mbytes and the minimal install of the Fedora 39 Server will consume only around 686 Mbytes.
Here is how to make a bootable USB flash drive using dd:

root@srv ~ # dd if=/mnt/media/OS/Fedora/Fedora-Server-netinst-x86_64-39-1.5.iso of=/dev/sdc bs=8M status=progress oflag=direct
620756992 bytes (621 MB, 592 MiB) copied, 5 s, 123 MB/s719169536 bytes (719 MB, 686 MiB) copied, 5.87066 s, 123 MB/s

85+1 records in
85+1 records out
719169536 bytes (719 MB, 686 MiB) copied, 5.9026 s, 122 MB/s

The /dev/sdd is the removable USB drive. Be careful, it probably will with another name on a different system. Find the name by checking the dmesg.

SCREENSHOT 1) Select the UEFI OS (KINGSTON …), which is the USB flash drive connected to the server.

This USB flash drive is created by the Fedora Official ISO described above.

main menu
USB flash BIOS boot

Keep on reading!

List multiple connections with the same name using nmcli NetworkManager under CentOS

When using the NetworkManager it is possible to create multiple connections with the same name, which may result in confusion how to list them all and how to delete the unneeded ones.

main menu
List network connections

It is simple to create a connection with a certain name, activate it and then deactivate it:

[root@srv ~]# nmcli con add type ethernet con-name eno2 ifname eno2 ipv4.method manual ipv4.addresses 192.168.68.10/24
Warning: There are 3 other connections with the name 'eno2'. Reference the connection by its uuid '47488136-83bf-4394-b2aa-3123886ca9a5'
Connection 'eno2' (47488136-83bf-4394-b2aa-3123886ca9a5) successfully added.
[root@srv ~]# nmcli con down eno2
Connection 'eno2' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/6)

So after deactivating the “eno2” connection (the real network interface is with the same name) it is possible to create another connection with the name “eno2” using the same (or even other network interface).
If there are multiple connections with the same name, when creating a new one, there is a warning as it is shown above. There is also a line in the nmcli output, which indicates how many connections there are with this name:

 
[root@srv ~]# nmcli
br0: connected to br0
        "br0"
        bridge, AC:1F:6B:F6:F6:3C, sw, mtu 1500
        ip4 default
        inet4 192.168.0.10/24
        route4 default via 192.168.67.61 metric 425
        route4 192.168.0.0/24 metric 425
        inet6 fe80::c1d5:b200:7259:7e4d/64
        route6 fe80::/64 metric 1024

eno1: connected to bridge-slave-eno1
        "Intel I210"
        ethernet (igb), AC:1F:6B:F6:F6:3C, hw, mtu 1500
        master br0

eno2: disconnected
        "Intel I210"
        3 connections available
        ethernet (igb), AC:1F:6B:F6:F6:3D, hw, mtu 1500

lo: unmanaged
        "lo"
        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
        servers: 8.8.8.8 1.1.1.1
        interface: br0

Use "nmcli device show" to get complete information about known devices and
"nmcli connection show" to get an overview on active connection profiles.

Consult nmcli(1) and nmcli-examples(7) manual pages for complete usage details.

Under the disconnected connection name “eno2”, there is a line informing there are 3 connections available under this section.

To list all network connections use the short syntax, which will show all the connections identified by their unique identifier (UUID):

main menu
3 connections with the same name

Keep on reading!

Automatically start zram swap device on boot with systemd zram-generator under CentOS Stream 9

zram-generator package will install necessary tools to automate the creation on boot the compressed RAM devices. This article focuses on compressed swap devices.

main menu
install

As of writing this article, the latest version in the package system under CentOS Stream 9 is 0.32. The the latest version on the original page of the software is much higher number 1.1.2 and many of the following configuration options are marked as OBSOLETE, but they work in the 0.32 version included in CentOS Stream 9 (and the new configuration options does not!). That’s why it is important to check the included sample configuration file.
The package installs no configuration file, just a sample configuration file – /usr/share/doc/zram-generator/zram-generator.conf.example.
zram in the kernel space – https://docs.kernel.org/admin-guide/blockdev/zram.html

STEP 1) Install the zram-generator

It is easy and straightforward, just a single package:

[root@srv) ~]# dnf install -y zram-generator
Last metadata expiration check: 3:42:20 ago on Fri 20 Oct 2023 05:18:32 AM UTC.
Dependencies resolved.
==============================================================================================================
 Package                      Architecture         Version                      Repository               Size
==============================================================================================================
Installing:
 zram-generator               x86_64               0.3.2-7.el9                  appstream               409 k

Transaction Summary
==============================================================================================================
Install  1 Package

Total download size: 409 k
Installed size: 983 k
Downloading Packages:
zram-generator-0.3.2-7.el9.x86_64.rpm                                         2.1 MB/s | 409 kB     00:00    
--------------------------------------------------------------------------------------------------------------
Total                                                                         1.3 MB/s | 409 kB     00:00     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                      1/1 
  Installing       : zram-generator-0.3.2-7.el9.x86_64                                                    1/1 
  Running scriptlet: zram-generator-0.3.2-7.el9.x86_64                                                    1/1 
  Verifying        : zram-generator-0.3.2-7.el9.x86_64                                                    1/1 

Installed:
  zram-generator-0.3.2-7.el9.x86_64                                                                           

Complete!

STEP 2) Create a configuration and start the service

By default, there is no configuration file. The best place for it is /etc/systemd/zram-generator.conf.
Here is an example, which will fulfill the following:

  • Set the maximum RAM of the system, because it is a hard-coded 9G, by default. And if not redefined the device will be with 9G max memory no matter how much is tuned by the other options.
  • Set the RAM of the compressed device.
  • Set the fraction of the ram, which may be used by the device. Again as with the above configuration option, it is important, because it limits the maximum available memory to allocate for the compressed device.
  • Set the type of the device – filesystem or swap device.

There is the real world example configuration – /etc/systemd/zram-generator.conf

[root@srv ~]# cat /etc/systemd/zram-generator.conf
[zram0]
host-memory-limit = none
max-zram-size = 32768
zram-fraction = 1.0
compression-algorithm = zstd
swap-priority = 100
fs-type = swap

Keep on reading!

binutils and the error ld: unrecognized option ‘–no-dynamic-linker’

Yet another bites of an old bintuils installed in the system, which leads to an error and failed a building of glibc this time. The last time it was a kernel building failure, check out here – . Most of the time, these kind of errors occurs when upgrading an old system, so as soon as building the new binutils package with emerge it is mandatory to remove the old one to minimize compiling errors of this sort.

main menu
building failure

This time the error under Gentoo system is (but it could happen in any system with old and new binutils!):

/usr/lib/gcc/x86_64-pc-linux-gnu/11/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognized option '--no-dynamic-linker'
/usr/lib/gcc/x86_64-pc-linux-gnu/11/../../../../x86_64-pc-linux-gnu/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status

To fix the error simply remove the (all) old binutils package(s) with emerge command:

[root@srv ~]# emerge -vaC =binutils-2.25-r1
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean <atom>` to check for reverse dependencies before
 * removing packages.

>>> These are the packages that would be unmerged:

 sys-devel/binutils
    selected: 2.25-r1 
   protected: none 
     omitted: 2.41-r1 

All selected packages: =sys-devel/binutils-2.25-r1

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

Would you like to unmerge these packages? [Yes/No] yes
>>> Waiting 5 seconds before starting...
>>> (Control-C to abort)...
>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) sys-devel/binutils-2.25-r1...
No package files given... Grabbing a set.
<<<          obj /usr/x86_64-pc-linux-gnu/binutils-bin/2.25/strip
<<<          obj /usr/x86_64-pc-linux-gnu/binutils-bin/2.25/strings
<<<          obj /usr/x86_64-pc-linux-gnu/binutils-bin/2.25/size
<<<          obj /usr/x86_64-pc-linux-gnu/binutils-bin/2.25/readelf
......
......

Keep on reading!

Edit with systemctl edit to add restart on fail to a service – nfs-ganesha

A quick tip how to edit a service unit file under a c system like CentOS Stream 9 or Ubuntu. The best way is to edit it with the the tool “systemctl edit [service_name]”, which will trigger the default editor to open a temporary copy of the systemd unit file with the service name used with it. The default editor in the console is controlled by “EDITOR” variable and may be changed prior using the systemctl edit. After a successful manipulation of the system unit file the new one will be installed and a reload of the systemd unit files will be triggered with “systemctl daemon-reload” automatically. Indeed, it is just a text edit of a text file, which will do several actions when using “systemctl edit” command.

main menu
systemctl cat service

systemd options ro restart a service on fail are:

[Service]
Restart=on-failure
RestartSec=5s

Here, the example is to add a restart-on-fail functionality to the nfs-ganesha service (NFS service). The systemctl edit may be used for many other changes to the systemd unit file under the console and it is the easiest and proper way.

SCREENSHOT 1) Use “systemctl edit” to edit a copy of the systemd override unit file.

do not insert anything at the end of the comments or below the second red line comments – “### Lines below this comment will be discarded”. This temporary override file includes a systemd unit file of the service, which is opened for editing. The result override.conf file will only include the added lines, no other comments shown below the second red line.

main menu
systemctl edit opened

Keep on reading!