Fedora-Fr

Valdes · 2012-07-28T10:29:30+00:00

Bonjour à tous. J'ai remarqué que depuis que je suis sous f17 (et donc que j'utilise Grub2), le boot met un certain temps lorsqu'il est écrit "loading initi...

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Grub2 : "loading initial ramdisk" qui rame...

Valdes

Le 3.4. Je suis en train de mettre à jour vers le 3.5.
Je vous tiens au courant dès que la MAJ est faite.
Merci du tuyau 😉

Edit : Attends, on a déjà le 3.5 ?! Il est sorti y'a une semaine !
Cette réactivité m'impressionne !

Valdes

Non toujours pareil. Gros temps mort au boot.
C'est une bonne idée de virer tout le bordel à la ligne GRUB_CMDLINE_LINUX ou pas ?
Je pense que non...

Valdes

Bon alors première avancée : j'ai viré

rd.lvm.lv=vg_valhost/lv_swap rd.md=0 rd.dm=0 SYSFONT=True rd.lvm.lv=vg_valhost/lv_root rd.luks=0

de la ligne

GRUB_CMDLINE_LINUX="rd.lvm.lv=vg_valhost/lv_swap rd.md=0 rd.dm=0 SYSFONT=True rd.lvm.lv=vg_valhost/lv_root rd.luks=0  KEYTABLE=fr-latin9 LANG=en_US.UTF-8 pcie_aspm=force quiet"

Et du coup, le passage "loading initial ramdisk" prend 1 seconde. Ce qui est BIEN mieux que ce que j'avais.
Sauf que je sais pas ce que ça enlève. Pourtant, mon système a l'air de marcher tout pareil...

chepioq

Valdes wrote:
J'ai un milliard de lignes comparé à toi ! WTF?!

C'est vraiment bizarre cette affaire ! Et je trouve rien sur le net...

J'ai plus de ligne que cela, j'ai juste mis la partie correspondante à celle de ton post initial...

GRUB_CMDLINE_LINUX="rd.lvm.lv=vg_valhost/lv_swap rd.md=0 rd.dm=0 SYSFONT=True rd.lvm.lv=vg_valhost/lv_root rd.luks=0  KEYTABLE=fr-latin9 LANG=en_US.UTF-8 pcie_aspm=force quiet"

C'est vrai que cette ligne est longue, comparée à la mienne, cela est peut-être du au fait que tu es en LVM et moi non....

Valdes

Bon ben ça a l'air de bien marcher en virant la ligne. Mon LVM fonctionne à priori bien.
Personne ne saurait à quoi sert

rd.lvm.lv=vg_valhost/lv_swap rd.md=0 rd.dm=0 SYSFONT=True rd.lvm.lv=vg_valhost/lv_root rd.luks=0

nouvo09

Tu dois pouvoir trouver ces infos dans la doc du noyau:

/usr/share/doc/kernel-doc-X.X.X.X/Documentation

Valdes

Je n'ai pas ce dossier. Je vais essayer de le trouver ailleurs.

nouvo09

Tu as installé le paquet kernel-doc ?

Valdes

Je viens de le faire, mais j'avoue ne pas trop savoir où regarder... Il y a des centaines de fichiers...

CanalGuada

Salut,

Tu peux trouver des explications dans les pages du manuel de dracut.

$ man dracut.cmdline

Tu devrais pouvoir les supprimer mais ça ne te fera clairement pas gagner du temps vu leur utilité :-D

Valdes

Merci CanalGuada !

Du coup :
rd.lvm.lv=vg_valhost/lv_swap : permet de n'activer que le volume SWAP
rd.md=0 : désactive la détection RAID MD
rd.dm=0 : désactive la détection RAID DM
SYSFONT=True : charge le jeu de caractères "True" (qui n'existe pas). Ça expliquerait les erreurs que j'ai au boot à ce propos.
rd.lvm.lv=vg_valhost/lv_root : permet de n'activer que le volume root
rd.luks=0 : permet de désactiver la recherche de LUKS machin chose

En gros : je peux tout virer sans souci.

Merci à vous tous, mon problème est résolu 😉

hiker

Même symptome, même remède et ça marche. Merci pour cette investigation.
++

Valdes

Ouais ben en fait ça marche que dalle après une update... C'est même presque plus lent qu'avant...
Zut !

Valdes

Bon je déterre ce topic pour vous faire part d'une étrangéité : depuis que j'ai mis à jour le kernel, le boot est redevenu aussi lent qu'avant (pourtant, les lignes que j'avais enlevé de /etc/default/grub ne sont pas revenues...) ; par contre, quand je fais 'e' dans Grub2 pour arrêter le démarrage et passer en mode Édition, que j'attends un peu et que je fais F10 pour booter, je n'ai plus ce temps d'attente et le reste du système démarre à fond la caisse. Comme si un timer était présent dans Grub2... C'est assez bizarre.

Quelqu'un aurait une idée de où chercher pour trouver la cause du problème (je ne trouve rien dans dmesg ni dans /var/log/messages) ?

chepioq

Il y a en effet un timer dans grub, plus exactement dans /etc/default/grub , c'est la ligne « GRUB_TIMEOUT=5 » chez moi.
C'est la valeur par défaut lors de l'installation, et je ne pense pas que tu l'ai changé...

Valdes

Non ça n'a strictement rien à voir. C'est d'ailleurs la première chose que je change après une install.

GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=0
GRUB_CMDLINE_LINUX="KEYTABLE=fr-latin9 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 pcie_aspm=force quiet"

Je pensais plus à un timer qui n'aurait rien à faire ici. Mais ça ne doit pas être un timer étant donné que personne d'autre n'a l'air d'avoir ce problème...

chepioq

Il faudrait peut-être regarder le lancement des services.
Que donne :

systemd-analyze blame

Valdes

Rien à voir non plus :

[Val@valhost ~]$ systemd-analyze blame
  2777ms rc-local.service
  2157ms mysqld.service
   526ms httpd.service
   400ms udev-settle.service
   386ms NetworkManager.service
   355ms akmods.service
   267ms avahi-daemon.service
   224ms nfs-lock.service
   198ms ip6tables.service
   193ms iptables.service
   179ms auditd.service
   178ms chronyd.service
   170ms mcelog.service
   167ms acpid.service
   151ms abrt-vmcore.service
   151ms systemd-logind.service
   149ms fedora-storage-init.service
   147ms abrt-ccpp.service
   141ms irqbalance.service
   122ms udev-trigger.service
   110ms dbus.service
    98ms systemd-readahead-replay.service
    87ms bluetooth.service
    86ms systemd-readahead-collect.service
    86ms systemd-user-sessions.service
    80ms fedora-storage-init-late.service
    77ms fedora-loadmodules.service
    70ms lvm2-monitor.service
    68ms dev-hugepages.mount
    62ms sys-kernel-debug.mount
    62ms udev.service
    58ms media.mount
    55ms systemd-vconsole-setup.service
    54ms spice-vdagentd.service
    53ms fedora-readonly.service
    42ms accounts-daemon.service
    40ms colord.service
    36ms systemd-sysctl.service
    36ms rpcbind.service
    35ms udisks2.service
    33ms systemd-remount-fs.service
    33ms dev-mqueue.mount
    31ms boot.mount
    24ms colord-sane.service
    23ms fedora-wait-storage.service
    11ms wpa_supplicant.service
     8ms upower.service
     8ms sys-kernel-config.mount
     7ms rtkit-daemon.service
     3ms sys-fs-fuse-connections.mount

C'est vraiment Grub2 qui me prend du temps...

chepioq

je ne sais pas si tu l'as déjà fait, mais essaye un :

yum reinstall grub2

Valdes

C'est une idée à laquelle je n'avais pas du tout pensé.
Je teste ça desuite.

« Page précédente Page suivante »