process_random_seed: Failed to open random seed file: Not found

dimich · 2026-07-01 20:53:41

Today I noticed the message in red color on top of boot logo during boot, before any kernel messages:

../systemd/src/boot/random-seed.c:216@process_random_seed: Failed to open random seed file: Not found

Already found bugreport about this message: https://github.com/systemd/systemd/issues/42801
It is going to be "fixed" in next release: https://github.com/systemd/systemd/pull/42807
However, the "fix" will be to create that seed file directly from EFI stub.

Also in the journal I see "No ESP found, not initializing random seed" from bootctl starting at least from Nov 28 2025 (I have no journal before that date):

Dec 09 05:13:44 dimich systemd[1]: Starting Update Boot Loader Random Seed...
Dec 09 05:13:44 dimich bootctl[794]: No ESP found, not initializing random seed.
Dec 09 05:13:44 dimich systemd[1]: Finished Update Boot Loader Random Seed.
Dec 10 22:39:59 dimich systemd[1]: systemd-boot-random-seed.service: Deactivated successfully.
Dec 10 22:39:59 dimich systemd[1]: Stopped Update Boot Loader Random Seed.

(Strange, at some boots this bootctl message is shown as output of systemd-boot-random-seed.service, sometimes it is not a part of the service output).

The error in journal may be caused by my "non-standard" EFI partition layout. I have ESP partition mouned as /boot/esp:

$ tree /boot/esp/
/boot/esp/
└── EFI
    ├── Dell
    │   ├── Bios
    │   │   └── Recovery
    │   │       ├── BIOS_CUR.RCV
    │   │       └── BIOS_PRE.rcv
    │   └── logs
    │       ├── diags_current.xml
    │       └── diags_previous.xml
    └── Linux
        └── linux-signed.efi

I use direct UKI boot with custom UEFI keys and no bootloaders, and have no any issue with boot so far.

1st question: is that random seed file required for boots with efistub, as in my case?

2nd question: is it considered to be safe to store anything cryptography-related (a random seed is one) on EFI partition, which is not encrypted and publicly visible?

Last edited by dimich (2026-07-01 21:47:08)

seth · Yesterday 12:31:36

https://man.archlinux.org/man/systemd-r … ESCRIPTION
https://man.archlinux.org/man/random.4.en#Usage

Afaiu you get to see the message now because the logging code was changed in https://github.com/systemd/systemd/comm … 843770018b
The seed has also previously been written, https://github.com/lionheartyu/systemd_ … 70cff9286c

twig · Yesterday 13:03:58

Hello!

I will add a bit more context to seth's reply. When you boot your machine, your system quickly needs a good source of randomness for some operations, such as but not only cryptographic ones. The systemd random seed is one of the different ways to obtain such randomness, but not the only one. On modern hardware, the hardware itself can provide it, such as your CPU (via RDRAND), your TPM, or the EFI firmware [1]. This is why, in your case, you can normally boot your machine without a random seed. You are getting good quality randomness by other means.

Even though you are not using systemd-boot, your UKI still uses systemd-stub under the hood, which always looks for the random seed [2]. So, to your questions:

No, the random seed is not strictly required because you have a modern machine, but it is still wanted by systemd-stub.
It is generally considered safe to store the seed unencrypted since, on modern hardware, it is only one of many sources that are mixed together to get randomness at boot. It gets consumed and immediately overwritten during the boot process so that it cannot be reused or recovered. Plus, the seed on your ESP cannot work alone. It needs the second half called the system token stored in your motherboard's NVRAM. In addition, since you have Secure Boot enabled, systemd uses a hashing scheme that blends the disk seed with a UEFI monotonic counter, a timestamp, and the EFI's hardware RNG. This prevents a physical attacker from tampering with the unencrypted file [3].

Regarding the fix you linked, it will fix this:

../systemd/src/boot/random-seed.c:216@process_random_seed: Failed to open random seed file: Not found

But not this:

Dec 09 05:13:44 dimich bootctl[794]: No ESP found, not initializing random seed.

Those are two different components that are used in two different stages.

The first one is managed by systemd-stub and overwrites the seed with a low-entropy one, so that if power suddenly cuts out immediately after booting, the next boot won't accidentally reuse the exact same seed.
The second update by bootctl ensures that the new seed uses high entropy collected while the system was actually running [4].

The command that is run is

bootctl --graceful random-seed

so if you want to keep your ESP at /boot/esp/ you should edit the

SYSTEMD_ESP_PATH

environment variable [5]. I recommend using one of the standard ESP paths (/efi/, /boot/, or /boot/efi/) though.

Thanks for the question! I actually learned something new today while looking into this.

[1] https://systemd.io/RANDOM_SEEDS/
[2] https://man.archlinux.org/man/systemd-b … rvice.8.en
[3] https://github.com/systemd/systemd/comm … ee6864aea8
[4] https://www.freedesktop.org/software/sy … rvice.html
[5] https://systemd.io/ENVIRONMENT/

Last edited by twig (Yesterday 13:36:49)

dimich · Yesterday 18:30:19

Thank you both for replies.

Yeah, I read the docs. My main concern is about this (https://man.archlinux.org/man/bootctl.1):

random-seed
Generates a random seed and stores it in the EFI System Partition (ESP), for use by the systemd-boot boot loader.

Since I don't use systemd-boot boot loader, storing random seed to ESP partition seems pointless.

seth wrote:

The seed has also previously been written

Afaiu it isn't written in my case because "loader" directory doesn't exist. Now they will create the directory explicitly in EFI stub. I'd prefer to keep it not created, as is now, but without anoying message at the very beginning of boot.
It feels like systemd-boot boot loader is gradually pushed to be mandatory.

twig wrote:

When you boot your machine, your system quickly needs a good source of randomness for some operations

I appreciate such a detailed answer, thanks. I know that lack of entropy right after boot can be problematic, faced it many times in embedded systems with poor external entropy sources. However, there is /var/lib/systemd/random-seed already. I don't understand why to pull this stuff into EFI stub at early boot stage. Of course, in some cases boot loader or initramfs may want to establish secure communication for further boot and needs crng. But this should be optional itfp.

twig wrote:

Regarding the fix you linked, it will fix this ... But not this

I understand. I don't mind that systemd tools can't find ESP by default, because they shouldn't. I'm concerned that such disposition may stop the system from booting at all in the future.

twig wrote:

if you want to keep your ESP at /boot/esp/ you should edit the SYSTEMD_ESP_PATH environment variable.

There is already

default_uki="/boot/esp/EFI/Linux/linux-signed.efi"

in my /etc/mkinitcpio.d/linux.preset.

twig wrote:

I recommend using one of the standard ESP paths (/efi/, /boot/, or /boot/efi/) though.

I don't remember exact motivation why current layout is used. Afair, there was no requirements at the moment of installation. Anyway, imho the system should work normally even without ESP partition mounted permanently, mounting it only for UKI update.

seth · Yesterday 19:13:33

It feels like systemd-boot boot loader is gradually pushed to be mandatory.

That's probably not an option since there's a whole bunch of usecases it doesn't cover.

Since systemd-boot-random-seed.service runs bootctl and that's explicitly controlling systemd-boot you could just boldly mask the service, it's

Condition: start condition unmet

here

twig · Yesterday 19:59:06

No, it will not stop the system from booting, as a random seed is not strictly required on a modern machine. I think you are right that you won't be able to natively prevent systemd-stub from trying to generate and use a seed file.

The only workaround that comes to my mind is to create a plain file named /boot/esp/loader. This will physically prevent systemd from creating a loader/ directory and writing the seed into it. However, you will still see a non-fatal error message about it in the logs (https://github.com/lionheartyu/systemd_ … eed.c#L231). If you take this route, I would also mask systemd-boot-random-seed.service as seth suggested.

Edit:
While it's true that the bootctl man page says:

Generates a random seed and stores it in the EFI System Partition (ESP), for use by the systemd-boot boot loader

The systemd-boot-random-seed.service man page clarifies:

The boot loader random seed is primarily consumed and updated by systemd-boot(7) from the UEFI environment (or systemd-stub(7) if the former is not used, but the latter is)

Which is exactly the case with a UKI:

It is the combination of a UEFI boot stub program like systemd-stub(7), a Linux kernel image...

If you want to bypass systemd-stub altogether, I think you could stop using a UKI and configure efibootmgr to point directly to the kernel itself (https://wiki.archlinux.org/title/EFI_bo … efibootmgr).

Last edited by twig (Yesterday 20:23:42)

dimich · Yesterday 22:19:38

seth wrote:

Since systemd-boot-random-seed.service runs bootctl and that's explicitly controlling systemd-boot you could just boldly mask the service

Already masked it. Of course, this didn't affect stub behavior.
By the way, conditions to start systemd-boot-random-seed.service are:

# Only run this if the boot loader can support random seed initialization.
ConditionPathExists=|/sys/firmware/efi/efivars/LoaderFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
ConditionPathExists=|/sys/firmware/efi/efivars/StubFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f

The service shouldn't start if none of those entries present. There are no LoaderFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f entry in my /sys/firmware/efi/efivars. However, systemd-stub creates StubFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f unconditionally.

twig wrote:

If you want to bypass systemd-stub altogether, I think you could stop using a UKI and configure efibootmgr to point directly to the kernel itself

Unfortunately, this doesn't work on my Dell laptop. (Even if it worked, I'm not sure secure boot is possible without UKI (Edit: or signed bootloader in the chain).

The only way I see for now is to replace systemd-stub with some dumb stub that only prepares parameters and passes control to the kernel. Does such thing exist in nature?

Last edited by dimich (Yesterday 22:29:04)

twig · Yesterday 23:45:01

I agree with you that the best way to use Secure Boot is with a UKI. Regarding replacing systemd-stub, it is technically possible but not very practical if the goal is not to have the random seed. You could try using Stubby (https://github.com/puzzleos/stubby), but it looks unmaintained, so you will likely run into a lot of issues. I actually found a nice flag in the kernel’s command-line parameters:

random.trust_bootloader=off
[KNL,EARLY] Disable trusting the use of the a seed
passed by the bootloader (if available) to
initialize the kernel's RNG.

So, you could let systemd-boot generate the seed and use it, but instruct the kernel not to trust it. This is pretty clean I think if you don't trust the seed. Otherwise, simply stick with systemd-stub and prevent it from generating the seed by creating a plain file at /boot/esp/loader and masking systemd-boot-random-seed.service.

dimich · Today 01:21:14

twig wrote:

You could try using Stubby

Thanks, I'll take a look.

twig wrote:

So, you could let systemd-boot generate the seed and use it, but instruct the kernel not to trust it

Actually, the use of entropy from systemd by kernel is not the root problem. The main goal it to avoid garbaging EFI partition AND useless error/warning messages at boot. I prefer to use things that function correctly and cleanly rather than to workaround consequences of fancy functioning.

twig · Today 09:16:23

Actually, you could try compiling the kernel yourself and using the

CONFIG_INITRAMFS_SOURCE

option (https://docs.kernel.org/filesystems/ram … ramfs.html). This lets you specify an initramfs to be automatically incorporated and linked directly into the kernel binary. In theory, this would allow you to point efibootmgr at the resulting file and bypass systemd-stub entirely. You would also only need to sign this single file for Secure Boot. It makes sense to me on paper, but I haven't tested it myself.

dimich · Today 15:44:08

twig wrote:

you could try compiling the kernel yourself and using the CONFIG_INITRAMFS_SOURCE option

This will require re-compiling on every kernel update, as well as re-linking and re-installing the kernel with modules on every initramfs or cmdline change.

twig wrote:

It makes sense to me on paper, but I haven't tested it myself.

This method is widely used in embedded, IoT and other specialized niches. But for desktop system it's overhead, imho.

twig · Today 17:34:16

I know, I know, and I agree, but I honestly don't see any other way to get the exact combination you're after. No random seed, no errors (which currently means avoiding systemd-stub), and Secure Boot. I'm completely out of ideas. The best scenario would be finding a reliable, minimal alternative to systemd-stub.

dimich · Today 17:38:03

twig wrote:

The best scenario would be finding a reliable, minimal alternative to systemd-stub.

Or write it by myself, if I had enough free time to look into details

Arch Linux

#1 2026-07-01 20:53:41

process_random_seed: Failed to open random seed file: Not found

#2 Yesterday 12:31:36

Re: process_random_seed: Failed to open random seed file: Not found

#3 Yesterday 13:03:58

Re: process_random_seed: Failed to open random seed file: Not found

#4 Yesterday 18:30:19

Re: process_random_seed: Failed to open random seed file: Not found

#5 Yesterday 19:13:33

Re: process_random_seed: Failed to open random seed file: Not found

#6 Yesterday 19:59:06

Re: process_random_seed: Failed to open random seed file: Not found

#7 Yesterday 22:19:38

Re: process_random_seed: Failed to open random seed file: Not found

#8 Yesterday 23:45:01

Re: process_random_seed: Failed to open random seed file: Not found

#9 Today 01:21:14

Re: process_random_seed: Failed to open random seed file: Not found

#10 Today 09:16:23

Re: process_random_seed: Failed to open random seed file: Not found

#11 Today 15:44:08

Re: process_random_seed: Failed to open random seed file: Not found

#12 Today 17:34:16

Re: process_random_seed: Failed to open random seed file: Not found

#13 Today 17:38:03

Re: process_random_seed: Failed to open random seed file: Not found

Board footer