If SigeonOS has stopped and shown you a red screen, this page will help you read it, recover from it, and report it so it can be fixed.
Why SigeonOS stops and what the red screen means.
A kernel panic is SigeonOS's last line of defence. When the kernel hits a problem it cannot safely recover from — such as an unhandled page fault, a division by zero, or an invalid opcode — it stops everything, records what happened, and shows you a panic screen instead of continuing to run in a broken state.
The panic screen is not a crash you can click past. It is the kernel telling you: something went wrong that I could not handle, and I am halting to protect your data and your machine.
Most panics come from one of four places:
A panic is different from a normal application crash. If a built-in app or a PEX program fails, you will usually see an alert or a closed window, not a panic. The panic screen only appears when the kernel itself has stopped.
Every part of the screen has a purpose. Here is what to look for.
A short, specific label such as EXC_PAGE_FAULT or EXC_GENERAL_PROTECTION. This is the single most important thing to note down.
A one-line description of what the kernel was doing when it stopped. It often includes a memory address or the name of the subsystem involved.
A link to kernel-panic.sigeon.xyz with the error code pre-filled. Scan it with your phone to open this site and look up the code.
The message Press ENTER to restart SigeonOS. Pressing Enter attempts a clean reboot.
If you have a serial console attached, the same information is written there, and can be captured to a file for a bug report.
The machine will not respond to mouse or keyboard except for the restart prompt. This is intentional.
That is fine. The QR code is designed to be scanned from the screen, and the error code is printed large enough to read from a photograph. If you are reporting the panic, a photo plus the error code is the most useful thing you can provide.
When SigeonOS is booted with a serial console attached, the full panic log is written to the serial port as well as the screen. Capturing that log gives the developers much more detail than a photo alone.
What to do in the first minute.
Before you restart, note the error code exactly as it appears. If you can, also write down the log line and any numbers in it. This is the most valuable information you can give to anyone helping you.
If you have a phone, photograph the whole screen. It captures the error code, the log line, and the QR code in one shot, and removes the risk of misreading a character.
Press Enter on the panic screen. SigeonOS will attempt to restart. Most one-off panics do not come back after a clean reboot.
If the machine boots normally and the panic does not return, you can continue working, but you should still report the panic so the underlying cause can be tracked down.
If the same panic happens every boot, stop and read Recovering from a repeating panic before doing anything else. Repeated panics usually mean a hardware problem or a boot-time driver bug that needs attention.
What each panic code means and what usually causes it.
| Code | Meaning |
|---|---|
| EXC_DIVIDE | A division by zero or a divide overflow occurred in kernel code. Usually a bug in a driver or the kernel's own arithmetic. |
| EXC_INVALID_OPCODE | The CPU tried to execute an instruction it does not recognise. Often a corrupted code path or a jump into the wrong memory. |
| EXC_DOUBLE_FAULT | A second fault happened while the kernel was already handling the first one. This is always serious and usually indicates a broken interrupt handler or stack. |
| EXC_INVALID_TSS | The task-state segment is invalid. This is normally a bug in the kernel's descriptor-table setup. |
| EXC_SEGMENT_NP | A segment that is not present was referenced. Usually a descriptor-table problem or a bad far call. |
| EXC_STACK | A stack overflow or an invalid stack access. Often caused by runaway recursion or a corrupted stack pointer. |
| EXC_GENERAL_PROTECTION | The kernel accessed a segment or descriptor in a way the CPU does not allow. Common causes are a null pointer dereference or a mis-set segment register. |
| EXC_PAGE_FAULT | A memory access to an unmapped or protected page. This is the most common panic and usually means the kernel tried to read or write an address it does not own. |
| EXC_ALIGNMENT | An unaligned memory access where the architecture requires alignment. Often a driver bug with a packed structure. |
| MANUAL_CRASH | The developer crash chord was pressed on purpose. This is not a real fault — it is a test. |
Many panics include a memory address, like 0x0000000000000010. A very small address (below 0x1000) almost always means a null pointer dereference — the kernel read from or wrote to an offset from a null pointer. A large address is more likely a real memory-management bug.
New codes are added as the kernel grows. If you see a code that is not in this table, the code itself is still the most useful thing to report. The SigeonOS team can look it up from the kernel source, and the table will be updated.
What to include and where to send it.
A good panic report is short but complete. Include:
EXC_PAGE_FAULT.The SigeonOS community reports panics in the #bug-reports channel on Discord. It is the fastest way to get a human to look at your report.
A developer or community member will usually reply to confirm the code, ask for any missing detail, and either suggest a workaround or file the panic as a known issue. If the panic has a known fix, they will point you at it.
Support channels for SigeonOS kernel panics.
The main support channel. Post in #bug-reports for panics, or ask in the general channels for help reading a code. Join at discord.gg/C6QfW357fw.
kernel-panic.sigeon.xyz is the reference for panic codes and recovery steps. The QR code on your panic screen links directly here.
The full SigeonOS manual covers the desktop, apps, terminal, and networking. Start there if you are new to the system.
The SigeonOS source lives at github.com/sigionosdeveloper. If the project has an issue tracker open, panics can also be filed there.
Scanning the QR code on a panic screen opens this site with the error code pre-filled, so you can jump straight to the right section.
If you can attach a serial console, capture the full panic log. Developers can usually diagnose a panic from the log alone, without needing the machine in front of them.
Have the error code ready, and if possible a photo of the screen. It is much easier to help when the code is known, because the recovery path and likely cause are different for each one.
If Discord is unavailable to you, the same information can be posted on the GitHub repository if an issue tracker is open, or included in any community forum where SigeonOS is discussed. The error code is the key detail — it is what everyone will ask for first.
What to do when the machine will not stay up.
If the panic happened once and the machine restarts normally, you do not need to do anything special. Note the code, report it, and keep using the machine. One-off panics are usually caused by a rare race or a transient hardware glitch and rarely repeat.
If the machine panics every time you start it, work through these steps in order:
SigeonOS writes filesystem snapshots to disk with an atomic two-bank journal. If the machine panicked while you were working, the previous committed snapshot is used on the next successful boot, so files you had already saved should still be there. Work that was open but not saved at the moment of the panic may be lost.
If the machine boots but Finder shows an empty or unreadable disk, the snapshot journal may have been unable to recover. In that case, boot from the ISO and copy any important files off the disk if you can mount it, then reinstall SigeonOS. The SigeonFS journal is designed to make this rare, but no filesystem can protect against every possible hardware failure.
If the machine will not boot at all and you have tried the steps above, reinstalling SigeonOS from the ISO will give you a clean system. This clears the installed filesystem, so back up anything you can reach first. After reinstalling, if the panic returns, the problem is likely hardware rather than the installation.
How the QR code on your panic screen works.
Every panic screen prints a QR code. The code encodes a URL of the form:
Scanning it with a phone opens this site with the error code already known, so you land directly on the right page. The code is standard version 3, error-correction level M, and can be read by any normal QR scanner.
The code is printed at a fixed size on the panic screen. If your scanner has trouble, move the phone a little further away or adjust the screen brightness. If it still will not scan, you can simply visit kernel-panic.sigeon.xyz manually and enter the error code from the screen.
A panic can happen on a machine with no working network, and typing a long error code by hand is error-prone. A QR code lets you capture the exact code and hand it to a working device without retyping it.
The one-screen summary.
| Step | Action |
|---|---|
| 1 | Write down the error code and, if you can, the log line. |
| 2 | Photograph the screen if you have a phone. |
| 3 | Press Enter to restart. |
| 4 | If it boots normally, report the panic in Discord #bug-reports. |
| 5 | If it repeats, remove recently added hardware and try again. |
| 6 | If it still repeats, boot from the ISO to check whether the problem is on the installed disk. |
| 7 | If nothing works, report the code and hardware in Discord — do not keep power-cycling. |
The single most useful thing you can do after a panic is write down the error code. Everything else follows from that.