Merge pull request #3 from theupriser/fix/steamify-install-var-log

fix: Steamify's install-time logs are readable after the first boot
This commit is contained in:
theupriser authored and GitHub committed 2026-09-29 19:08:54 +02:00
commit f71ef695db
2 files changed
+11

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 `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 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` 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 * **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 `%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 * **Build:** finishes cleanly as root and reports no error after a successful build; the Steamify page's
@@ -20,6 +20,14 @@ for id in ${choice//,/ }; do
*) options+="${options:+,}$id" ;; *) options+="${options:+,}$id" ;;
esac esac
done 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 and leave it mounted: the caller reads the log afterwards, and unmounts
# all of $root at the end anyway (Calamares' umount step, the test's poweroff).
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)
[[ -n "${dev:-}" ]] && mount -o "$opts" "$dev" "$root/var/log" 2>/dev/null
fi
# systemd-boot: cachyos-installer runs `bootctl install` in a chroot, and bootctl leaves the EFI # 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 # 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 # its other entries first and finds the disk's fallback path last (or never). bootctl can't be made