Show the systemd-boot menu before and after, captured from a VM - #11
Merged
Merged
Conversation
A new check, systemd-boot-menu, boots systemd-boot from an ESP at 4K with the driver in its drivers directory, the deployment path, dumps the framebuffer once the menu has settled, and asserts the glyph height. Its images are the README's: the menu with the stock console, the driver, and the 2x build, as 1:1 crops of one window and as reduced whole frames. OVMF's stock console runs at the resolution its PlatformConfig variable prefers and defaults to a small mode, so each scene first boots the shell, stores 3840x2160 there, and resets; the boot that matters then starts from a 4K stock console. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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.
The README shows the difference now: the systemd-boot menu at
3840x2160 with the stock console, with Big Console, and with the 2x
build, as 1:1 crops of the same 1280x720 window (glyphs at real size)
and as reduced whole frames (how much of the panel each uses).
Where the images come from
A new check,
systemd-boot-menu, boots systemd-boot from an ESP at 4Kwith the driver in
EFI/systemd/drivers/, the way it is deployed,dumps the framebuffer once the menu has settled, and asserts the glyph
height (19 px for the stock console, the cell height for the driver).
Four scenes: stock, driver, driver with
console-mode max, and the 2xdriver. Nothing was loaded from a shell, so this is the first check of
the drop-in path end to end; the existing VM checks load from the
shell.
OVMF's stock console runs at the resolution its
PlatformConfigvariable prefers (what its setup screen writes) and defaults to a small
mode, which would have made the "before" image a low-resolution
console rather than the tiny-text-at-4K case the driver exists for. So
each scene first boots the shell, stores 3840x2160 in that variable
with
setvar, and resets; the second boot then starts from a 4K stockconsole, which is also the flickerless case for the takeover.
The
console-mode maxscene looks the same as the default becausesystemd-boot centers its menu inside whatever grid it has; it stays as
a check of that setting and is not in the README.
The verifier gains
--band(tallest lit-row band) and--bbox(bounding box of what was drawn), used for the assertion and to place
the 1:1 crop window.
🤖 Generated with Claude Code