# Why isn't kernel starting with init=/bin/bash?

## colag

It's not related to gentoo. Gentoo stage3 is not extracted in /media/sda7. /dev/sda7 is empty ext4 partition. It has only glibc,binutils,ncurses,readline,bash and kernel is in /boot/vmlinuz-4.8.0.

```

linux   /boot/vmlinuz-4.8.0 root=/dev/sda7 ro init=/bin/bash

```

Error after booting:

```

kernel panic - not syncing: Attempted to kill inint !

bash not painted

```

I've installed glibc,binutils,ncurses,readline,bash in /dev/sda7 from /dev/sda9. Debian system is in /dev/sda9

I installed glibc,binutils,ncurses,readline,bash in this way:

```

glibc:

cd /media/sda7/packages/glibc-2.24

./configure --prefix=/media/sda7 --enable-kernel=2.6.32

make

make install

binutils:

cd /media/sda7/packages/binutils-2.27

./configure --prefix=/media/sda7

make

make install

ncurses:

cd /media/sda7/packages/ncurses-5.9

./configure --prefix=/media/sda7 --with-shared --with-termlib

make

make install

readline:

cd /media/sda7/packages/readline-6.3

./configure --prefix=/media/sda7

make

make install

bash:

cd /media/sda7/packages/bash-4.4

./configure --prefix=/media/sda7

make

make install

```

Bash is there.

```

mount /dev/sda7 /media/sda7

cd /media/sda7/bin

ls | grep bash

bash

bashbug

cd /media/sda7/lib

ls | grep libc

libc-2.24.so

libc.a

libcidn-2.24.so

libcidn.so

libcidn.so.1

libc_nonshared.a

libcrypt-2.24.so

libcrypt.a

libcrypt.so

libcrypt.so.1

libc.so

libc.so.6

ls | grep libtinfo

libtinfo.a

libtinfo_g.a

libtinfo.so

libtinfo.so.5

libtinfo.so.5.9

ls | grep ncurses

libncurses.a

libncurses++.a

libncurses_g.a

libncurses.so

libncurses.so.5

libncurses.so.5.9

ls | grep ld

ld-2.24.so

ld-linux.so.2

```

grub.cfg

```

menuentry 'Kernel boot with bash' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-69b65444-5f22-4b9b-9afc-3a815c0d44b8' {

    load_video

    insmod gzio

    insmod part_msdos

    insmod ext2

    set root='hd0,msdos7'

    if [ x$feature_platform_search_hint = xy ]; then

      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7  69b65444-5f22-4b9b-9afc-3a815c0d44b8

    else

      search --no-floppy --fs-uuid --set=root 69b65444-5f22-4b9b-9afc-3a815c0d44b8

    fi  

    echo    'Loading Linux 4.8.0 ...'

    linux   /boot/vmlinuz-4.8.0 root=/dev/sda7 ro init=/bin/bash

}

```

Am I missing anything to install? Is the glibc installed properly? Are all requiredl shared library loaded correctly? How can I check if glibc is ok?

----------

## NeddySeagoon

colag,

```
$ ls /lib/ld* -l

-rwxr-xr-x 1 root root 144616 Apr  9  2016 /lib/ld-2.22.so

lrwxrwxrwx 1 root root     10 Apr  9  2016 /lib/ld-linux-x86-64.so.2 -> ld-2.22.so
```

Do ls /bin/bash and look at the ELF header.

```
Program Headers:

  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align

  PHDR           0x000040 0x0000000000400040 0x0000000000400040 0x000230 0x000230 R E 0x8

  INTERP         0x000270 0x0000000000400270 0x0000000000400270 0x00001c 0x00001c R   0x1

      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
```

On my install /lib and /lib64 are symlinked together.

Notice that when bash loads, it wants to use  /lib64/ld-linux-x86-64.so.2, which is a symlink to the linker.

Is your ld-linux-x86-64.so.2 -> ld-2.22.so symlink name correct?

If not bash cannot load as it cannot be linked.

----------

## colag

NeddySeagoon,

```

ls -l /media/sda7/lib/ld*

-rwxr-xr-x 1 root root 725744 Oct 15  lib/ld-2.24.so

lrwxrwxrwx 1 root root     10 Oct 15    lib/ld-linux.so.2 -> ld-2.24.so

ls /bin/bash

/bin/bash

ls /media/sda7/bin/bash

/media/sda7/bin/bash

```

ls /bin/bash didn't match the output of yours.

----------

## NeddySeagoon

colag,

What matters is that all your pieces are self consistent.

Your 

```
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
```

from your /bin/bash must point (via several symlinks if needed) to your  /lib/ld-...

If that's incorrect, /bin/bash will load, fail to find the dynamic linker, then you get that error about bash.

You need to answer the question about your system being self consistent.

I have met this issue before.  Cross compiled programs for a Raspberry Pi failed to run on the target because of exactly this issue.

Natively build programs and cross compiled programs used different names for the linker in the ELF header.

Adding a symlink so both names worked, fixed it.

----------

## colag

NeddySeagoon,

 *Quote:*   

> 
> 
> What matters is that all your pieces are self consistent. 
> 
> You need to answer the question about your system being self consistent. 
> ...

 

What does that mean? I think, everything in debian system is self consistent/stable.

```

readelf -l /media/sda7/bin/bash | grep ': /lib'

[Requesting program interpreter: /lib/ld-linux.so.2]

```

But this returns nothing:

```

readelf -l /media/sda7/bin/bash | grep ': /media/sda7/lib'

```

Is this ok?

----------

## NeddySeagoon

colag,

That's OK because /media/sda7/lib is the path to your chrooted /lib from outside the chroot.

When you chroot or boot the kernel in /sda7 the bash ELF header says to use the linker at /lib/ld-linux.so.2

Going back to a previous post, you said

```
ls -l /media/sda7/lib/ld*

-rwxr-xr-x 1 root root 725744 Oct 15  lib/ld-2.24.so

lrwxrwxrwx 1 root root     10 Oct 15    lib/ld-linux.so.2 -> ld-2.24.so 
```

So the bash ELF header points to /lib/ld-linux.so.2, which in turn is a link to ld-2.24.so, which exits in your filesystem.

That's good. It rules out not finding the linker as a cause.

----------

## szatox

Hint:

create link named "sh" pointing  to /bin/busybox

and set init to that link.

Once you boot into the minimal shell, try calling /bin/bash. And check the error it throws. File not found by any chance?

----------

