BIOS vs UEFI

Both BISO and UEFI constitute an interface between the Operating System and the firmware of the hardware platform. They are pieces of software that is embedded on some chip or controller on the hardware, i.e. the motherboard of a server. Both BIOS and UEFI look for instructions on the disks that help locate the respective bootloader. BIOS Looks for the MBR (Master Boot Record) in the first sector of the disk. UEFI looks for the .efi files that are located in the EFI Special Partition (ESP) under /boot/efi/EFI/. Once the bootloader is located, the interface (BIOS or UEFI) loads it in memory and give it control for the rest of the OS boot operations.

Preprovisioned tuning profiles

user1@rhel10-vm2:~$ ls /usr/lib/tuned/profiles
accelerator-performance  balanced          desktop      intel-sst            network-latency     optimize-serial-console  throughput-performance  virtual-host
aws                      balanced-battery  hpc-compute  latency-performance  network-throughput  powersave                virtual-guest
user1@rhel10-vm2:~$

Verify and change tuning profiles

Verify that the tuned service is installed with DNF:

user1@rhel10-vm2:~$ dnf list --installed | grep tuned
tuned.noarch                                   2.25.1-2.el10_0                @rhel-10-for-x86_64-baseos-rpms   

Verify the status of the service with systemctl:

user1@rhel10-vm2:~$ systemctl status tuned
● tuned.service - Dynamic System Tuning Daemon
     Loaded: loaded (/usr/lib/systemd/system/tuned.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-08-21 19:29:51 CEST; 1h 15min ago
 Invocation: fa8cec68b5b449ee9d4f13e2ef0a4618
       Docs: man:tuned(8)
             man:tuned.conf(5)
             man:tuned-adm(8)
   Main PID: 936 (tuned)
      Tasks: 4 (limit: 10680)
     Memory: 17.7M (peak: 19.7M)
        CPU: 952ms
     CGroup: /system.slice/tuned.service
             └─936 /usr/bin/python3 -Es /usr/sbin/tuned -l -P

Warning: some journal files were not opened due to insufficient permissions.
user1@rhel10-vm2:~$

Display the list of available tuning profiles:

Definition

Syslogs contain subsets of information on faults, events, audit & session data, all related the monitored objects. Not all logs depict errors. Syslog can include audit and event logs.

Syslog Facilities

Any program or process capable of generating syslogs.

Syslog Severities

aka syslog severity levels or syslog priorities. The describe different levels of importance. Example of syslog severities: emergency, alert, critical, informational, warnings.

How Linux implements logging

rsyslogd

Verify the version of rsyslogd deployed on a RHEL machine:

Finding the kernel packages

The Linux kernel is not a monolithic file but rather a set of RPM packages.

Find out the installed kernel packages:

user1@localhost:~$ rpm -qa *kernel*
kernel-modules-extra-matched-6.12.0-124.8.1.el10_1.x86_64
kernel-tools-libs-6.12.0-124.8.1.el10_1.x86_64
kernel-modules-core-6.12.0-124.8.1.el10_1.x86_64
kernel-core-6.12.0-124.8.1.el10_1.x86_64
kernel-modules-6.12.0-124.8.1.el10_1.x86_64
kernel-modules-extra-6.12.0-124.8.1.el10_1.x86_64
kernel-tools-6.12.0-124.8.1.el10_1.x86_64
kernel-6.12.0-124.8.1.el10_1.x86_64
user1@localhost:~$ 

Find out the kernel version and release:

user1@localhost:~$ uname --help
Usage: uname [OPTION]...
Print certain system information.  With no OPTION, same as -s.

  -a, --all                print all information, in the following order,
                             except omit -p and -i if unknown:
  -s, --kernel-name        print the kernel name
  -n, --nodename           print the network node hostname
  -r, --kernel-release     print the kernel release
  -v, --kernel-version     print the kernel version
  -m, --machine            print the machine hardware name
  -p, --processor          print the processor type (non-portable)
  -i, --hardware-platform  print the hardware platform (non-portable)
  -o, --operating-system   print the operating system
      --help        display this help and exit
      --version     output version information and exit

GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
Full documentation <https://www.gnu.org/software/coreutils/uname>
or available locally via: info '(coreutils) uname invocation'
user1@localhost:~$ 
user1@localhost:~$ uname -v
#1 SMP PREEMPT_DYNAMIC Fri Oct 17 13:03:58 EDT 2025
user1@localhost:~$ uname -r
6.12.0-124.8.1.el10_1.x86_64
user1@localhost:~$ 

Kernel-related files

in the /boot directory

With the exception of the efi and grub2 directories, which deal with the bootloader for UEFI and BIOS systems respectively, the rest of the files and subdirectories under the /boot/ directory are related to the kernel.

Locating GRUB2

On a BIOS machine, GRUB2 does not exist as a monolithic file. It takes more than one shape and form, depending on the boot stage. The first form of GRUB2 is a binary code on a section on the MBR of a bootable disk. Once the linux firmware locates the first form of GRUB2, it loads it in memory. The program then relies on the GRUB2-related files under /boot/ and /etc/ to respectively load the main image of GRUB2 and read the configuration.

Linux units

Units are configuration files that describe the resources that are managed by systemd. They are stored in four filesystem paths. If I do a manual search I can approximately tell where they are:

Wassim@linux:~$ find / -mindepth 1 -name systemd 2>/dev/null
/home/Wassim/Documents/ddupdate/systemd
/home/Wassim/.config/systemd
/run/systemd
/run/udev/tags/systemd
/run/user/1000/systemd
/etc/xdg/systemd
/etc/systemd
/var/lib/systemd
/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/49/e51263e53d04900556e2f97ac2b27201f632f604d68d67f50323f9a99389fdb0/files/lib/systemd
/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/49/e51263e53d04900556e2f97ac2b27201f632f604d68d67f50323f9a99389fdb0/files/share/licenses/gnome/systemd
/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/50/a8da766dd0273a67539d2b98358ed6809d8e729280baf63428108837135229d3/files/lib/systemd

<---- output omitted ---->

/var/lib/snapd/snap/gnome-3-38-2004/143/usr/lib/systemd
/usr/lib/systemd
/usr/lib/systemd/systemd
/usr/lib64/systemd
/usr/lib64/python3.12/site-packages/systemd
/usr/share/licenses/systemd
/usr/share/doc/systemd
/usr/share/systemd
/usr/share/cockpit/systemd
Wassim@linux:~$ 

/run/systemd seem to store runtime unit files, because /run/ typically contains runtime data, so it can not be a permanent location of systemd unit files. There is also /etc/systemd and /usr/lib/systemd/system/. The latter appears to store system units: