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.
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.
Add a new series of patches which add measurement support for skylake,
add IOMMU for skylake, fix TPM support, and add support for TPM for
the Librem 13v2 and Librem 15v3 hardware.
If a file $module_$version.series exists, it will be used to
specify a list of patch files to apply to the module.
This is becoming necessary for coreboot which has an increasing
amount of patches required and which makes it hard to maintain
all in one file.
The number of options we want in the menu is starting to get large
enough that it's worth slimming things down in the main menu and move
options to nested menus. Along with this nested menu change is the
option to re-sign and re-hash files in /boot directly from the menu.