Ubuntu启动时a start job is running for dev-disk-by延时解决

写在前面：本博客为本人原创，严禁任何形式的转载！本博客只允许放在博客园（.cnblogs.com），如果您在其他网站看到这篇博文，请通过下面这个唯一的合法链接转到原文！

本博客全网唯一合法URL：http://www.cnblogs.com/acm-icpcer/p/8448519.html

我在我写的博客

最全最详细：ubuntu16.04下linux内核编译以及设备驱动程序的编写（针对新手而写）

里面的“虚拟机扩容”这个部分有点问题，本来按照我所描述的步骤去操作是没什么问题的（因为后来我给家里的联想古董一体机安装了linux发现没有出问题），但是可能是第一次给虚拟机挂载硬盘的时候交换区swap没有设置好，导致linux内核不能感知到硬盘交换区的存在，本来不是什么大问题，因为linux默认在90s内如果没有感知到swap交换区就会执行默认引导程序启动操作系统，但是这就使得开机时间增加了90s。这还了得！+90s的续命机会怎么能放弃？于是本文就续命。。。不是，就解决该问题提出解决方案。

　　首先我们可以在开机界面发现linux内核的报错语句：

a start job is running for dev-disk-by uuid <disk-partition-uuid>

　　这就是万恶之源，linux就是在此处被延时了90s，但是这句话看得人半懂不懂，没关系，90s延时过去后下面还有一条不起眼的语句：

Denpendency failed for Swap

　　  之前就是因为没有看见这句最关键的警告所以才一直没有找到解决方法，看到这句话之后，恍然大悟，才知道是交换区出了问题。

　　那么如何解决呢，自然只好到交换区里面去看看了，执行命令：

swapon --show

　　如果你的交换区正常，那么就会是这样：

　　不正常就是这样：

　　也就是说，你执行了查看swap区命令，但是却找不到交换区，也就是说实际上你的操作系统根本没有交换区。这是很麻烦的事情，因为这样的话操作系统内存与虚拟内存的数据交换就是直接进行的，首先，这会拖慢系统吞吐量，因为虚拟内存在硬盘上，无论是ssd还是机械的温彻斯特硬盘，它们的速度都远不敌dram内存的速度快；其次，离开了交换区的缓冲效果，大量数据直接从内存写入硬盘，硬盘会受不了，造成一定的损伤。总之，长远来看，没有交换区这是一个很严重的问题。尤其对于大型服务器来说，这是致命伤，因为如果访问量过大或者服务器遭受了DDoS攻击的话，服务器硬盘很可能会直接烧坏。

　　不过，既然知道了问题所在就好解决了。我们知道，操作系统通过PCB感知进程，通过TCB感知线程，通过JCB感知等待调度的作业，那么操作系统必定会通过一个东东来感知数据交换区，这个东东就是UUID号码。

　　先执行以下命令查看现有的硬盘情况：

mount

　　结果是：

　　上面这是我修复后的结果，如果没有修复我们可以从执行的结果看出swap区并没有挂载。

　　输入以下命令查看操作系统预备给交换区的UUID：

sudo blkid

　　执行后的结果如下图：

　　从第二条信息/dev/sda5可以看到swap区本应该拥有的UUID。

　　查看一下我们挂载硬盘失误后实际产生的UUID：

sudo nano /etc/fstab

　　执行后发现两个UUID不一致，才知道问题出在UUID上。

　　知道了问题那就好办了，更改/etc/fstab文件中swap分区的UUID就可以了。即通过命令打开vim来修改：

sudo vim /etc/fstab

　　切记在此一定要用sudo的权限去修改，因为/etc/fstab文件是系统文件，不使用管理员权限的话只能读而不能写。

　　修改文件内的swap的UUID为刚刚使用命令sudo blkid查看的swap应持有的UUID即可，下图是修改成功的结果：

　　重启操作系统，问题修复。续命+90s。

　　

　　

TZ@home

2018/2/14