Skip to content

HSCL1 0.1.8-alpha.0

Pre-release
Pre-release

Choose a tag to compare

@timfromhcs timfromhcs released this 12 Nov 21:49
· 12 commits to main since this release

HSCL1 0.1.8-alpha.0

A pre-alpha live/installer image. Not a v1 release: physical hardware, USB boot, Secure Boot
acceptance, TPM unlocking and release signing are not verified.

This release fixes the installer's intermittent startup crash. It was the single defect that had
survived every previous probe, and it is now found, fixed and verified on the built media.

  • ISO: HSCL1-0.1.8-alpha.0-amd64.iso
  • SHA-256: def7f190a061811970f6a053d2dfbe1e2e9e797926c62c2b12a28952fcd8c84d
  • Size: 5 027 201 024 bytes (split into 3 parts, each below 1900 MiB)
  • Built from: commit 91c8acbeff461e733d60452eecd2c608cbd13de0 on main, clean tree, xz
  • Base: Kubuntu 26.04.1 desktop amd64 (Ubuntu resolute), KDE Plasma 6.6 LTS
  • Languages: English, German, French

The installer crash: cause and fix

Since 0.1.4 the installer died at startup in roughly one start in six, with no core dump and an unhelpful
crash dialog. Three earlier readings of its log were wrong; getting a core is what settled it.

The trick was chmod -x /usr/lib/x86_64-linux-gnu/libexec/drkonqi: with no crash reporter to find, KCrash
does what its source says it does and re-raises the signal, so the kernel writes a core. Every core has the
same stack:

QListView::paintEvent
 -> QStyledItemDelegate::initStyleOption
 -> Calamares::ViewManager::data
 -> NotesQmlViewStep::prettyName()
 -> Calamares::Locale::TranslatedString::get(QLocale const&)
 -> SIGSEGV in libcalamares.so.3.3

The crash was in the notesqml step - an HSCL1 addition - while the progress tree painted that step's
name. In the live guest: with the step wired, 2 deaths in 8 starts; with the sequence line removed, 0 in 10.

On this artifact: /etc/calamares/settings.conf contains no notesqml line, and 20 of 20 sequential
installer starts survive with drkonqi disabled and a core pattern set - zero crashes, zero cores. The image
gate now asserts that the step stays disabled, and a unit test stops the hook from silently re-adding it.

The notes page's QML, its German/French translations and its module config stay in the package, so the step
can be re-enabled once upstream makes prettyName() safe. The disk-encryption explanation it carried is still
covered by the handbook and by the installer's own "your /boot is not encrypted" message.

What changed since 0.1.7-alpha.0

  • the installer startup crash (above)
  • scripts/dev/bump_version.py reads the current version from VERSION instead of hardcoding it, so a
    release bump cannot silently skip a file (0.1.6 shipped from a branch that was never merged precisely
    because of a version drift)

Verified on this artifact

  • UEFI boot at 4 GB (QEMU 9.2.0, WHPX): desktop reached, scripts/qa_report.py exits 0 (9 checks ok, one
    info line about Secure Boot). Evidence: artifacts/boot-0.1.8.
  • Image gates: every check passed on the built tree, including installer notes step stays disabled (Q-68).
  • Installer start: 20 of 20 starts survive, no core (artifacts/boot-0.1.8/hscl1-report.txt).
  • Workshop stays inert: workshop_default: disabled in the ISO manifest.

Not verified in this release

  • physical hardware, USB boot and TPM unlocking are not tested
  • the ISO is unsigned: no release signature exists yet
  • Secure Boot acceptance is not demonstrated - the test firmware runs with Secure Boot off, although the
    image carries the signed Canonical/Microsoft boot components
  • no encrypted install was re-run on this exact artifact; the LUKS2 evidence is from the 0.1.4/0.1.5 line
  • the SBOM is CLI-scoped (hscl-cli, 99 packages); there is no ISO package-list SBOM
  • the empty-ESP cause is still unknown; the install is guarded and fails visibly instead (Q-66)

Verify your download

$ gh release download v0.1.8-alpha.0 --repo timfromhcs/HSCL1
$ git clone https://github.com/timfromhcs/HSCL1 ../HSCL1-src
$ bash ../HSCL1-src/scripts/release-join.sh . --verify-only
$ bash ../HSCL1-src/scripts/release-join.sh .

SHA256SUMS is LF-only, so sha256sum -c SHA256SUMS works on Linux; the join script checks the three parts
and the rejoined image.

See docs/KNOWN_LIMITATIONS.md, docs/CLAIMS.md and docs/BUILD_LOG.md for the full, dated evidence.