Repository navigation
Conversation
This was referenced Oct 2, 2026
…lacks for it: each device with the driver that took it, the firmware the kernel asked for and did not find as lines for firmware.list, the devices and disks that want a line in boot.fragment, and the kernel log, with serial numbers, hardware addresses and UUIDs struck
… one at the first match killed its writer, which pipefail reported as a script no service runs
… gets the report at boot, and kryptik-hwreport --save writes one from its root shell: a temporary file, fsynced, renamed, and the partition unmounted again. No other stick is written, and the installer leaves the reports on the stick
… unprepared stick stays byte for byte what it was, a prepared one gets whole reports on a clean filesystem, a write-protected one is told why it gets none, an install from it carries none over, and the command writes one from the root shell
…ger's mention of the service
DevomB
force-pushed
the
hardware-report
branch
from
October 2, 2026 15:14
0b9505d to
a1f52f1
Compare
…her filesystem under the stick's label, a link at the report's name would carry root's write to a disk of the machine
This was referenced Oct 5, 2026
run-ovmf.sh keeps main's second head and 4Kn disk beside the report's writable stick, and its help prints the whole header again (lines 2-40; main's range stopped two lines short). kryptik-install.sh drops both the report folder and slot b's medium kernel from the copied ESP.
… EDID serial, none of which may reach the report The tool reads an allowlist of DMI fields and a connector's state and modes, never its EDID; the fixture now plants each identifier a real machine has there and denies it in the report, and wants the panel named by connector, state and mode.
…hes, a zone's sched and ioprio calls refused, proxy-calls ending at a proxy's exit
… themselves A USB device's manufacturer and product strings, DMI fields and an interface's name reach the report as their makers wrote them: the kernel filters no control characters from usb_string(), and an interface name may hold an ESC. A stick naming itself with an escape sequence would have it run on the terminal of whoever prints or reads the report. scrub(), which every line passes, now drops C0 controls but tab and newline, DEL, and C1 controls in UTF-8 (U+0080 to U+009F, CSI among them).
…ay scale, exFAT), run-ovmf's --second-head refusal with --s3, proxy-calls traced alone, source mirrors # Conflicts: # build/stages/04-base-system.sh # tools/image/run-ovmf.sh
Stage 06 checks the root's executable files against image-programs.txt both ways, and the report added /usr/sbin/kryptik-hwreport and the medium's /usr/libexec/kryptik/hw-report.sh without naming them, so a build of this branch stopped at its rootfs step.
…nds the laptop sound note sorts The report listed every PCI device, so the audio controller's class was there, but not what tells one kind of laptop sound from another: whether the firmware describes digital microphones for Intel's DSP, SoundWire parts, speaker amplifiers, or microphones on AMD's coprocessor. The October machines' reports are meant to answer that. A new `audio` section: each audio controller on PCI with its class and the driver that took it, AMD's coprocessor among them; the HD Audio codecs by maker and subsystem; the NHLT table's endpoints by link type (pdm, ssp); the SoundWire controller ACPI describes at _ADR 0x40000000 under an HD Audio controller, as the kernel finds it, and each part on it by link, maker and part; the speaker amplifiers ACPI names (Cirrus's CSC3551/4/6/7 and CLSA0100/1, TI's TIAS2781, TXNW2770/2781/5825 and INT8866) with any driver bound to them; and which of AcpDmicConnected, acp-audio-device-type and _WOV the ACPI tables hold, the names AMD's drivers look for. Model and part IDs only. tools/tests/hwreport.sh builds each kind on the fixture machine: HD Audio alone, a DSP with an NHLT of a microphone array and an I2S link, a SoundWire controller with two parts beside an ACPI node that is not one, AMD's coprocessor with AcpDmicConnected in its DSDT, and two CS35L41s described as one device beside one the firmware calls absent.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For the hardware tests planned for October 2026: a report of what a machine is made of and what the image lacks for it, taken by booting the USB medium.
To ask for a report: make a folder named
kryptik-reporton the stick's first partition from any computer, boot the stick on the machine, wait a minute and switch off; or, at the medium's root shell, runkryptik-hwreport --save. The report iskryptik-report/report-N.txton that partition.What it holds: the machine's maker and model, the firmware's Secure Boot state, the processor with its microcode revision and mitigations, every PCI and USB device with the driver that took it (named from hwdata), the devices nothing drives with their modalias, the disks with the drivers under them, DRM, network, wireless and input devices, the loaded modules, the sound hardware, and the kernel log. A
missingsection draws the conclusions: the firmware files the kernel asked for and did not find, as lines forbuild/config/firmware.list; the storage, network, display, USB host and radio devices with no driver, each wanting its driver's line inbuild/config/kernel/boot.fragment; and the disks behind a driver that is a module, which must be built in before a root can sit there (ADR-013). No serial number, hardware address or UUID is read, and the log's own are struck.The sound, by kind. The
audiosection names each audio controller on PCI with its class and the driver that took it, AMD's coprocessor among them; the HD Audio codecs; the NHLT table's endpoints by link type; the SoundWire parts ACPI describes under an HD Audio controller, by link, maker and part, found at _ADR 0x40000000 as the kernel finds it; the speaker amplifiers ACPI names, with any driver bound to them; and which ofAcpDmicConnected,acp-audio-device-typeand_WOVthe ACPI tables hold. Those tell apart the kinds of laptop sound docs/design/laptop-audio.md (#532) sorts, which 1.0 does not drive, so each October report says which a machine is. Model and part IDs only.How it is kept safe:
hw-report, a oneshot, mounts the USB medium's first partition read-only, looks for the directory and unmounts; without it nothing is written, and an ISO or an installed system is never looked at.kryptik-hwreportwithout--saveprints to stdout on any system.kryptik-installcopies the medium's first partition whole, so it removeskryptik-reportfrom the copy. The unattended installer waits forhw-report, so the two never hold the partition at once.Tests:
tools/tests/hwreport.shruns the tool on a made-up machine, the struck identifiers among its checks, and then on one of each kind of sound: HD Audio alone, a DSP with an NHLT naming a microphone array, SoundWire parts beside an ACPI node that is not their controller, AMD's coprocessor withAcpDmicConnected, and CS35L41 amplifiers beside one the firmware calls absent.tools/image/hwreport-test.sh, a newbootitem of acceptance, boots copies of the medium under OVMF: an unprepared stick booted writable stays byte for byte what it was; a prepared one getsreport-1.txtand thenreport-2.txt, with the filesystem clean and the signed boot file unchanged; the same stick write-protected gets none and says why; an install from it leaves no report on the installed disk; and the command writes one from the root shell.run-ovmf.shgains--usb-writablefor those copies; every other boot keeps the stick write-protected.Also here:
tools/tests/services.shlooked for a sourced script through a pipeline it left at the first match, which pipefail reports as a failure once the writer is killed; a third script sourcingask.shmade that likely.Not in this change: the user guide and the README, which other open changes hold. Not to be merged before v1.0.0 is tagged.