O primeiro passo para diagnosticar uma inicialização lenta é observar a saída de dmesg . dmesg exibe o conteúdo do buffer de anel do kernel, que contém mensagens de status registradas pelo kernel mais ou menos desde o momento em que o controle é passado para o kernel do Linux até o ponto em que o daemon syslog assume as tarefas de registro.
Para obter a saída do dmesg em um arquivo para facilitar a navegação, faça dmesg > dmesg.txt . Agora dmesg.txt no seu diretório atual contém o log do kernel.
Lendo o dmesg: Toda linha de saída do dmesg começa com uma sequência como [ 0.106607] . Este é um timestamp no formato "T-plus": é o número de segundos desde o instante em que o kernel foi iniciado.
Para identificar sua lentidão, procure um ponto em que o timestamp "salte" muito de uma linha para a próxima (dica: você também pode usar dmesg -d para obter o dmesg para imprimir a diferença de tempo de um timestamp para o próximo entre colchetes angulares após o registro de data e hora):
[ 3.201806] usb 2-4: >New USB device strings: Mfr=2, Product=3, SerialNumber=4
[ 3.201810] usb 2-4: >Product: Android
[ 3.201813] usb 2-4: >Manufacturer: Android
[ 3.201816] usb 2-4: >SerialNumber: 00093f054d0a2f
[ 43.254818] EXT4-fs (sda5): orphan cleanup on readonly fs
[ 43.254827] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 10747985
[ 43.254879] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 10748275
[ 43.254892] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 10748394
Aqui vemos um salto de T + 3 segundos para T + 43 segundos, o que significa que por 40 segundos o kernel não estava registrando nada, e presumivelmente girando seus polegares esperando que algo acontecesse. Isso é logo depois que é reconhecido um dispositivo Android conectado, por isso, para começar, podemos querer ter esse dispositivo Android desconectado durante a inicialização. Isso pode ser uma pista falsa - o atraso pode ser causado pela limpeza do sistema de arquivos que está acontecendo a seguir.
Isso é seguido em breve por:
[ 43.254959] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 10748175
[ 43.254969] EXT4-fs (sda5): 8 orphan inodes deleted
[ 43.254970] EXT4-fs (sda5): recovery complete
[ 52.161162] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
[ 451.530476] Adding 51097596k swap on /dev/sda2. Priority:-1 extents:1 across:51097596k
[ 451.540572] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 455.117113] udevd[430]: starting version 175
[ 458.734692] lp: driver loaded but no devices found
Uau, uma lacuna de T + 52 segundos para T + 451 segundos. Percebemos que a última coisa que acontece antes do atraso é o sistema de arquivos que está sendo montado.
Uma pequena pesquisa (fazer uma busca no Google por um sistema de arquivos montado com 'slow boot dmesg' com modo de dados ordenados "') resulta em uma vantagem promissora: um bug não corrigido pertencente a udev que se refere a uma longa espera na inicialização logo após esta mensagem!
Ao navegar por esse segmento, parece que a solução alternativa foi estabelecido:
Consiste em adicionar um parâmetro --noudevsync ao comando vgchange em /lib/udev/rules.d/85-lvm2.rules. Então regenerando o initramfs com update-initramfs -u
Então, faremos algo assim:
sudo nano /lib/udev/rules.d/85-lvm2.rules
Encontre o trecho que parece com /sbin/lvm vgchange -a y e altere para ler /sbin/lvm vgchange --noudevsync -a y . Pode ser necessário acrescentar a mesma opção à chamada /sbin/lvm vgscan .
Agora, faça sudo update-initramfs -u e reinicialize quando for bem-sucedido.