Why did this happen?

What you're seeing

copperos.org/try used to boot CopperOS inside your browser. It now shows a hanging OUT OF ORDER sign and a Why? button, and there is no Start button any more.

Why it happened

The emulator was never CopperOS itself — it was v86, an x86 PC emulator compiled to WebAssembly, running in your browser tab and pointed at copperos.iso as if it were a CD in a drive. That arrangement has three fragile joints, and they were all creaking at once:

• The engine came from somebody else's CDN. The v86 build, the SeaBIOS image, and the VGA BIOS were fetched from jsDelivr at page load. If any one of those requests failed or was blocked, the page hung on "Booting…" forever with no useful message.
• The whole ISO had to arrive before anything happened. The emulator downloaded the full 1.8 MB image up front. On a slow or metered connection that felt identical to a broken page.
• CopperOS is a real BIOS-era kernel, and v86 is an approximation. Copperhead drives VESA graphics modes and BIOS interrupts directly. v86's emulation of those is close but not exact, so the boot could stall or draw garbage on hardware paths that work fine in QEMU.

Rather than leave a page that fails in an ambiguous way, the emulator is switched off and says so honestly. Turning it off also let the site's Content-Security-Policy drop unsafe-eval, wasm-unsafe-eval and the external script source it needed — so the rest of copperos.org is measurably harder to attack now.

How to run CopperOS instead

Local emulation is faster and considerably more accurate. Grab the ISO from the download page, then:

qemu-system-x86_64 -cdrom copperos.iso -m 256M -boot d

In VirtualBox: create a new machine, type Other / Unknown (32-bit), 256 MB RAM, no hard disk, then attach copperos.iso to the optical drive and start it. The copperos.vdi download works as a hard disk instead if you prefer.

Is it coming back?

The plan is to bring it back self-hosted rather than CDN-loaded, so it either works or reports precisely which file failed. There is no date attached to that, and the roadmap will say so before this page does.

What you're seeing

You clicked Download ISO (or IMG, VDI, or checksums) and got a small file that your system refuses to mount or boot. Opening it in a text editor reveals a web page rather than a disk image. It may have been saved as copperos.iso but it was only a few kilobytes.

Why it happened

This was a real bug on this site, and it is fixed. Two things combined:

• The files genuinely weren't published. The download buttons pointed at /build/copperos.iso, /build/copperos.img, /build/copperos.vdi and /build/SHA256SUMS. Those paths were never part of the deployed site — the images existed only inside the source archive.
• A catch-all redirect turned the miss into a web page. The site had one rule at the bottom of its routing table: anything that matches nothing goes to the not-found page. It sent a 302 redirect, and your browser politely followed it and received a perfectly valid HTML document with a 200 OK status. Because the link carried the download attribute, the browser saved that HTML under the filename you asked for. From the browser's point of view nothing failed at all — which is exactly why there was no error message.

What was changed

• The real copperos.iso, copperos.img and copperos.vdi images are now published on the site, along with a SHA256SUMS file generated from those exact files.
• Each download is served with its true content type and an explicit attachment header, so browsers save them as binaries instead of trying to render them.
• The catch-all now answers with a genuine 404 status instead of a redirect. A missing file is now reported as a failed download rather than silently substituted with a page.

How to fix your copy

Delete the bad file and download again — a hard reload (Ctrl+Shift+R, or Cmd+Shift+R on a Mac) clears any cached redirect. Then confirm you have the real thing:

# Should print: ISO 9660 CD-ROM filesystem data 'COPPEROS' (bootable)
file copperos.iso

# Should be roughly 1.8 MB, not a few kilobytes
ls -lh copperos.iso

# On Windows PowerShell:
Get-Content copperos.iso -TotalCount 1

If file still reports HTML, you are being served a cached copy. Try a private window or append ?v=2 to the download address once.

What you're seeing

sha256sum -c SHA256SUMS reports FAILED, or the hash you computed differs from the published one.

Why it happened

• The download was truncated. By far the most common cause. An interrupted transfer produces a file that looks present but is short.
• You are checking a file from an older release. The checksums are regenerated whenever the images are rebuilt, so a hash from a previous visit will not match a newer image.
• The transfer mangled line endings. Only affects SHA256SUMS itself, not the images — some tools rewrite text files during transfer, which breaks the checksum list even when the images are perfect.

How to fix it

# Re-fetch both, then verify in the same directory:
sha256sum -c SHA256SUMS

# Check one file by hand:
sha256sum copperos.iso

# macOS:
shasum -a 256 copperos.iso

# Windows PowerShell:
Get-FileHash copperos.iso -Algorithm SHA256

Compare the size first — if the file is smaller than it should be, the checksum will never match and re-downloading is the only fix. If a full-size file still fails after two clean downloads, that is worth reporting on the support page.

What you're seeing

A black screen, a no bootable medium message, an immediate reboot loop, or the boot sequence starting and then freezing partway through.

Why it happened

Copperhead is a 32-bit, BIOS-booting kernel. It does not support UEFI, it does not support 64-bit long mode, and it expects to talk to a BIOS the way PCs did in the 1990s. Modern virtualisation defaults fight all three of those assumptions.

• UEFI firmware is selected. There is no EFI boot loader in the image, so UEFI firmware finds nothing to start. This is the single most common cause.
• Boot order prefers a hard disk. The CD is attached but is not first in line, so the machine tries an empty disk and gives up.
• Not enough memory. Below roughly 128 MB the kernel cannot lay out its framebuffer and stops early.
• The guest type is set to a modern OS. That hands the machine a chipset and graphics adapter Copperhead does not drive.

How to fix it

QEMU, which is the configuration Copperhead is developed against:

# Boot from the CD (-boot d) with BIOS firmware, which is QEMU's default
qemu-system-x86_64 -cdrom copperos.iso -m 256M -boot d

# Watch the serial output if the screen stays black
qemu-system-x86_64 -cdrom copperos.iso -m 256M -boot d -nographic

# Boot the disk image instead of the CD
qemu-system-x86_64 -drive format=raw,file=copperos.img -m 256M

VirtualBox, setting by setting:

• Type Other, version Other/Unknown (32-bit).
• Base memory 256 MB.
• System → Motherboard → leave “Enable EFI” unchecked. This is the setting that matters most.
• Boot order: Optical first.
• Attach copperos.iso to the optical drive, or attach copperos.vdi as the hard disk and boot from that instead.

If it boots but the picture is wrong rather than absent, that is a graphics-mode problem, not a boot problem — the kernel asks for VESA 1280×720×8 first and falls back through more common modes. Reporting which host and which VM you used is genuinely helpful on the support page.

What you're seeing

A CopperOS-branded 404 page instead of what you asked for.

Why it happened

The address matched no page, no asset and no API route on this site. Usually that means a typo, a link from somewhere else that has gone stale, or a page that was renamed. A few real examples: the roadmap lives at /roadmad (an old typo that is kept working on purpose so existing links do not break), and the emulator page is /try rather than /emulator.

A 404 here is a genuine 404 — the site answers with a real not-found status rather than pretending the page exists. That matters for downloads, which is the subject of errDownloadHtml.

How to fix it

Start from the home page, or jump straight to downloads, the FAQ, or discussions. If a link on this site brought you here, that is a bug on our side — please say where you clicked from on the support page.

What you're seeing

You already chose Accept or Decline, but the notice appears again on the next page or the next visit.

Why it happened

Your choice is remembered in a single first-party cookie called copperos_consent. The notice reappears whenever that cookie is not readable when a page loads:

• Cookies are blocked entirely, so the choice has nowhere to live. There is no way around this one — remembering that you declined still requires storing the fact that you declined.
• A privacy extension clears cookies on tab close, or you are in a private window that discards them when it ends.
• The request to record it failed. If the network hiccuped, the banner falls back to writing the cookie itself — but if scripts were blocked too, neither route worked.
• You visited a different hostname. A cookie set on copperos.org is not sent to a www. or preview-deploy address.

How to fix it

Allow cookies for copperos.org specifically, or add it to your extension's exception list. If you would rather not, the notice is harmless — declining leaves the site fully usable, and you can dismiss it as often as it appears.

To change a choice you already made, use the cookies page — it explains exactly what each category does and lets you set it again.

What you're seeing

One of: That code was not accepted, Too many failed attempts, or Administration is switched off.

Why it happened

• “That code was not accepted” — the code did not match. The message is deliberately vague and every answer takes the same amount of time, so nothing about the real code can be inferred from how the site responds.
• “Too many failed attempts” — five wrong codes from one address within fifteen minutes locks that address out for the rest of the window. Waiting is the only way through; there is no bypass.
• “Administration is switched off” — no admin code is configured for this site, or the configured one is shorter than twelve characters. Rather than accept a weak code, the admin area refuses to open at all.

If you are the site owner

Set ADMIN_CODE in the project's environment variables to a random string of twelve characters or more, then redeploy. Nothing else needs changing, and the code is never written into any file in the repository.

Can the code be extracted from the page?

No, and the site is built so that it cannot be. The code exists only as a server environment variable. It is compared inside a server function using a constant-time digest comparison, so a wrong guess reveals nothing through timing. It is never sent to the browser, never logged, and never stored in a file. When a login succeeds the browser receives an opaque random session token in a cookie marked HttpOnly, Secure, SameSite=Strict and __Host- prefixed — meaning page scripts cannot read it via document.cookie, it cannot travel over plain HTTP, it is not attached to requests from other sites, and it is pinned to this exact hostname. Only a SHA-256 hash of the token is stored on the server, so even a database read cannot be replayed as a login. The session expires after thirty minutes.

What you're seeing

no auth, username taken, banned, or a post that silently does not appear.

Why it happened

• no auth — your account token is missing. Tokens live in your browser's local storage, so clearing site data, switching browsers, or using a private window signs you out. Create or re-enter an account on the discussions page.
• username taken — names are unique regardless of capitalisation, so Copper and copper collide.
• banned — a keyword filter flagged the post and applied an automatic fifteen-minute ban. The filter is deliberately blunt and does produce false positives; the response includes the time the ban lifts.
• Nothing happened at all — the post was empty, or the request failed. Both title and body are sent as text; a post with no content is accepted but shows as blank.

How to fix it

Sign in again, pick a name nobody has, and if a ban looks wrong, wait it out and then say so on the support page — false positives are useful bug reports. You can also review or delete your account at any time from manage my account.

What you're seeing

The form reloads without confirming, or you never reach the thank-you page.

Why it happened

• A required field was empty. Name, email and message are all mandatory; the browser blocks submission and highlights whichever is missing.
• The spam trap caught it. There is a hidden field that must stay empty. Aggressive autofill extensions sometimes fill it in, and that silently discards the submission.
• Scripts were blocked. The form still sends — it just arrives without the account and country attribution that a script normally attaches.

How to fix it

Fill in every field, disable autofill for the page if you use an aggressive password manager, and check for a typo in your email address — a reply cannot reach a malformed one. If the form still refuses, the discussions page reaches us too.