Skip to content

Kicksecure ISO live amnesic (USER Session) boot fails on novacustom-v540tu; works on x230 and nv4x_adl #2188

Description

@tlaurion

Before filing a bug report

Follow-up to #2008 and #2186. #2186 merged in master.

Hardware details

  • Board: novacustom-v540tu (failing). Working: x230 (EOL_x230-maximized), novacustom-nv4x_adl.
  • GPU: iGPU-only (Intel Meteor Lake, device ID 7d55).
  • Heads/Dasharo: Dasharo Heads-v0.2.1-3144-g7850f7a (DMI BIOS string), vendor-installed by Novacustom.
  • ROM: vendor (Dasharo) image, maximized.

Please describe the problem

Describe the bug

#2186 ("initrd: boot dd-written hybrid ISOs in mount-usb and usb-autoboot") fixes #2008 ("kicksecure iso doesn't boot under Heads") on x230 and novacustom-nv4x_adl. On novacustom-v540tu the Kicksecure ISO fails to boot only in live-amnesic mode ("LIVE Mode | USER Session | disposable use"): the machine auto-reboots before/at the LXQt desktop.

The failure is specific to the live-amnesic USER session. Non-live-amnesic modes boot fine on the same machine: "LIVE Mode | SYSMAINT Session" (sysmode) boots to console, and the other grub entries are unaffected.

To Reproduce

  1. Boot the Kicksecure 18 live ISO on novacustom-v540tu via Heads (dd-written hybrid ISO path from initrd: boot dd-written hybrid ISOs in mount-usb and usb-autoboot #2186).
  2. Select "LIVE Mode | USER Session | disposable use".
  3. The machine auto-reboots before the desktop.
  4. Select "LIVE Mode | SYSMAINT Session" instead: boots to console fine. Both entries work on x230 and novacustom-nv4x_adl.

Expected behavior

Live amnesic USER session boots to the LXQt desktop with autologin, as on x230 and nv4x_adl.

Additional context

Full sysmode capture (the mode that was successfully logged, since live-amnesic reboots before a capture is possible): https://gist.github.com/tlaurion/f9d3070cd0126a190fe52eec8732c302 (kicksecure_sysmode_v540tu.log).

The two modes pass an identical kernel cmdline except the session target (graphical.target + autologin vs systemd.unit=sysmaint-boot.target + noautologin), so the failure is at graphical/display bring-up, not the overlay. The v540tu is the only machine whose i915 driver does not initialize cleanly. Relevant lines from the gist above:

  • L1926: i915 0000:00:02.0: [drm] Found METEORLAKE (device ID 7d55) display version 14.00
  • L2360: i915 0000:00:02.0: [drm] [ENCODER:249:DDI B/PHY B] failed to retrieve link info, disabling eDP
  • L2393-L2437: panel power-sequencing WARN + Call Trace:
    • L2394: i915 0000:00:02.0: [drm] drm_WARN_ON(intel_dp->pps.vdd_wakeref)
    • L2395: WARNING: CPU: 8 PID: 1012 at drivers/gpu/drm/i915/display/intel_pps.c:755 intel_pps_vdd_on_unlocked+0x32b/0x340 [i915]
    • L2402: RIP: 0010:intel_pps_vdd_on_unlocked+0x32b/0x340 [i915]
    • L2414: Call Trace: ... drm_dp_dpcd_probe / intel_dp_detect / intel_dp_set_edid
  • L3565: i915 0000:00:02.0: [drm] *ERROR* GT1: GSC proxy component didn't bind within the expected timeout
  • L3566: i915 0000:00:02.0: [drm] *ERROR* GT1: GSC proxy handler failed to init

x230 and nv4x_adl show clean i915 init (zero kernel WARNINGs).

Also noted: the v540tu final ISO cmdline retains intel_iommu=on while x230/nv4x_adl strip it, traced to a per-machine config.user override (config-gui "Debug/Output" menu) rather than a board-config difference. Unlikely the cause (no DMAR faults on v540tu), but worth checking.

This looks like an upstream i915/Meteor Lake display issue surfaced by the graphical autologin session. Next steps: reproduce in plain Debian trixie, and capture a live-amnesic boot over the Heads serial console to confirm the failure at graphical.target.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions