Since fbwhiptail allows us to customize the background colors, we should
colorize warnings and error messages to provide a user with an
additional subtle cue that there might be a problem. I have added two
additional configuration options:
CONFIG_WARNING_BG_COLOR
CONFIG_ERROR_BG_COLOR
and in the librem13v2.config file you can see an example for how to set
them to be yellow and red gradients, respectively. I've also updated the
main two scripts that use whiptail to include those background colors.
If you decide to use regular whiptail, just don't set these config
options and it should behave as expected.
When a user gets confirmation of their boot menu choice, that's largely
to give them the option of making their boot choice the default. In the
case of "force mode" there's no reason for the user to be presented with
that dialog so this change skips right ahead to the boot once they have
In the event a user does pick the insecure "force" boot option that
bypasses checksum and signing checks in Heads, it would be nice to
provide a clear visual warning during the boot process that they are in
this state. This change will add a kernel argument that changes the boot
console background to be red and removes any boot splash that might
obscure it, in the event the user picks the insecure boot mode.
Since a user should only boot into this mode during emergencies, having
it be apparent that it's an unsafe mode helps ensure the user doesn't
pick this boot option needlessly.
Currently when the boot entries change, kexec-select-boot dies. Given
the normal loop is set up to catch this event and display a regular boot
menu at the next iteration of the loop, instead of dying it would be
better to just warn and then return from that function back into the
main loop. In addition to that I added a GUI menu for the same warning
when in GUI mode.
Fixes access to the EC through the Index I/O interface
Fixes AC and DC LoadLine values to avoid overheating problems
Fix Turbo mode value from EC
Change version name to have '-heads' suffix
By enabling Pass-through iommu, it fixes the GPU glitching issues
we've had with IOMMU, and it also allows us to boot a target kernel
without having to give it intel_iommu=igfx_off as argument.
Part of the Heads workflow involves handling legitimate changes to /boot
as part of the package manager. This is a challenging workflow to handle
as package managers on many systems work in a completely unattended way
(and some even reboot first, apply updates, and then reboot again).
We need to be able to detect changes that are potentially caused by a
package manager so to do that I've set up a trigger within the OS
(currently just for Debian) that runs both before and after package
updates. It verifies the signatures in /boot and if they fail before
package updates it creates a log file in
/boot/kexec_package_trigger_pre.txt. If they fail after package updates
run /boot/kexec_package_trigger_post.txt is created. These files contain
the following fields:
CHANGED_FILES: A list of files in /boot that failed the sha256sum check
UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to
trigger initramfs changes
Following those fields is a list of log output from the last package
manager run which contains its own formatted fields (I'm pulling from
/var/lib/dpkg/info).
When a user selects a boot option, gui-init first verifies the
checksums just to catch errors before calling kexec-select-boot. If
there are any errors it looks for these package logs and if they exist,
it displays appropriate warnings. If the files are absent it displays a
more generic warning. The user is also given an opportunity to re-sign
the /boot hashes.
