/bin/sh: can't access tty; job control turned off

Question

I have been following the commands from the book "Mastering embedded linux programming" by Chris Simmonds. I have created the toolchain, kernel zImage and busybox file system. When I combine these together to run on QEMU, It should display a root shell prompt.

When I run the command, I get the following.

/bin/sh: can't access tty; job control turned off 
input: ImExPS/2 Generic Explorer Mouse as /devices/platform/amba/amba:fpga/10007000.kmi/serio1/input/input2 

When I press enter, I am able to see the root shell prompt and I am able to execute simple shell commands.

However, when I press exit, I get the following error.

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000

CPU: 0 PID: 1 Comm: sh Not tainted 4.9.13 #1
Hardware name: ARM-Versatile (Device Tree Support)
[<c001b5a4>] (unwind_backtrace) from [<c0018860>] (show_stack+0x10/0x14)
[<c0018860>] (show_stack) from [<c00737f4>] (panic+0xb8/0x230)
[<c00737f4>] (panic) from [<c0024e24>] (do_exit+0x8e8/0x938)
[<c0024e24>] (do_exit) from [<c0025cf8>] (do_group_exit+0x38/0xb4)
[<c0025cf8>] (do_group_exit) from [<c0025d84>] (__wake_up_parent+0x0/0x18)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000

How do I resolve this

EDIT:

The following is the QEMU command that I ran

QEMU_AUDIO_DRV=none \qemu-system-arm 
-m 256M -nographic 
-M versatilepb 
-kernel ~/linux-4.9.13/arch/arm/boot/zImage 
\-append "console=ttyAMA0,115200 rdinit=/bin/sh" 
-dtb ~/linux-4.9.13/arch/arm/boot/dts/versatile-pb.dtb 
-initrd ~/busybox/initramfs.cpio.gz

Answer 1

(You don't say what your QEMU command line is.)

These error messages generally are what you should expect if you tell the kernel to run /bin/sh directly as its process 1 (eg with "init=/bin/sh" on the kernel command line). First the shell complains that it doesn't have a tty, but it can continue anyway with some facilities disabled. Then, when you eventually tell the shell to exit, because the shell itself is process 1 the kernel complains. (Usually process 1 is supposed to be an "init" program, which runs forever and deals with starting other processes in the system. If "init" ever dies the kernel has nothing else it can do.)

If you were intending to run /bin/sh as your process 1, then this is all normal. If you didn't want to do that, then you have an issue with either your root filesystem or with your command line which means that it isn't properly starting an /sbin/init in the guest, and you should look at why.