这类问题很常见,先总体介绍一下解决思路。
能出现让人激动的的控制台,那么系统移植已经接近完成;但是不少人在最后一步出现问题。
要点如下:
1. 在正确的位置烧写正确格式的文件系统映象:
2. 内核支持这种文件系统格式
3. 文件系统的内容要完备
上面说得简单,一个个介绍。
1. 在正确的位置烧写正确的文件系统映象:
(a). 正确的位置
嵌入式开发中,常通过bootloader烧写文件系统映象,假设写在flash的地址A处。
内核启动时,显然要从地址A处读取文件系统,内核是怎么知道的呢?通过命令行参数,比如“root=/dev/mtdblock2 ”。/dev/mtdblock2 又是怎么和地址A对应上的呢?内核将flash划分为
几个分区,这是在代码中固定的。/dev/mtdblock2是第3个分区,它的开始地址必须是A。
在内核启动时,可以看到这些分区的开始地址、结束地址,比如内核启动时会有类似下面的信息:
Creating 3 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x00000000-0x00030000 : "bootloader"
0x00050000-0x00250000 : "kernel"
0x00250000-0x03ffc000 : "root"
对于上面的内核信息,/dev/mtdblock2对应root分区,开始地址为0x00250000,使用bootloader写文件系统映象时,烧写的地址必须是0x00250000
所以,要保证3点:① bootloader烧到地址A,② 地址A是内核某个分区的开始地址,③ 命令行参数“root=/dev/mtdblockXXX ”是这个分区
(b). 正确格式的文件系统映象
不同的bootloader支持的烧写的文件系统映象格式不同、使用的烧写命令也可能不同,请注意这点。
另外,马大哈们制作文件系统映象时,使用的工具也不要弄错了。
最后,请保证这个文件系统映象是“真的烧写了”,因为如果flash只是擦除而没有烧写,它也是“正确的、可以挂接的文件系统”──有人碰到这个问题,我和他答非所问地折腾了很久。
2. 内核支持这种文件系统格式
配置内核时选上要支持的文件系统格式
1、2这两个问题如果不能保证,内核启动时会出现类似如下错误:
VFS: Cannot open root device "mtdblock2" or unknown-block(2,0)
Please append a correct "root=" boot option
如果1、2能保证,就可以挂接上文件系统,出现类似下面的字样时,革命已经成功了80%:
VFS: Mounted root (cramfs filesystem) readonly.
Freeing init memory: 116K
3. 文件系统的内容要完备
挂接文件系统后,内核就会读取、执行文件系统中的某个文件,通过它来启动应用程序。这个文件要么通过命令行参数“init=xxxx”来指定,要么取默认的文件(下面说明)。
一般制作文件系统映象时,都是在一个目录(假设目录名为rootfs)下放好各种东西:bin/,sbin/,lib/等目录,etc/fstab等文件,然后将这个目录制作为文件系统映象。
可以想象,如果这个目录中的东西不对、不全,即使制作出了文件系统映象,也只是能识别出来,挂接上去;但是启动不了──所谓启动,不就是执行文件系统中的程序嘛?
这时会有类似以下的错误:
Failed to execute /linuxrc. Attempting defaults...
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
它说得很明显,"Failed to execute /linuxrc"──执行/linuxrc失败:
它为什么要执行/linuxrc,还不是因为你在命令行中加入了“init=/linuxrc”这个参数。
它为什么会失败?原因有二:
一、你制作文件系统映象时,rootfs目录下有linuxrc这个文件吗?
二、rootfs目录的linuxrc文件是正确的吗?
请好好确定这两点,大多数是没有linuxrc文件──linuxrc是busybox自动生成的,只要配置好就可以。
如果有linuxrc,那么就是它无法执行了(解决方法在下面)。
不用linuxrc行不行?当然行!看看内核文件init/main.c,有如下字样:
run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");
panic("No init found. Try passing init= option to kernel.");
就是说,它会依次尝试执行/sbin/init、/etc/init、/bin/init、/bin/sh这些文件,都失败后才打印出错信息"No init found. Try passing init= option to kernel."。
所以,出现这个出错信息时,就表明了没有或是无法执行这些文件:命令行参数“init=xxxx”来指定的xxx文件、/sbin/init、/etc/init、/bin/init、/bin/sh。
一、请检查你的rootfs目录,看看这点些文件是否存在
二、使用file命令看看它们是什么文件类型,是否可执行。
使用busybox时,这些文件是到/bin/busybox文件的链接,那就看看busybox的文件类型,可以使用下面的命令:
$ file linuxrc
linuxrc: symbolic link to `bin/busybox'
$ file bin/busybox
bin/busybox: ELF 32-bit LSB executable, ARM, version 1, for GNU/Linux 2.4.3, dynamically linked (uses shared libs), stripped
注意了:如果bin/busybox 是一个动态链接的文件,还要把它用到的库复制到rootfs中。唉,越说越复杂了。这些库在交叉编译工具的相应目录下,如果不知道,查google,否则再发帖。
最后一点,文件系统中各种配置文件、dev目录也要正确。出现问题时再在这个帖子中说吧。这样写下去真是没完没了。
回到这个帖子,它的内核打印信息为:
VFS: Mounted root (cramfs filesystem) readonly.
Freeing init memory: 116K
Failed to execute /linuxrc. Attempting defaults...
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
说明文件系统挂接成功(VFS: Mounted root (cramfs filesystem) readonly.);
还说明/linuxrc不存在或者不可执行(Failed to execute /linuxrc. Attempting defaults...);
但是楼主的意思是linuxrc已经有了,内容为:
#!/bin/sh
echo "mount /etc as ramfs"
/bin/mount -n -t ramfs ramfs /etc
/bin/cp -a /mnt/etc/* /etc
echo "re-create the /etc/mtab entries"
# re-create the /etc/mtab entries
/bin/mount -f -t cramfs -o remount,ro /dev/mtdblock/3 /
/bin/mount -f -t ramfs ramfs /etc
exec /sbin/init
它是一个脚本,它的执行依赖于/bin/sh,问题转为:/bin/sh是否存在?是否可以执行?
用file命令看看它的类型、是否需要动态库。
Quote
分享到:
相关推荐
Linux操作系统启动时,内核需要加载并初始化一系列组件和服务,其中最关键的一个步骤就是挂载根文件系统(Root File System, 简称 RootFS)。根文件系统包含了系统运行所需的最基本文件和目录结构,是整个系统的基础...
完成以上步骤后,ZYNQ7045系统将在启动时挂载JFFS2文件系统,允许用户在该系统上创建文件和目录,且这些更改将在下次重启后保持不变。JFFS2文件系统的使用显著增强了基于Xilinx ZYNQ平台的系统的非易失性存储能力,...
Linux 根文件系统的挂载过程是 Linux 启动过程中的一个关键步骤,它直接影响着 Linux 系统的启动和运行。为了帮助读者更好地理解 Linux 根文件系统的挂载过程,本文将对其进行详细的分析。 一、前言 在编译 kernel...
如果不删除旧的内核镜像,/boot分区将会被占满,导致Grub无法挂载根文件系统,从而出现“Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)”错误。 要解决这个问题,我们可以使用...
首先,文档中提到的“Kernel panic-not syncing: VFS: Unable to mount root fs on unknown-block(2,0)”是一个常见的内核启动错误,它表明内核在启动过程中无法挂载根文件系统。这个问题可能由多个原因引起,比如...
在 CentOS 中,VFS 是指根文件系统的挂载点。 四、总结 CentOS 内核报错是指操作系统在启动过程中出现的内核崩溃或无法启动的问题。解决方案是修改 grub.conf 文件,将默认启动的内核版本改为旧版本。同时,本文还...
服务器无法启动,显示 kernel panic 信息,显示超出范围的文件描述符、无法找到 Ext3 文件系统、无法挂载根文件系统等错误信息。通过分析这些错误信息,作者怀疑 Superblock 故障的可能性,可能是由于删除大量文件...
需要注意的是,在挂载Yaffs2文件系统时,可能会遇到由于NANDFLASH的页、块参数与内核中预设的不匹配导致的问题。遇到问题时,需检查文件系统的制作过程,确保使用正确的参数。 在文档中还提到,不同来源的文件系统...
当用户尝试启动Ubuntu或Debian虚拟机时,如果遇到“Mount of filesystem failed”错误,这通常意味着虚拟机无法正确挂载其文件系统。可能的原因有多种,例如磁盘损坏、文件系统错误或者虚拟机配置不正确。针对这种...
通过研究这个文件,开发者可以学习如何根据实际需求定制QEMU的启动配置,例如添加特定的硬件模拟、调整内存大小、挂载特定的磁盘映像等。 在进行内核调试时,常见的任务包括追踪系统调用、分析中断处理、检查内存...
- 如果在编译后的内核中无法挂载文件系统(Kernel panic),可能是由于未能正确加载磁盘硬件控制器的模块驱动。解决方案是在`make menuconfig`中选择对应的IDE/SATA/SAS驱动模块。 - 另外一种方法是查看`/etc/...
需要设置共享文件系统在系统启动时自动挂载,并设置服务自启动。此外,还可以添加新节点到现有的OCFS2集群中,以扩展集群的规模。 OCFS2文件系统在创建和管理上有一些特殊的注意事项。比如,如果启用global-...
- 客户端在挂载文件系统时出现kernel panic现象; - 无法从串口登录系统。 这些常见问题需要在搭建过程中特别注意,文档中也给出了相应的解决方案。 搭建完成PXE服务器后,它能够在网络中广播,为需要安装操作系统...
- **`have_submounts`**:判断一个给定的 dentry 是否具有子挂载点,即是否存在其他文件系统挂载在其下。 - **`shrink_dcache_parent`**:与 `shrink_dcache_sb` 类似,但它是针对父目录缓存进行清理操作。 - **`d_...
`mnt_init()`函数用于初始化与文件系统挂载相关的数据结构。 - **2.5 块设备驱动模型的初始化** `bdev_cache_init()`函数用于初始化块设备相关的缓存。 - **2.6 字符设备驱动模型的初始化** `chrdev_init()`...
如果在修复GRUB后仍然无法正常启动,并出现"Kernel panic – not syncing: Attempted to kill init!"的错误,这意味着需要进一步修改系统以支持SCSI驱动。这可以通过编辑`/etc/modprobe.conf`文件实现,添加`alias ...
为 Arch Linux 分区时,通常会创建一个主分区用于根文件系统(/),以及一个交换分区(swap)。以下是一个简单的示例命令: ```bash gparted /dev/sdX # 替换 sdX 为实际的 USB 设备名 ``` 在 GParted 中创建分区...