#1148126 dracut: Including busybox module results in errors "Invalid ELF header magic" during early boot

Package:
dracut
Source:
dracut
Submitter:
Farblos
Date:
2026-09-17 10:35:02 UTC
Severity:
normal
#1148126#5
Date:
2026-09-17 10:33:01 UTC
From:
To:
Dear Maintainer,

Since the installation of dracut 112-6 yesterday I get journal
errors (prio <3>) during early boot:

  [1.680672] <5> kernel Loaded X.509 cert 'Build time autogenerated kernel ke>
  [1.680676] <6> kernel Demotion targets for Node 0: null
  [1.680679] <5> kernel Key type .fscrypt registered
  [1.680683] <5> kernel Key type fscrypt-provisioning registered
  [1.680687] <3> kernel Invalid ELF header magic: != %7FELF
  [1.680691] <3> kernel Invalid ELF header magic: != %7FELF
  [1.680694] <3> kernel Invalid ELF header magic: != %7FELF
  [1.680698] <3> kernel Invalid ELF header magic: != %7FELF
  [1.680702] <5> kernel Key type encrypted registered
  [1.680706] <6> kernel AppArmor: AppArmor sha256 policy hashing enabled
  [1.680710] <6> kernel ima: Allocated hash algorithm: sha256
  [1.680713] <6> kernel ima: No architecture policies found

(Note: These errors are visible only as shown above with my
private journalctl wrapper - more on that below.)

If I explicitly omit module "busybox" in my dracut configuration
and rebuild the initramfs, above error messages do not occur in
the journal.


From what I understood with some LLM help:

- dracut 112-5 includes the busybox module by default, and I can
  see it being included in my initramfs, where it replaces insmod
  and modprobe:

    dracut modules:
    [...]
    busybox
    [...]

    usr/sbin/insmod -> ../bin/busybox
    usr/sbin/modprobe -> ../bin/busybox

- Busybox's insmod/modprobe can show above error when trying to
  process a compressed module, as described here:

https://lists.busybox.net/pipermail/busybox/2023-March/090205.html

  After issuing the error, Busybox's insmod/modprobe try to
  uncompress the module being processed, which succeeds.


Not sure whether you consider this a bug, just thought to report
it.


Now for the journal thingy.  With a stock journalctl, I see above
journal snippet as follows:

  Sep 17 10:46:56 host01 kernel: Loaded X.509 cert 'Build time autogenerated kernel key: 670c83507bab56189d03e08d7e0b98e062686569'
  Sep 17 10:46:56 host01 kernel: Demotion targets for Node 0: null
  Sep 17 10:46:56 host01 kernel: Key type .fscrypt registered
  Sep 17 10:46:56 host01 kernel: Key type fscrypt-provisioning registered
  Sep 17 10:46:56 host01 kernel: [33B blob data]
  Sep 17 10:46:56 host01 kernel: [33B blob data]
  Sep 17 10:46:56 host01 kernel: [33B blob data]
  Sep 17 10:46:56 host01 kernel: [33B blob data]
  Sep 17 10:46:56 host01 kernel: Key type encrypted registered
  Sep 17 10:46:56 host01 kernel: AppArmor: AppArmor sha256 policy hashing enabled
  Sep 17 10:46:56 host01 kernel: ima: Allocated hash algorithm: sha256
  Sep 17 10:46:56 host01 kernel: ima: No architecture policies found

Only in verbose format the error hidden in the "blob data" gets visible:

  [~]$ journalctl --since 00:00:00 -a -o verbose -p 3..3
  Thu 2026-09-17 10:46:56.289932 CEST [s=6be00687ad164dc79ad4730c28e80569;i=2c0b4>
    _TRANSPORT=kernel
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    _BOOT_ID=bf8f0850f5fe4e67b0f681d1c5850e7a
    _MACHINE_ID=e9a7104c5a904888af3f7971a1a82f6c
    _HOSTNAME=host01
    _RUNTIME_SCOPE=initrd
    _SOURCE_BOOTTIME_TIMESTAMP=1014165
    _SOURCE_MONOTONIC_TIMESTAMP=1014165
    PRIORITY=3
    MESSAGE=Invalid ELF header magic: != ^?ELF
  [...]