Install Fedora 39 KDE Plasma Desktop (KDE GUI)

This article will show the simple steps of installing a modern Linux Distribution like Fedora 39 KDE Plasma with KDE for the user graphical 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 of it. Here is another article available with more screenshots of the installed and working Fedora 39 KDE Plasma – coming soon. If the user is interested in Gnome as a graphical interface there are two articles on how to install Fedora 39 Workstation Edition, which comes with GNOMEInstall Fedora Workstation 39 (Gnome GUI) and Review of freshly installed Fedora 39 Workstation (Gnome GUI).
This is the simplest 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 39 KDE Plasma. All disk information in sda disk device will be permanently deleted by the installation wizard!

The Fedora 39 KDE Plasma Desktop comes with

  • Xorg X11 server – 1.20.14 and Xorg X11 server XWayland 23.2.2 is used by default
  • linux kernel – 6.5.6
  • KDE Plasma version: 5.27.8
  • KDE Frameworks version: 5.110.0
  • QT version: 5.15.10

For more packages and versions information the user may check out the Fedora 39 server articles – Software and technical details of Fedora Server 39 including cockpit screenshots.

We used the following ISO for the installation process:

https://fedora.ipacct.com/fedora/linux/releases/39/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-39-1.5.iso

It is a LIVE image so you can try it before installing it. The easiest way is just to download the image and burn it to a DVD disk or to flush a USB drive with the ISO. Just use the Linux command dd and a USB flash drive. It’s worth mentioning the dd command will destroy all data on the USB drive and overwrite it with the Fedora KDE Live ISO, so be sure to use a UBS Flash, which data is not important or with no data on it. The dd command uses the ISO as input and the output is the USB drive in Linux device form as /dev/sd?. For the following dd command, the USB drive is /dev/sdd

dd if=/mnt/media/OS/Fedora/Fedora-KDE-Live-x86_64-39-1.5.iso of=/dev/sdd bs=8M status=progress oflag=direct
2399141888 bytes (2.4 GB, 2.2 GiB) copied, 24 s, 99.9 MB/s2481055744 bytes (2.5 GB, 2.3 GiB) copied, 24.8488 s, 99.8 MB/s

295+1 records in
295+1 records out
2481055744 bytes (2.5 GB, 2.3 GiB) copied, 24.8797 s, 99.7 MB/s

SCREENSHOT 1) Boot from the UEFI USB Drive Kingston device.

It is the same as the USB CD/DVD-ROM bootable removable drive. Choose the UEFI USB CD/DVD drive and boot the installation live drive.

main menu
UEFI BIOS DVD-ROM boot

Keep on reading!

Govee WiFi Thermometer Hygrometer H5179 cannot connect to the Wi-Fi

Govee WiFi Thermometer Hygrometer (model H5179) uses 3 AA batteries, which may last year or two depending on the period of pushing the data to the severs in the Internet (i.e. using the Wi-Fi module). The device may suddenly to begin losing Wi-Fi connection or even stop connecting to it, which is an indicator that the batteries should be replaced. Despite that the battery indicator in the app is full, the batteries probably supply low voltage to the electronics in the device that’s why the Wi-Fi begins not to work properly! The device may have kept normal Bluetooth operation for several month leaving the user wondering what is going on! In fact, problems with the Wi-Fi module is the first signal for a battery replacement.
There three screenshots of a device, which works perfectly fine without the Wi-Fi. It reports via Bluetooth the temperature and keeps track of it, but cannot connect to the Wi-Fi, despite it says the Wi-Fi settings are successfully saved.

SCREENSHOT 1) In the device settings the Wi-Fi is successfully set and the device immediately tries connecting.

main menu
settings Wi-Fi successfully set

Keep on reading!

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!

nginx with SELinux and ngx_http_lua_module – PANIC: unprotected error in call to Lua API

main menu
runtime code generation failed restricted kernel

The CentOS 8 (CentOS Stream 9, too) might prevent to successfully execute a Lua code in NGINX web server with the modules like ngx_http_lua_module because of insufficient SELinux rules. By default, the web server is not allowed to execute programs that require memory addresses that are both executable and writable. Using Lua code may even crash with a core dump and restart of the NGIX worker process. The error logs contains information for the incident:

PANIC: unprotected error in call to Lua API (runtime code generation failed, restricted kernel?)

In fact, the error message hints what is going on – that the kernel prevents the execution of a code, which might be an addition limit enforced to this system.
Searching through the SELinux audit log shows the solution by enable the httpd_execmem SELinux boolean.

[root@srv ]# ausearch -c 'nginx' --raw | audit2allow


#============= httpd_t ==============

#!!!! This avc can be allowed using the boolean 'httpd_execmem'
allow httpd_t self:process execmem;

Apparently, the Lua code used needs a privileges to execute a code in the memory addresses (execmem). So when using the OpenResty ngx_http_lua_module, which is not distributed with the NGINX server, the server administrator should enable to true the SELinux boolean – httpd_execmem with:

setsebool -P httpd_execmem=1

The “-P” is going to make the value persistent over reboots.

Note, the official manual for the SELinux boolean. By enabling the httpd_execmem, several SELinux rules are applied, which may make the web server less secure, because the web server process is allowed to execute code in the memory.

– httpd_execmem

When enabled, this Boolean allows httpd to execute programs that require memory addresses that are both executable and writable. Enabling this Boolean is not recommended from a security standpoint as it reduces protection against buffer overflows, however certain modules and applications (such as Java and Mono applications) require this privilege.

The AVC (Access Vector Cache) message looks like:

type=AVC msg=audit(1699774004.724:59165857): avc:  denied  { execmem } for  pid=3872876 comm="nginx" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process permissive=0
type=SYSCALL msg=audit(1699774004.724:59165857): arch=c000003e syscall=10 success=no exit=-13 a0=7f399cd69000 a1=10000 a2=5 a3=38 items=0 ppid=884311 pid=3872876 auid=4294967295 uid=990 gid=987 euid=990 suid=990 fsuid=990 egid=987 sgid=987 fsgid=987 tty=(none) ses=4294967295 comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0 key=(null)ARCH=x86_64 SYSCALL=mprotect AUID="unset" UID="nginx" GID="nginx" EUID="nginx" SUID="nginx" FSUID="nginx" EGID="nginx" SGID="nginx" FSGID="nginx"
type=PROCTITLE msg=audit(1699774004.724:59165857): proctitle=6E67696E783A20776F726B65722070726F63657373

More on NGINXhttps://ahelpme.com/tag/nginx/ or SELinuxhttps://ahelpme.com/tag/selinux/.

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!