Full graphical user interface experience, no console log

[wessel-novacustom]

During boot and certain actions, Heads falls back to the console mode. For most users, this can look very technical and scary.

• Proposed solution: Heads loading overlay covering the full screen. Same for user inputs, etc.
• • I think this should be a setting, so that more technical users can still use the Console log view mode.

[tlaurion]

Some technical, current limitations of Heads

• Heads uses whiptail(console)/fbwhiptail(high resolution framebuffer) as a front-end to bash scripts for user interactions/menu drawn on the screen (console).
• Heads wraps around (uses, maybe too directly) many standard Linux tools (see modules/*) and delegates to those tools input output. Some more wrapping could be added (Heads doing gpg passphrase prompts and calling gpg with cached passphrase, cryptsetup and then some: hotp-verification, qrencode, etc)
• whiptail/fbwhiptail does not provide, in current used built configuration, input management from GUI(free text input, multiple selection from list, direct drawing of pictures etc), which is historically why we use console driven input/output to do this on console. But I see why this might fright non-technical users.

I asked, off channel what is the desired implementation that would close this issue.

Some specifics, still needing more practical answers:

• when /boot is changed from OS/tampering: Heads shows whiptail list of files added/removed/modified when <10 entries, or if >10 outputs to file and use vi to show list of files and guides user to quit vi after having taken note of what changed prior of signing actual changes on /boot content . What that would look like without console?
• Heads currently leaves gpg deal with input directly: ie, GPG pin when signature is to be applied. What would that look like?
• Heads currently outputs to console qrencode output for TPMTOTP Qr code for user to scan. Desire would be to output that as well in fbwhiptail to be drawn in "full screen overlay"?
• Heads currently calls hotp-verification and leaves this binary deal with user for needed interactions : the app asks user to touch HOTP security dongle if it blinks, asks for secure element passphrase (now different/same then GPG Admin PIN) : how would that look like?

I probably miss some.

---

My take on this was simpler #1822: so that on default boot codepath (90% of time UX) we hide console output (TPM extend operations for config.user, gpg keyring trustdb, loaded per board config kernel drivers (usb controller, USB keyboard), then hide "good" state information (/boot good detached signature, luks header measurement) up to default automatic boot asking user to type TPM Disk Unlock Key passphrase since everything prior is in expected state, and then hide chipset locking (PR0) and secret.cpio override up to showing "kexec into main OS".

But hiding all console would be something totally different and harder as a goal.

Maybe @JonathonHall-Purism see this easier to do then I do? How would the path leading to this look like?

[wessel-novacustom]

This issue is not a hard requirement, it's just an expression of our preference to have as much as fairly possible in a graphical environment.

Sure, /boot changes can still be in tty. But I thought maybe it's possible to have more things shown in a graphical environment instead of tty/console.

The flow as described in #1822 would be absolutely fine, too. Key point is to hide technical logs for end users. I'm therefore closing this issue.