OLE common mistakes
OLE · Understand the traps and how to avoid them.
Treating UEK and the RHCK as interchangeable by editing /boot/grub2/grub.cfg by hand to change the default kernel, or assuming 'uname -r' output starting with 5.15/6.12 is the RHCK.
Candidates memorize that Oracle Linux ships two kernels but never learn that UEK release strings contain 'uek' and that the default boot entry must be set with 'grubby --set-default' or by setting GRUB_DEFAULT in /etc/default/grub followed by 'grub2-mkconfig -o /boot/grub2/grub.cfg'. Manual edits are overwritten on the next kernel install, and questions probe which kernel provides btrfs, Ksplice, and newer drivers.
What to do instead
Learn the identification commands ('uname -r', 'grubby --default-kernel', 'grubby --info=ALL') and the supported change path: install/remove kernel-uek packages with DNF, then set the default with grubby or GRUB_DEFAULT plus grub2-mkconfig. Remember UEK is the default on Oracle Linux installs and is the kernel that carries btrfs, Ksplice support, and DTrace.
Assuming Ksplice patches every kernel and every package, or that it requires a reboot after 'uptrack-upgrade -y'. Candidates also confuse the Ksplice client package names between UEK and RHCK.
Ksplice is Oracle Linux-specific and heavily marketed, so candidates over-generalize: they forget it only covers kernels and a defined set of critical user-space packages, that an effective kernel must be supported, and that the client is 'ksplice-uptrack' (with ksplice support enabled through ULN or the Ksplice-aware yum repo). Questions test whether a reboot is needed and how to verify patch state.
What to do instead
Memorize the workflow: register the system for Ksplice, install ksplice-uptrack, run 'uptrack-upgrade -y' to apply, and verify with 'uptrack-show' or 'uptrack-uname -r'. State explicitly that no reboot is required for an effective kernel and that Ksplice does not replace normal DNF errata for user-space packages.
Configuring repositories by hand-editing /etc/yum.repos.d files with guessed baseurls, or forgetting that ULN registration and the public yum mirrors are different access paths with different repo IDs.
Oracle Linux offers several repository sources (ULN, the public yum.oracle.com mirrors, and local ISO/media repos), and candidates mix them. They also forget that a system registered with ULN must have its repos enabled per system, and that 'yum-config-manager --enable' or 'dnf config-manager --set-enabled' is needed after registration. Baseurl typos and missing gpgkey settings then cause silent failures.
What to do instead
Know the three paths and their commands: 'uln_register' or the ULN web UI for entitled systems, the public oraclelinux-release-el9/oraclelinux-release-el8 packages that drop in the yum.oracle.com repo files, and 'createrepo' plus a file:// baseurl for a local mirror. Always verify with 'dnf repolist -v' and check gpgcheck/gpgkey before installing.
Extending an LVM logical volume with 'lvextend' and then reporting the filesystem as full, or resizing the filesystem before the LV.
Candidates learn lvextend and resize2fs as separate steps but forget the order and the filesystem-specific tool. On XFS they run resize2fs (which fails, since XFS cannot shrink and uses xfs_growfs), and they forget that xfs_growfs takes a mount point while resize2fs takes a device. Questions often combine pvcreate/vgextend/lvextend into one chain.
What to do instead
Use the correct order and tool per filesystem: for XFS, lvextend then 'xfs_growfs /mountpoint' (or 'lvextend -r' to resize in one step); for ext4, lvextend then 'resize2fs /dev/vg/lv'. Remember XFS cannot be shrunk, and that 'lvextend -r' requires the filesystem to be mounted.
Editing /etc/fstab with a UUID or label that does not match, or omitting 'nofail', and then being unable to boot into multi-user because systemd drops to emergency mode.
Candidates copy device names like /dev/sdb1 from a lab, which shift after reboot, or they add NFS/extra mounts without nofail and x-systemd.automount. They also forget that a broken fstab triggers emergency mode and that the fix requires booting with rd.break or emergency.target and remounting root read-write.
What to do instead
Always derive entries with 'blkid' or 'lsblk -f' and use UUID= or LABEL=. Add 'nofail' for non-essential mounts and test with 'mount -a' and 'systemctl daemon-reload' before rebooting. Know the recovery path: boot with systemd.unit=emergency.target, 'mount -o remount,rw /', fix fstab, then reboot.
Using ifcfg-* files and 'systemctl restart network' on Oracle Linux 8/9, or applying nmcli changes without bringing the connection up, so the configuration is never active.
Older study material and muscle memory point to the legacy network service and /etc/sysconfig/network-scripts, which are deprecated or absent on EL8/EL9. Candidates also run 'nmcli con mod' and assume it takes effect immediately, but modifying a connection does not activate it until 'nmcli con up' or a reactivate is issued.
What to do instead
Use NetworkManager tooling: 'nmcli con add/mod', 'nmcli con up ', 'nmcli device status', and 'nmcli con show'. Persist settings in /etc/NetworkManager/system-connections/*.nmconnection (keyfile format) or via nmcli, and verify with 'ip addr' and 'nmcli con show --active'. Use 'nmcli networking connectivity check' to diagnose.
Disabling SELinux permanently by setting SELINUX=disabled in /etc/selinux/config to make an application work, instead of fixing contexts or booleans.
SELinux denials look like random permission failures, so candidates reach for the off switch. They also forget that changing SELINUX=enforcing to permissive requires a reboot, that 'setenforce 0' is temporary, and that file contexts are fixed with restorecon or semanage fcontext rather than chmod. Questions test targeted fixes and denial analysis.
What to do instead
Diagnose with 'ausearch -m avc -ts recent' and 'sealert -a /var/log/audit/audit.log'. Fix labels with 'semanage fcontext -a -t ' plus 'restorecon -Rv ', toggle booleans with 'setsebool -P', and only use permissive mode temporarily for diagnosis. Keep SELINUX=enforcing and SELINUXTYPE=targeted in config.
Opening a port with firewalld but forgetting '--permanent' followed by '--reload', or editing iptables directly while firewalld is running.
firewalld keeps a runtime and a permanent configuration, and candidates apply a rule, test it successfully, then lose it after reboot. Others bypass firewalld with iptables commands that firewalld later flushes. They also forget that a service must be added to the correct zone and that the default zone matters.
What to do instead
Use 'firewall-cmd --add-service=... --permanent' then 'firewall-cmd --reload', and verify with '--list-all' and '--list-all --permanent'. Determine the active zone with 'firewall-cmd --get-active-zones'. Do not mix direct iptables rules with firewalld; use rich rules or '--add-port' instead.
Writing a cron entry in /etc/cron.d without the user field, or expecting a shell script to run from cron with the same PATH and environment as an interactive login.
The format of /etc/cron.d and /etc/crontab includes a user column that user crontabs do not, and candidates copy entries between the two. They also forget cron's minimal environment, so scripts relying on PATH, aliases, or relative paths fail silently, and they miss that output goes to local mail and cron logs to /var/log/cron.
What to do instead
Include the user field in /etc/cron.d and /etc/crontab entries; omit it in 'crontab -e'. Use absolute paths, set PATH or source a profile at the top of the script, redirect output to a log, and verify execution in /var/log/cron and journalctl. For systemd timers, pair a .timer with a .service and enable the timer, not the service.
Creating a user with useradd but never setting the password or shell, or fixing permissions with chmod 777 instead of group ownership and setgid, and forgetting that umask determines default permissions.
Candidates focus on the command name and skip the attributes that matter: 'useradd -m -s /bin/bash', 'passwd', supplementary groups with 'usermod -aG', and the difference between primary and supplementary groups. Permission questions test setgid directories for shared collaboration and the effect of umask 027 versus 022, which candidates rarely rehearse.
What to do instead
Practice the full sequence: 'useradd -m -s /bin/bash user', 'passwd user', 'usermod -aG group user', and verify with 'id user'. For shared directories use 'chgrp' plus 'chmod 2770' (setgid) so new files inherit the group, and know that umask 027 yields 750/640 defaults. Use ACLs ('setfacl -m g:group:rwx') when group-only permissions are insufficient.