Trouble installing Linux kernel version 5.14.12 - kernel panic not syncing no working init found try passing init

psrksprasad · 10-16-2021, 12:25 PM

Hello all,
I tried installing the latest kernel version 5.14.12 in my 32-bit system.While configuring the kernel options,in make menuconfig I disabled 64bit support because my system is 32 bit.I was able to successfully build and install the kernel 5.14.12.But when I rebooted to find the changes to take place the system is giving the following error :

kernel panic not syncing no working init found try passing init.init error 8.
Is there any solution?

Regards
Prasad

Ser Olmy · 10-16-2021, 10:04 PM

There's always a solution. But first you need to properly identify the problem.

"No working init found" means the kernel can't locate the file "/bin/init" (or the alternative init filename you've specified in the .configure file) in the root filesystem.

Are you using an initrd? Have you successfully booted any other 5.14.x kernel on this system? Which distribution are you running? What is your root filesystem?

psrksprasad · 10-17-2021, 03:11 AM

Hello Ser Olmy,
Thank you for your reply.This is the first time I am installing the linux kernel 5.14.12 on my system.I am running Ubuntu 20.04.3 LTS on my machine.I ran the command df -Th and got the below output about the file system.

prasad@prasad-desktop:/$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs tmpfs 391M 1.6M 389M 1% /run
/dev/sda5 ext4 457G 8.6G 426G 2% /
tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/loop1 squashfs 33M 33M 0 100% /snap/snapd/12704
/dev/loop2 squashfs 51M 51M 0 100% /snap/snap-store/547
/dev/loop3 squashfs 56M 56M 0 100% /snap/core18/2128
/dev/loop0 squashfs 66M 66M 0 100% /snap/gtk-common-themes/1515
/dev/loop4 squashfs 219M 219M 0 100% /snap/gnome-3-34-1804/72
/dev/sda1 vfat 511M 4.0K 511M 1% /boot/efi
tmpfs tmpfs 391M 112K 391M 1% /run/user/1000

As far as initrd is concerned,I ran the following command and got the output as below.
prasad@prasad-desktop:/$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.11.0-37-generic root=UUID=a1f65d91-d564-4d93-bbac-df272208d8e1 ro quiet splash vt.handoff=7

But I think the real problem is not detecting init.It is detecting init and giving init error 8.

lovemeslk · 10-17-2021, 03:33 AM

here use this one boot without an intrid

ondoho · 10-17-2021, 03:38 AM

^ I haven't looked at that file, but "init" is not the same as "initrd".

Ser Olmy · 10-17-2021, 07:15 AM

Quote:

Originally Posted by psrksprasad

This is the first time I am installing the linux kernel 5.14.12 on my system.

OK. There is a specific problem with 5.14.12 that seems to predominantly affect 32-bit systems. This may or may not be related to your issue (we'll see), but that's why I asked.

Quote:

Originally Posted by psrksprasad

I am running Ubuntu 20.04.3 LTS on my machine.I ran the command df -Th and got the below output about the file system.

prasad@prasad-desktop:/$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs tmpfs 391M 1.6M 389M 1% /run
/dev/sda5 ext4 457G 8.6G 426G 2% /

So your root file system is ext4, and you're running Ubuntu. That means the new kernel must include ext4 support (CONFIG_EXT4_FS), and the init system is systemd.

How did you generate the .config file before compiling the new kernel? Did you start with a .config file from a running Ubuntu system, or did you start from scratch?

Quote:

Originally Posted by psrksprasad

As far as initrd is concerned,I ran the following command and got the output as below.
prasad@prasad-desktop:/$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.11.0-37-generic root=UUID=a1f65d91-d564-4d93-bbac-df272208d8e1 ro quiet splash vt.handoff=7

So you're not using an initrd. That means ext4 support must be compiled into the kernel proper, and not as a module. Same goes for the hard drive controller.

psrksprasad · 10-17-2021, 12:49 PM

Quote:

Originally Posted by Ser Olmy

OK. There is a specific problem with 5.14.12 that seems to predominantly affect 32-bit systems. This may or may not be related to your issue (we'll see), but that's why I asked.So your root file system is ext4, and you're running Ubuntu. That means the new kernel must include ext4 support (CONFIG_EXT4_FS), and the init system is systemd.

How did you generate the .config file before compiling the new kernel? Did you start with a .config file from a running Ubuntu system, or did you start from scratch?So you're not using an initrd. That means ext4 support must be compiled into the kernel proper, and not as a module. Same goes for the hard drive controller.

Thank you for your response. I used the .config file from a running Ubuntu system.The kernel version in the running Ubuntu system is 5.11.0-37-generic.How the hard drive controller support must be compiled into the kernel proper?Could you suggest any articles?It is also fine if you explain it.

Ser Olmy · 10-17-2021, 01:55 PM

Quote:

Originally Posted by psrksprasad

Thank you for your response. I used the .config file from a running Ubuntu system.The kernel version in the running Ubuntu system is 5.11.0-37-generic.How the hard drive controller support must be compiled into the kernel proper?Could you suggest any articles?It is also fine if you explain it.

If you used an existing config file, the required filesystem and controller support really ought to be present.

Check the .config file for ext4 support:

Code:

grep "CONFIG_EXT4_FS=" .config

If this returns CONFIG_EXT4_FS=y, you're good. If it says CONFIG_EXT4_FS=m you'll need to generate an initrd.

As for the controller, the command lspci -v should be able to identify the hard drive or NVME controller in your system.

The next step would be for you to post more of the kernel "splat", not just the "Kernel Panic - not syncing" part. You need to nail down exactly why it's unable to find the init file.

Capturing kernel messages during boot may be somewhat difficult without a serial connection, but you could add boot_delay=200 to the kernel command line in GRUB. That would add a 200 ms delay for each line of output from the kernel during boot, which should help you get a screenshot of the part just before a panic is reported.

psrksprasad · 10-18-2021, 04:30 AM

Quote:

Originally Posted by Ser Olmy

If you used an existing config file, the required filesystem and controller support really ought to be present.

Check the .config file for ext4 support:

Code:

grep "CONFIG_EXT4_FS=" .config

If this returns CONFIG_EXT4_FS=y, you're good. If it says CONFIG_EXT4_FS=m you'll need to generate an initrd.

As for the controller, the command lspci -v should be able to identify the hard drive or NVME controller in your system.

The next step would be for you to post more of the kernel "splat", not just the "Kernel Panic - not syncing" part. You need to nail down exactly why it's unable to find the init file.

Capturing kernel messages during boot may be somewhat difficult without a serial connection, but you could add boot_delay=200 to the kernel command line in GRUB. That would add a 200 ms delay for each line of output from the kernel during boot, which should help you get a screenshot of the part just before a panic is reported.

Thank you for your response.I am attaching the dump that is appearing on the screen when I try to boot.Probably this may give you some hint.Please let me know if I have to provide some thing else.

colorpurple21859 · 10-18-2021, 05:23 AM

On my xubuntu the nvme support section is setup as modules in my generic-config, I would think it needs to be built in.