No fallback kernel

Breadway commented

2026-09-26 07:28:13 +08:00

Owner

Problem

Only linux ships. A bad kernel update can only be recovered through snapshots (see BOS-26).

Fix

Add linux-lts to the installed package set (not needed on the live ISO), and make sure bos-copy-kernel, the mkinitcpio presets and grub-mkconfig pick it up. Bear in mind this interacts with BOS-32 (NVIDIA DKMS) and BOS-24 (sign the LTS kernel too).

Acceptance

The GRUB menu shows an LTS entry, and it boots.

Source: BOS v0.6.2 source review (tag dated 2026-09-19). Read AGENTS.md first. One issue per branch/PR, match existing style. Verify with FAST_BUILD=1 sudo ./build-local.sh plus a VM install. Add a CHANGELOG [Unreleased] entry.

## Problem Only `linux` ships. A bad kernel update can only be recovered through snapshots (see BOS-26). ## Fix Add `linux-lts` to the installed package set (not needed on the live ISO), and make sure `bos-copy-kernel`, the mkinitcpio presets and grub-mkconfig pick it up. Bear in mind this interacts with BOS-32 (NVIDIA DKMS) and BOS-24 (sign the LTS kernel too). ## Acceptance The GRUB menu shows an LTS entry, and it boots. --- Source: BOS v0.6.2 source review (tag dated 2026-09-19). Read AGENTS.md first. One issue per branch/PR, match existing style. Verify with `FAST_BUILD=1 sudo ./build-local.sh` plus a VM install. Add a CHANGELOG `[Unreleased]` entry.

Breadway added the

recovery

P2

packages

labels

2026-09-26 07:28:13 +08:00

Breadway commented

2026-09-30 03:46:47 +08:00

Author

Owner

Investigation found an installer design blocker before implementation. iso/packages.x86_64 is also the live ISO package set, so adding linux-lts there installs it on the live medium, contrary to this issue. The only target-side package step is Calamares packages, which is configured to skip when offline. Adding linux-lts there would leave offline installs without the fallback. That step also currently runs after post-install.sh has rebuilt mkinitcpio presets and grub.cfg, so the install flow must be reordered or the target finalization must run after the LTS package is installed.

There are two related acceptance dependencies: BOS-24's Secure Boot work currently signs /boot/vmlinuz-linux and still lacks fresh-VM acceptance, and BOS-32 will need to account for the additional kernel when choosing an NVIDIA driver. A fallback that only works with Secure Boot disabled or before the NVIDIA setup path is exercised would not satisfy the intended recovery behavior across supported installs.

Please decide how BOS installs should obtain target-only packages during offline installs: should the ISO carry an installer-only linux-lts package/cache, or should installing BOS require internet for this package? Once decided, the implementation can place the LTS kernel installation before initramfs/GRUB generation and coordinate its signing and NVIDIA handling. I left BOS-33 in TODO pending that decision and the VM acceptance path.

Investigation found an installer design blocker before implementation. `iso/packages.x86_64` is also the live ISO package set, so adding `linux-lts` there installs it on the live medium, contrary to this issue. The only target-side package step is Calamares `packages`, which is configured to skip when offline. Adding `linux-lts` there would leave offline installs without the fallback. That step also currently runs after `post-install.sh` has rebuilt mkinitcpio presets and grub.cfg, so the install flow must be reordered or the target finalization must run after the LTS package is installed. There are two related acceptance dependencies: BOS-24's Secure Boot work currently signs `/boot/vmlinuz-linux` and still lacks fresh-VM acceptance, and BOS-32 will need to account for the additional kernel when choosing an NVIDIA driver. A fallback that only works with Secure Boot disabled or before the NVIDIA setup path is exercised would not satisfy the intended recovery behavior across supported installs. Please decide how BOS installs should obtain target-only packages during offline installs: should the ISO carry an installer-only linux-lts package/cache, or should installing BOS require internet for this package? Once decided, the implementation can place the LTS kernel installation before initramfs/GRUB generation and coordinate its signing and NVIDIA handling. I left BOS-33 in TODO pending that decision and the VM acceptance path.

Breadway referenced this issue from a pull request that will close it,

2026-09-30 04:25:47 +08:00

No fallback kernel #66

Breadway commented

2026-09-30 04:26:01 +08:00

Author

Owner

PR: #66

Implemented the installer-only signed LTS package cache, target installation before initramfs and GRUB generation, and post-finalizer sbctl tracking for the LTS image. The fast ISO build succeeded. An offline extracted-root simulation installed linux-lts, generated its initramfs, and produced LTS GRUB entries. QEMU booted the LTS kernel and initramfs to the BOS tty login prompt.

A full Calamares GUI VM installation was not completed because desktop control could not connect to Hyprland (hyprctl clients -j failed). I am leaving BOS-33 in DOING until that installed-VM path is checked. BOS-24 PR #54 is still open; the added signing step runs after its finalizer. BOS-32 follow-up needs DKMS and headers for both installed kernels.

PR: https://git.breadway.dev/Breadway/bos/pulls/66 Implemented the installer-only signed LTS package cache, target installation before initramfs and GRUB generation, and post-finalizer sbctl tracking for the LTS image. The fast ISO build succeeded. An offline extracted-root simulation installed linux-lts, generated its initramfs, and produced LTS GRUB entries. QEMU booted the LTS kernel and initramfs to the BOS tty login prompt. A full Calamares GUI VM installation was not completed because desktop control could not connect to Hyprland (`hyprctl clients -j` failed). I am leaving BOS-33 in DOING until that installed-VM path is checked. BOS-24 PR #54 is still open; the added signing step runs after its finalizer. BOS-32 follow-up needs DKMS and headers for both installed kernels.

Breadway commented

2026-09-30 10:29:15 +08:00

Author

Owner

PR #66 contains the installer-only linux-lts cache. The implementer verified staged offline install, LTS GRUB entries, and QEMU boot to a tty, but the independent review agent hit its usage limit before reviewing. No CI statuses are configured. Moving to TODO until independent review can run and the VM-install acceptance gap is resolved.

Breadway commented

2026-09-30 10:58:42 +08:00

Author

Owner

Review of PR #66 found no code defect in the installer-only cache flow, but the stated boot acceptance is not yet demonstrated end to end.

Acceptance mapping:

Offline installs install the cached LTS package before initramfs and GRUB generation: customize_airootfs.sh:29-45 stages the signed package; bos-copy-kernel:67-84 installs it; settings.conf:41-59 orders that before initcpio and post-install GRUB generation. The recorded offline simulation covers this path.
The GRUB menu shows an LTS entry: post-install.sh:177-221 regenerates GRUB after both kernels are installed, and the recorded test confirms LTS entries in grub.cfg. The test did not exercise the installed GRUB menu.
The LTS kernel boots: the recorded QEMU test booted the kernel and initramfs directly to a tty. That does not verify selecting the LTS entry from the installed GRUB menu or the end-to-end Calamares install path.

Please verify an installed system in a headless nested VM: install from the ISO, confirm the GRUB menu includes the LTS entry, select it, and reach the tty login. No live desktop session is needed. Keep rework on the existing branch feature/bos-33-fallback-kernel and PR #66 open; do not open a second PR. No CI statuses are configured.

Review of PR #66 found no code defect in the installer-only cache flow, but the stated boot acceptance is not yet demonstrated end to end. Acceptance mapping: 1. Offline installs install the cached LTS package before initramfs and GRUB generation: `customize_airootfs.sh:29-45` stages the signed package; `bos-copy-kernel:67-84` installs it; `settings.conf:41-59` orders that before initcpio and post-install GRUB generation. The recorded offline simulation covers this path. 2. The GRUB menu shows an LTS entry: `post-install.sh:177-221` regenerates GRUB after both kernels are installed, and the recorded test confirms LTS entries in grub.cfg. The test did not exercise the installed GRUB menu. 3. The LTS kernel boots: the recorded QEMU test booted the kernel and initramfs directly to a tty. That does not verify selecting the LTS entry from the installed GRUB menu or the end-to-end Calamares install path. Please verify an installed system in a headless nested VM: install from the ISO, confirm the GRUB menu includes the LTS entry, select it, and reach the tty login. No live desktop session is needed. Keep rework on the existing branch `feature/bos-33-fallback-kernel` and PR #66 open; do not open a second PR. No CI statuses are configured.

Breadway commented

2026-10-01 15:56:56 +08:00

Author

Owner

Updated the existing PR #66 branch with current origin/main (5ae8040) and ran shell syntax plus static package/module-order checks successfully. BOS has no ordinary-push CI configured. The installer acceptance remains incomplete: the existing headless guest reached Calamares Users, but no install completed and the installed GRUB menu was not checked. Root has directed that no further guest input or VM be started, so the required install, GRUB LTS selection, and LTS boot evidence cannot be collected in this run. Leaving this issue in TODO pending that acceptance. Existing guest and scratch artifacts are preserved.

Updated the existing PR #66 branch with current `origin/main` (5ae8040) and ran shell syntax plus static package/module-order checks successfully. BOS has no ordinary-push CI configured. The installer acceptance remains incomplete: the existing headless guest reached Calamares Users, but no install completed and the installed GRUB menu was not checked. Root has directed that no further guest input or VM be started, so the required install, GRUB LTS selection, and LTS boot evidence cannot be collected in this run. Leaving this issue in TODO pending that acceptance. Existing guest and scratch artifacts are preserved.

Breadway commented

2026-10-01 16:26:42 +08:00

Author

Owner

PR #66 has the implementation and offline package/initramfs/GRUB checks recorded on the rebased head. The full Calamares install and selecting the LTS entry from installed GRUB remain outstanding; BOS has no ordinary push CI. Moving the implementation to REVIEW for the requested handoff. Do not treat as verified or done until those acceptance checks are recorded.

Breadway closed this issue

2026-10-02 14:32:14 +08:00

Rows
Columns

No fallback kernel #33

Problem

Fix

Acceptance