web-dev-qa-db-fra.com

Le noyau Xubuntu 18.04 met longtemps à démarrer

Après la mise à niveau à partir de 17h10, le temps de démarrage est plus long. Au début, cela a pris plus de 5 minutes. dmesg a révélé que le coupable était un lecteur de disquette inexistant, que le noyau avait essayé de trouver.

Supprimant rapidement cela, les 5 minutes ont été ramenées à environ 40 secondes, ce qui, selon moi, est encore plus long qu’il ne l’avait fallu avant la mise à jour. Lancer à nouveau dmesg indique qu'il faut 30 secondes pour monter un système de fichiers ( sortie complète ), avec le message suivant:

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

Je démarre à partir d'un disque SSD, avec deux autres disques durs branchés, dont l'un est formaté en ext4, mais ne contient aucune donnée système. Je présume que c'est le SSD. Pendant ces 30 secondes, aucun texte n'est affiché, ni splash, juste un écran vide.

Maintenant, j’ai dit que c’est plus lent qu’avant la mise à jour, parce que je n’ai pas les heures exactes, ma première question est la suivante: est-il normal de prendre 30 secondes pour monter un système de fichiers, et si non, comment en savoir plus sur ce qui pourrait causer le retard?

EDIT 1:

Activer ou désactiver le swap n'a aucun effet

En attendant, j'ai également installé un autre disque dur dans mon ordinateur. Il semble que cela ait encore prolongé mon temps de démarrage d'environ 10 secondes, une autre ligne apparaissant dans la sortie dmesg, juste avant le délai de 30 secondes susmentionné:

[    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 blame résultats sont ici

entre-temps, après plusieurs redémarrages, les lignes dmesg que j’ai blâmées ci-dessus ont changé leur temps ainsi:

[    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)

Je vais faire quelques redémarrages pour savoir si cela change de façon aléatoire ou reste identique (le bloc de code lors de la première édition est celui du premier démarrage après l'insertion du disque dur supplémentaire).

EDIT 2.5: le random: crng init done apparaît généralement à l’heure indiquée dans l’édition 1, rarement comme dans l’édition 2. Il semble être ... aléatoire.

bootxubuntu18.04
7
Jes Wanson

J'ai eu le même problème. Pendant les messages de démarrage, il était indiqué que le délai d'attente du périphérique de reprise était dépassé. Archivez /etc/initramfs-tools/conf.d/resume s'il y a un UUID dans celui-ci comme RESUME=some-uuid, supprimez-le et remplacez-le par "none" pour être RESUME=none. Après cela, lancez Sudo update-initramfs -uk all et ça devrait aller.

12
Alex

J'ai eu ce problème à plusieurs reprises, et ma solution fonctionne dans toutes les situations.

Lorsque vous exécutez dsmeg, l’erreur s’affiche:

[    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)

La solution consiste à:

Commencez par comparer votre fstab et votre 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$

Comme vous pouvez le constater, mon swap/dev/sda7 a un UUID différent dans fstab que dans blkid. Ceci était, dans mon cas, causé par une autre installation de Linux qui repartit le swap et provoquait la modification de l'UUID. Le délai de démarrage est dû au fait que le système tente de trouver le nouvel UUID du swap. Pour résoudre ce problème, copiez simplement l'UUID dans blkid qui ne correspond pas au fichier fstab, puis enregistrez.

Si, après le redémarrage, l'erreur de démarrage est toujours présente, vous devez également modifier votre fichier initramfs.conf.

Faites ceci par:

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

Ensuite, en créant un nouveau fichier ou en modifiant le fichier de reprise actuel, écrivez sur la première ligne RESUME = UUID = << UUID of swap >>

Par exemple, le mien ressemble à

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

Ensuite, exécutez la commande ci-dessous pour mettre à jour votre fichier initramfs.

#Sudo update-initramfs -u

Puis redémarrez. L'erreur aura disparu.

4
Andrew

Au démarrage, le noyau attend les mouvements de la souris pour initialiser le générateur de nombres aléatoires. Messages du noyau au démarrage:
Sudo dmesg | less

Le problème:
kernel: random: crng init done

La solution:
Sudo apt install haveged
Sudo systemctl enable haveged

1
virusmxa

J'ai constaté une augmentation similaire du temps de démarrage et, après avoir enquêté avec dmesg et systemd-analyze blame, le coupable semblait être random: crng init

Le problème semble être pas assez d'entropie lors du démarrage à partir du SSD pour l'initialisation. Cette hypothèse semble être confirmée car remuer la souris pendant le démarrage réduit le temps de démarrage d’environ 2 minutes à presque ce qu’il était auparavant.

1
Jay