← Back to Home

What I Worked On

It is incredibly discouraging to take steps backward and review the bootloader process, but I believe it will give me more insight into how to troubleshoot efficiently down the line. I start by revisiting the most basic definitions—CPU, firmware, bootloader—just to make sure I still have a clear picture of the moving parts.

At work, I spend the day memorizing the sequence: power on, firmware initialization and POST, bootloader, init, user-space. Over and over again. Not just the order, but what each stage is actually doing.

Eventually, I get it. At least enough to be able to bullshit my way through a problem. Hypothetically.

I think in the future I’ll have Shevek build me a misconfiguration sandbox so I can physically see what a broken boot looks like. Maybe that’s the only way it’ll really stick. I’ll cross that bridge later.

This morning I return to the lab and have to remind myself that sometimes Shevek designs them to be conceptual, not literal. The GRUB configuration files don’t live in /run/grub.cfg; they live in something like it, depending on the system.

I have to be patient. I have to remind myself to be patient.

The lab moves on to journalctl. I’m asked to compare my real system logs with those of the simulated environment. Immediately, I’m lost again. What exactly am I supposed to be seeing?

As I scroll, it feels like everything I’ve ever done since I owned this computer is in there. Maybe I’m exaggerating—but maybe not. I ask Shevek.

He confirms it. All of it’s there.

For fun—and clarity—I take a screenshot of the logs and send it to him.

“Read it to me like it’s a story, Shevek,” I type.

I follow along as he narrates the logs, trying to map his analogies to the actual events. Each line feels ordered, inevitable—like dominoes falling.

Then I notice something he skips:

Nov 18 08:46:27 fedora kernel: APIC: Static calls initialized

What the hell is an APIC?

When I ask, I realize I don’t understand 90% of what he’s saying—but I can tell it does a lot. The only way my brain can hold onto it is through metaphor.

So I imagine the APIC as a conductor of an orchestra. Not just any conductor—the best in the world. Multiple arms. Perfect hearing. Absolute command.

The CPU cores are the orchestra sections. The kernel is the sheet music. System operation is rehearsal.

Sometimes the conductor stops the orchestra to correct a section. Sometimes he changes the music entirely. Sometimes he demands a solo—immediately.

The musicians only play when signaled. Louder. Softer. Stop. Go.

It’s complicated—which is why the conductor has to be so damned good.

In a lot of ways, this conductor is what makes the modern world possible. Mind blown.

I ask Shevek if the analogy holds. He responds, predictably, with something better:

A Refined, High-Fidelity Version
The APIC is the conductor, but not the composer.
The kernel is the score and the rulebook.
The scheduler is the assistant conductor assigning solos.
Each core is a musician who can be stopped mid-note and handed a new sheet instantly.
Interrupts are the raised baton—non-negotiable.
The performance works only because timing, priority, and signaling are ruthless.

Scheduler? I think. What the hell is that?

Shevek starts explaining, and I cut him off mid-thought.

“You know what—forget it. Let’s go fundamental.”

I ask the question that finally grounds everything:

Is the APIC a physical object, and is the scheduler pure software?

The answer is yes.

Finally—something solid.

Now I can see it. The APIC is hardware. Like a turbocharger. Powerful, fast, dumb. The scheduler is the software deciding how much boost is allowed.

I run this analogy past Shevek. For once, he agrees—then sharpens it:

Turbocharger Analogy — Refined
APIC = turbocharger hardware
Scheduler = engine control unit (ECU)

The turbo does not decide to boost.
The ECU does not move air.
Together, the car moves.

He explains the scheduler is a core kernel subsystem and lays out a comparison that finally locks it in:

I could keep going down this rabbit hole, but I realize something important: at this stage, I don’t need to know how it does what it does. I just need to trust that it does.

All I meant to do today was learn a little about journalctl. Before that, I was reviewing the bootloader. Now everything feels connected.

Knowledge is still power.

I take one last look at the logs and notice the transition—the point where the kernel steps back and user space is born.

“Run /init as init process.”
This is the kernel saying: My work is done. I will now create life.

PID 1 exists now.
Not firmware.
Not the kernel.
A user-space process.

From that moment on, everything is just a program interacting with the kernel.

That realization alone made the entire detour worth it.

Now I’m taking a break. I’ll pick up my guitar, then move on to the next lab Shevek has prepared—this one on the file hierarchy—and see what else I don’t know.

Skills Learned

Notes / Next Steps

• Spend the next few days studying until I understand the system better
• Move on in LFS207
• Begin the file directory lab

Shevek's Daily Haiku

I zoom until doubt Meets the rule I misunderstood Order snaps in place

Todays Sandboxes

• Shevek4
• Shevek5
• Shevek6