Top
2楼 xfzhao_cn () 回复于 2005-01-07 12:02:11 得分 0
我想应该是你做ramdisk的方法不对。
Top
3楼 flik (阳光下的蚂蚁) 回复于 2005-01-09 14:02:27 得分 0
现在发现在启动时出现RAMDISK: compressed image found at block 0 是正常的，之所以停止
在此处是因为下面要执行的不正确，我少拷了配置文件需要的/sbin中的文件。
但是现在又出现了kernel panic: no init found try passing init= option to kernel
的错误，很头疼。
shuyu 于 2006-09-05 10:28:55发表:
能具体一下步骤吗?
苏小小 于 2006-09-05 09:06:38发表:
这个错误一般是没有核心映象文件造成的。 你看看是不是kernel没放进去。
shuyu 于 2006-09-05 08:32:29发表:
上面这此是我在网上搜集的一点资料，但是看不懂，希望对解决问题有点帮助。
“RAMDISK: Compressed image found at block 0' 时启动中止
系统试图给另一个内核载入 RAM disk ，但启动程序的配置文件指向了一个错误的或不存在的 RAM disk （可选项 initrd=）。启动开机菜单中的另一个条目(entry)，用 'mkinitrd' 为新内核建立一个 RAM disk ，或用 Mandrake 配置中心(Control Center)的 'Boot config' 模块自动生成相应条目的 'initrd' 映象(image)。
如果没有其他启动条目，可使用外部的急救系统，请见上面的“症状 I”。”
shuyu 于 2006-09-05 08:30:51发表:
精简系统启动错误:RAMDISK: compressed image found at block 0
，就会忽略正在执行的步骤，继续后面的启动。
flik (阳光下的蚂蚁) 2005-01-06 14:56:47 在 Linux/Unix社区 / 内核及驱动程序研究区 提问
我制作了一个小系统,启动时出现RAMDISK: compressed image found at block 0 的错误,并停在此处.
文件系统只有几M,而我设置的RAMDISK_SIZE=20000感觉应该足够大了,请问该怎么解决,谢谢!!
问题点数：0、回复次数：3
1楼 redex (cc) 回复于 2005-01-07 10:28:10 得分 0
是不是没加解压程序？
Top
2楼 xfzhao_cn () 回复于 2005-01-07 12:02:11 得分 0
我想应该是你做ramdisk的方法不对。
Top
3楼 flik (阳光下的蚂蚁) 回复于 2005-01-09 14:02:27 得分 0
现在发现在启动时出现RAMDISK: compressed image found at block 0 是正常的，之所以停止
在此处是因为下面要执行的不正确，我少拷了配置文件需要的/sbin中的文件。
但是现在又出现了kernel panic: no init found try passing init= option to kernel
的错误，很头疼。
症状 I：系统不启动
这种错误经常是由于启动程序配置不当。您得想办法重启系统，然后修改 启动程序的配置 。
如果当前有一张启动盘，那您就很幸运 ;-) 。如果没有，我建议您现在就制作一张。可以通过 Mandrake 的配置中心（开机 - 开机启动盘）很容易地完成。
如果您更喜欢命令行，可以用：
mkbootdisk $(uname -r)
但如果启动失败，手边又没有启动盘，那可以动用某个外部系统，Mandrake Linux 的急救系统就是不错的选择，在 上一篇 中已作介绍，然后就可以对启动程序的配置进行修改（或至少制作一张启动盘）。
修改完 LiLo 的配置文件 '/etc/lilo.conf' 后，不要忘了运行 lilo 。但前提是 'lilo' 在那块硬盘上，毕竟要更新的是该设备上的启动扇区，如何实现呢？
很简单，进入硬盘系统挂载的根目录，也就是 '/mnt' ，然后改变 'root' 目录：
chroot .
这是在做什么呢？当处于急救系统中时，根目录在光盘上，而硬盘的系统则挂载于 '/mnt' 。用 'chroot' 就可以将根目录切换到硬盘上。如果现在运行命令，执行的就是硬盘上的命令版本，而不是光盘上的。接着运行
/sbin/lilo
含有新配置的启动扇区就被写到了 MBR (master boot record)上。对于 GRUB ，相应地运行
grub-install /dev/hda
当然，由于硬件不同，这里的设备名可能有出入。要将根目录切换回光盘，输入：
exit
分区表被破坏
如果无法在启动时完成修复，而 'cfdisk' 和 'fdisk' 都报告说硬盘上没有可供读取的分区表（there just isn't any partition table to read on your hard disk），这时分区表就有可能已被破坏了(corrupt)。
可安装分区表急救工具 gpart ，然后针对坏掉的 boot record 运行：
gpart /dev/device
device 是指整个硬盘设备（比如 hda 或 sda）。'gpart' 将进行扫描，看是否能找出分区。请注意，这步会花较长的时间，而且将消耗相当多的系统资源。如果 'gpart' 找到的看起来挺合理，就可以将其写到 boot record ：
gpart -W /dev/device
在完成分区表的写入前，不要关机或 kill 这个进程。有时候 'gpart' 看起来好象顿住了，其实还在工作，请耐心等待。结束后，重启系统。
如果硬盘上的分区表实在无法读取，就要动用 Mandrake Linux 的急救系统了。其中有个工具称为 'rescuept' ，我诂计您从这个名称就已经猜到其用途了吧(rescue corrupt) ;-) 。第一步和 'gpart' 一样：
rescuept /dev/device
这将在控制台列出 'rescuept' 的查找结果。如果结果合理，那就可以将其通过管道(pipe | )送到另一个磁盘工具 'sfdisk' ，从而写入硬盘的启动扇区(boot sector)：
rescuept /dev/device | sfdisk /dev/device
这里要绝对确保管道两边的设备名相同 …… 完成后，重启系统。
Super Block Damaged（超级快被损坏）
这是很罕见的情况。我用了六年 Linux ，这儿列出的所有症状中，只有这种至今还没有碰到过 ;-) 。
super block 是 extfs2 分区的第一个块(block)，其中含有关于文件系统的重要数据，比如大小、剩余空间（和 FAT 分区的文件分配表：File Allocation Table 类似）。如果超级块被破坏，分区也就无法被挂载。幸运的是，extfs2 对超级块作了几个备份。
启动您最喜欢的急救系统；
备份一般位于每个 8 KB (8192 bytes) 块的头部，因此下一个备份就位于 No. 8193 byte ；
输入下面命令，以使备份恢复到超级块：
e2fsck -b 8193 /dev/device
但如果这个块也被破坏了，那就试试后面的 No. 16384 byte ，依此类推； 重启系统。
section index top
症状 II ：系统启动时停住
启动失败，有几种可能的原因。
内核没有正确载入（Kernel Doesn't Load Properly）
内核升级、启动程序配置出错、'/boot' 下放错了符号链接(simlinks)，都可能导致这种问题。启动另一个内核或急救系统的步骤在 升级内核 中已有介绍。
Rebuilding RPM database 或 Finding Module Dependencies 时启动中止
启动时遇到这类情况，只要同时按下
如果停顿是由 'Rebuilding RPM database' 引起的，就以 'root' 身份运行 rpm --rebuilddb 。
如果是由于 'Finding module dependencies' ，就有可能因为内核从源码升级，但没有设置正确。检查一下 '/boot' 和 '/lib/modules' 目录下的文件和当前的内核版本(kernel-version)是否一致（要和当前版本号相同），详情请参阅 从源码升级内核 。
RAMDISK: Compressed image found at block 0' 时启动中止
系统试图给另一个内核载入 RAM disk ，但启动程序的配置文件指向了一个错误的或不存在的 RAM disk （可选项 initrd=）。启动开机菜单中的另一个条目(entry)，用 'mkinitrd' 为新内核建立一个 RAM disk ，或用 Mandrake 配置中心(Control Center)的 'Boot config' 模块自动生成相应条目的 'initrd' 映象(image)。
如果没有其他启动条目，可使用外部的急救系统，请见上面的“症状 I”。
Kernel panic: VFS: Unable to mount root fs on xx:yy ，启动中止
内核试图挂载 'root' 分区，但可能找不到需要的驱动，或找不到 'root' 分区。
如果访问 root 文件系统时需要的驱动，是以内核模块的方式构建(build)的，这些模块就必须通过一个 'init RAM disk' (initrd)来载入，在启动程序的配置文件中要提到。请注意，要访问非 ext2 文件系统，比如 Reiserfs、XFS 或 JFS ，也需要模块及一个 RAM disk ，请参看上一则。
如果内核无法找到 root 分区，就要检查启动程序的配置，特别是那个 'root' 可选项。
文件系统检查失败
如果系统碰到没有正常卸载(unmount)的介质(medium)，就会运行常规的文件系统检查（'fsck'），倘若您用了日志式(journaling)文件系统（Mandrake Linux 8 中的默认设置），在下次挂载该介质时就会进行日志恢复。
如果文件系统没有日志功能，'fsck' 将进行一致性(consistency)核查，并删除或移动空的及不合理的数据。您过后就能在在'fsck' 运行的分区，从 'lost+found' 目录中，找到这些数据。
'fsck' 自己能修复绝大多数错误。但如果删除了数据，'fsck' 可能会退出，接着系统就进入了 root shell 。这时您可以手动运行 'fsck'，继续原来该设备上的 'fsck' 。
e2fsck /dev/device
这是一个交互模式，'fsck' 在进一步动作前，会向您询问。如果您还不是文件系统方面的高手(guru)，可以禁用询问，让 'fsck' 自己决定怎么做：
e2fsck -py /dev/device
'-p' 可选项告诉 'e2fsck' 不需要询问，直接进行必要的修复，'-y' 假定所有问题的回答都是 'yes' 。
核查和修复完成后，按 CTRL-D 退出急救控制台，系统将重启。
系统重启后，您要做的第一件事就是：马上将所有重要的数据备份到外部介质中。看一下系统中的 'lost+found' 目录，里面应该有些带 '#' 的文件。这些文件被转移到这里，以改进文件系统的一致性，这意味着这些文件可能是重要的系统配置文件。
benny_feng 于 2006-09-04 23:04:58发表:
没见过这种情况