Skip to content

fix: session edge paths, non-well-formed locked rc.xml, fail-soft packaging - #4

Open
DeBondor wants to merge 5 commits into
singularityos-lab:mainfrom
DeBondor:fix/session-and-packaging-edges
Open

fix: session edge paths, non-well-formed locked rc.xml, fail-soft packaging#4
DeBondor wants to merge 5 commits into
singularityos-lab:mainfrom
DeBondor:fix/session-and-packaging-edges

Conversation

@DeBondor

@DeBondor DeBondor commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

Fixes session edge paths, installer reboot handling, fail-soft firmware verification, and the desktop schema version. Verified through installation, first boot, greeter, and desktop login in QEMU with OVMF and swtpm.

DeBondor added 5 commits July 26, 2026 13:04
The header comment mentioned singularity-shortcut's --serve mode. "--"
is not allowed inside an XML comment, so libxml2 fails the whole file
with "Double hyphen within comment" and labwc discards the locked
config: the greeter and OOBE compositor run with labwc defaults, without
the keybind lock this file exists to apply.
In client mode the OOBE runs as root and pointed XDG_RUNTIME_DIR at
/run/singularity purely to reach the persistent compositor's socket.
Every client library root loads then puts its runtime state there:
at-spi, dconf, gvfs and gvfsd land as root-owned 0700 directories, and
greeter-ready as root:root 0644, in a directory owned by the greeter
(0770 greeter:singularity-session) that the greeter has to write once we
hand over.

The greeter runs as uid greeter and cannot rewrite any of it, so it dies
on "can't create /run/singularity/greeter-ready: Permission denied" and
greetd loops on "greeter exited without creating a session": a black
screen after the OOBE completes.

Keep XDG_RUNTIME_DIR at root's own /run/user/0 and reach the compositor
through an absolute WAYLAND_DISPLAY, which libwayland uses verbatim
instead of resolving against XDG_RUNTIME_DIR. greeter-ready is the one
file that still has to be shared, so mark it with chmod as the own-labwc
fallback already does. The fallback starts its own labwc, which binds
its socket itself, so the inherited absolute path is unset there.
The installer's last page offers a button labelled "Restart now", but its
handler is only `this.close ()`. atom-install-session ran labwc with -s, so
the compositor outlived the window it was started for: the user pressed
"Restart now" and got a black screen with a cursor, with nothing left to
interact with and no way out short of a hard power cycle.

Make the exit path explicit in the launcher, which is the only place that
knows what should happen next:

  - atom-install drops /run/atom/install-complete. singularity-installer
    exits 0 both when the install finished and when the window was closed
    early, so exit status alone cannot tell the two apart.
  - atom-installer-launch stops exec'ing the installer and acts on its
    exit: reboot on a finished install (what the button promises), return
    on a finished OOBE (greetd moves on to the greeter), otherwise
    relaunch the wizard up to three times.
  - both session scripts run labwc with -S instead of -s, so the
    compositor terminates with the launcher and no clientless compositor
    is ever left on screen.

Verified on a live boot: the "is ready" page stays up until the button is
pressed, then the machine shuts down cleanly (stopping default.target,
sync, rebooting) and comes back into the OOBE on the installed disk.
The cmd/fw-verify guard covers an AtomLoops checkout that has no such
directory, but not one where the directory exists and the build fails
(a mid-refactor HEAD, a dependency it cannot resolve offline). Under
set -e the bare go build then aborts the whole run, after the erofs,
the verity tree and the UKI are already done.

build-initramfs.sh already treats a missing verifier as "no firmware
verifier, base firmware only", so this is a degraded image rather than
a broken build. Warn and carry on.
Buildroot 2026.02.2, which prepare.sh downloads, ships
gsettings-desktop-schemas 45.0, whose org.gnome.desktop.interface has no
accent-color key. That key landed in 47.

singularity-shell writes it unconditionally on startup. main.vala:100
registers an Idle callback that calls update_accent_color(), which reads
dev.sinty.desktop accent-color -- default 'blue', a named colour, so the
"skip wallpaper-derived and custom colours" guard does not apply -- and
then does, at main.vala:883:

    try {
        var iface = new GLib.Settings("org.gnome.desktop.interface");
        iface.set_string("accent-color", color_name);
    } catch (GLib.Error e) {

The catch cannot help. A key absent from the schema is a g_error inside
GIO, not a returned GError, so the process dies rather than raising:

    $ gsettings list-keys org.gnome.desktop.interface | grep -c accent-color
    0
    $ python3 -c 'from gi.repository import Gio
    s = Gio.Settings.new("org.gnome.desktop.interface")
    try:    s.set_string("accent-color", "blue")
    except Exception as e: print("caught", e)'
    GLib-GIO-ERROR **: Settings schema 'org.gnome.desktop.interface' does
    not contain a key named 'accent-color'
    $ echo $?
    134

134 is SIGABRT. singularity-desktop dies on every shell start, the
session supervisor gives up and greetd falls back to the greeter, which
is a login loop.

Written as buildroot-source-patches/0006-*.patch to match the patch set
eec8a89 introduced. Hashes are the upstream sha256sum file for 48.0.
Verified that it applies forward on a pristine 2026.02.2, that a reverse
dry-run is rejected there, and that the reverse dry-run succeeds on an
already-patched tree so prepare.sh reports "already applied" on a rerun.
@DeBondor
DeBondor force-pushed the fix/session-and-packaging-edges branch from 3eb450f to db373a1 Compare July 26, 2026 11:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant