request_module: runaway loop modprobe binfmt-464c Kernel panic - not syncing: No init found Pid: 1, comm: swapper/0 Not tainted

This is usually caused by a mismatch in architecture and happens frequently in development environments.

Here is a example of what caused this issue:

1. Your binaries are based on one architecture
2. Your kernel was compiled with another architecture.

Why does this happen?

Perhaps you migrated your dev environment and chrooted into it, in a new architecture or perhaps you migrated to newer hardware with a different architecture (eg. your dev container is now running on a different architecture than the original).  When you make your kernel, it will by default compile for the active architecture (eg. if you are in a 64 bit x64 kernel then it will compile the kernel as x64 even if your kernel config specified ARM or i386).

A good hint that this is happening is if you have the same kernel, same config but it is asking you questions about enabling different kernel modules and drivers.  It is likely because of the change in architecture.

This is a frequent cause of the issue that leads to the mismatch and which is why it tries to modprobe binfmt-464c module to try to try make the non-compatible binaries work.

How to avoid this?

Never migrate or one simple way is when you make your kernel specify the architecture using the ARCH= switch.

make ARCH=i386

request_module, runaway, modprobe, binfmt, kernel, syncing, init, pid, comm, swapper, tainted, solutionrequest_module, mismatch, architecture, frequently, environments, binaries, compiled, migrated, dev, chrooted, newer, hardware, eg, container, default, compile, active, config, specified, enabling, modules, drivers, module, compatible, migrate, specify,

Latest Articles