Aurora OS Download

🐞

Bugs we found and how we fixed them

Real bugs met while building and using Aurora, what caused them and how they were fixed.

Real bugs met while building Aurora, most of them by using the system the way a person does (on real hardware, in QEMU and on Hyper-V). Each fix has a test that would catch it coming back.

SymptomCauseFix
On Hyper-V, after installing, the VM skipped the disk and tried the network (PXE).Boot entries written by the guest into the VM's firmware are unreliable on Hyper-V (Debian #949751), and the disk's fallback path held shim without the GRUB and config it loads (Debian's signed GRUB always reads \EFI\debian\grub.cfg).The installer uses Debian's --force-extra-removable (the full signed chain in \EFI\debian and \EFI\BOOT, no fbx64.efi), writes no firmware entry on Hyper-V and removes the one the bootloader step made. The install test boots the disk with an empty NVRAM, like a fresh Hyper-V VM.
Wayfire flickered on Hyper-V.Hyper-V's display driver copies each frame to the host's video memory when the compositor commits it, right after glFlush(), while Mesa's software renderer can still be drawing it in background threads.On Hyper-V, llvmpipe runs without worker threads (LP_NUM_THREADS=0): each frame is complete before it is copied.
On Hyper-V, the live ISO didn't start with Secure Boot on (PXE).The live ISO's boot loader isn't signed.The Hyper-V script and guide turn Secure Boot off for the ISO; installed systems start GRUB directly there (the signed shim chain on other machines).
"Try Aurora OS (safe graphics)" only reached a text login.It used nomodeset, and Debian's kernel has no simpledrm: without a KMS driver a Wayland compositor has no display.Safe graphics keeps the display driver and forces software rendering and labwc (aurora.safegraphics nouveau.noaccel=1).
"Boot from hard disk" did nothing on UEFI.It chained to the disk's boot sector, which only BIOS has.On UEFI it returns to the firmware, which starts the next device.
The shell didn't start on Hyper-V.UPower's display device there isn't a battery, and reading it raised an error.The battery code reads the device kind; every hardware service fails safe instead of stopping the shell.
Double-clicking a file on the desktop did nothing, then took down the whole shell.Gtk.FileLauncher goes through the portal, which can't handle the shell's layer surfaces: a Wayland protocol error.Files open in their default app directly; the session restarts the shell if it ever exits.
Double-clicking a desktop icon never opened it.The icon button's own gesture claimed the presses, so the second click never arrived.The double-click gesture runs in the capture phase.
Hot corners never fired.The compositor gives no pointer input to a fully transparent surface.The corners are 1% opaque: invisible, but they receive the pointer.
A top-bar menu opened by shortcut ignored Esc and kept the keyboard.The menu opened before the bar had keyboard focus, and the bar kept it afterwards.The bar takes the keyboard first, then opens the menu, and gives it back when it closes.
Files' context menu never appeared.translate_coordinates() returns two values in the PyGObject Debian ships, not three.The call accepts both forms.
Text containing "&" vanished in Settings ("Date & Time").Adwaita reads row titles as markup.Rows show plain text; group titles are escaped.
The dock stayed magnified, or animated forever under a still pointer.Resizing icons makes GTK report the pointer again at the same place, which restarted the animation.Motion at an unchanged position is ignored; magnification is recomputed after the dock rebuilds.
The dock's right-click menu listed "Terminal" three times.Renaming apps at build time also renamed their actions (New Window, Preferences…).Only the [Desktop Entry] group is renamed; an image check guards it.
Every installed machine had the same SSH host keys.openssh-server generated them at build time.The image ships without keys; sshd creates them on each machine.
Stale, half-erased regions on screen in virtual machines.GLES and GTK's GL renderers on Mesa's software rasterizers redraw partially wrong there.Without a real GPU the compositor uses pixman and GTK uses cairo.
GTK 3 apps (Firefox, LibreOffice) crashed when started from the dock.They inherited the shell's GTK 4 layer-shell preload.The shell removes the preload before starting apps; the boot test checks it.
The boot menu's highlight overlapped the next entry.GRUB offsets the selected entry's text by its box's border.The other entries get an invisible box with the same borders.
A local AI model could fill the disk.Downloads didn't check free space.A download only starts if the disk keeps 5% free (2–10 GB); a full disk mid-download removes the partial file; the shell warns when a disk gets that full.
The installer couldn't copy the system, then refused every password.squashfs-tools and the cracklib dictionary were missing from the image.Both are in the package lists; the install test runs the real installer end to end.
The Assistant refused attachments with Ollama or LM Studio on the network.It only allowed attachments for the built-in local model.Attachments go to any model on this computer or a private network address, never to a cloud endpoint; a headless test checks both.
“Attach file” seemed to do nothing.The file chooser opened behind the always-on-top Assistant.labwc and Wayfire keep the portal's file chooser on top too.
Wayfire exited at once on virtio-gpu without 3D.Mesa refuses software rendering when a render node exists, and forcing it crashes Wayfire.That setup starts labwc; ~/.config/aurora/compositor can still choose Wayfire.
On Hyper-V the installed system sat at “Start PXE over IPv4”.Not the disk: the VM's boot order had the network before the disk (Hyper-V's default), and our script only moved the DVD first. A report script on the Windows host showed it.The script and the guide set the whole order: DVD, disk, network.
On Hyper-V the installed system still didn't start: “The boot loader did not load an operating system”, whatever boot loader was on the disk.Not the disk, nor any boot loader: the VM's firmware couldn't read the virtual disk (“Read file error - BlockIo” in a UEFI Shell started from the DVD). On that host it reads a .vhdx only through a checkpoint's differencing disk, and our VM script turned checkpoints off. Found by trying: the same disk started in a VM made with Windows' defaults, then eight boots with checkpoints on and off.The script and the guide leave checkpoints as Windows sets them, and turn them back on for VMs made earlier. Meanwhile the EFI step had been changed twice on wrong guesses; on Hyper-V with Secure Boot off it installs GRUB directly, which is what started on the real host.
The installer's checkboxes were flat squares with no tick.The image has no Qt SVG image plugin, so the SVG marks weren't drawn.The marks are PNGs rendered at build time.
The live system warned “Disk almost full”.Its root is an overlay in RAM with about 2 GB free.The warning skips file systems in memory (overlay, tmpfs); a unit test checks it.
The weather under the calendar disappeared in the live system.Its time zone is UTC, which has no city to take the location from.It asks to choose a city in Weather instead of hiding.