The rejection inside the new PID namespace ran without privileged mode, so
it never reached the caller lookup, and nothing would have caught a check
that accepted -p anywhere in the arguments.
The check read /proc/$$/cmdline. arch-chroot runs its command in a new PID
namespace beneath the outer /proc, where $$ names no process or someone
else's, so every bash -p entrypoint was rejected there with status 126.
The installer met this as soon as one was called at install time:
install/config/thunderbolt-authorization.sh runs
omarchy-thunderbolt-authorization-admin, and the edge ISO stopped in
"Configuring system" with "/proc/219/cmdline: No such file or directory".
The check runs in a child of the caller, so read the parent from that
child's /proc/self/stat, which is given in the numbering of the /proc it is
read through. Outside a PID namespace that is $$, as before.
Naming a unit's source in default/ counted as installing it, so a command
that never copied the unit, or copied it after enabling it, passed. Look
for the install or cp of that source ahead of the enable instead.
The first-run test accepted any script that tried three of the units. It
now requires one enable --now per unit and, with each unit unknown in
turn, exactly the calls of a clean run minus that unit.
The Thunderbolt approval watcher is enabled by its setup command, a
migration and first-run, but no package put it in a user unit folder and
nothing installed it. On edge the migration failed with "Unit
omarchy-thunderbolt-authorization.service does not exist", so every later
migration stayed pending. First-run failed too, and enabled none of its
units: given a list, systemctl enables nothing when one unit is unknown.
The units are now shipped by the settings packages (omarchy-pkgs#922).
Here, first-run enables its units one at a time, so a unit missing from a
build costs only that unit, and config-test fails when a unit under
default/systemd/user is enabled without being shipped or installed first.
The migration read ESP_PATH from /etc/default/limine at its top. On a
machine without that file sed fails, and under bash -euo pipefail the
migration stopped there with an error, before the check that lets a
machine without Limine skip it.
The read moves to after the rebuild, the one place the path is used; a
path given for the tests is taken first, and a missing file means /boot.
limine-mkinitcpio carries on past a kernel it could not build, with a
full boot partition for one, and still exits 0. The migration then wrote
its marker over an unchanged boot image, and no later update would try
again.
After the rebuild it now looks at the boot menu: if the menu has command
lines and none carries the parameter, the migration fails and stays
pending. A menu with no command lines in it, where they are inside the
boot images, cannot be checked this way and is accepted as before.
The test ran the migration with plain bash. omarchy-migrate runs it with
bash -euo pipefail, and the migration depends on that: it is what stops
a failed limine-mkinitcpio before the marker is written, so the next
update tries again. The stand-in rebuild could not fail, so nothing held
that promise.
The test now uses the same options and adds the case: a rebuild that
fails ends the migration with an error and leaves no marker, and the
next run rebuilds and marks it.
About 1 boot in 10 of an installed system stops on a black screen at
"Starting Switch Root" until a key is pressed. systemd 257 and later
asks the console for its size with ANSI escape sequences when PID 1
starts and waits for the reply; with Plymouth holding the VT the reply
sometimes never comes.
Measured in QEMU on repeated boots of one install: 3 hangs in 30 and 1
in 40 on the prebuilt UKI, 7 in 40 on the stock initramfs, every one of
them ended by pressing Enter; none in 40 with a serial console, none in
40 with plymouth.enable=0, and none in 80 with
systemd.tty.term.console=dumb, which makes systemd skip the query.
systemd fixed two variants of this in v261; Arch's 261.2 still shows it.
The parameter goes where the last Plymouth boot fix went (3f725531,
initramfs_async=0): into the packaged omarchy-defaults.conf for fresh
installs, and a migration rebuilds the boot image on existing systems,
once per machine, only where the booted command line lacks it. Nothing
visible changes under "quiet splash".
Refs #2931
The existing test runs mise-work.sh in the runtime context, which skips
the bundled tarball altogether. This offers both tarballs to an x86_64
and an aarch64 machine and checks that each unpacks its own and hands
Mise that version, and that a machine with only the other architecture's
tarball fails. Against the old script the aarch64 case fails.
An aarch64 ISO bundles node-v*-linux-arm64.tar.gz, and mise-work.sh
looked for node-v*-linux-x64.tar.gz on every machine. An offline install
on aarch64 stopped at its last step: "Error: bundled Node.js tarball
missing from /opt/packages".
The name now follows uname -m. x86_64 looks for the same file as before.
This is the change the n1x branch already carries, from Spencer Bull's
6d022e36.
Emir Beganović