O kernel do Xubuntu 18.04 demora muito para inicializar


10

Após a atualização da 17.10, experimentei tempos de inicialização mais longos. No início, levou mais de 5 minutos. dmesgrevelou que o culpado era uma unidade de disquete inexistente, que o kernel tentou encontrar.

Removendo prontamente isso, os 5 minutos foram reduzidos para cerca de 40 segundos, o que eu acho que ainda é mais do que levou antes da atualização. A execução dmesgnovamente mostra que são necessários 30 segundos para montar um sistema de arquivos ( saída completa ), com a seguinte mensagem:

[   36.362834] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

Estou inicializando a partir de um SSD, com dois outros discos rígidos conectados, um dos quais está formatado em ext4, mas não contém dados do sistema. Presumo que este seja o SSD. Durante esses 30 segundos, nenhum texto é exibido, nem respingo, apenas uma tela em branco.

Agora, eu disse que parece mais lento do que antes da atualização, porque não tenho horários exatos de antes, então minha primeira pergunta é: é normal levar 30 segundos para montar um sistema de arquivos e, se não, como descobrir mais sobre o que poderia estar causando o atraso?

EDIT 1:

Ativar ou desativar a troca não tem efeito algum

Enquanto isso, eu também instalei outro disco rígido no meu computador. Parece ter prolongado ainda mais meu tempo de inicialização em 10 segundos, com outra linha aparecendo na dmesgsaída, logo antes do atraso de 30 segundos acima mencionado:

[    3.312351] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   17.169519] random: crng init done
[   51.611617] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

EDIT 2:

systemd-analyze blameos resultados estão aqui

Enquanto isso, após várias reinicializações, as dmesglinhas que culpei acima mudaram seus tempos da seguinte maneira:

[    3.348384] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   34.091886] random: crng init done
[   36.488321] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

Vou fazer algumas reinicializações para descobrir se isso muda aleatoriamente ou permanece o mesmo (o bloco de código na primeira edição é da primeira inicialização depois de inserir o disco rígido extra).

EDIT 2.5: random: crng init donegeralmente aparece nos tempos mostrados na edição 1, raramente na edição 2. Parece ser ... aleatório.


Você pode executar systemd-analyze blamee editar sua pergunta para incluir a saída deste comando?
Vidarlo 29/04

Já o executei antes e a soma dos resultados ficou abaixo de 8 a 9 segundos, então achei que seria irrelevante. Eu adicionei os resultados.
precisa saber é o seguinte

Respostas:


17

Eu tive o mesmo problema. Durante as mensagens de inicialização, o tempo limite era excedido, aguardando a retomada do dispositivo. Faça o check-in /etc/initramfs-tools/conf.d/resumese houver UUID, como RESUME=some-uuidremova o uuid e substitua por "none" RESUME=none. Depois dessa corrida sudo update-initramfs -uk all, deve ser bom ir.


2
Finalmente! Isso resolveu um problema em que estive pesquisando por inúmeras horas - agora reduzia pela metade o tempo de inicialização. Informações úteis sobre o que este currículo é sobre: askubuntu.com/questions/1057556/...
Casperrw

11
isso parece funcionar para mim também, tenho cerca de 38 segundos de inicialização antes disso e 8 segundos depois.
Pablo Pazos

O problema apareceu para mim após a atualização da distribuição de 16.04 para 18.04 - e esse método também remove o atraso de 30 anos.
Bonlenfum 01/09/19

5

Eu tive esse problema várias vezes e minha solução funciona em todas as situações.

Ao executar o dsmeg, o erro aparece como:

[    6.382044] random: crng init done
[    6.382048] random: 7 urandom warning(s) missed due to ratelimiting
[   32.162934] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)

A solução é:

Primeiro compare seu fstab e blkid:

$ blkid
/dev/sda1: UUID="C0C0-7641" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="1085d848-f8b9-45e2-a6be-087acb32a820"
/dev/sda3: LABEL="Windows" UUID="8662302C623022FB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="de399a3e-c832-4dca-a09d-f65789425b89"
/dev/sda4: LABEL="Windows RE tools" UUID="2262513962511341" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="18feb4e1-5770-4e13-92b8-bb8ba8005536"
/dev/sda5: UUID="81a474ab-98bf-4d40-b03e-e5e647163d7e" TYPE="ext4" PARTLABEL="Arco Linux" PARTUUID="3759200f-6317-4487-8b10-3a0140c67bd5"
/dev/sda6: LABEL="rootMX17" UUID="7bae9e4d-61fa-4187-b11f-517c799f7c94" TYPE="ext4" PARTLABEL="MX Linux" PARTUUID="417c8cbd-11b7-4fe6-9b15-ac9082d74460"
/dev/sda7: UUID="d9539219-1c29-468f-bbd0-106663fdef59" TYPE="swap" PARTLABEL="Swap" PARTUUID="fefe3061-bf7b-4a26-8c20-08e209acc28e"



$ sudo nano /etc/fstab


# /etc/fstab: static file system information
#
# Created by make-fstab on Mon Nov 19 17:10:30 EST 2018

# <file system>                            <mount point>                               <type>     <$

#-> /dev/sda6  label=rootMX17
UUID=7bae9e4d-61fa-4187-b11f-517c799f7c94  /                                           ext4       d$
#-> /dev/sda1
UUID=C0C0-7641                             /boot/efi                                   vfat       d$
#-> /dev/sda7
UUID=42e5a9cd-b6e1-4d57-9a3a-2ad910862579  swap                                        swap       d$

Como você pode ver, meu swap em / dev / sda7 tem um UUID diferente no fstab do que no blkid. Isso foi, no meu caso, causado por outra instalação do linux reparticionando a troca e causando a alteração do UUID. O atraso de inicialização é causado pelo sistema tentando encontrar o novo UUID da troca. Para corrigi-lo, basta copiar o UUID em blkid que não corresponde ao arquivo fstab e salvar.

Se após a reinicialização o erro de inicialização ainda estiver lá, você precisará editar adicionalmente o arquivo initramfs.conf.

Faça o seguinte:

$ sudo nano  /etc/initramfs-tools/conf.d/resume

Em seguida, criando um novo arquivo ou editando o arquivo de currículo atual, escreva na primeira linha RESUME = UUID = << UUID de troca >>

Por exemplo, o meu parece

RESUME=UUID=d9539219-1c29-468f-bbd0-106663fdef59

Em seguida, execute o comando abaixo para atualizar seu arquivo initramfs.

#sudo update-initramfs -u

Então reinicie. O erro desapareceu.


1

Eu experimentei um aumento semelhante no tempo de inicialização, e depois de investigar dmesge systemd-analyze blameo culpado parecia estarrandom: crng init

O problema parece não ser entropia suficiente na inicialização do SSD para inicialização. Essa hipótese parece ser confirmada porque mexer muito no mouse durante a inicialização diminui o tempo de inicialização de cerca de 2 minutos para baixo, próximo ao que era antes.


1

Na inicialização, o kernel aguarda os movimentos do mouse para inicializar o gerador de números aleatórios. Mensagens do kernel na inicialização:
sudo dmesg | less

O problema:
kernel: random: crng init done

A solução:
sudo apt install haveged
sudo systemctl enable haveged


0

Eu tive esse problema com o tempo de inicialização lento no ubuntu 19.04 depois de remover a partição swap e criar o arquivo swap.

A saída do dmesg

[    2.220963] hid-generic 0003:1B1C:1B0F.0003: input,hidraw2: USB HID v1.11 Device [Corsair Corsair M45 Gaming Mouse] on usb-0000:00:14.0-1/input2
[   33.321639] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
[   33.407323] systemd[1]: RTC configured in localtime, applying delta of 120 minutes to system time.
[   33.417651] systemd[1]: Inserted module 'autofs4'

Nenhum arquivo de swap no / etc / fstab. Todos os discos / uuids montados estavam corretos.

Eu verifiquei, /etc/initramfs-tools/conf.d/resumemas esse arquivo estava faltando.

Eu apenas corro

sudo update-initramfs -uk all

E agora ele inicializa muito rápido.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.