web-dev-qa-db-fra.com

Démarrage lent avec SSD et LVM lors de la nouvelle installation du 18.04

Ma première installation n'incluait pas LVM et prenait environ 15 secondes après le démarrage du BIOS. Ma deuxième installation incluait LVM et prenait environ 45 secondes après le démarrage du BIOS. Après beaucoup de recherches sur Google, le consensus semble être que c'est un bogue dans lequel choisir LVM tout en utilisant "certains" disques SSD lors de l'installation causera un long démarrage tant que le système ne cherchera pas et ne trouvera pas de fichier d'échange. Le délai d'attente est de 30 secondes. Quelqu'un a-t-il trouvé un moyen de contourner ce problème?

bootlvm
1
wirebender

Disclaimer: au moment d'écrire ces lignes, je n'ai pas assez de réputation pour commenter d'autres réponses, je dois donc en entrer une nouvelle (principalement comme référence pour moi-même)

J'ai eu un problème similaire sur une nouvelle installation Ubuntu, avec une installation en mode nu démarrant dans environ 15 secondes, alors que le démarrage d'une installation LVM prenait environ 50 secondes (avec une pause d'environ 30 secondes sur un écran noir).

Un premier appel à Sudo systemd-analyze blame a indiqué que j'avais un autre problème:

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

Que j'ai pu résoudre grâce à cet autre Q & A: Long délai de démarrage sur l'écran de chargement/démarrage d'Ubuntu après une mise à niveau régulière sur une installation SSD propre (18.04) en installant rng-tools et en définissant HRNGDEVICE=/dev/urandom en tant que source d'entrée pour des données aléatoires dans /etc/default/rng-tools.

Cela a résolu le problème de l'entropie snapd:

$ 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.
  ....

Mais le noyau prenait toujours environ 35 ans alors je suis passé par la méthode "Idiot Proof" de nils-fenner , cela ne fonctionnait pas au début, mais après avoir été mélangé à la première solution de Arni et David J'ai finalement réussi à réduire le temps de départ à ~ 10 secondes.

Donc, pour (ma propre) référence, voici ma version d'un chemin sûr pour résoudre le problème:

 $ 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

Cela a fait le tour pour moi. HTH.

1
Bruno Sinou

Essayez l’une des méthodes suivantes ou les deux.

Première méthode

Vérifiez combien de temps dure le démarrage du noyau en ouvrant un terminal et en tapant:

systemd-analyze

Le wait-for-root dans /usr/share/initramfs-tools/scripts/local expire après une expiration de 30 secondes (valeur d'inactivité). La variable dev_id reçoit la valeur de RESUME qui est définie à /etc/initramfs-tools/conf.d/resume. Cet UUID affecté à RESUME est l'UUID de la partition de swap LVM. Affectez le chemin d'accès au fichier de périphérique de la partition d'échange LVM à RESUME et utilisez wait_for_udev au lieu de wait-for-root.

Pour ce faire, tapez (dans le terminal):

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

Une fois cela terminé, tapez:

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

Recréez initrd et redémarrez le système.

Sudo update-initramfs -u

Une fois cela terminé, tapez:

Sudo reboot

Le temps de démarrage du noyau devrait être plus rapide. Vérifiez en tapant:

systemd-analyze

Vous pourrez également utiliser l'hibernation après cela.

( Source )

Deuxième méthode

Accédez à /etc/initramfs-tools/conf.d/

Faites un clic droit sur "CV" et choisissez Modifier en tant qu'administrateur . Changer la ligne

RESUME=UUID=<WHATEVER YOUT NUMBER IS>

(e. g. RESUME=UUID=67b3fe6f-1ec4-413f-8c5a-1136bc7f3270) to:

RESUME=none

Maintenant ouvrez un terminal et tapez:

Sudo update-initramfs -u

Une fois cela terminé, tapez:

Sudo reboot

Le temps de démarrage du noyau devrait être plus rapide. Vérifiez en tapant:

systemd-analyze

( Source )

1
Arni

On dirait que la deuxième façon décrite ci-dessus ne fonctionne pas en général. Aussi, je recommande un peu plus "idiot proof" pour éviter de remplacer accidentellement l'UUID de swap.

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

Maintenant, nous pouvons simplement basculer dans les deux sens en renommant les deux fichiers.

0
Nils Fenner