Inicialização lenta com SSD e LVM na nova instalação do 18.04

1

Minha primeira instalação não incluiu o LVM e levou cerca de 15 segundos após a inicialização do BIOS. Minha segunda instalação incluiu o LVM e levou cerca de 45 segundos após a inicialização do BIOS. Depois de muita pesquisa no Google, o consenso geral parece ser que este é um bug no qual escolher o LVM enquanto estiver usando SSDs "certos" durante a instalação causará uma longa inicialização enquanto o sistema procura e não encontra um arquivo de troca. O tempo limite é de 30 segundos. Alguém encontrou um trabalho para isso?

    
por wirebender 17.05.2018 / 18:16

3 respostas

1

Tente um dos dois métodos a seguir, ou ambos.

Primeiro método

Verifique por quanto tempo o tempo de inicialização do kernel é abrindo um terminal e digitando:

systemd-analyze

O wait-for-root em /usr/share/initramfs-tools/scripts/local expira depois de expirar 30 segundos (valor do descanso). A variável dev_id recebe o valor de RESUME , que é definido em /etc/initramfs-tools/conf.d/resume . Este UUID que é atribuído a RESUME é o UUID da partição swap LVM. Atribua o caminho do arquivo de dispositivo da partição swap do LVM para RESUME e use wait_for_udev em vez de wait-for-root .

Para fazer isso, digite (no terminal):

sudo sed -e 's/^RESUME=/#RESUME=/g' \
   -i /etc/initramfs-tools/conf.d/resume

Depois disso, digite:

echo "RESUME=/dev/mapper/ubuntu--YOUR FLAVOR OF UBUNTU HERE--vg-swap_1" | \
sudo tee -a /etc/initramfs-tools/conf.d/resume

Recrie o sistema initrd e reboot.

sudo update-initramfs -u

Depois disso, digite:

sudo reboot

O tempo de inicialização do kernel deve ser mais rápido. Verifique digitando:

systemd-analyze

Você também poderá usar a hibernação depois disso.

( Fonte )

Segundo método

Navegue até /etc/initramfs-tools/conf.d/

Clique com o botão direito do mouse em "currículo" e escolha Editar como administrador . Mude a linha

RESUME=UUID=<WHATEVER YOUT NUMBER IS>

(por exemplo, RESUME=UUID=67b3fe6f-1ec4-413f-8c5a-1136bc7f3270 ) para:

RESUME=none

Agora abra um terminal e digite:

sudo update-initramfs -u

Depois disso, digite:

sudo reboot

O tempo de inicialização do kernel deve ser mais rápido. Verifique digitando:

systemd-analyze

( Fonte )

    
por Arni 19.05.2018 / 06:49
1

Disclaimer: no momento da escrita, eu não tenho reputação suficiente para comentar outras respostas, então eu devo inserir um novo (principalmente como uma referência para mim)

Eu tive um problema parecido em uma nova instalação do Ubuntu, com a instalação bare-metal em ~ 15s enquanto a inicialização em uma instalação LVM levou ~ 50s (com uma pausa de cerca de 30s em uma tela preta).

Uma primeira chamada para sudo systemd-analyze blame apontou que eu tinha outro problema:

$ sudo systemd-analyze blame
     40.699s snapd.seeded.service
     ...

Que eu consegui resolver graças a este outro Q & A: Longo atraso de inicialização na tela de carregamento / splash do Ubuntu seguindo dist-upgrade regular na instalação limpa do SSD (18.04) instalando rng-tools e definindo HRNGDEVICE=/dev/urandom como fonte de entrada para dados aleatórios em /etc/default/rng-tools .

Isso resolveu o problema da entropia instantânea:

$ sudo journalctl -u snapd.seeded.service --since today
  -- Logs begin at Tue 2018-08-21 18:22:53 CEST, end at Tue 2018-08-21 19:40:09 CE
  # Before: ~40s
  Aug 21 18:22:54 zen systemd[1]: Starting Wait until snapd is fully seeded...
  Aug 21 18:23:36 zen systemd[1]: Started Wait until snapd is fully seeded.
  Aug 21 18:50:18 zen systemd[1]: Stopped Wait until snapd is fully seeded.   
  -- Reboot --
  # After: <1s
  Aug 21 18:51:19 zen systemd[1]: Starting Wait until snapd is fully seeded...
  Aug 21 18:51:19 zen systemd[1]: Started Wait until snapd is fully seeded.
  ....

Mas o kernel ainda demorou ~ 35s para começar, então eu passei pelo modo "Idiof-prova" de nils-fenner , ele não funcionou no começo, mas depois de misturar com a primeira solução de Arni e David finalmente consegui baixar o tempo de início para ~ 10s.

Portanto, para referência (minha), aqui está a minha versão de um caminho seguro para resolver o problema:

 $ cd <whatever back up folder on your machine>
 # backup initial config
 $ cp /etc/initramfs-tools/conf.d/resume .

 # Retrieve the correct path to the swap partition (for manually configured LVMs)
 $ sudo fdisk -l

   ... some partitions

   Disk /dev/mapper/vg_zen-uswap: 4 GiB, 4294967296 bytes, 8388608 sectors
   Units: sectors of 1 * 512 = 512 bytes
   Sector size (logical/physical): 512 bytes / 512 bytes
   I/O size (minimum/optimal): 512 bytes / 512 bytes

   ... some more partitions

 # Update the "resume" file with the new path
 # Caution "vg_zen-uswap" is for *my* machine only :)
 $ echo "RESUME=/dev/mapper/vg_zen-uswap" | sudo tee /etc/initramfs-tools/conf.d/resume
   RESUME=/dev/mapper/vg_zen-uswap   

 # Recreate initrd
 $ sudo update-initramfs -u 
   update-initramfs: Generating /boot/initrd.img-4.15.0-32-generic

 # reboot

Isso fez o truque para mim. HTH.

    
por Bruno Sinou 21.08.2018 / 20:42
0

Parece que a segunda maneira descrita acima não funciona em geral. Também recomendo um pouco mais de "idiot proof" para evitar acidentalmente substituir o UUID de troca.

sudo -i    #become root
cd /etc/initramfs-tools/config.d
mv resume resume.uuid
echo "RESUME=/dev/mapper/YOUR UBUNTU FLAVOUR HERE--vg-swap_1" > resume
#Example: echo "RESUME=/dev/mapper/lubuntu--vg-swap_1" > resume

update-initramfs -uk all
sync && reboot

Agora podemos simplesmente alternar entre os dois arquivos.

    
por Nils Fenner 10.07.2018 / 06:41