I run Debian 9 with secure boot enabled, with self-signed keys. It can certainly protect against trivial Evil Maid-type attacks like plugging in a bootable USB drive to grab data from your system or to install malware to non-encrypted partitions. But that's hardly the limit of what an Evil Maid could do: if you're serious about this, you should also think about the physical security of the system chassis.
For "retroactive" integrity checks, you would need a TPM chip and a bootloader that will utilize its PCR registers. Those registers cannot just be set to any value: when new data is fed to those registers, the TPM chip itself will calculate a hash of the old value of the register + the data input, and assign that as the new value of the register. The system firmware will populate the first few PCR registers with the hashes of the firmware itself, the current firmware settings, and the first piece of boot code that was actually used. After that point, the control will be transferred to that boot code.
If you used a bootloader that similarly records the hashes of the kernel and initramfs files actually loaded into the PCR registers, you could then verify the PCR values against a set of "known good" values stored in the encrypted part of the disk, and display a warning if the current values won't match the known-good state. The kernel also has the CONFIG_IMA option which, when activated, makes the kernel use one PCR register of the TPM to maintain a hash of hashes of everything it has loaded. (A hash of hashes, because a TPM is not especially fast: sending a full copy of all loaded data to TPM for hashing would massively slow down the boot process.)
Of course, you would then have to update the known-good values each time you update any part of the system that gets hashed into the PCRs, or you'll get a false alarm. When installing a system update (e.g. a kernel with a security patch) it can be hard to predict in advance what the new "good" PCR values will be, so yo may have to install the update, accept that the next boot will trigger the alarm, and then record the new "good" state.
A few years ago, when I experimented with the TPM PCRs, it was with a system with a legacy BIOS firmware. With TrustedGRUB (basically a TPM-enabled version of GRUB Legacy) I was able to implement the kind of checking I outlined in the previous paragraph. I'm not sure if there is a Linux UEFI bootloader with TPM support available yet, so you might not get complete PCR coverage of the early system, unless you boot using only the kernel's built-in UEFI stub loader (so the firmware will end up recording the hash of the actual kernel instead of just the bootloader).