GRUB devenu extrêmement lent

Ludox · 08-12-2018 16:30:37

Bonjour, cela fait un petit temps que je n'ai pas fait appel à vos bons services, preuve que ma Debian Stretch (EB Gnome) ne marche pas trop mal.
Depuis quelques semaines le compte à rebours de Grub sur mon Macbook unibody est devenu trèèès lent (avant de passer à la suite), les secondes se comptent, en fait, en dizaines de secondes. Je suis en simple boot et le mac conserve ce qui me semble être un EFIBoot.
Je peux toujours passer immédiatement à la suite en tapant 'enter', mais ce ralentissement me semble étrange.
Quelqu'un aurait-il une idée pour résoudre cette fantaisie de la part de mon PC?

Dernière modification par Ludox (08-12-2018 20:31:32)

melissa6969 · 08-12-2018 21:30:39

je suis pas sûre d'avoir bien compris le problème, mais donne le retour de cette commande stp

cat /etc/default/grub

Ludox · 08-12-2018 21:52:34

Bonsoir Melissa6969,
mon problème n'en n'est peut être pas un, mais je suis curieux. Lorsque l'écran de Grub apparaît il reste quelques secondes (5) avant de passer tout seul à la phase suivante (qui est le chargement du noyau si je comprends bien). Sur mon PC, ces 5 secondes durent beaucoup plus que 5 secondes, alors qu'avant: non. Je me demande si quelque chose ne s'est pas déréglé ou corrompu.
Voici le retour de ta commande:

# If you change this file, run 'update-grub' afterwards to update

# /boot/grub/grub.cfg.

# For full documentation of the options in this file, see:

#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0

GRUB_TIMEOUT=5

GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs

# This works with Linux (no patch required) and with any kernel that obtains

# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)

#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)

#GRUB_TERMINAL=console

# The resolution used on graphical terminal

# note that you can use only modes which your graphic card supports via VBE

# you can see them in real GRUB with the command `vbeinfo'

#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux

#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries

#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start

#GRUB_INIT_TUNE="480 440 1"

melissa6969 · 08-12-2018 22:24:00

oui je voulais m'assurer que le temps de grub était pas anormalement long, donc il est bien de 5 secondes.

c'est donc pas le grub qui est long à se charger, mais le kernel ou les services en arrière plan.

du coup donnes moi le retour de ces commandes
on va voir comme ça, si un service est (anormalement) long à s'initialiser durant la phase de démarrage

systemd-analyze

systemd-analyze blame

systemd-analyze critical-chain

Ludox · 08-12-2018 22:40:58

Merci du coup de main.
pour

systemd-analyze

le retour:

Startup finished in 5.019s (kernel) + 28.347s (userspace) = 33.366s

pour

systemd-analyze blame

le retour:

 9.304s keyboard-setup.service

          7.738s NetworkManager-wait-online.service

          7.024s dev-sda2.device

          6.459s accounts-daemon.service

          4.032s networking.service

          3.832s NetworkManager.service

          3.750s ModemManager.service

          3.120s systemd-logind.service

          3.111s rsyslog.service

          3.111s pppd-dns.service

          3.020s bluetooth.service

          2.661s apt-daily.service

          1.831s systemd-udevd.service

          1.782s avahi-daemon.service

          1.564s systemd-tmpfiles-setup-dev.service

          1.333s linuxlogo.service

          1.267s packagekit.service

          1.074s polkit.service

          1.045s systemd-modules-load.service

           948ms colord.service

           948ms colord.service

          1.045s systemd-modules-load.service

           948ms colord.service

           857ms wpa_supplicant.service

           781ms gdm.service

           775ms rtkit-daemon.service

           715ms speech-dispatcher.service

           680ms systemd-backlight@backlight:nv_backlight.service

           658ms dev-sda3.swap

           573ms sys-kernel-debug.mount

           572ms dev-hugepages.mount

           572ms dev-mqueue.mount

           569ms systemd-remount-fs.service

           427ms systemd-random-seed.service

           419ms systemd-tmpfiles-setup.service

           418ms systemd-timesyncd.service

           359ms systemd-journal-flush.service

           345ms user@117.service

           342ms systemd-udev-trigger.service

           341ms upower.service

           310ms boot-efi.mount

           250ms systemd-journald.service

           243ms systemd-fsck@dev-disk-by\x2duuid-4805\x2d03A9.service

           198ms udisks2.service

           192ms systemd-rfkill.service

           173ms systemd-update-utmp.service

           162ms systemd-sysctl.service

           137ms kmod-static-nodes.service

           124ms systemd-user-sessions.service

           109ms user@1001.service

            87ms systemd-tmpfiles-clean.service

            86ms minissdpd.service

            83ms console-setup.service

            63ms user@1000.service

            24ms alsa-restore.service

             7ms systemd-update-utmp-runlevel.service

             4ms sys-fs-fuse-connections.mount

Pour

systemd-analyze critical-chain

le retour:

The time after the unit is active or started is printed after the "@" character.

The time the unit takes to start is printed after the "+" character.

graphical.target @28.337s

└─multi-user.target @28.337s

  └─minissdpd.service @28.250s +86ms

    └─network-online.target @28.204s

      └─NetworkManager-wait-online.service @20.465s +7.738s

        └─NetworkManager.service @16.631s +3.832s

          └─dbus.service @13.551s

            └─basic.target @13.545s

              └─paths.target @13.545s

                └─cups.path @13.545s

                  └─sysinit.target @13.520s

                    └─systemd-timesyncd.service @13.102s +418ms

                      └─systemd-tmpfiles-setup.service @12.652s +419ms

                        └─local-fs.target @12.624s

                          └─run-user-117.mount @23.524s

                            └─local-fs-pre.target @12.032s

                              └─keyboard-setup.service @2.727s +9.304s

                                └─systemd-journald.socket @2.727s

                                  └─-.mount @2.498s

                                    └─system.slice @2.723s

                                      └─-.slice @2.498s

melissa6969 · 08-12-2018 23:39:51

on voit déjà que t'as plusieurs services qui sont longs à démarrer.

déjà y en a un que tu peux virer sûr et certain, donc tu vas faire ceci

sudo systemctl stop NetworkManager-wait-online.service

et ensuite tu fais un

sudo systemctl disable NetworkManager-wait-online.service

ensuite le service ""keyboard-setup.service"" est anormalement long
chez moi ce même service démarre en 83 ms

donc fais déjà la première manipulation que je t'ai donné, et redémarre ton pc pour voir si il y a un mieux ou pas.

et reposte le retour de la commande (pour comparer si il y a une petite amélioration)

systemd-analyze blame

EDIT :
ne fais pas d'autres manip (pour qu'on puisse comparer si il y a une évolution)
Je sors, on reprendra la suite demain

Dernière modification par melissa6969 (08-12-2018 23:47:03)

raleur · 09-12-2018 09:09:31

melissa6969 a écrit :

je suis pas sûre d'avoir bien compris le problème

Je partage tes doutes. Si j'ai bien compris, la durée réelle écoulée entre chaque seconde restante affichée par le compte à rebours de GRUB est beaucoup plus longue qu'une seconde. Cela n'a donc rien à voir avec le noyau, systemd ni les services qui ne sont pas encore actifs.

Croutons · 09-12-2018 09:32:52

Bonjour
Et dans l'heure du BIOS les secondes ce déroule normalement?

Ludox · 09-12-2018 09:45:01

raleur a écrit :

melissa6969 a écrit :
je suis pas sûre d'avoir bien compris le problème

Je partage tes doutes. Si j'ai bien compris, la durée réelle écoulée entre chaque seconde restante affichée par le compte à rebours de GRUB est beaucoup plus longue qu'une seconde. Cela n'a donc rien à voir avec le noyau, systemd ni les services qui ne sont pas encore actifs.

Bonjour, Raleur tu as effectivement bien cerné mon problème, que je n'ai peut être pas bien expliqué au départ.

Ludox · 09-12-2018 09:55:31

Croutons a écrit :

Bonjour
Et dans l'heure du BIOS les secondes ce déroule normalement?

J'ai essayé cette commande trouvée sur le net:

hwclock

le retour me donne la date et l'heure mais à un instant "i", figé donc. Si je répète la commande rapidement, les secondes semblent changer à un rythme correpondant...à des secondes!
Y a-t-il une commande permettant de voir évoluer en temps réel l'heure du bios?

Croutons · 09-12-2018 10:34:51

Je pensais avant de lancer le système , ouvrir le BIOS avec une touche de fonction
chez moi F10 par exemple, après suivant les marque d'ordi la touche est différente( a voir dans la doc)

Procédure d’accès au BIOS sur Apple MacBook Pro
Entrer dans le bios

Si vous voulez entrer dans le BIOS sur votre ordinateur Apple MacBook Pro, vous devez effectuer un reboot votre machine.

Pendant que l’ordinateur reboot, il va falloir appuyer une touche. En fonction du modèle de votre carte mère, la touche peut être différente.

Pour votre Apple MacBook Pro, nous vous préconisons d’essayer ces touches. Pour être sûr de ne pas rater le bon moment, il faut appuyer de nombreuses fois sur la touche:

La touche F2
La touche Suppr
La touche Echap
La touche F10
La touche F11

Dernière modification par Croutons (09-12-2018 10:37:41)

melissa6969 · 09-12-2018 11:21:23

oui regarder l'heure du bios si elle est correcte.

si t'as un décalage de plusieurs minutes alors la pile du bios est en train de rendre l'âme.
mais j'avoue que je savais pas que ça pouvait impacter sur le temps de chargement du grub, vu que dans le grub, on a pas l'heure, et qu'il liste les partitions systèmes pour trouver le boot et les OS.
mais bon je suis pas une experte en grub ni en bios, ni en matériel, ni en grand chose

Ludox · 09-12-2018 12:41:42

J'ai essayé différentes manières de redémarrer le mac:
- les touches conseillées par Crouton
- la touche C qui est celle préconisée sous osx pour redémarrer sur dvd d'installation
- la touche R comme sur les macpro
- cmd+alt+o+f (pioché sur le net)
- laisser la touche on/off enfoncée jusqu'à clignotement rapide du voyant de démarrage
....
j'atterris inlassablement sur Grub

C'est hypothétique de ma part, mais il m'est impossible de faire un multi boot sur cet appareil, sans que je perde ma Debian (au redémarrage après installation j’atterris sur l'écran de l'EFI boot qui ne me propose que la réinstallation d'OSX par le net), même l'usage d'un live usb m'est interdit. Je me demande donc si cet EFIBoot n'est pas source de verrouillages.

raleur · 09-12-2018 17:32:51

Est-ce que cette lenteur affecte seulement le compte à rebours ou d'autres fonctions de GRUB (déplacement dans les menus, édition d'un entrée de menu [e], invite de commande [c]...) ?

Ludox · 09-12-2018 18:01:39

Non, apparemment cela n'a aucune conséquence, à tout le moins visible, ailleurs. La curiosité m'aiguillonne, c'est pourquoi je vous pose la question ci dessus, comme en même temps je ne comprends pas pourquoi le multiboot m'est impossible, je me dis qu'il y a un point commun: quelque chose qui cloche dans la procédure de démarrage

Ludox · 09-12-2018 23:00:56

melissa6969 a écrit :

oui regarder l'heure du bios si elle est correcte.

si t'as un décalage de plusieurs minutes alors la pile du bios est en train de rendre l'âme.
mais j'avoue que je savais pas que ça pouvait impacter sur le temps de chargement du grub, vu que dans le grub, on a pas l'heure, et qu'il liste les partitions systèmes pour trouver le boot et les OS.
mais bon je suis pas une experte en grub ni en bios, ni en matériel, ni en grand chose

Peu importe ton expertise, elle est meilleure que la mienne
Merci de toutes manières.

melissa6969 · 10-12-2018 13:19:48

Et en + j'ai jamais utilisé de Mac de ma vie.

Alors comment ça fonctionne réellement dans le système efi par exemple j'en sais absolument rien....
Est ce aussi différent qu'un pc portable standard...
Je sais juste que l'installation d'un linux sur certains modèles de Mac relève d'un véritable parcours du combattant

Ludox · 14-12-2018 16:29:14

L'installation ça va (pour Debian), pourvu qu'on essaie pas le multi boot et le multi session sur une machine comme la mienne

Debian-facile

#1 08-12-2018 16:30:37

GRUB devenu extrêmement lent

#2 08-12-2018 21:30:39

Re : GRUB devenu extrêmement lent

#3 08-12-2018 21:52:34

Re : GRUB devenu extrêmement lent

#4 08-12-2018 22:24:00

Re : GRUB devenu extrêmement lent

#5 08-12-2018 22:40:58

Re : GRUB devenu extrêmement lent

#6 08-12-2018 23:39:51

Re : GRUB devenu extrêmement lent

#7 09-12-2018 09:09:31

Re : GRUB devenu extrêmement lent

#8 09-12-2018 09:32:52

Re : GRUB devenu extrêmement lent

#9 09-12-2018 09:45:01

Re : GRUB devenu extrêmement lent

#10 09-12-2018 09:55:31

Re : GRUB devenu extrêmement lent

#11 09-12-2018 10:34:51

Re : GRUB devenu extrêmement lent

#12 09-12-2018 11:21:23

Re : GRUB devenu extrêmement lent

#13 09-12-2018 12:41:42

Re : GRUB devenu extrêmement lent

#14 09-12-2018 17:32:51

Re : GRUB devenu extrêmement lent

#15 09-12-2018 18:01:39

Re : GRUB devenu extrêmement lent

#16 09-12-2018 23:00:56

Re : GRUB devenu extrêmement lent

#17 10-12-2018 13:19:48

Re : GRUB devenu extrêmement lent

#18 14-12-2018 16:29:14

Re : GRUB devenu extrêmement lent

Pied de page des forums