0

Attaching a bit more of the boot log.

HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
iommu: Default domain type: Translated 
iommu: DMA domain TLB invalidation policy: strict mode 
SCSI subsystem initialized
EDAC MC: Ver: 3.0.0
clocksource: Switched to clocksource arch_sys_counter
workingset: timestamp_bits=62 max_order=19 bucket_order=0
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler mq-deadline registered
cacheinfo: Unable to detect cache hierarchy for CPU 0
brd: module loaded
VFS: Mounted root (tmpfs filesystem) on device 0:15.
Freeing unused kernel memory: 704K
Run /init as init process
  with arguments:
    /init
  with environment:
    HOME=/
    TERM=linux
Kernel panic - not syncing: Requested init /init failed (error -2).
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc7-00001-g8d7daa446b53-dirty #33
Call trace:
 dump_backtrace+0x0/0x1d0
 show_stack+0x14/0x20
 dump_stack_lvl+0x64/0x7c
 dump_stack+0x14/0x2c
 panic+0x158/0x304
 kernel_init+0xf0/0x150
 ret_from_fork+0x10/0x20
Kernel Offset: disabled
CPU features: 0x00001001,20000802
Memory Limit: none
---[ end Kernel panic - not syncing: Requested init /init failed (error -2). ]---

I am building an embedded linux OS for an experimental FPGA platform. I used upstream U-boot(boot-loader), linux(kernel) and buildroot(just for filesystem).

I followed some examples and enabled the required initrd/initramfs support in my linux config.

CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=1
CONFIG_BLK_DEV_RAM_SIZE=10240

I used the bootm command in u-boot to load a FIT image that comprises of the linux kernel, dtb and the rootfs.cpio(compiled from buildroot). Relevant info here: FIT test

These are the bootargs passed to the kernel:

console=ttyS0,9600 earlyprintk maxcpus=1 earlycon root=/dev/ram init=/init rw rootfstype=tmpfs debug

Note:

Couple of other things I tried , but resulted in the same error.

  • Passing the kernel,dtb and fs image separately.
  • Tried passing init=/bin/sh , /sbin/init , /etc/init , /bin/init
  • Tried a basic initramfs with just an init script , simple directory structure and a separately compiled busybox placed in /bin/busybox with symbolic links.
  • Rather than passing an external FS, I passed the path to the initramfs source and compiled it into the kernel with CONFIG_INITRAMFS_SOURCE.

I would appreciate any feedback/pointers on what I could be missing, been stuck on this for while now.

Marco Bonelli
  • 63,369
  • 21
  • 118
  • 128
rish_1n4
  • 21
  • 3
  • The question is off-topic. This site is about programming. Unix and Linux StackExchange (a sister site of us, link on top right icon) may be more appropriate. The problem is not on kernel, but on the program "/init". Such program should never exit (and careful on the dependencies, it is the first program to be called (really the second one, loader/linker will setup init). But you cannot try everything. Think what you want, and load the correct init. /bin/sh is not appropriate. /bin/bash can handle init functionalities. – Giacomo Catenazzi Dec 16 '21 at 07:30
  • @GiacomoCatenazzi, Thanks for the reply. I will look more into "/init " and what is happening on that front. Definitely will be more careful next time about asking the relevant question on the appropriate site. – rish_1n4 Dec 16 '21 at 18:53
  • 2
    Don't use an initrd (a RAM disk), which is deprecated. Use an initramfs, which uses an integral capability of the kernel; there's no need to specify it in the kernel command line. Study **Documentation/filesystems/ramfs-rootfs-initramfs.rst**. – sawdust Dec 16 '21 at 23:04
  • 1
    Buildroot can get confused when initramfs options are enabled with an already-built kernel and rootfs. IOW it is best to start with a clean build environment. Or use the hack to delete hidden files mentioned in https://stackoverflow.com/questions/17885451/how-to-rebuild-rootfs-in-buildroot?noredirect=1&lq=1 Also study https://stackoverflow.com/questions/65868294/if-i-build-linux-kernel-from-source-does-it-contain-initramfs-inside-by-default?noredirect=1&lq=1 – sawdust Dec 17 '21 at 00:24
  • @sawdust, thanks for the pointers. Some follow up questions: How does the invoking method change in trying to use initrd vs initramfs? I tried your suggestion to not include the init in the command line and also based on the documentation tried passing rdinit= . Neither of them worked and I got hit by the No working init found. Try passing init= option to kernel. – rish_1n4 Dec 17 '21 at 19:24
  • @sawdust, I have dropped buildroot for now and have focused my efforts in just trying the examples given Documentation/filesystems/ramfs-rootfs-initramfs.rst. i.e. the hello world example and passing a separately compiled busybox with the init script to the CONFIG_INITRAMFS_SOURCE as outlined by the usr/gen_init_cpio help command. The behavior was even weirder. I don't even see the root fs being mounted. Refer log: https://pastebin.com/91ya0ArA – rish_1n4 Dec 17 '21 at 20:06
  • A proper initramfs requires no kernel parameters. **None**. *"I passed the path to the initramfs source"* - What does that mean? You need to specify a **cpio** archive of the rootfs. You need to configure for the Busybox **init** system. Properly configured, it simply just works/boots without any kernel command parameters. *"I don't even see the root fs being mounted"* -- there is no *"mounting"* of the initramfs; it's simply available. – sawdust Dec 17 '21 at 20:29
  • @sawdust, my understanding is that you can either pass the path to the cpio archive or the source directory containing the init script, busybox image with the general fs directory structure. I passed the cpio archive as well and just passed **console=ttyPS0,9600 earlyprintk maxcpus=1 earlycon** as kernel command parameters. I see the same panic as before. https://pastebin.com/mt791Ukc – rish_1n4 Dec 21 '21 at 19:13
  • Is there a possibility that something outside of the scope of the file system/command line bring up could be causing this panic. Is there anything in kernel config or device tree or bootloader setup that I should be on the lookout for? – rish_1n4 Dec 21 '21 at 19:21
  • You can specify that Buildroot create the cpio archive of the rootfs. Then you know exactly what is in that initramfs; i.e. you could simply extract the archive. When you use the list method, how do you verify the contents of the initramfs? Please make available the Buildroot and Linux kernel **.config** files – sawdust Dec 21 '21 at 20:26
  • @sawdust, the linux boot made it to command line successfully. I switched to a different gcc arm compiler toolchain. I tried versions of aarch64-linux-gnu- and linaro toolchains and they didn't work. But using aarch64-none-linux-gnu- (10.3 version) made it work. Not sure why that made a difference. Using Initramfs definitely helped the boot progress too. – rish_1n4 Dec 29 '21 at 20:53

0 Answers0