Repository navigation
Feat/alpha foundation - #2
Merged
Merged
Conversation
…artup reliable Hyprland 0.56 is configured in Lua. The shipped hyprland.conf was parsed by the legacy loader and produced 13 config errors on every login (removed gesture options, removed togglesplit dispatcher, deprecated windowrulev2, a source= glob that matched nothing). - hyprland.lua replaces hyprland.conf/monitors.conf; verified with 'Hyprland --verify-config' from the shipped 0.56.2 binary (config ok) - user.lua holds personal overrides and is loaded last through pcall - the keyboard layout comes from /etc/default/keyboard, so the layout chosen in the installer is the layout of the session (it was hardcoded to us) - simos-session starts the desktop in one ordered script: the session environment is exported to D-Bus/systemd before anything that needs it, which the concurrent exec list raced (mako and the polkit agent could start without WAYLAND_DISPLAY and fail) - swaybg replaces hyprpaper: hyprpaper >= 0.8 cannot allocate buffers on software-rendered machines and segfaults, leaving no wallpaper in VMs - upstream update-news and donation pop-ups are disabled - Waybar gains an 'Install SimulationOS' button that exists only while the installer does (live medium), and simos-welcome greets the first session
Everything SimOS-branded is now drawn 'in binary': the wordmark is a dot matrix whose cells are 0/1 digits, captioned with the name in ASCII binary (01010011 01101001 01101101 01001111 01010011). - three 2560x1440 wallpapers built entirely from binary digits, on original fantasy themes: a wall of ice under a winter moon, a dragon's eye in fire, a throne of swords (Super+W cycles them) - fastfetch shows the SimOS logo for every user (skel config + logo file) - application icon, Calamares logo/welcome/icon and the BIOS boot splash use the same mark; hyprlock shows SimOS with the binary caption - scripts/make-branding.py regenerates all of it deterministically and replaces make-wallpaper.py
The installer had never been run end to end. Running it for real found that it could not start, and that the sequence could not produce a bootable system even if it had: - cachyos-calamares links against Boost 1.91 while Arch ships 1.92, so every Calamares binary and module failed to load. scripts/calamares-compat.sh now runs before mkarchiso, detects the mismatch and stages the matching, signature-verified Boost libraries for the installer only (or does nothing once CachyOS has rebuilt). The build fails if that cannot be done. - 'calamares -c <dir>' aborts without <dir>/qml, and settings.conf lacked the required hide-back-and-next-during-exec key. - mount.conf, fstab.conf, umount.conf and keyboard.conf used schemas older than the shipped Calamares 3.4 (the mount job crashed on the first partition). - mkarchiso empties /boot inside the SquashFS, so the target had no kernel. simulationos-deloop now installs it from /usr/lib/modules the way the mkinitcpio pacman hook does. - initcpio.conf passed a literal '*' to mkinitcpio -p; it now builds all presets. - the installed system had no pacman keyring (it is a tmpfs on the live medium); deloop initialises it. Sequence: removeuser and deloop now run right after unpacking and BEFORE initcpiocfg/initcpio, so the archiso mkinitcpio config is gone when the initramfs is generated; displaymanager is configured; installer-only packages are removed before GRUB is installed; a new last job, simulationos-verify-target, refuses to report success for a target that cannot boot or still carries live-medium state. simulationos-deloop is idempotent and exits non-zero when a security- or boot-critical step fails, instead of always returning 0. The launcher verifies the install source at runtime (bootmnt or copytoram), checks that Calamares can load, hands only the display variables through pkexec, clears a stale single-instance lock, judges only the current run of the appended session log, and on failure names the failed job in a desktop notification and writes a diagnostics file. Alpha scope is narrowed to the golden path: UEFI, GPT, ext4, GRUB.
Until now the tests booted the live ISO and ran the de-live script in a chroot; Calamares was never started and no installed disk was ever booted. - scripts/install-test.py drives the journey like a person: QEMU key and pointer events plus OCR of the screen (the technique CachyOS uses with quicktest). It opens the installer from the desktop, installs to a blank disk (UEFI, GPT, ext4, GRUB), inspects what each job wrote, powers off, boots the disk WITHOUT the ISO, logs in through SDDM, obtains a shell with the user's sudo password, asserts on the running system, reboots, checks again and powers off. Screenshots, logs and a result matrix are kept. - VM tests use virtio-gpu: on QEMU's std VGA Hyprland has no renderer and draws nothing, which the process-only checks reported as a healthy desktop. live-health now asserts on the renderer, on Hyprland's own config-error list, on the bar and wallpaper layers, and that Calamares resolves its libraries. - .github/enable-kvm.sh lets runners use KVM; everything still works under TCG. - deloop-test.sh also checks the installer and Hyprland contracts against the real binaries, deloop idempotence, and that mkinitcpio -P yields an initramfs without archiso. - validate-profile.sh understands the Lua config and guards the installer job order, the qml directory, executable permissions in profiledef.sh and the wallpaper/fastfetch assets. - test-iso.sh works on macOS (no GTK/virgl there) as well as Linux.
…rfaces Failures of CI run 37142284869 (both in the test scripts, not the product): - deloop-test.sh deleted its work directory while /sys and /dev were still bind-mounted into it. The chroot now gets a fresh /proc, a read-only sysfs and a private tmpfs /dev with only the nodes the tools need; the work directory is removed only after findmnt confirms nothing is mounted beneath it, with --one-file-system as a second barrier. - the qml check followed an absolute symlink on the host; it now runs inside the image. - the fastfetch check prints fastfetch's output when the logo is missing. - live-health.sh (and install-test.py) treated 'the Waybar process exists' as 'the desktop is ready'. Under emulation the bar is mapped noticeably later; readiness now waits for the bar and wallpaper layer surfaces.
…call Failures of CI run 37144555200: - fastfetch showed the stock Arch logo. It resolves its config from the user's real home directory, so the skel copy only ever reached users created after installation - not root, and not the test. The config now lives in /etc/xdg/fastfetch and applies to every user. - live-health reported 'desktop not ready' although the bar and wallpaper were drawn: the readiness loop captured Hyprland's instance signature once, before Hyprland had started, and then queried a non-existent instance for the whole wait. hyprctl's instance is now resolved on every call (same fix in install-test.py).
- acceptance.yml gains the 'install' job (scripts/install-test.py) and uploads its screenshots, logs and result matrix; it can be dispatched against the ISO of an earlier run (run_id), so harness changes need no rebuild - live-health and boot jobs enable KVM on the runner - validate.yml lints the new scripts and proves that the new validator guards fire (initramfs generated before de-living; legacy hyprland.conf)
…s characters
Under KVM on the hosted runners the emulated UART repeats a character now
and then ("wallpapeer", "###END"). The first CI run of the install job
installed correctly - the screenshots show "All done." - but the harness
lost its end marker and reported a failure.
- command output is kept in a file in the guest and sent as hex bytes with
an MD5 and the exit status; repeated characters are undone, the sum is
checked and a damaged transfer is requested again
- markers are matched with repeated characters squeezed out
- an unanswered progress poll is no longer parsed as a job name
- the bar button is recognised by its first word inside the bar strip; the
bold monospace label does not OCR whole
… CI exposed The second CI run got through the installation and the first boot of the installed disk. What it still tripped over was the harness: - a whole Calamares log as plain hex takes minutes on a UART paced at its baud rate, so the transfer timed out and its tail corrupted the next commands; transfers are now gzipped - the serial login after the second boot matched the first boot's prompt that was still in the console log; wait_for can now start at a mark - the user's interactive shell aliases ls (ls -t failed), and hostname(1) is not installed; use 'command ls' and 'uname -n' - the bar button is recognised as the wide accent-coloured block in the bar instead of by OCR of its label - a failed unit is reported with its result and last journal lines
The live medium enables systemd-time-wait-sync because pacman's keyring needs a sane clock. The installer copied that onto the target, where the unit times out whenever no time server is reachable and leaves every such boot "degraded" (seen in the CI install test: "start operation timed out", "Exit without adjtimex synchronized"). simulationos-deloop now removes the enablement; systemd-timesyncd stays enabled.
- after 'systemctl reboot' the old desktop stays on screen while the session stops, and the harness typed the greeter credentials into it; it now waits for the firmware's message on the serial console - findmnt was given two mount points as one device/mountpoint pair - only the outline of the Calamares log is fetched: the serial line manages a few hundred characters a second on the hosted runners
Shutdown of the installed system took longer than the 120 s budget in CI (reboot and power-off). Allow three times that, record the duration, and log the previous boot's stop-job timeouts so the cause is in the evidence.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.