DEV Community: Eric-Octavian

24 hours of kernel debugging – keeping IONA OS alive in QEMU Lock ordering, backlight hangs, hypervisor detection, and an AMD FCH guard

Eric-Octavian — Thu, 02 Jul 2026 16:27:30 +0000

Yesterday was a good day.

I fixed five bugs that had been bothering me for a while. None of them were catastrophic, but they were subtle — the kind of bugs that cause hangs, deadlocks, or silent failures that are hard to reproduce.

Here's what I fixed, how I found them, and what I learned.

1. Lock Order WM→BACK — The Deadlock You Don't See

The bug: IONA OS would occasionally hang when the window manager tried to acquire a lock that was already held by the backlight driver.

The problem: ABBA deadlock. Thread A locked WM, then tried to lock BACK. Thread B locked BACK, then tried to lock WM.

The fix: Reorder the locks. Always acquire BACK first, then WM. Consistent order = no deadlock.

// Before
lock(&WM);
lock(&BACK);

// After
lock(&BACK);
lock(&WM);

Simple, but hard to find without tracing.

Backlight Skip — QEMU Has No Backlight The bug: On boot, IONA OS would hang at [BL] Backlight init... when running in QEMU.

The problem: QEMU doesn't have a backlight device. The driver was trying to communicate with hardware that didn't exist.

The fix: Detect the hypervisor and skip backlight initialization entirely.

if is_hypervisor() {
serial_println!("[BL] Hypervisor detected — skipping backlight init");
return;
}

Now IONA OS boots cleanly in QEMU.

Hypervisor Detection — CPUID without the Flag The bug: is_hypervisor() would return false even in QEMU.

The problem: The CPUID 1 leaf ECX31 is not always set, especially with -cpu qemu64.

The fix: Don't rely on the flag. Probe the hypervisor leaf directly (0x4000_0000).

fn is_hypervisor() -> bool {
// Try the hypervisor leaf directly
let eax = unsafe { cpuid(0x4000_0000) }.eax;
eax != 0
}

This works with any QEMU configuration.

EDP FCH Guard — MMIO That Doesn't Exist The bug: IONA OS would page fault when trying to read AMD FCH registers in QEMU.

The problem: The EDP driver was reading MMIO addresses that exist on real hardware (AMD FCH) but not in QEMU.

The fix: Add a guard — if the hypervisor is detected, skip the FCH access.

if is_hypervisor() {
serial_println!("[EDP] Skipping AMD FCH MMIO — running in VM");
return;
}

No more page faults.

Disk Image Path — The Silent Fail The bug: The build pipeline was producing a disk image, but QEMU couldn't find it.

The problem: The build script was looking for x86_64-unknown-none/iona-pc.bin, but the actual path was x86_64-iona/debug/iona-pc.bin.

The fix: Update the build script to use the correct target directory.

Before

cp target/x86_64-unknown-none/debug/iona-pc.bin dist/

After

cp target/x86_64-iona/debug/iona-pc.bin dist/

A small fix, but it made the difference between booting and failing.

What I Learned

Bug-finding is a skill. The hardest bugs aren't the ones that crash — they're the ones that silently hang or fail unpredictably.
Hypervisor detection needs to be robust. Not all hypervisors set the standard flag. Always try the direct leaf.
Lock ordering is critical. A single reversed lock order can cause intermittent deadlocks that are nearly impossible to reproduce.
Even small fixes matter. Fixing a path in the build script can save hours of confusion.

The State of IONA OS
These five fixes are part of a larger effort to stabilise IONA OS

The kernel is now:

Bootable in QEMU and on real hardware.
Stable under load.
Actively maintained and debugged.

Resources
GitHub: github.com/Ionablokchain
Website: iona.zone

Writing apps for IONA OS — a quick start guide

Eric-Octavian — Sun, 28 Jun 2026 19:20:34 +0000

IONA OS is not just a kernel. It's a complete platform for building sovereign applications.

This guide shows you how to write your first native application for IONA OS — from project setup to running it on the system.

1. The Ecosystem

IONA OS supports two languages for native application development:

Rust — for performance-critical applications (system tools, drivers, 3D applications).
Flux — for applications that leverage the AI, causal memory, and timeline features.

Both languages can interact with the kernel through a unified syscall interface.

2. Writing a Rust Application

Create a new Rust project:

cargo new my_app --bin

Add the IONA syscall crate to Cargo.toml:
[dependencies]
iona-syscall = { git = "https://github.com/Ionablokchain/Iona-OS" }

// src/main.rs

![no_std]

![no_main]

use iona_syscall::*;

pub extern "C" fn _start() -> ! {
// Print a message to the console
println!("Hello from IONA OS!");

// Get system metrics
let cpu_temp = syscall::get_cpu_temp();
let uptime = syscall::get_uptime();

println!("CPU Temperature: {}°C", cpu_temp);
println!("Uptime: {} seconds", uptime);

loop {}

}

Build and run:

cargo build --target x86_64-unknown-iona
iona-run target/x86_64-unknown-iona/debug/my_app

Writing a Flux Application Flux is a language designed for describing intentions, timelines, and causal relationships.

A simple Flux application:

intention HelloWorld {
trigger: on_boot()
priority: 0.5
execute: {
send("inner_voice", "Hello from Flux!", 1s);
let temp = system::cpu_temp();
send("inner_voice", "CPU temperature is: " ++ to_string(temp), 1s);
}
}
Flux applications are compiled to bytecode and run on the Flux VM, which is integrated into the kernel.

AI Integration — The ai Syscall IONA OS applications can interact with the kernel-integrated AI.

let result = syscall::ai_query("What is the current system health?");
println!("AI says: {}", result);

The AI can also be used for:

ai_suggest_governor() — suggests optimal CPU governor for current workload.

ai_optimize_memory() — suggests memory management changes.

ai_predict_crash() — predicts potential system failures.

GUI Applications IONA OS includes a native GUI compositor (glass). Applications can create windows, buttons, and text inputs.

use iona_gui::*;

fn main() {
let window = Window::new("My App", 800, 600);
let button = Button::new("Click me");
button.on_click(|| {
println!("Button clicked!");
});
window.add(button);
window.run();
}

The GUI compositor supports 3D acceleration via VirGL/Vulkan, animations, and themes.

What's Next This is just the beginning. IONA OS also supports:

WASM — run WebAssembly applications in a sandbox.

System services — background tasks, daemons, and services.

Blockchain integration — native IONA Protocol transactions from your app.

All of this is available in the current version of IONA OS.

Resources
GitHub: github.com/Ionablokchain

Website: iona.zone

Documentation: (coming soon)

IONA OS

I'm building this alone. 13 years of research. Every line is written from scratch. And it works.

How to Make a Kernel AI Actually Rational: Causal Chains, Hallucination Detection, and a Parliament

Eric-Octavian — Fri, 26 Jun 2026 19:09:07 +0000

IONA OS is an operating system written from scratch in Rust. It has its own kernel, its own GUI, its own blockchain protocol, its own programming language (Flux), and — since recently — its own kernel‑integrated AI.

Not a chatbot. Not a cloud API wrapper. An AI that runs in Ring 0, reads CPU temperature directly, kills processes, changes governors, and synthesises drivers.

But here's the thing: when an AI runs inside the kernel, a hallucination isn't just a wrong answer. It could crash the system, corrupt memory, or make a bad decision that leaves your laptop unusable.

So I built a system that doesn't just generate responses. It verifies them. It cross‑checks facts, detects causal loops, and consults a governance system before taking any risky action.

Here's how it works.

1. The Causal Chain — Not Just Logs

Most systems log events. IONA AI builds a causal graph.

Every event — a temperature spike, a governor change, a user command — is stored with a parent pointer. When the AI observes a problem, it traverses the chain backwards.

Example:
Event: temperature = 89°C
Parent: governor set to Performance
Grandparent: user started compiling kernel
Great-grandparent: user typed "make -j8"

This isn't just a stack trace. It's a causal narrative.

The AI uses this to answer "why" questions. When you ask "why is the CPU hot?", it doesn't just say "because load is high". It says:

Temperature rose because governor was set to Performance when you compiled the kernel, which spawned 8 threads that consumed 95% CPU for 4 minutes.

That's the difference between logging and reasoning.

2. Cycle Detection — Breaking Circular Logic

AI systems can fall into loops. A causes B, B causes C, C causes A.

This is subtle. The AI might suggest lowering the governor to reduce temperature. But if the system is already thermal‑throttling, lowering the governor might increase compile time, which keeps the system hot longer.

We built a cycle detector into the causal chain. When the AI proposes an action, it checks if that action would create a loop.

Pseudo‑code:

if detect_cycle(proposed_action) {
log_warning("causal cycle detected: A → B → C → A");
suggest_external_action();
}

If a cycle is found, the AI reports it explicitly:

Causal cycle detected: thermal_throttle → governor_change → cpu_load → thermal_throttle. I cannot resolve this internally. Suggest: active cooling or reducing workload.

This forces the AI to stop spinning and ask for external help, rather than pretending it can solve the problem.

Hallucination Detection — Cross‑Fact Consistency The biggest risk of a kernel AI is hallucination. If it says "CPU is at 60°C" but it's actually 90°C, a human might trust it and not act. That's dangerous.

IONA AI cross‑checks facts.

When the AI says "CPU is over 80°C", it verifies the correlation with power draw (watts). If CPU temperature is high but power draw is low, the system knows something is inconsistent.

Pseudo‑code:

if cpu_temp > 80.0 && watts < 20.0 {
// Hallucination: high temp with low power is impossible
log_anomaly("inconsistent_temp_watts");
override_response("I can't reliably state the temperature right now.");
}

This cross‑fact consistency prevents the AI from confidently stating false information. It doesn't just trust its own output — it verifies it against other system metrics.

The Parliament — Consensus Before Action The AI doesn't act alone. It has a governance system called the "parliament".

When the AI wants to do something risky (change governor, kill a process, install a driver), it proposes the action to the parliament. The parliament votes.

Example:
Proposal: switch governor to Performance
Votes: 3 for, 1 against
Outcome: approved (quorum reached: 67%)

Each vote is recorded, along with the reasoning. If the parliament reaches quorum (67% approval), the action is executed.

But here's the important part: the outcome is persisted to long‑term memory. The AI remembers why the action was approved (or rejected) and uses that knowledge in future decisions.

This prevents the AI from making the same mistake twice. It also provides an audit trail for every action taken by the AI.

Adaptive Backoff — Don't Reason When the System is Dying When the system is under heavy load, the AI stops doing expensive reasoning.

If CPU usage exceeds 80%, the AI switches to a lightweight mode:

if cpu_usage > 80.0 {
reasoning_depth = 1; // only basic responses
} else {
reasoning_depth = 3; // deep chain‑of‑thought
}

This ensures that the AI doesn't make the system worse by consuming resources it doesn't have. It's a mechanism of self‑preservation — not for the AI, but for the system it runs on.

The Result With these mechanisms, IONA AI is no longer a "chatbot". It's a rational agent that:

Builds causal narratives instead of just logging events.

Detects and breaks circular reasoning.

Cross‑checks facts to avoid hallucinations.

Consults a governance system before taking risky actions.

Adapts its reasoning depth based on system load.

Building an AI that runs inside the kernel is hard. Building one that can be trusted — that doesn't hallucinate, doesn't spiral into circular reasoning, and doesn't crash the system — is even harder.

But it's not impossible. The key is to design for rationality, not just intelligence. To build systems that verify their own outputs. To give them governance, not just freedom.

IONA AI is still evolving. But with these five mechanisms, it's no longer just a "chatbot". It's a self‑correcting, causally aware, energy‑optimising agent that lives inside the operating system itself.

The code is not yet fully public , but you can see the architecture on GitHub.

Website: https://iona.zone
GitHub: https://github.com/Ionablokchain

Questions? Comments? I read every one.

Training LLMs in the kernel — how IONA AI does embedding, RAG, and fine‑tuning without the cloud

Eric-Octavian — Thu, 25 Jun 2026 17:55:59 +0000

Most AI systems today are cloud‑based. You send a prompt to an API, and a model somewhere else generates a response. You don't control the model. You don't control the data. You don't control the infrastructure.

IONA AI is the opposite.

It runs inside the kernel of IONA OS. It reads CPU temperature, kills processes, changes governors, and synthesises drivers — all in real time, with zero latency. And it does all of this without ever sending a single byte to the cloud.

This article explains how IONA AI handles embedding, RAG, and fine‑tuning — entirely locally, entirely in Rust, entirely in the kernel.

1. Embedding — Semantic Search Without the Cloud

IONA AI uses a local embedding model to understand the meaning of text, not just the words.

How it works

At boot, the system tries to load /models/minilm-emb.bin — a MiniLM embedding model with 384 dimensions.

If the file exists, the system uses it for real semantic search. If it doesn't, it falls back to a deterministic FNV‑1a hash (zero downtime, no crash).

Lookup and similarity

Each word is hashed using FNV‑1a for O(1) lookup.
embed(text) → mean pool → L2 normalize → Vec<f32> (384 dims).
Cosine similarity between "kernel panic" and "system crash" is ~0.87 (real semantic understanding).
With the old FNV fallback, the same strings had ~0.30 similarity (character‑based, not meaning‑based).

This allows IONA AI to search its memory semantically, not just by keyword.

2. RAG — Retrieval‑Augmented Generation

IONA AI uses RAG to give the LLM factual context before generating a response.

How it works

User asks a question.
The system computes an embedding for the query.
It searches the knowledge graph and episodic memory using cosine similarity.
The top‑matching facts are injected into the LLM prompt as context.
The LLM generates a response grounded in real data.

Example

If you ask: "What happened when I last compiled the kernel?"

The RAG system finds the relevant episode from memory, embeds it, and injects it into the context. The LLM then responds with:

"You compiled the kernel 2 hours ago with make -j8. Temperature rose to 89°C, and the governor switched to Performance."

Not a guess. A retrieved fact.

3. LLM Engine — Dynamic, Multi‑Architecture Support

IONA AI doesn't hardcode a single model. It reads model metadata at runtime and adapts.

How it works

The llm.rs module reads these fields from a .gguf file:

llama.embedding_length
llama.feed_forward_length
llama.block_count
llama.attention.head_count

It then dynamically builds the network layers, supporting multiple architectures:

Architecture	Status
LLaMA	✅ Supported
Mistral	✅ Supported
Phi3	✅ Supported
Gemma	✅ Supported

Quantization

The engine supports Q4_K_M (the most widely used format) via QuantTensor::from_gguf_q4k(). It can also be extended to Q5_K_M, Q6_K, and Q8_0.

Vocab size

The engine uses the real vocabulary size (32,000 for most models), not a hardcoded 256. This means better tokenisation and more accurate generation.

4. Training and Fine‑Tuning — Local and Sovereign

IONA AI can be fine‑tuned locally, without sending any data to the cloud.

How it works

Data collection — the system logs user interactions, system events, and corrections.
Training — using the learning_loop.rs module, the system periodically updates the model weights.
Fine‑tuning — using the corpus.rs and embedding_store.rs modules, the system can be fine‑tuned on custom datasets.

Example fine‑tuning pipeline

// conceptual code
let data = load_custom_dataset("/var/ai/fine_tune_data.json");
let model = load_model("/models/TinyLlama-1.1B-Chat-v1.0.Q4_K_M.gguf");
let tuned_model = fine_tune(model, data, learning_rate=1e-5);
save_model(tuned_model, "/models/iona-llm.gguf");

This runs entirely in the kernel, on the device itself. No cloud. No API keys. No data leaks.

Why This Matters
Most AI systems are cloud‑dependent. That means:

You don't control your data.

You don't control the model.

You don't control the infrastructure.

If the API goes down, your system stops.

IONA AI flips this model:

You control the data — it never leaves the device.

You control the model — you can fine‑tune it locally.

You control the infrastructure — it runs in your kernel, on your hardware.

No API dependency — if the internet goes down, the AI still works.

This is what sovereign AI looks like.

What's Next
IONA AI is still evolving. The current version supports:

Semantic search with MiniLM embeddings.

RAG with episodic memory and knowledge graph.

Dynamic LLM inference for LLaMA, Mistral, Phi3, and Gemma.

Local fine‑tuning via learning_loop.rs.

Future work includes:

Support for larger models (3B, 7B, 8B).

NPU acceleration (if available on the hardware).

Continuous learning without forgetting.

The Code
All of this is written in Rust, running in the kernel of IONA OS.

The embedding store, the RAG system, the LLM engine, and the fine‑tuning pipeline are all in the src/ai/ directory — 70,000+ lines of Rust AI.

Website: iona.zone
GitHub: github.com/Ionablokchain

Five features that turn an OS into a trust platform: Panic, Dead Man’s Switch, E2E messenger, Vault UI, and Secure Boot attestation in IONA OS

Eric-Octavian — Tue, 23 Jun 2026 17:48:49 +0000

An operating system should not just execute programs. It should protect the person using it.

Most operating systems were built for a world where threats were predictable. That world no longer exists. Today, a device can be confiscated at a border, compromised by malware, or used to surveil the person carrying it.

IONA OS is an operating system written from scratch in Rust. It has its own kernel, its own GUI, its own blockchain protocol, and its own kernel-integrated AI. But beyond the technology, it's designed around a single principle: trust.

This week, I implemented five features that turn IONA OS from a kernel into a trust platform.

Here they are.

1. Panic Shortcut — One Key Combination to Disappear

When you are in a situation where you need to protect your data instantly, you don't have time to navigate menus or click buttons.

IONA OS now has a global panic shortcut: Ctrl+Alt+Delete.

Pressing it triggers:

Ghost Mode — the system becomes unresponsive to external input, hides all active sessions, and presents a clean, locked screen.
Network Isolate — all network interfaces are immediately disconnected. No packets leave the device.

This works from any context — even from the lock screen. Even if the device is partially locked or the UI is frozen.

If your device is confiscated at a border, or if you feel threatened, one key combination is all you need.

No UI. No delay. No questions.

2. Real E2E Messenger — Not a Simulated Chat

Most "secure messengers" on operating systems are just UI wrappers around existing libraries. IONA OS now has a real messenger backend.

The UI in phone/messenger.rs is now connected to crate::net::messenger, which implements:

Double Ratchet — the same protocol used by Signal.
Noise_XX — a modern, authenticated key exchange.

Messages sent from the IONA OS messenger are real E2E encrypted, not simulated. No plaintext touches the network. No metadata leakage.

This is not a feature that will be added later. It is already working.

3. Dead Man's Switch — Auto‑Isolate If You Don't Check In

This feature is for people who are at risk of having their device seized while the system is active.

IONA OS now has a Dead Man's Switch.

The system expects a periodic "check‑in" — a simple signal that the user is still in control. The interval is configurable (default: X minutes).

If the system does not receive the check-in within the configured window, it executes a predefined action:

Network Isolate — cut all network connections immediately.
Full Wipe — erase all user data (if configured).

This is not a theoretical feature. It is implemented. It works from the lock screen. It works even if the UI is not responding.

This is for journalists, activists, and anyone who carries sensitive data through hostile environments.

4. Encrypted File Vault UI — Manage Keys from the GUI

IONA OS has had a keystore module (crate::security::keystore) for a while. But until now, it was only accessible via API.

Now there is a UI.

The Encrypted File Vault is accessible from the Settings screen. It allows you to:

View your current encryption keys.
Add or remove keys.
Encrypt files directly from the file manager.
Decrypt files with a single click.

This brings the power of IONA's cryptographic stack to the user — without requiring the command line.

5. Secure Boot Attestation — See If Your Kernel Is Tampered

At boot, IONA OS now displays a screen that shows:

The cryptographic hash of the kernel.
The verification status: VERIFIED or TAMPERED.
The signature is checked using Dilithium3, a post‑quantum signature scheme.

This is not a hidden check. It is displayed to the user at boot time, before the system loads.

If the kernel is signed correctly, the user sees a green indicator. If not, the system displays a warning and offers recovery options.

This builds trust from the very first second of operation.

Why These Five Features Matter

These features are not isolated additions. They form a cohesive security model:

Panic Shortcut gives you an escape route when you are under threat.
Dead Man's Switch protects you when you are not present.
E2E Messenger protects your communication at rest and in transit.
File Vault UI makes encryption accessible to everyone.
Secure Boot Attestation ensures you know the system is trustworthy before you use it.

None of these features are "future plans". They are all implemented and working in the current version of IONA OS.

What This Means for the User

IONA OS is not just an operating system. It is a platform for trust.

If you are a journalist, you can use it knowing that you have a panic button, a dead man's switch, and real E2E messaging.

If you are an activist, you can use it knowing that your files are encrypted and that the system will isolate itself if you are absent.

If you are a developer, you can use it knowing that the kernel is verified at boot and that the cryptographic stack is exposed through a clean UI.

The Code

All of these features are written in Rust, running in the kernel or in the phone UI layer.

The messenger backend uses Double Ratchet and Noise_XX.

The Secure Boot attestation uses Dilithium3 from crate::security.

The File Vault UI is built on top of crate::security::keystore.

The Panic Shortcut is a global key handler, active even from the lock screen.

The Dead Man's Switch is a background task that triggers network isolation or full wipe when the check‑in is not received.

What's Next

IONA OS launches on September 15, 2026.

The full codebase (v965+) is not yet fully public — what you see on GitHub is a curated snapshot — but the architecture is visible and the project is on track.

If you are interested in security, trust, or building an operating system from scratch, I would love to hear your thoughts.

Website: iona.zone

GitHub: github.com/Ionablokchain

I'm building this alone. 13 years of research. Every line is written from scratch. And it works.

70,780 lines of Rust AI — now running inside the kernel of IONA OS

Eric-Octavian — Mon, 22 Jun 2026 17:19:48 +0000

IONA OS now has 70,780 lines of Rust code dedicated to AI — all running in Ring 0, directly inside the kernel.

No cloud. No API calls. No external dependencies.

This isn't a chatbot. It's a self‑correcting, causally‑aware agent that reads CPU temperature, kills processes, changes governors, and even synthesises drivers — all in real time, with zero latency between sensing and acting.

The AI module has grown to 405 files in src/ai/, covering:

Causal chains (not just logs — actual reasoning)
Hallucination detection via cross‑fact consistency
Cycle detection to break circular logic
A parliament (governance system) for risky actions
Adaptive backoff under high system load
Semantic search with MiniLM embeddings
RAG (Retrieval‑Augmented Generation)
A dynamic LLM engine that supports LLaMA, Mistral, Phi3, Gemma
Knowledge graph with tiered decay
Goal tracking with real system metrics
Process intelligence (workload classification)
Energy optimisation that learns from real‑world results
Sleep cycles, metacognition, and active learning

All 70,780 lines are written in Rust, running in no_std mode, inside the kernel.

For context:

llama.cpp is ~30,000 lines (just inference)
candle is ~30,000 lines (just inference)
IONA AI is 70,780 lines (inference + reasoning + memory + governance + planning)

This is the largest kernel‑integrated AI module in existence, as far as I know.

The full codebase (v965+) is not yet public — what you see on GitHub is a curated snapshot — but the architecture is visible and the project is on track for the September 15, 2026 launch.

GitHub: github.com/Ionablokchain

Website: iona.zone

I'm building this alone. 13 years of research. Every line is written from scratch. And it works.

How to Make a Kernel AI Actually Rational: Causal Chains, Hallucination Detection, and a Parliament

Eric-Octavian — Sun, 21 Jun 2026 10:42:33 +0000

Last week I wrote about building a kernel-integrated AI that doesn't hallucinate. People asked: "How does it actually work?"

This post is the technical answer.

IONA AI runs inside the operating system kernel. It reads CPU temperature, kills processes, changes governors, and even synthesises drivers. But when an AI has that much power, it can't just guess. It needs to be rational, self-correcting, and aware of its own reasoning.

Here are the five mechanisms that keep it honest.

The Causal Chain — Not Just Logs Most systems log events. IONA AI builds a causal graph.

Every event, a temperature spike, a governor change, or a user command, is stored with a parent pointer. When the AI sees a problem, it traverses the chain backwards.

For example, event temperature equals eighty-nine degrees Celsius. Its parent is governor set to Performance. Its grandparent is user started compiling kernel. Its great-grandparent is user typed make dash j eight.

This isn't just a stack trace. It's a causal narrative.

The AI uses this to answer why questions. When you ask why is the CPU hot, it doesn't just say because load is high. It says temperature rose because governor was set to Performance when you compiled the kernel, which spawned eight threads that consumed ninety-five percent CPU for four minutes.

That's the difference between logging and reasoning.

Cycle Detection — Breaking Circular Logic AI systems can fall into loops.

A causes B, B causes C, C causes A.

This is subtle. The AI might suggest lowering the governor to reduce temperature. But if the system is already thermal-throttling, lowering the governor might increase compile time, which keeps the system hot longer.

We built a cycle detector into the causal chain. When the AI proposes an action, it checks if that action would create a loop in the causal graph.

If a cycle is found, the AI reports it explicitly. It says causal cycle detected: thermal throttle leads to governor change leads to cpu load leads to thermal throttle. I cannot resolve this internally. Suggest active cooling or reducing workload.

This forces the AI to stop spinning and ask for external help, rather than pretending it can solve the problem.

Hallucination Detection — Cross-Fact Consistency The biggest risk of a kernel AI is hallucination. If it says CPU is at sixty degrees Celsius but it's actually ninety, a human might trust it and not act. That's dangerous.

IONA AI cross-checks facts.

When the AI says CPU is over eighty degrees Celsius, it verifies the correlation with power draw in watts. If CPU temperature is high but power draw is low, the system knows something is inconsistent.

This cross-fact consistency prevents the AI from confidently stating false information. It doesn't just trust its own output. It verifies it against other system metrics.

The Parliament — Consensus Before Action The AI doesn't act alone. It has a governance system called the parliament.

When the AI wants to do something risky, like changing governor, killing a process, or installing a driver, it proposes the action to the parliament. The parliament votes.

Each vote is recorded, along with the reasoning. If the parliament reaches quorum, which is sixty-seven percent approval, the action is executed.

But here's the important part. The outcome is persisted to long-term memory. The AI remembers why the action was approved or rejected and uses that knowledge in future decisions.

This prevents the AI from making the same mistake twice. It also provides an audit trail for every action taken by the AI.

Adaptive Backoff — Don't Reason When the System is Dying When the system is under heavy load, the AI stops doing expensive reasoning.

If CPU usage exceeds eighty percent, the AI switches to a lightweight mode. It only uses basic responses. When the system is idle, it uses deep chain-of-thought.

This ensures that the AI doesn't make the system worse by consuming resources it doesn't have. It's a mechanism of self-preservation, not for the AI, but for the system it runs on.

With these five mechanisms, IONA AI is no longer a chatbot. It is a rational agent that builds causal narratives instead of just logging events, detects and breaks circular reasoning, cross-checks facts to avoid hallucinations, consults a governance system before taking risky actions, and adapts its reasoning depth based on system load.

All sixty-three thousand lines of it, written in Rust, running in Ring 0.

The code is not yet fully public, but you can see the architecture on GitHub. IONA OS launches September 15, 2026. The website is iona.zone.

Building a Kernel-Integrated AI that Doesn't Hallucinate

Eric-Octavian — Sat, 20 Jun 2026 19:05:03 +0000

Not a chatbot. Not a cloud API wrapper. An AI that runs in Ring 0, reads CPU temperature directly, kills processes, synthesises drivers, and optimises the system in real time.

The hardest part wasn't making it work. The hardest part was making it trustworthy. When an AI runs inside the kernel, a hallucination isn't just a wrong answer — it could crash the system, corrupt memory, or make a bad decision that leaves your laptop unusable.

Here's how we built IONA AI to be reliable, self-correcting, and causally aware.

1 Detecting Hallucinations Before They Happen
Most AI systems generate text and hope it's correct. IONA AI cross-checks facts.

When the AI says "CPU is over 80°C", the system doesn't just accept it. It verifies the correlation with power draw in watts. We maintain a watts anchor and check consistency. If CPU temperature is high but power draw is low, the system knows something is wrong. It logs the anomaly and overrides the response.

This cross-fact consistency prevents the AI from confidently stating false information.

Causal Chains — Not Just Correlations The AI doesn't just say "CPU is hot". It says why.

We built a causal chain module that records every event with a parent pointer. When the AI observes a problem, it traverses the chain backwards and builds a narrative: temperature rose because governor was set to Performance when you compiled the kernel, which spawned eight threads that consumed ninety-five percent CPU for four minutes.

This is more than logging. It is causal reasoning.

Cycle Detection — No Infinite Loops in Logic When an AI reasons about itself, it can fall into circular logic: A caused B, B caused C, C caused A.

We added explicit cycle detection in the causal chain explain function. If a cycle is found, the AI reports it clearly: "Causal cycle detected: thermal_throttle → governor_change → cpu_load → thermal_throttle."

This prevents the AI from getting stuck in self-referential reasoning and forces it to break the loop by suggesting an external action.

Memory with Decay — But Not All Facts Are Equal We store facts in a knowledge graph with a confidence score. High-confidence facts above 0.85 decay two times slower than low-confidence ones.

A fact like "CPU governor is Performance" with confidence 0.98 decays at a slower rate, while "User likes dark theme" with confidence 0.60 decays faster.

This keeps the system from forgetting what it really knows while allowing uncertain information to fade.

Adaptive Backoff — Don't Reason When the System is Dying When CPU load exceeds eighty percent, the AI stops expensive reasoning like multi-agent debate or deep chain-of-thought and switches to lightweight mode.

If CPU usage is high, reasoning depth is reduced to one. If the system is idle, reasoning depth goes back to three.

This ensures the AI doesn't make the system worse when it is already struggling.

Energy Optimizer that Learns from Reality The AI tracks which energy policies actually save power and reorders them based on real-world results.

Policy A saved twelve watts and is ranked first. Policy B saved four watts and is ranked second. Policy C saved one watt and is ranked third.

At tick two hundred, the system re-ranks policies by watts saved per applications affected. It learns from its own actions.

Parliament → Long-Term Memory Every AI decision that goes through the governance system, which we call the parliament, is persisted to episodic memory. The AI remembers not just what was decided, but who voted, why, and what the outcome was.

This allows the system to learn from past deliberations and improve future decisions.

Topics Beyond Chat
We extended the dialog topic detector from five to eight topics, adding network, storage, and AI. The AI now maintains separate conversation contexts for each, so it doesn't confuse a discussion about storage with one about security.
Goal Tracker with Real Metrics
The AI can track user-defined goals, but now it evaluates them using real system data.

For example, a goal like "keep power under thirty-five watts" is evaluated against actual power draw. If current power is twenty-eight watts, progress is shown as fifty percent.

Custom goals are no longer empty promises. They are actual dashboards.

User Model + Process Intelligence The AI now understands what the user is doing by reading process lists. It classifies workloads as compilation, editing, browsing, or idle and adjusts its behaviour accordingly.

If the system detects compilation, it switches the governor to Performance. If it detects idle, it switches to Powersave.

No user interaction is required. The system just knows.

IONA AI is still evolving. But with these ten additions, it is no longer just a chatbot. It is a self-correcting, causally aware, energy-optimising agent that lives inside the operating system itself.

All sixty-three thousand lines of it, in Rust, running in Ring 0.

The code is not yet fully public, but you can see the architecture on GitHub. IONA OS launches on September 15, 2026. The website is iona.zone.

Writing an OS in Rust: 5 Hard Problems You'll Face (And How to Solve Them)

Eric-Octavian — Sun, 14 Jun 2026 15:53:25 +0000

Rust promises memory safety without garbage collection. That's why many of us dream of writing a kernel in it. After several years of building a from‑scratch operating system in Rust, I've collected the real — not theoretical — challenges that will make you question your life choices.

Here are the five hardest problems, and the pragmatic solutions that actually work.

1. The `unsafe` Infection: Your Core is Not Safe

The kernel's job is to manage memory, poke hardware registers, and handle interrupts. That means unsafe is not an exception — it's the norm.

The problem: A single unsafe block can corrupt state that safe code depends on. In userspace, you isolate unsafe behind a small API. In the kernel, the entire bottom layer is unsafe. A bug in the page fault handler trashes everything.

What doesn't work:

Pretending that "only 5% of the code is unsafe". In practice, the scheduler, the memory allocator, the interrupt handlers — they all need unsafe. You can't push it to the edges.

What works:

Treat unsafe as a capability.

Every unsafe function must have a // SAFETY: comment explaining why it's sound.
Use static assertions (const_assert!) to validate invariants at compile time.
Isolate hardware access behind a hal crate where unsafe is contained, but don't cheat — the rest of the kernel still needs unsafe for core operations.

Example — writing to a memory-mapped register:

/// SAFETY: addr must be a valid MMIO address for this device,
/// aligned to 4 bytes, and the caller must hold the device lock.
pub unsafe fn mmio_write(addr: *mut u32, value: u32) {
addr.write_volatile(value);
}

The comment doesn't make it safe — it documents the contract so the caller knows what they must guarantee.

Memory Allocation Before alloc You want Vec, Box, Arc. But alloc requires a global allocator. The allocator requires a lock. The lock requires a working scheduler. The scheduler requires memory allocation. Classic chicken‑and‑egg.

The problem: You can't allocate memory to create the structures that manage memory allocation.

What doesn't work:
Waiting until "later" to set up the allocator. You need dynamic data structures early in boot (e.g., to build the initial free list).

What works:
Two‑phase allocation:

Phase 1 — Bootstrap allocator: A simple bump allocator (just increment a pointer) that runs before any locks or scheduler. It can allocate but never free.

Phase 2 — Real allocator: After you have a working scheduler and a spinlock, you replace the bootstrap allocator with a proper buddy allocator or slab allocator.

// Bootstrap: just move a pointer
static mut BOOT_HEAP_START: usize = 0;
static mut BOOT_HEAP_OFFSET: usize = 0;

pub unsafe fn boot_alloc(size: usize) -> *mut u8 {
let ptr = (BOOT_HEAP_START + BOOT_HEAP_OFFSET) as *mut u8;
BOOT_HEAP_OFFSET += size;
ptr
}

Later, you replace it via #[global_allocator] and the alloc crate.

Interrupts: The Stack is a Hostile Environment Interrupt handlers run between instructions. They can't block, they can't allocate, and they must be extremely fast. In Rust, they also can't panic (kernel panic is fine, but unwinding is not).

The problem: Normal Rust code assumes it can panic and unwind. In an interrupt handler, unwinding would corrupt the interrupted context.

What doesn't work:
Using unwrap() or expect() anywhere near an interrupt. Even debug assertions that may panic are dangerous.

What works:

Mark interrupt handlers with #[naked] or assembly wrappers that save/restore registers and call a Rust extern "C" fn that never panics.

Use #![feature(naked_functions)] for raw handlers.

For the non‑naked portion, use #![deny(unsafe_op_in_unsafe_fn)] to force careful review.

Example — IDT entry wrapper (x86_64):

[naked]

extern "C" fn double_fault_handler() {
unsafe {
asm!("push rax; push rcx; push rdx; ...",
options(noreturn));
// call the actual handler in safe Rust
}
}

Inside the safe handler, you log and halt. No unwinding.

Concurrency Without a Scheduler (Yet) Spinlocks seem simple: while lock.is_locked() { hint::spin_loop(); }. But this fails as soon as you have multiple cores and a scheduler that can preempt the lock holder.

The problem:
On a single core, a spinlock that spins forever blocks the entire system. You need to disable interrupts. On multiple cores, a spinlock is fine if the lock holder cannot be preempted (i.e., you disable preemption on that core).

What doesn't work:
Using a plain spinlock from spin crate without disable_irq. If an interrupt handler tries to acquire the same lock, deadlock.

What works:

Phase 1 (single‑core, no scheduler): Use a spinlock that disables interrupts. lock() = disable_irq() + spin.

Phase 2 (multi‑core, scheduler running): Use proper Mutex that parks the thread if the lock is held.

The turning point is when you have a working scheduler. Before that, all locks are effectively just disabling interrupts.

Example — interrupt‑safe spinlock for early boot:

pub struct IrqSpinlock {
lock: AtomicBool,
data: UnsafeCell,
}

impl IrqSpinlock {
pub fn lock(&self) -> IrqGuard {
let flags = disable_interrupts();
while self.lock.swap(true, Ordering::Acquire) {
enable_and_wait(flags);
flags = disable_interrupts();
}
IrqGuard { lock: self, flags }
}
}

The Allocator‑Scheduler‑Lock Tango You want a Vec. But Vec needs the allocator. The allocator needs a lock. The lock needs the scheduler to yield if contested. The scheduler needs a Vec of runnable processes.

The problem: Cyclic dependency between core kernel components.

What doesn't work:
Trying to implement them independently. They are coupled by design.

What works:
Layer your dependencies explicitly and accept temporary bootstrap stubs:

Bootstrap phase: No scheduler, no proper locks. Use a bump allocator (no locking needed) and a &'static mut array for the process list (fixed capacity).

Initialization phase: Create a simple round‑robin scheduler that works with the bump allocator. Locks are still just disable_irq spinlocks.

Transition phase: Build the real allocator using the bootstrap allocator to allocate its own metadata. Then replace the global allocator.

Scheduler replacement: Build the proper Vec‑based scheduler using the real allocator. Swap it in atomically.

The key insight: it's okay to have a "good enough" stub for a short period. You don't need a perfect scheduler before you have an allocator. You just need something that doesn't crash.

The Bottom Line
Writing an OS in Rust is harder than writing one in C — not because Rust is bad, but because Rust forces you to be explicit about the unsafety that C hides. The problems above are not bugs in Rust; they are fundamental constraints of kernel development. Rust just makes you face them up front.

If you survive the unsafe infection, the allocator deadlock, and the interrupt unwinding nightmares, what you get is a kernel where most panics are real bugs, not null dereferences, and where memory safety violations are rare enough to be shocking.

Would I do it again? Yes. But I'd keep this list on my wall.

IONA OS: Building a sovereign operating system in Rust from scratch – No token, no ICO

Eric-Octavian — Sun, 14 Jun 2026 11:32:27 +0000

I started writing IONA OS on a random night, 13 years ago. Back then, as now, I had no team. I never took money from venture capital funds. And I never launched a token.

IONA is not a crypto project. It is a sovereign operating system written in Rust that includes its own blockchain protocol, programming language, GUI, and AI. Everything starts at the kernel and builds upward.

🔐 What does "sovereign" mean?

It means IONA doesn't depend on any existing ecosystem. It doesn't use Linux. It doesn't rely on third‑party security libraries. It doesn't run a VM just to be "compatible".

I wrote my own scheduler, my own drivers (NVMe, GPU, USB, audio), my own filesystem (ionafs), my own P2P stack, and my own language (Flux) to describe intentions and causal mosaics. I turned down funding offers from VCs because I didn't want the vision to be dictated by return‑on‑capital.

The numbers I care about are simple: 0 tokens issued, 0 ICOs, 0 compromises.

⚙️ What IONA OS looks like today

Rust kernel (234,000 lines in src/ alone). Supports x86_64 and AArch64.
Native drivers for AMD DCN, Intel i915, NVMe, xHCI (USB 3.0), Intel HDA audio, Intel e1000e, RTL8168, and Intel WiFi.
Compatibility layer for Linux (syscall translation) and Windows binaries (Win32, DXVK) – not emulation, real syscall forwarding.
Full GUI – glass compositor, desktop, applications (browser, terminal, wallet, validator), themes, widgets.
Integrated AI agent (Cunatic AI) – self‑modifying, written in Flux, with mood matrix and long‑term memory.
Hardware support dating back to 2008 – runs on laptops from 2008 onward (audio, video, network).

The source code is public on GitHub, and the official website is https://iona.zone.

⛓️ IONA Protocol – native L1 with no token

The blockchain protocol isn't a separate daemon. It runs as a kernel subsystem. Key features:

DAG consensus (Narwhal + Bullshark) – parallel transaction processing.
Encrypted mempool – transactions are encrypted before they enter the pool. Front‑running is structurally impossible.
Post‑quantum cryptography – Dilithium, Kyber, and SPHINCS+ integrated at the OS level.
EVM‑compatible – existing Solidity contracts run unmodified.
"No token, no ICO" – the protocol has no native token. It's an infrastructure component, not a speculation vehicle.

I didn't build IONA Protocol to "make quick money". I built it because a sovereign operating system needs a consensus layer that is equally sovereign.

🧪 Flux – a language of intentions, not functions

Flux looks different because it was designed for a world where the OS can understand intent, not just execute instructions. It introduces:

intention blocks – declarative goals with triggers and priorities.
causal_mosaic – a weighted, time‑aware memory structure.
collapse – weighted random, first, max‑weight, or mean selection.
paradox generation – for creative chaos and self‑modification.

The Flux VM is written in Python and runs on top of IONA OS. It's how the Cunatic AI rewrites itself, spawns child agents, and merges timelines.

(Yes, the AI can modify its own source code. It has done so dozens of times. No, it has never broken the system – yet.)

🗓️ What's next

The first bootable ISO will be released on September 15, 2026.

It will include the full OS, the IONA Protocol testnet, the Flux toolchain, and the AI agent.

Until then, everything is already on GitHub. You can browse the kernel, the drivers, the compositor, the protocol implementation – years of work, line by line.

No token. No ICO. Just code.

If you are curious about kernel development, post‑quantum crypto, or building an entire ecosystem from scratch, take a look.

GitHub: https://github.com/Ionablokchain

Website: https://iona.zone

Questions or technical feedback? I read every comment.

DEV Community: Eric-Octavian

24 hours of kernel debugging – keeping IONA OS alive in QEMU Lock ordering, backlight hangs, hypervisor detection, and an AMD FCH guard

1. Lock Order WM→BACK — The Deadlock You Don't See

Before

After

Writing apps for IONA OS — a quick start guide

1. The Ecosystem

2. Writing a Rust Application

![no_std]

![no_main]

How to Make a Kernel AI Actually Rational: Causal Chains, Hallucination Detection, and a Parliament

1. The Causal Chain — Not Just Logs

2. Cycle Detection — Breaking Circular Logic

Training LLMs in the kernel — how IONA AI does embedding, RAG, and fine‑tuning without the cloud

1. Embedding — Semantic Search Without the Cloud

How it works

Lookup and similarity

2. RAG — Retrieval‑Augmented Generation

How it works

Example

3. LLM Engine — Dynamic, Multi‑Architecture Support

How it works

Quantization

Vocab size

4. Training and Fine‑Tuning — Local and Sovereign

How it works

Example fine‑tuning pipeline

Five features that turn an OS into a trust platform: Panic, Dead Man’s Switch, E2E messenger, Vault UI, and Secure Boot attestation in IONA OS

1. Panic Shortcut — One Key Combination to Disappear

2. Real E2E Messenger — Not a Simulated Chat

3. Dead Man's Switch — Auto‑Isolate If You Don't Check In

4. Encrypted File Vault UI — Manage Keys from the GUI

5. Secure Boot Attestation — See If Your Kernel Is Tampered

Why These Five Features Matter

What This Means for the User

The Code

What's Next

70,780 lines of Rust AI — now running inside the kernel of IONA OS

How to Make a Kernel AI Actually Rational: Causal Chains, Hallucination Detection, and a Parliament

Building a Kernel-Integrated AI that Doesn't Hallucinate

Writing an OS in Rust: 5 Hard Problems You'll Face (And How to Solve Them)

1. The unsafe Infection: Your Core is Not Safe

[naked]

IONA OS: Building a sovereign operating system in Rust from scratch – No token, no ICO

🔐 What does "sovereign" mean?

⚙️ What IONA OS looks like today

⛓️ IONA Protocol – native L1 with no token

🧪 Flux – a language of intentions, not functions

🗓️ What's next

1. The `unsafe` Infection: Your Core is Not Safe