A start job is running for dev disk by when Ubuntu starts

write in front: this blog is my original, no reprint in any form! This blog is only allowed to be placed in the blog Garden (. Cnblogs. Com). If you see this blog post on other websites, please go to the original through the only legal link below

the only legal URL of this blog: http://www.cnblogs.com/acm-icpcer/p/8448519.html

I’m on my blog

The most complete and detailed: Linux kernel compilation and device driver writing under Ubuntu 16.04 (for novices)

There is something wrong with the “virtual machine expansion” in . Originally, it was no problem to operate according to the steps I described (because I later installed Linux on Lenovo antique all-in-one machine at home and found that there was no problem), but maybe it was the first time when I attached the hard disk to the virtual machine that swap was not set properly, It’s not a big problem that Linux kernel can’t sense the existence of the hard disk switch area, because Linux is within 90 seconds by default. If it doesn’t sense the swap switch area, it will execute the default boot program to start the operating system, but this will increase the boot time by 90 seconds. That’s too much+ How can 90s give up the chance of life extension?So this article will continue… No, put forward a solution to the problem

first of all, we can find the error statements of Linux kernel in the boot interface:

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

this is the root of all evils. Linux has been delayed for 90 seconds here, but this sentence is not understood. It doesn’t matter. After the 90 seconds delay, there is another unimportant sentence:

Denpendency failed for Swap

before, I didn’t find a solution because I didn’t see the most critical warning. After seeing this sentence, I suddenly realized that there was something wrong with the exchange area

so how to solve this problem?Naturally, we have to go to the exchange area and execute the command:

swapon --show

if your swap area is normal, it will be like this:

abnormal is this:

in other words, you execute the command to view the swap area, but you can’t find the swap area. That is to say, your operating system doesn’t have a swap area at all. This is a very troublesome thing, because in this way, the data exchange between the operating system memory and the virtual memory is carried out directly. First of all, it will slow down the system throughput, because the virtual memory is on the hard disk, whether it is SSD or mechanical Winchester hard disk, their speed is far less than DRAM memory; Secondly, without the buffer effect of the switch area, a large amount of data is written directly from the memory to the hard disk, which will be unbearable and cause certain damage. In short, in the long run, there is no exchange zone, which is a very serious problem. Especially for large servers, this is a fatal injury, because if the access volume is too large or the server is attacked by DDoS, the server’s hard disk is likely to burn out directly

however, now that you know what the problem is, it’s easy to solve it. We know that the operating system perceives processes through PCB, threads through TCB, and jobs waiting to be scheduled through JCB. Then the operating system must perceive the data exchange area through an East, which is the UUID number

first execute the following command to view the existing hard disk:

mount

the result is:

the above is the result of my repair. If not, we can see from the execution result that the swap area is not mounted

enter the following command to view the UUID prepared by the operating system for the switch area:

sudo blkid

The results of implementation are shown in the following figure:

from the second message/dev/sda5, you can see the UUID that the swap area should have

look at the UUID actually generated after we failed to mount the hard disk:

sudo nano /etc/fstab

after execution, it is found that the two UUIDs are inconsistent, and then it is known that the problem lies in the UUID

if you know the problem, it’s easy to do. Just change the UUID of the swap partition in the/etc/fstab file. That is to say, open VIM through command to modify:

sudo vim /etc/fstab

remember to use sudo’s permission to modify here, because /etc/fstab file is a system file, which can only be read but not written without administrator’s permission

modify the UUID of the swap in the file to the UUID that should be held by the swap just viewed with the command sudo blkid. The following figure shows the result of successful modification:

restart the operating system and fix the problem. Life extension + 90s

  

  

[email protected]

2018/2/14

Similar Posts: