linux内核无法启动

linux内核无法启动,第1张

  Linux在启动过程中会出现一些故障,导致系统无法正常启动,本文列举了几个应用单用户模式、GRUB命令 *** 作、Linux救援模式的典型故障修复案例帮助读者了解此类问题的解决。

  u-boot内核移植出现问题

  ## BooTIng kernel from Legacy Image at 30000000 。。。

  Image Name: Linux-3.4.2

  Created: 2014-10-15 3:14:05 UTC

  Image Type: ARM Linux Kernel Image (uncompressed)

  Data Size: 2486120 Bytes = 2.4 MiB

  Load Address: 30108000

  Entry Point: 30108000

  Verifying Checksum 。。。 Bad Data CRC

  ERROR: can‘t get kernel image!

  原因:

  分区设置不对,实际内核大小为2.4M,但是我的分区设为2M。

  mtdparts=mtdparts=rookie_wei-nand:256k(bootloader),128k(params),2m(kernel),-(rootfs)

  解决办法;

  办法一:(不推荐,每次启动都得设置)

  set mtdparts “mtdparts=rookie_wei-nand:256k(bootloader),128k(params),4m(kernel),-(rootfs)”

  办法二:

  在u-boot源码是设置,使内核分区为4m

  一、单用户模式

  Linux提供了单用户模式(类似Windows安全模式),可以在最小环境中进行系统维护。在单用户模式(运行级别1)中,Linux引导进入根shell,网络被禁用,只有少数进程运行。单用户模式可以用来修改文件系统损坏、还原配置文件、移动用户数据等。

  以下列举了几个单用户模式修复系统故障的典型案例:

  案例:硬盘扇区错乱

  在启动过程中最容易遇到的问题就是硬盘可能有坏道或扇区错乱(数据损坏)的情况,这种情况多由于异常断电、不正常关机导致。

  此种问题发生,在系统启动的时候,屏幕会显示:

  Press root password or ctrl+D:

  此时输入root密码系统自动进入单用户模式,输入“fsck -y /dev/hda6”(fsck为文件系统检测修复命令,“-y”设定检测到错误自动修复,/dev/hda6为发生错误的硬盘分区,请依据具体情况更改此参数),系统修复完成后,用命令“reboot”重新启动即可。

  二、GRUB引导故障排除

  有时Linux启动后会直接进入GRUB命令行界面(只有“grub》”提示符),此时很多用户就选择了重新安装GRUB 甚至重新安装系统。其实一般而言此故障的原因最常见的有两个:一是GRUB配置文件中选项设置错误;二是GRUB配置文件丢失(还有少数原因,如内核文件或镜像文件损坏、丢失,/boot目录误删除等),如果是第一种情况,可以首先通过GRUB命令引导系统后修复;若是第二种情况,则要使用Linux救援模式修复了(本文后续有描述)。

  首先,我们需要了解GRUB启动系统的引导过程,grub.conf文件中主要的配置选项如下(注意,GRUB配置文件为/boot/grub/grub.conf,/etc/grub.conf只是此文件的软链接):

  TItle Fedora Core (2.6.18-1.2798.fc6)

  root (hd0,0)

  kernel /boot/vmlinuz-2.6.18-1.2798.fc6 ro root=LABEL=/ rhgb quiet

  initrd /boot/initrd-2.6.18-1.2798.fc6.img

  其中“TItle”段指定了GRUB引导的系统;“root”段指定了/boot分区所在的位置;“kernel”段指定了内核文件所在位置,内核加载时权限属性为只读(“ro”)以及指定根分区所在位置(root=LABEL=/);initrd指定了镜像文件所在位置。所以GRUB在引导时顺序为首先加载/boot分区,然后依次载入内核与镜像文件。

  案例:“TItle Fedora Core (2.6.18-1.2798.fc6)”段被误删除

  此时,系统启动后会自动进入“GRUB》”命令行,为排除故障我们可以依次做如下 *** 作:

  1、查找/boot/grub/grub.conf文件所在分区

  GRUB》 find /boot/grub/grub.conf

  (hd0,0)

  2、查看grub.conf文件错误

  GRUB》cat (hd0,0)/boot/grub/grub.conf

  建议系统安装设置好后,要将grub.conf文件备份,如果有备份文件如grub.conf.bak,则此时可以查看备份文件,与当前文件比较,发现错误:

  GRUB》cat (hd0,0)/boot/grub/grub.conf.bak

  3、确认错误后,先通过命令行方式完成GRUB引导,进入系统后再行修复grub.conf文件错误:

  1)指定/boot分区

  root (hd0,0)

  2)指定内核加载

  kernel /boot/vmlinuz-2.6.18-1.2798.fc6 ro root=LABEL=/ rhgb quiet

  3)指定镜像文件所在位置

  initrd /boot/initrd-2.6.18-1.2798.fc6.img

  提示:GRUB支持tab键命令补全功能

  4、从/boot分区启动

  boot (hd0,0)

  命令行模式可以在GRUB菜单模式中通过按“c”键调用,也可以用于测试新编译的内核(设置kernel、initrd引导新内核及镜像文件)。增加对GRUB引导以及Linux系统引导知识的了解将对此类故障排除大有帮助。

  三、Linux救援模式应用

  当系统连单用户模式都无法进入时或出现GRUB命令行也不能解决的引导问题,我们就需要使用Linux救援模式来进行故障排除了。步骤如下:

  1、将Linux安装光盘(如果使用CD光盘,则放入第一张引导光盘)放入光驱,设置固件 CMOS/BIOS为光盘引导,当Linux安装画面出现后,在“boot:”提示符后输入“linux rescue”回车进入救援模式。(想了解救援模式详细信息,还可以按F5键查看)

  linux内核无法启动,linux内核无法启动,第2张

  2、系统会检测硬件,引导光盘上的Linux环境,依次提示你选择救援模式下使用 的语言(建议选择默认的英文即可,根据笔者测试,部分Linux系统选择中文会出现乱码);键盘设置用默认的“us”就好;网络设置可以根据需要,大部分 故障修复不需要网络连接,可不进行此项设置,选择“No”。

  linux内核无法启动,linux内核无法启动,第3张

  3、接下来系统将试图查找根分区,出现以下提示:

  默认在救援模式,硬盘的根分区将挂载到光盘Linux环境的/mnt /sysimage目录下,默认选项“continue”表示挂载权限为读写;“Read-only”为只读,如果出现检测失败可以选择“skip”跳 过。此处,因为要对系统进行修复,所以需要有读写权限,一般选择默认选项“continue”。

  进入下一步后,系统提示执行“chroot /mnt/sysimage”命令,可以将根目录挂载到我们硬盘系统的根目录中去。

  案例:双系统启动修复

  当我们安装双系统环境,先安装Linux再安装Windows;或者已经安装好双系统环境的Windows 损坏,在重新安装Windows后,保存GRUB的MBR(Master Boot Record,主引导记录)会被Windows系统的自举程序NTLDR所覆盖,造成Linux系统无法引导。

  1、如果要恢复双系统引导,首先用上述方法进入救援模式,执行chroot命令如下:

  sh-3.1# chroot /mnt/sysimage

  2、将根目录切换到硬盘系统的根目录中,然后执行grub-install命令重新安装GRUB:

  sh-3.1#grub-install /dev/hda

  “/dev/hda”为硬盘名称,如使用SCSI硬盘或Linux安装在第二块IDE硬盘,此项设置要做相应调整。

  3、然后依次执行exit命令,退出chroot模式及救援模式(执行两次exit命令):

  sh-3.1# exit

  sh-3.1# exit

  系统重启后,将恢复GRUB引导的双系统启动。

  uboot无法启动linux内核

  1、u-boot中的命令行参数中console设定有问题,对2.6的内核应该使用ttySAC0,而不是ttyS0。更改为“console=ttySAC0”就可以解决问题。

  2、u-boot中FCLK与kernel时钟频率不一致。kernel的FCLK为200MHz,但是uboot的默认值是202.8MHz。(vivi默认的也是200MHz,所以vivi不会出现这个问题。)这样修改uboot的时钟频率设定就可以解决问题。

  但是这两个方案并不适合我这种情况。经过分析和读bootm的源代码,现在提出两点额外考虑的地方:

  1、如果你在配置文件中不定义tag list的成员,那么默认情况下bootm是不会传递命令行参数的。也就是说,如果你uboot环境变量中设定了正确的bootargs,但是配置文件中没有设置,这时就会出现问题。为了使用上的方便,你至少应该在头文件中定义:

  /* tag list choosing */

  #define CONFIG_CMDLINE_TAG

  //#define CONFIG_SETUP_MEMORY_TAGS

  这样就可以保证你在命令行状态下修改环境变量bootargs后,可以传递进内核。同时也就避免了重新编译uboot。

  2、我在使用中发现,如果在bootargs中没有指定mem的大小,那么CONFIG_SETUP_MEMORY_TAGS也是需要设定的。我就是因为bootargs没有设定mem,所以导致出现上述的情况。现在我的bootargs为:

  bootargs=noinitrd root=/dev/mtdblock3 console=ttySAC0,115200 mem=64M

  在这种情况下,使用go和bootm都可以正常引导内核。

  综上可知,在tag list的设定上,一定要考虑CONFIG_CMDLINE_TAG和内存两个部分,否则的话,可能出现上述无法引导内核的问题。

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/dianzi/2717152.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-08-17
下一篇 2022-08-17

发表评论

登录后才能评论

评论列表(0条)

保存