Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Oracle Linux lastboot: A Quick Way to Investigate Unexpected Reboots



An unexpected server reboot can be difficult to investigate, especially when the system is already back online. By the time an administrator starts checking the issue, important logs or information about what happened before the reboot may no longer be easy to correlate.

Oracle Linux Enhanced Diagnostics provides the oled lastboot tool to help with this situation.

What is oled lastboot?

lastboot is part of the oled-tools package. It installs a small systemd service that runs once during every boot.

Its purpose is simple:

  • Check what happened during the previous boot.

  • Determine whether the reboot was graceful or unexpected.

  • Check whether the unexpected reboot appears to be related to a kernel crash.

  • Generate a report that can be reviewed after the server comes back online.

  • For abnormal reboots, optionally collect additional information using hooks.

This is particularly useful when a server unexpectedly restarts and you need to start the investigation after the system has recovered.

Enable lastboot

After installing the required oled-tools package, enable the service:

# oled lastboot enable

Check its status:

# oled lastboot status

The service runs during boot and then exits. It is not a continuously running background process.

The generated reports are stored under:

/var/oled/lastboot-report/

You can also check the service activity using:

# journalctl -u oled_lastboot_report.service -b

How does it identify the previous reboot?

lastboot checks recent reboot and shutdown records from wtmp.

If a shutdown record exists before the reboot, the previous reboot is classified as:

Graceful reboot

If a reboot record exists without a matching shutdown record, it is classified as:

Unexpected reboot

This distinction is important because an unexpected reboot could have several causes, including power loss, host reset, kernel panic, or another failure path.

How does it detect a possible kernel crash?

For an unexpected reboot, lastboot looks for a vmcore file in the configured kdump location.

It reads the path setting from:

/etc/kdump.conf

It also checks:

/var/crash
/var/oled/crash

If a recent vmcore is found within the defined crash-detection window, the event is reported as:

Kernel crash

The report also provides recommended follow-up actions, such as collecting the vmcore, an sosreport, PCP data and console or serial logs when available.

The most useful command for an administrator

Once the server is back online, start with:

# oled lastboot report

The report provides information such as:

  • Host name

  • Boot time

  • Time zone

  • Reboot status

  • Kernel crash status

  • Detected vmcore path

  • Recommended follow-up actions

The status gives you a quick indication of what happened:

Graceful reboot – A matching shutdown record was found.

Unexpected reboot – The previous boot did not have a matching graceful shutdown record.

Kernel crash – The reboot was unexpected and a recent vmcore was found.

Going beyond the basic report

For abnormal reboots, lastboot can also run administrator-defined hooks.

Hooks are executable scripts placed under:

/usr/libexec/oled-tools/lastboot-hooks.d/

These can collect environment-specific information such as logs, command output, sosreport, vmcore metadata or application-specific files.

The collected artifacts are stored under:

/var/oled/lastboot-artifacts/

The corresponding state information is stored under:

/var/lib/oled/lastboot/state/

The state file also records whether a hook completed successfully, failed, timed out or was skipped.

Why this is useful during an incident

For a junior or mid-level administrator, one of the challenges after an unexpected reboot is knowing where to start.

Instead of immediately going through multiple logs, oled lastboot provides a starting point:

# oled lastboot report

If the reboot was unexpected, you can then check:

# journalctl -u oled_lastboot_report.service -b

and review the generated report and any collected artifacts.

This helps preserve and organize information close to the time of the reboot, making the initial investigation more structured.

Key takeaway

oled lastboot is a useful Oracle Linux diagnostic tool to have enabled on systems where unexpected reboots need to be investigated.

The workflow is straightforward:

Enable → Reboot occurs → Server comes back → Review oled lastboot report → Investigate further if the reboot was abnormal.

For abnormal reboots, the tool can go further by running hooks, collecting environment-specific information and, when configured, uploading the collected artifacts.

For administrators responsible for Oracle Linux servers, knowing about lastboot can make the first few steps after an unexpected reboot much easier and more consistent.

Resolving Public IP and Hostname Mappings Using dig and openssl

 In day-to-day infrastructure troubleshooting, especially in hybrid and cloud environments, verifying DNS mappings and certificate bindings is a routine yet critical task. Whether validating load balancer configurations, troubleshooting SSL issues, or confirming external exposure of services, having quick command-line methods can save significant time.

This article walks through two practical techniques:

  1. Identifying the public IP mapped to a DNS hostname

  2. Identifying the public hostname(s) associated with a public IP via SSL certificate inspection


1. Finding the Public IP Address for a Hostname

To determine the IP address associated with a public DNS record, the dig command is both simple and reliable.

Command

dig +short <public_url_hostname>

Example

dig +short example.mycompany.com

What It Does

  • Queries the DNS system for the A record.

  • +short ensures only the IP address is returned.

  • Works for publicly resolvable DNS records.

Sample Output

203.0.113.10

When to Use This

  • Validating DNS propagation

  • Confirming load balancer IP mapping

  • Verifying cutover during migrations

  • Troubleshooting connectivity issues

This is often the first step in confirming whether a hostname resolves to the expected public endpoint.


2. Finding Hostname(s) Mapped to a Public IP Using SSL Certificate

Reverse DNS lookups do not always return the expected hostname. However, if the server presents an SSL certificate, you can extract the Subject Alternative Names (SAN) from the certificate to identify the DNS names associated with that endpoint.

Command

openssl s_client -connect <public_url_host>:<port> -servername dummy </dev/null 2>/dev/null | \
openssl x509 -noout -text | grep DNS

Example

openssl s_client -connect 203.0.113.10:443 -servername dummy </dev/null 2>/dev/null | \
openssl x509 -noout -text | grep DNS

What This Command Does

  • openssl s_client -connect
    Establishes an SSL/TLS connection to the target IP and port.

  • -servername dummy
    Enables SNI (Server Name Indication). Some servers require SNI during TLS negotiation.

  • </dev/null 2>/dev/null
    Suppresses interactive input and hides connection noise.

  • openssl x509 -noout -text
    Extracts certificate details.

  • grep DNS
    Filters the output to display only DNS entries under the Subject Alternative Name section.

Sample Output

DNS:example.mycompany.com, DNS:www.example.mycompany.com

When to Use This

  • Identifying which hostname a public IP is serving

  • Validating SSL certificate bindings

  • Troubleshooting multi-domain load balancers

  • Confirming SAN entries after certificate renewal


Important Notes

  • This method works only if the service exposes an SSL certificate.

  • If multiple virtual hosts exist behind the same IP, SNI may affect which certificate is presented.

  • The certificate may contain multiple DNS entries.

Bringing Your Own Images into Oracle Cloud Infrastructure

Oracle Cloud Infrastructure allows customers to import external custom images; however, most of these images are originally built for environments that boot from local disks or use paravirtualized storage. While this works well for virtual machines, bare metal provisioning in OCI follows a different boot model and therefore requires additional preparation.

Why External Images Often Fail on Bare Metal

When an external image is imported into OCI and launched on a bare metal shape without modification, one or more of the following issues commonly occur:

  • The instance fails to complete the boot process

  • The operating system cannot locate the root filesystem

  • Network interfaces are not initialized during early boot

These behaviors are not platform defects. They indicate that the image lacks specific prerequisites required for bare metal booting in OCI.

Once these requirements are understood, the remediation is straightforward and enables the use of a single image across both virtual machine and bare metal instances.

Key Areas to Address for Image Compatibility

To ensure that one custom image works reliably across all OCI compute shapes, focus on the following three core areas.


1. Enable iSCSI Boot Support

Bare metal instances in OCI boot from network-attached storage using iSCSI. The operating system image must therefore support iSCSI during the earliest stages of the boot process.

At a minimum, the image should include:

  • Installation of the iSCSI initiator utilities (for example, iscsi-initiator-utils)

  • Required kernel parameters:

    • rd.iscsi.ibft=1

    • rd.iscsi.firmware=1

  • A rebuilt initramfs that incorporates iSCSI and networking support

With these elements in place, the operating system can:

  • Discover the boot volume presented by OCI

  • Initialize networking early enough to access the volume

  • Mount the root filesystem and continue the boot sequence

This configuration does not affect virtual machines, allowing the same disk layout to function on both VM and bare metal shapes.


2. Align Cloud-Init with OCI Requirements

Cloud-init is responsible for essential first-boot activities, including:

  • Applying SSH keys from instance metadata

  • Configuring network interfaces

  • Processing custom initialization scripts

External images frequently include outdated or incompatible cloud-init versions designed for other cloud platforms. For reliable operation in OCI, the image must:

  • Include cloud-init version 20.3 or later, which supports OCI as a data source

  • Remove or replace older cloud-init packages that may conflict

  • Configure Oracle Cloud Infrastructure as the authoritative metadata source

Once properly aligned, both virtual machine and bare metal instances initialize consistently and predictably.


3. Clean the Image Before Capture

Before converting the configured system into a reusable custom image, the operating system should be cleaned to remove residual state. This step prevents subtle and difficult-to-diagnose issues during future provisioning.

Recommended cleanup actions include:

  • Clearing cloud-init state and logs using cloud-init clean --logs

  • Removing old log files and temporary data

The objective is to ensure that every instance launched from the image behaves as a fresh deployment, regardless of the compute shape.


Summary

By enabling iSCSI boot support, ensuring cloud-init compatibility with OCI, and properly cleaning the image before capture, organizations can successfully reuse a single external custom image across both virtual machine and bare metal instances in Oracle Cloud Infrastructure. This approach reduces image sprawl, improves consistency, and simplifies operations across hybrid and cloud-native environments.

Oracle Linux vs. Red Hat Enterprise Linux: Clearing the Confusion

 


For many years, people have often assumed Oracle Linux and Red Hat Enterprise Linux (RHEL) are the same—or weren’t sure what truly sets them apart. While both share the same open-source upstream code base, Oracle Linux offers more flexibility, cost efficiency, and performance tuning.

🔍 Key Highlights

  • Binary Compatibility: Oracle Linux is 100% compatible with RHEL, ensuring that any application running on RHEL will run flawlessly on Oracle Linux.

  • Two Kernel Options:

    • Red Hat Compatible Kernel (RHCK) – identical to RHEL’s kernel.

    • Unbreakable Enterprise Kernel (UEK) – optimized for Oracle workloads and cloud performance.

  • Lower Total Cost: Oracle Linux delivers enterprise-grade support at a lower price, without additional subscription fees for updates or security patches.

  • Free Access to Updates: Oracle provides open and free access to all updates and patches through the Oracle Linux yum server—something RHEL restricts to paid subscribers.

  • Built for Oracle Cloud: Oracle Linux is deeply integrated with Oracle Cloud Infrastructure (OCI), providing consistency across on-premises and cloud environments.


Oracle Linux: Introduction to CPU Hotplug (Quick Summary)

CPU Hotplug in Oracle Linux allows you to dynamically enable or disable CPU cores in a running system—without requiring a reboot. This is especially useful in virtualized and cloud environments where workloads fluctuate.

🔍 Key Points:

  • Hotplug Support is included in the Unbreakable Enterprise Kernel (UEK) and enabled by default.

  • 🛠️ You can manage CPU state using simple sysfs commands:

    echo 0 > /sys/devices/system/cpu/cpuX/online  # offline
    echo 1 > /sys/devices/system/cpu/cpuX/online  # online
    
  • 🔒 Security-conscious systems can restrict CPU hotplug operations using procfs and system security modules like SELinux or AppArmor.

  • 💡 Useful for performance tuning, resource scaling, and testing failover behavior without downtime.


Bottom Line:
CPU Hotplug gives administrators more control and flexibility over CPU resource allocation—supporting smarter, dynamic infrastructure management in Oracle Linux.

👉 Full Blog Here


📢 Oracle Linux 10 is Now Generally Available!

 

Oracle has officially released Oracle Linux 10 for x86_64 (Intel/AMD) and aarch64 (Arm) architectures. This latest major version delivers significant enhancements in performance, security, cloud integration, and support for modern hardware.


🔧 What’s New in Oracle Linux 10

  1. Next-Generation Kernel
    Built on Unbreakable Enterprise Kernel (UEK) 8.1, it includes advanced features from the upstream Linux kernel, offering superior stability and performance.

  2. Broad Architecture Support
    Native builds for both x86_64 and aarch64 platforms ensure full compatibility and native performance on today’s enterprise-grade servers and edge devices .

  3. Optimized for Modern Workloads
    Enhanced virtualization, real-time computing, container orchestration, and networking capabilities—engineered for cloud, on-premises, and hybrid deployments.


🎯 Why Upgrade?

  • High Performance & Reliability
    Includes the latest Linux kernel innovations, optimized for Oracle Database and high-demand environments.

  • Seamless Enterprise Support
    Backed by Oracle's robust support lifecycle, including kernel updates, live patching, and enterprise-grade maintenance.

  • Security & Compliance
    Features kernel live patching, FIPS compliance, and other security enhancements—ideal for critical and regulated workloads .


🛠️ Next Steps

  • Download Oracle Linux 10 for your platform today.

  • Review the Oracle Linux 10 documentation to plan upgrades from Oracle Linux 8/9 or other RHEL-based systems.

  • Oracle Linux 10 sets a new standard for enterprise Linux—designed for the future of cloud, edge, and hybrid computing.