Arch Linux User Repository

@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.

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!

@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.

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?

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.

@DefaultSpatula

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

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.

@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.

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?

@pezz Expect it to be updated today, at most tomorrow. I still haven't fixed all the bugs chkboot-git had.