we're trying to implement an initramfs with the intent of:

Open a LUKS partition (using a key saved on TPM) Mounting the partition RO Mounting an OverlayFS switch_root to the new system

The first part of the script seems to work fine. Our problem is in the "switch_root" part which ends in a kernel panic.

Please note that we have the same problem also without the encryption/overlay part. The problem seems strictly related to the switch_root.

We are using Yocto Sumo and the initramfs image is bundled with the kernel.

Please find attached the kernel panic log.

    bash-4.4# exec switch_root /newroot /sbin/init
BusyBox v1.27.2 (2020-05-20 09:00:12 UTC) multi-call binary.

Us[  593.127118] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[  593.127118]
age: switch_root [-c [/ d e59v3/.137247] CPU: 1 PID: 1 Comm: init Tainted: G        W       4.14.98+g80655a2d3532 #1
[  593.147478] Hardware name: Engicam i.Core MX8MM module (DT)
onsole] N[E W _5R9O3O.T1 5N3E0W8_] Call trace:
[  593.157367] [<ffff000008089c30>] dump_backtrace+0x0/0x3c8
[  593.162798] [<ffff00000808a00c>] show_stack+0x14/0x20
[  593.167891] [<ffff000008d50040>] dump_stack+0x9c/0xbc
[  593.174075] [<ffff0000080ce5b0>] panic+0x11c/0x28c
[  593.178902] [<ffff0000080d27d8>] complete_and_exit+0x0/0x20
[  593.184495] [<ffff0000080d2840>] do_group_exit+0x38/0xa0
[  593.189828] [<ffff0000080d28b8>] __wake_up_parent+0x0/0x28
[  593.195338] Exception stack(0xffff00000805bec0 to 0xffff00000805c000)
[  593.201800] bec0: 0000000000000001 0000000000000001 0000000000000001 0000ffffa819b700
[  593.209644] bee0: 0000000000000020 0000ffffcb90abc8 0000000000010000 0000ffffa81a4a18
[  593.217490] bf00: 000000000000005e fffffffffffffff0 0101010101010101 0000000000000000
[  593.225336] bf20: 0101010101010101 00000000004f2f10 0000ffffa7fe92c8 0000ffffa7fdbde0
[  593.233184] bf40: 0000ffffa7fd7028 0000ffffa800cb68 00000000000005c2 0000000000000008
[  593.241030] bf60: 0000000000000008 0000ffffa8122bb8 0000000000000001 0000ffffa8125000
[  593.248874] bf80: 0000ffffa81265a0 0000ffffa81a3738 0000000000000001 0000000000000000
[  593.256719] bfa0: 0000ffffa812a000 0000ffffcb90ac70 0000ffffa800c7f0 0000ffffcb90ac70
[  593.264564] bfc0: 0000ffffa807946c 0000000060000000 0000000000000001 000000000000005e
[  593.272408] bfe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[  593.280259] [<ffff000008083ac0>] el0_svc_naked+0x34/0x38
[  593.285620] SMP: stopping secondary CPUs
[  593.290003] Kernel Offset: disabled
[  593.293520] CPU features: 0x080200c
[  593.297028] Memory Limit: none
[  593.300135] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[  593.300135]


  • I am not familiar with BusyBox. Maybe there are limitations for the use of exec? May 30 '20 at 4:39
  • This error message gives very little to work with. Basically all it says is this script, sitch_root, or /shin/init terminated. I wonder if adding -c /dev/console would give more. May 30 '20 at 8:42
  • We found the problem. I edited the first post. Thanks.
    – nellorocca
    Jun 10 '20 at 14:36
  • 1
    Nellorocca that's good you've foud the answer. Please post that as an answer (i.e not in your question) so that you can accept it. This shows everyone else it was the solution that worked for you - and therefore is most likely to work for them
    – roaima
    Jun 10 '20 at 14:59

We found the solution. Basically, for testing purpose, we were executing our exec switch_root from a /bin/bash opened at the end of the init script. The problem is that switch_root requires to run with PID 1 but, in our setup, that PID was not available since it was occupied by init.

PID 1: /init PID x: /bin/bash => exec switch_root from /bin/bash would assign the PID x to switch_root. That's not an option. So, for testing environment the solution was to call exec /bin/bash at the end of init and then, as usual, exec swtich_root. For production, we moved exec switch_root at the end of init (of course removing the call to /bin/bash).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.