摘要：本文主要介绍了几种linux启动过程中几个重要部分出现问题后的解决方案。如加载开机启动图形界面的程序，被恶意链接到关机、重启等程序上致使linux系统无法正常开机，这该如何解决； linux系统的grub(引导加载程序)被破坏的解决方案； linux系统的内核模块被恶意破坏的解决办法； 系统初始化镜像文件被恶意破坏的解决方案；MBR的前446字节的主引导记录程序被恶意破坏的解决方案。
一、将重启的程序链接到开机加载图形界面的链接上等类似问题该如何解决？
###1. 启动系统后各种服务自启动的原因：
#首先我们先了解一下系统中的各种服务在开机时为何会自启动？
我们先进到 /etc/systemd/system/multi-user.target.wants/ 这个目录中一探究竟：
在上图中有很多熟悉的身影，如ssh服务、chronyd服务、libvirtd服务等等。
我们再看看这些服务的文件属性，如下图：
从上图应该可以看出这些文件都是些链接文件，而执行这些链接的时候，真正执行的是其链接指向的文件，即图中箭头指向的文件。
#那么接下来我们就去寻找真正执行的那些文件。
如上图所有链接的执行文件，也即执行脚本都在 /usr/lib/systemd/system/这个目录下，但这个目录下的文件除了这些链接文件的执行文件以外，还有许多其他的文件：
#到这里开机后有些服务会自启动，有些服务不会自启动的原因已经显而易见了：
只要将 /usr/lib/systemd/system/ 目录中的执行脚本文件 在 /etc/systemd/system/multi-user.target.wants/ 目录中创建链接，那么开机后这些执行脚本就会自启动；其实我们经常使用的命令 systemctl enable xxx.service 就是这个过程：
####2. 恶意链接导致的系统不能正常启动的解决方案：
#下面我们以一个例子来说明类似的问题
正常情况下我们系统启动时，会自动加载图形界面的程序，而该程序会被链接到 /etc/systemd/system 目录下的default.target这个链接文件，这样图形界面才会正常启动。
但有时候会发生下图的情况：
没错，你的开机加载图形窗口的链接被链接到了开机就关机的执行文件上，这时当你重启系统时就会......变成下图的摸样：
对，卡在这起不来了。。。
这时我们再次强制重启电脑，当出现下图时按上下键停住，然后在有你内核的那个选项上点击字母'e'进行编辑：
点击‘e’进来后如下图，出现如下图的界面：
在以linux16开头的那段程序之后添加一个数字 5，如下图所示， 这个5表示指定开机时启动图形界面，编辑好后按 ‘ctrl x' 重新启动系统，如下图所示：
这时系统就能正常启动了，但是当你再次重启系统时还是不能正常启动，这时因为下图的原因：
#所以我们最主要的任务还是将正确的链接指向 default.target。
一种方法是通过命令 systemctl set-default graphical.target 来恢复正常：
一种方法是删除掉错误的链接文件，然后自己创建正确的链接，过程不再演示，要使用的命令是：ln -s /usr/lib/systemd/system/graphical.target /etc/systemd/system/defalut.target 。
二：当grub2（引导加载程序）被恶意破坏后的解决方案：
如果你的引导加载程序被删除后，系统将不能正常启动，会出现如下图的界面：
这时我们需要自己输入引导程序来加载系统的引导程序、内核模块文件、系统初始化镜像文件，我们输入下图的程序：
注意 3.10.0-123.el7.x86_64 是作者系统的内核版本，你们在进行该步操作时应该写自己的内核版本，若不知道内核版本可用命令 uname -r 进行查看得知。
# set root='hd0,msdos1' 作用是指定主引导程序在哪块磁盘上。
# linux16 /boot/vmlinuz-3.10.0-123.el7.x86_64 ro root=/dev/vda1 作用是指定在/boot/目录下去读取内核模块文件，并进行可读挂载，然后区读取内核文件；注意博主的boot分区的位置是在/分区下面的，所以这里的路径为/boot/，若你的boot分区是单独出来的分区，你就直接写 /vmlinuz-3.10.0-123.el7.x86_64 ro root=/dev/vda1 即可。
# initrd16 /boot/initramfs-3.10.0-123.el7.x86_64.img 作用是指定系统初始化镜像的位置，然后区读取它。
这时系统就能够正常启动了，但是再次重启时电脑还是不能重启，这是因为grub2文件还是被破坏的状态。我们需要用命令 grub2-mkconfig > /boot/grub2/grub.cfg 恢复该文件：
到这里因系统的引导加载程序被破坏所导致的系统不能正常启动的问题才算得到了解决。
三、系统内核模块被破坏导致的系统不能正常启动的解决方案：
内核模块文件的存在位置是在/boot/这个目录下，如下图的阴影部分即为内核文件：
# 若该文件被恶意破坏后导致系统不能重启该怎么解决？请阅读下方。
该文件被删除或破坏，我们进行恢复的思路就是再 copy 一份，所以我们得制作一个和自己系统版本相同的镜像文件； 因为作者是在虚拟机里头做的，所以只需将下载好的镜像文件通过插入光驱而挂载到虚拟机系统上；若是真机，则需要思路也类似，需要制作一个U盘镜像，然后通过调整BIOS的磁盘引导顺序，使系统使用U盘镜像启动。
在做实验之前，我们先删除掉该内核文件：
再重启电脑，这时就不能正常启动了,出现下图的提示：
我们现在开始恢复这个内核模块文件！
# 1.给虚拟机加入镜像文件：
并调整bios引导的磁盘顺序，使镜像文件所在的光驱为bios检测的第一块磁盘：
然后保存设置：
# 2.进入镜像文件的援救模式
这时再次重启电脑，出现如下窗口：
上图的三个选项中，第三条即为援救模式，我们按选择它按回车键进入援救模式；接着就出现了下图的窗口，我们选择第二条条选项后回车：
出现下图界面，我们选择继续（有的系统在这里需要选择数字1进入援救模式），再选择OK：
根据上面三张图可以知道，我们的整个系统被挂载到了 镜像文件援救模式下的 /mnt/sysimage目录下。
# 3.恢复内核文件
进入后的界面如下：
虽然上方已经告诉了我们的系统被挂载到哪个目录下了，为了保险期间，最好用命令 df 查看一下，作者的系统在/dev/vda1这个分区中，经查看，确实是被挂载到了/mnt/sysimage 目录下。
下面我们切换到 /mnt/sysimage 目录下，并在该目录下面创建目录rhel7.0，再将光盘镜像挂载到该目录上：
然后切换到 /rhel7.0/Packages 目录下：
我们要copy的内核文件就在Packages目录下，下来我们将其复制到/mnt 目录下:
接着将该rpm报使用命令 rpm2cpio kernel-3.10.0-123.el7.x86_64.rpm | cpio -id 来解开，解开后ls 看一下，发现有一个boot目录：
现在我们进入该目录，然后找到一个和我们被破坏的内核文件同名的一个文件，再将其复制到我们根目录下的boot下：
这时我们缺失或者被破坏的内核文件就被和它一模一样这个文件所替补了。
最后我们连续用 exit命令退出两次，然后记得调整bios检查引导程序的磁盘顺序：
这时重启，电脑就能正常工作了。
四、linux系统的初始化镜像文件遭破坏后的解决方案：
为了进行实验，我们删除本机的初始化镜像文件：
#和上一个实验一样我们同样需要进入援救模式。
记得再正式实验前挂载和系统版本相同的镜像，以及调整bios检测引导的磁盘顺序。详细步走请翻阅上个实验。
##1. 首先进入援救模式，然后再切入到挂载我们系统的目录 /mnt/sysimage 下面，再切换到/boot/目录下，ls一下发现缺失初始化镜像文件是缺失的：
# 2. 恢复缺失的初始化镜像文件：
使用命令 mkinitrd initramfs-$(uname -r).img $(uname -r) 创建出缺失的初始化镜像文件：
然后使用 exit 命令退出两次重启系统，紧接着调整bios 检测磁盘的顺序，别忘记保存设置哦：
再次重启，系统就能正常启动了。
五、当MBR（主引导记录）的前446字节的引导程序遭到破坏导致系统不能正常启动的解决策略：
我们先看一下引导程序在哪块磁盘上,在vda这块磁盘上有个星号，星号上方是boot，这说明主引导程序在该磁盘上：
下面我们破坏掉该磁盘的前446字节的数据：
这时重启我们的系统就会发现系统卡在如下图的界面，不能正常启动：
这时我们依旧调整bios检测磁盘的顺序，然后进入挽救模式，再切换到挂载我们系统的目录 /mnt/sysimage 下面。
最后输入命令：grub2-install /dev/vda 来安装缺失的446字节的引导程序：
安装成功后，输入两次exit命令退出挽救模式。再调整bios检测磁盘的顺序，记得保存设置：
再次重启系统就能正常使用了。
本篇博文到这里就结束了，因为读者是初学者，所以文章内容可能会有很多错误或者漏洞，若您发现请务必提出指正，谢谢！