Package Details: chkboot 1.3-1

Git Clone URL: https://aur.archlinux.org/chkboot.git (read-only, click to copy)
Package Base: chkboot
Description: Create hashes of all files under /boot and warns the user if they are modified
Upstream URL: https://github.com/grazzolini/chkboot
Keywords: boot check security
Licenses: GPL
Submitter: None
Maintainer: grazzolini
Last Packager: grazzolini
Votes: 18
Popularity: 0.30
First Submitted: 2012-02-23 08:55 (UTC)
Last Updated: 2019-04-16 21:41 (UTC)

Dependencies (4)

Required by (0)

Sources (1)

Latest Comments

1 2 Next › Last »

wolfk commented on 2025-09-17 14:16 (UTC)

@grazzolini IMO the chkboot hook for mkinicpio is wrong: This is being run before the last step of mkinitcpio: Creating zstd-compressed initcpio image: '/boot/initramfs-linux-fallback.img' which is why chkboot is always complaining about this file upon reboot after a new kernel has been deployed on my system Instead of using the mkinitcpio install hook in /usr/lib/initcpio/install/chkboot a mkinitcpio post script in /usr/lib/initcpio/post should be used, then the fallback image will be included in the last /var/lib/chkboot/BOOTFILES-* file

grazzolini commented on 2019-11-01 14:27 (UTC)

@pancakes,

It looks like systemd started updating this random-seed filed recently, hence why it started triggering chkboot. I personally mount the ESP to /boot/efi, so I get chkboot check for free on my efistub.

But, since I don't use systemd-boot, I don't have this issue. I really suggest you don't mount your ESP under /boot or use another bootloader.

pancakes commented on 2019-10-28 19:59 (UTC) (edited on 2019-10-28 20:09 (UTC) by pancakes)

Hi @grazzolini, and thanks for the very helpful link!

I don't quite understand the implications of mounting the ESP to a non /boot partition very well, so I'm hesitant to do that for now.

Since I don't really mind a delay in boot speed on my machine, I thought I'd disable this systemd feature instead, at least as a test:

  • I tried removing /sys/firmware/efi/efivars/LoaderSystemToken-* which cleared the variable according to efivars -l. However, and for some reason, the var was repopulated on boot, which is against my understanding of what the RANDOM_SEEDS documentation states (I didn't re-run bootctl random-seed, of course).

  • I tried adding random-seed-mode off to my loader.conf file, and for some reason, that setting is also being totally ignored! The loader/random-seed file still gets regenerated on boot.

So the issue remains unresolved for now.

I'm still curious why it only started happening recently, and whether other users have experienced the same issue. I may take it to the forums if it keeps eating at me :) - Cheers!

grazzolini commented on 2019-09-14 04:19 (UTC)

@pancakes,

This seems to be used by systemd-boot, see https://systemd.io/RANDOM_SEEDS. Looks like if you have a seed on the efivar, it'll merge that with the file, triggering chkboot on every boot. My suggestion would be to not mount the ESP under the same path as your /boot partition. If you mount your ESP to /boot/efi, try mounting it to /efi.

pancakes commented on 2019-09-12 08:57 (UTC)

I recently started getting a new /boot/loader/random-seed file on boot on every reboot, triggering chbkoot's warnings. Anyone has an idea on what's the cause behind this? I suspect a systemd update, in which case, is it happening to others as well?

DefaultSpatula commented on 2019-04-16 22:11 (UTC)

I appreciate you taking the time to update this package; thanks!

Notice to everyone: After updating to 1.3, chkboot will warn you about changed hashes. This is because the hashing algorithm has been updated to use SHA512.

grazzolini commented on 2019-04-15 16:51 (UTC)

@DefaultSpatula

I'm going through your PR's. But please, don't advise anyone on using then, specially the EFI one.

DefaultSpatula commented on 2019-04-13 15:05 (UTC)

A heads up for anyone trying to use this on an EFI system: Manually apply pull requests #9, #10, and #11 from github and it'll work perfectly.

Additionally, pull request #13 includes pacman hooks to automate the process when your boot images, systemd, or kernel microcode receive updates.

grazzolini commented on 2015-08-17 15:02 (UTC)

@noxp You're right, this hook has some limitations, specially regarding the usage of a EFI system partition as /boot. I am currently planning a complete revamp of this hook, including a merge with https://aur.archlinux.org/packages/mkinitcpio-chkcryptoboot/ It shouldn't be difficult to add a special case for an EFI system partition, since the UEFI specification determines it must be a FAT filesystem. As for the disk head, it backups the MBR, which on GPT is the protective MBR. Unless you are creating your GPT without it. Right now it backups 512 bytes. But that also backups the partition table, on a MBR disk. If you change your partitioning, it would trigger a false positive chkboot warning.

noxpo commented on 2015-08-16 08:25 (UTC)

Thx for your great work man. My /boot is a FAT32 UEFI System partition on a disk with a GPT label. For this case, I have two suggestions: 1) The number of sectors of the stored disk head should be configurable, I use 34 to cover the entire GPT. 2) The inode and extent fileds in the boot file list don't make a lot of sense for a FAT filesystem, how about comparing the first x sectors of the partiton head holding the file allocation table?

1 2 Next › Last »