I don’t have my Librem Key with me right now, but when I booted this morning I got a message that changes had been made to certain files. I had just done updates last night, so I’m guessing that’s why. Anyhow, I proceeded for now to boot despite the issues. My question where do I find these errors in my logs?
1 Like
As I remember from something that wrote @Kyle_Rankin about heads the logfile about changes is planned, but not implemented.
But you could look at your /boot to find out. If you look there you’ll find a file containing a list of files in /boot and the corresponding sha256 checksums. That’s the file that is signed by your secret key stored in your LibremKey and then evaluated at every boot against the public key you stored in heads.
Using sha256sum on the command line you could generate the same checksums for the actual files in your /boot and compare them to the stored checksums. By doing so you’ll find out which files changed.
Edit: Here’s a command line that writes a list of checksums like in /boot/kexec_hashes.txt to the file hashes in your actual directory. Don’t overwrite something you might still need.
user@system:~/tmp$ for F in `find /boot -type f -not -iname kexec*`; do sha256sum $F; done | perl -pe's/(\s)\/boot/$1./' > hashes
find: ‘/boot/lost+found’: Keine Berechtigung
To compare the two files you could use:
user@system:~/tmp$ diff /boot/kexec_hashes.txt hashes
333c333
< d4e3450f29f6c173ca6910b92232a9f1e18ee6e19c70d403f1e7c7fce574db76 ./disk_fillup_for_heads_check
---
> d4e3450f29f6c173ca6010b92232a9f1e18ee6e19c70d403f1e7c7fce574db76 ./disk_fillup_for_heads_check
You can see that in my case the file disk_fillup_for_heads_check changed.
2 Likes
BTW, @Kyle_Rankin, wouldn’t it be a quiet easy intermediate solution to keep the old /boot/kexec_hashes.txt and /boot/kexec.sig for further reference? On my disk there’s already a /boot/kexec_default.1.txt that is older than /boot/kexec_default_hashes.txt and might a copy of an older version. Would be nice to have the option to look back what changed when (include a file date in sig?).
Those errors aren’t logged, as the idea is to present you with the warning that something changed at boot. If you decide to boot anyway (unless you pick the failsafe boot mode) you will be prompted to re-sign all the files in /boot, which means you trust the changes.
As you said, this appeared just after you had done updates, which makes sense–your updates probably updated either the kernel or triggered a change in the corresponding initrd file.