Initramfs Built into Custom Linux Kernel Is Not Running

Initramfs built into custom Linux kernel is not running

I figured it out. I will post the answer in case anyone else has this issue.

I was missing a console device, this line was the clue:

Warning: unable to open an initial console.

After adding printk's so that I better understood the startup sequence, I realized that console device is opened prior to running the init script. Therefore, the console device must be in the initramfs filesystem directly, and we cannot rely on the devtmpfs mount to create that.

I think when the init script ran the shell was trying to open the console and failed, that's why the kernel was outputting:

Kernel panic - not syncing: Attempted to kill init!

Executing the folowing commands from within the /dev directory of initramfs on the kernel build machine will generate the required device nodes:

mknod -m 622 console c 5 1
mknod -m 622 tty0 c 4 0

After re-CPIO archiving the filesystem and rebuilding the kernel, I finally have a working filesystem in initramfs that the kernel will boot.

If I build linux kernel from source, does it contain initramfs inside by default?

If I build linux kernel from source, does it contain initramfs inside by default?

Yes, but it will be empty (by default).

As stated in Documentation/filesystems/ramfs-rootfs-initramfs.txt:

The 2.6 kernel build process always creates a gzipped cpio format initramfs
archive and links it into the resulting kernel binary.  By default, this
archive is empty (consuming 134 bytes on x86).

You can populate the initramfs with either an internal or external cpio archive.

Use CONFIG_INITRAMFS_SOURCE to point to a cpio archive file, which will be embedded into the kernel image.

Otherwise an (external) cpio archive file can be specified during boot by using the old initrd mechanism.

If an initrd/initramfs is passed to the arm64 kernel at boot, it must reside entirely within a 1 GB aligned physical memory window of up to 32 GB in size that fully covers the kernel Image as well.

---

The cpio archive needs to contain an init file in order to inhibit the further processing for mounting a root filesystem. As documented:

After extracting, the kernel checks to see if rootfs contains a file "init",
and if so it executes it as PID 1.  
If found, this init process is responsible for bringing the system the
rest of the way up, including locating and mounting the real root device (if
any).  
If rootfs does not contain an init program after the embedded cpio
archive is extracted into it, the kernel will fall through to the older code
to locate and mount a root partition, then exec some variant of /sbin/init
out of that.

Busybox can be built to provide that init file.

---

ADDENDUM

I had found CONFIG_INITRAMFS_SOURCE value in my old .config file (year 2013~2014) was set to just empty (set to " ").

A string of a single space does not make sense.

Did you mean an empty string, as in "" which is the default value?
The default value means that no archive for the initramfs is to be built with the kernel image.

Now I just now found CONFIG_RD_GZIP=y too in the file.

That simply enables support for loading of a gzip-encoded initial ramdisk or cpio buffer. It is just one of several compression methods available that can be configured. There could also be support for bzip2, LZMA, XZ, LZO, and LZ4.

The salient configuration symbol would be CONFIG_BLK_DEV_RAM, which would enable RAM disk support.

At that time we put busybox120.gz file under arch/sparc/boot before doing linux 'make sImage'. so I guess when there is a .gz file under arch/sparc/boot, the kernel build system uses that .gz file as the initramfs.

No, simply storing a file in a directory is not going to cause inclusion in the kernel build.

Since no initramfs file is specified, the likeliest use of that busybox120.gz file would be for a ramdisk.

Archives are typically named with .cpio or .tar filename extensions. Your file has neither, so that could mean that it is not an archive. The absence of an archive extension could mean that it is an image file, which would never be used for a ramfs but could be used for a ramdisk (or initrd).

AFAIK an image (or archive) for the initrd is loaded by the boot program (ref: Using the initial RAM disk (initrd)) rather than linked in.

Check the kernel command line used with that kernel image.

Are there parameters that specify a ramdisk, e.g. initrd=... and/or root=/dev/ram0?

Be sure that you do not conflate initramfs and initrd. See Documentation/filesystems/ramfs-rootfs-initramfs.txt and
The difference between initrd and initramfs?

Newly installed kernel runs only with initramfs prompt

Possible workaround:
1.Try going into grub editor during boot(press 'e' on kernel you want to boot in the grub menu). You will have a line:
"/boot/vmlinuz-2.6.31-23-generic root=UUID=4614036b0-1c9a-4311-b452-c5c0d3762690 ro quiet splash"

2.Remove the "root=UUID=4614036b0-1c9a-4311-b452-c5c0d3762690" and try "/dev/sda1"

Look at this post: here (the last one on the page has screenshots)

---

Related Topics