Turning an Incomplete Runbook into a Verified Rocky Linux RT Host

The assignment

I was asked to prepare a reclaimed small-form-factor computer as a minimal Rocky Linux host for real-time audio testing. The system arrived without a storage drive or a reliable configuration history.

My responsibility was to establish the operating-system baseline so that the next technical owner could continue with proprietary application work and performance testing.

The objective was not merely to make the machine boot. It was to create a known, secure, remotely manageable, and verifiable real-time Linux host without claiming results that could not yet be tested.

The instructions began in the middle

The supplied implementation material contained useful technical direction, but it was not a complete server-build procedure. It assumed that suitable hardware, storage, networking, administrative access, security configuration, and an installed operating system already existed.

The document also contained paths for more than one Linux distribution. The Rocky Linux instructions assumed that the server was already ready to receive real-time packages and application dependencies.

I therefore treated the material as a technical reference to validate against the actual machine rather than as a sequence to execute without inspection.

What complicated the work

• The machine had no installed storage device.
• Its previous role and configuration were undocumented.
• The implementation material assumed a prepared server.
• Some package, repository, and kernel examples did not match the installed Rocky Linux environment.
• Real-time CPU configuration depended on hardware topology and workload requirements that were not fully documented.
• The proprietary application source and acceptance test plan were outside my access.

Working outward from the evidence

I separated the work into a general server baseline and a project-specific real-time configuration. This created a clear boundary between infrastructure readiness and later application work.

1. Inspect and prepare the reclaimed hardware.
2. Establish a known Rocky Linux baseline.
3. Verify networking and administrative access.
4. Preserve security controls while changing remote access.
5. Validate repository, package, and kernel assumptions against the installed platform.
6. Verify the active real-time kernel and tuning components.
7. Record the resulting system state.
8. Stop where application ownership and testing began.

Establishing the server baseline

Hardware and operating system

I selected an appropriately sized reclaimed storage device, inspected and cleaned the hardware, reviewed firmware settings, and installed a minimal Rocky Linux environment with the administrative and networking components required for a headless server.

I then verified connectivity, installed the organization’s standard administrative utilities, and recorded hardware, storage, network, kernel, and service information for later comparison.

Secure remote administration

Remote access had to be moved to the organization’s approved administrative configuration. This required coordinated changes across the SSH service, firewall, SELinux policy, and client connection.

I preserved the existing recovery path until a completely new remote session succeeded. Only after the replacement path had been verified was the original access path removed.

Real-time Linux configuration

The expected real-time packages were not initially available from the configured repositories. Rather than enabling unrelated repositories until the packages appeared, I identified the platform-specific real-time package source and installed the required kernel and tuning components from the appropriate repository.

I inspected the installed kernel entries, selected the exact real-time kernel, rebooted the system, and verified that the running kernel was the intended RT build.

Diagnosing across system layers

One remote-access change initially failed because the SSH service could not bind to the new configuration. Firewall changes alone could not resolve that failure because the restriction occurred at the operating-system security-policy layer.

I installed the required SELinux administration utility, added the necessary policy assignment, validated the SSH configuration, confirmed the listening service, and tested a fresh remote session before retiring the earlier access path.

Avoiding undocumented hardware assumptions

The supplied material included a fixed CPU-isolation example. Because real-time processor isolation depends on both hardware topology and workload behavior, I did not treat that example as a universally reusable value.

I reviewed it as an architecture decision that required documented justification. A value that functions on one processor layout may be inappropriate when copied to a larger or differently organized system.

The reusable lesson was to inspect processor topology, identify the workload requirement, document the reason for the selected layout, and verify the result rather than preserving an unexplained constant.

Assisted discovery without blind automation

When the implementation material did not match the Rocky Linux environment, I used a generative technical assistant as one discovery source. I provided the expected instruction, the observed failure, and the platform context, then used the response to identify assumptions and possible areas to inspect.

Suggested commands were reviewed locally, compared with system documentation, and adjusted without exposing internal values. The live system state and verified test result remained the authority.

1. Record the instruction, environment, and failure.
2. Investigate the mismatched assumption.
3. Review proposed commands and expected effects.
4. Compare against documentation or isolated testing.
5. Insert private environment values locally.
6. Execute and verify the change.
7. Preserve the useful result in project notes.

What I verified

• The machine booted reliably.
• The expected hardware inventory was present.
• Networking and package access were functional.
• Secure remote administration worked.
• The required administrative baseline was installed.
• The selected real-time kernel was active.
• The required real-time tuning components were present.
• The server was ready for application-specific configuration.

What remained outside the case study

The next implementation stage required proprietary application source, an approved code version, build requirements, test procedures, performance targets, and acceptance criteria. Those materials were not available within my assigned scope.

I documented the completed infrastructure work and marked application delivery, compilation, runtime testing, audio performance, and final acceptance as the next owner’s work.

This boundary prevented unverified application outcomes from being presented as completed results.

A verified Rocky Linux RT baseline

The completed deliverable was a working Rocky Linux real-time server baseline on reclaimed hardware.

The host booted successfully, matched the expected hardware inventory, ran the selected RT kernel, connected to the network, supported secure remote administration, and was ready for application-specific work.

The result also created a clearer record of what had been requested, discovered, changed, verified, and handed off.

From one server build to two reusable stages

Stage 1: Cold empty server

Establish a known, secure, remotely manageable Linux server before adding project-specific software. This stage covers hardware inspection, storage, firmware, operating-system installation, networking, access controls, administrative utilities, inventory, and completion checks.

Stage 2: Project-specific real-time host

Add the required repositories, RT kernel, tuning configuration, processor-topology review, application dependencies, source ownership, testing requirements, performance targets, and final acceptance criteria.