fix: steamify-install mounts the new system's /var/log (@log) first, so its logs aren't hidden under the mount after boot

This commit is contained in:
theupriser committed 2026-09-29 18:13:00 +02:00
1 parent ca74e10eee
commit faa57cdb7f
2 files changed
+14

No files matched your search

+3
View File
@@ -56,6 +56,9 @@ CachyOS 26.08 with Steamify built in: install CachyOS and turn the PC into a Ste
`steamify-install` now registers it with `efibootmgr` from the live system, with the ESP's real
disk and partition (bootctl in the chroot writes an entry without a partition, which the firmware
can't load); the output is in `/var/log/steamify-bootentry.log`
* **Installer:** Steamify's install-time logs (`/var/log/steamify-install.log`,
`steamify-bootentry.log`) are readable after the first boot: `/var/log` is its own btrfs subvolume
(`@log`) that wasn't mounted yet when Steamify ran, so they ended up hidden under it
* **Installer:** Steamify's setup never asks for a password (its sudo rule is read after CachyOS's
`%wheel` rule); Calamares starts with the Boost version it was linked against
* **Build:** finishes cleanly as root and reports no error after a successful build; the Steamify page's
@@ -20,6 +20,17 @@ for id in ${choice//,/ }; do
*) options+="${options:+,}$id" ;;
esac
done
# /var/log is its own btrfs subvolume (@log) that the installer doesn't mount at $root/var/log: what is
# written there now (these logs, Steamify's) would end up hidden under the mount after boot. Mount it
# from the new system's fstab for this run.
mounted_log=false
if [[ -n "$root" && -d "$root/var/log" ]] && ! mountpoint -q "$root/var/log"; then
read -r dev _ _ opts _ < <(awk '$2 == "/var/log" && $1 !~ /^#/' "$root/etc/fstab" 2>/dev/null)
if [[ -n "${dev:-}" ]] && mount -o "$opts" "$dev" "$root/var/log" 2>/dev/null; then
mounted_log=true
trap '$mounted_log && umount "$root/var/log"' EXIT
fi
fi
# systemd-boot: cachyos-installer runs `bootctl install` in a chroot, and bootctl leaves the EFI
# variables alone there: no "Linux Boot Manager" boot entry, so the firmware tries the network and
# its other entries first and finds the disk's fallback path last (or never). bootctl can't be made