自定义Linux内核中内置的Initramfs没有运行 [英] Initramfs built into custom Linux kernel is not running

问题描述

我正在将自定义的initramfs映像作为CPIO存档构建到Linux内核(3.2)中.

I am building a custom initramfs image that I am building as a CPIO archive into the Linux kernel (3.2).

我遇到的问题是，无论我尝试什么，内核似乎都没有尝试从initramfs运行.

The issue I am having is that no matter what I try, the kernel does not appear to even attempt to run from the initramfs.

我在CPIO存档中拥有的文件:

The files I have in my CPIO archive:

cpio -it < initramfs.cpio
.
init
usr
usr/sbin
lib
lib/libcrypt.so.1
lib/libm.so
lib/libc.so.6
lib/libgcc_s.so
lib/libcrypt-2.12.2.so
lib/libgcc_s.so.1
lib/libm-2.12.2.so
lib/libc.so
lib/libc-2.12.2.so
lib/ld-linux.so.3
lib/ld-2.12.2.so
lib/libm.so.6
proc
sbin
mnt
mnt/root
root
etc
bin
bin/sh
bin/mknod
bin/mount
bin/busybox
sys
dev
4468 blocks

初始化非常简单，应该只初始化设备并生成一个shell(目前):

Init is very simple, and should just init devices and spawn a shell (for now):

#!/bin/sh

mount -t devtmpfs none /dev
mount -t proc none /proc
mount -t sysfs none /sys
/bin/busybox --install -s
exec /bin/sh

在内核.config中，我有:

In the kernel .config I have:

CONFIG_INITRAMFS_SOURCE="../initramfs.cpio"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=1
CONFIG_BLK_DEV_RAM_SIZE=32768

内核构建，并且uImage的大小取决于initramfs的大小，因此我知道图像正在打包.但是我启动时会得到以下输出:

Kernel builds and the uImage size is larger depending on the initramfs size, so I know the image is being packed. However I get this output when I boot:

console [netcon0] enabled
netconsole: network logging started
omap_rtc omap_rtc: setting system clock to 2000-01-02 00:48:38 UTC (946774118)
Warning: unable to open an initial console.
Freeing init memory: 1252K
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new high speed SDHC card at address e624
mmcblk0: mmc0:e624 SU08G 7.40 GiB
 mmcblk0: p1
Kernel panic - not syncing: Attempted to kill init!
[<c000d518>] (unwind_backtrace+0x0/0xe0) from [<c0315cf8>] (panic+0x58/0x188)
[<c0315cf8>] (panic+0x58/0x188) from [<c0021520>] (do_exit+0x98/0x6c0)
[<c0021520>] (do_exit+0x98/0x6c0) from [<c0021e88>] (do_group_exit+0xb0/0xdc)
[<c0021e88>] (do_group_exit+0xb0/0xdc) from [<c0021ec4>] (sys_exit_group+0x10/0x18)
[<c0021ec4>] (sys_exit_group+0x10/0x18) from [<c00093a0>] (ret_fast_syscall+0x0/0x2c)

从该输出中，它看起来甚至都没有尝试将CPIO存档提取为initramfs.我希望看到这个printk输出，它存在于linux代码init/initramfs.c中:

From that output, it does not look like it is even trying to extract the CPIO archive as initramfs. I expect to see this printk output, which is present in linux code init/initramfs.c:

printk(KERN_INFO "Trying to unpack rootfs image as initramfs...\n");

引导完成后(使用chroot)，我尝试了文件系统，并且工作正常...因此，我相信文件系统/库是理智的.

I tried the filesystem once booting is complete (using chroot) and it works fine... so I believe the filesystem/libraries are sane.

有人可以给我一些有关我可能有不正确之处的提示吗?在此先感谢您的协助！

Could anyone give me some pointers as to what I may have incorrect? Thanks in advance for any assistance!

推荐答案

我知道了.如果其他人遇到此问题，我将发布答案.

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.

添加printk以便更好地理解启动顺序之后，我意识到在运行init脚本之前已打开控制台设备.因此，控制台设备必须直接位于initramfs文件系统中，并且我们不能依靠devtmpfs挂载来创建该设备.

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.

我认为当运行init脚本时，shell试图打开控制台并失败，这就是内核输出的原因:

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!

在内核构建计算机上的initramfs的/dev目录中执行以下命令将生成所需的设备节点:

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

在重新CPIO归档文件系统并重建内核之后，我终于在initramfs中有了一个可以启动内核的工作文件系统.

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

这篇关于自定义Linux内核中内置的Initramfs没有运行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！