[boot]Bureau lent a charger et fsck chaque démmarage

[YoanMathieu]

Bonjour,
Je suis sous archlinux depuis bientôt une semaine et en fesant des recherche je me suis rendu compte que mon arch prenait plus de temps a booter que d'autre machine moins puissante . Je m'explique:
-Du bouton power au grub 5s
-Du grub au bureau 30s
Sachant que le bureau reste figée sur une page grise avant d'afficher le panel puis de il se charge d'un coup aprés !

Mon pc et un hp-pavillon g6 avec 6giga de ram , carte graphique radeon, et un intel core i5

Voilà ce que donne systemd-analyze

Code : Tout sélectionner

Startup finished in 2.369s (kernel) + 1min 31.057s (userspace) = 1min 33.426s

et voila se que donne systemd-analyze blame

Code : Tout sélectionner

3.371s NetworkManager.service
          2.043s systemd-logind.service
          2.039s alsa-restore.service
          1.404s systemd-vconsole-setup.service
           721ms upower.service
           634ms lightdm.service
           628ms systemd-fsck@dev-disk-by\x2duuid-3208b7f4\x2d0ab6\x2d45df\x2da9
           490ms systemd-remount-fs.service
           485ms sys-kernel-debug.mount
           470ms dev-hugepages.mount
           431ms sys-kernel-config.mount
           427ms dev-mqueue.mount
           402ms tmp.mount
           377ms systemd-udev-trigger.service
           369ms systemd-fsck@dev-disk-by\x2duuid-c5a4079f\x2d37b6\x2d4c39\x2db1
           351ms udisks2.service
           321ms polkit.service
           295ms systemd-rfkill@rfkill1.service
           295ms systemd-rfkill@rfkill0.service
           292ms wpa_supplicant.service
           290ms systemd-sysctl.service
           259ms systemd-tmpfiles-setup-dev.service
           214ms kmod-static-nodes.service
           185ms systemd-backlight@backlight:acpi_video0.service
           178ms systemd-backlight@backlight:acpi_video1.service
           157ms systemd-journal-flush.service
           150ms boot.mount
           150ms systemd-update-utmp.service
           106ms systemd-random-seed.service
            78ms systemd-rfkill@rfkill2.service
            67ms home.mount
            67ms systemd-backlight@backlight:intel_backlight.service
            66ms systemd-tmpfiles-setup.service
            49ms systemd-udevd.service
            44ms rtkit-daemon.service
            43ms user@1000.service
            42ms systemd-tmpfiles-clean.service
            16ms systemd-user-sessions.service
             1ms sys-fs-fuse-connections.mount

Qu'est ce que je pourrai désactiver au démmarage ? je précise que je suis sous xfce4

[mimile]

Salut,

J'ai le même problème que toi sur un PC très comparable au tien (fait main) : 4 Go RAM, intel i core 5, carte graphique nVidia).

J'ai aussi des temps de latence qui font que mon bureau (Gnome) n'apparaît qu'environ une minute après avoir sélectionné Arch dans le panneau d'affichage de Grub (je suis en triple boot : W7, Debian Wheezy et Archlinux).

J'ai posté sur ce forum et d'autres sans obtenir de solution.

En ce qui concerne le fsck qui se fait à chaque boot, tu peux exécuter :

Code : Tout sélectionner

# tune2fs -c 20 /dev/sda1

De cette façon, fsck ne s'exécutera qu'après 20 boot.

un peu de lecture à ce sujet ici : https://wiki.archlinux.org/index.php/fsck

Si tu as un second disque, tu peux évidemment exécuter cette même commande en indiquant son nom (/dev/sdb1 par exemple).

[YoanMathieu]

Donc tu as toujours le même problème pour le chargement de bureau ?

Merci pour la reponse je vais le faire de suite

[mimile]

Pour ce qui est de la durée du boot depuis grub jusqu'à l'affichage de mon bureau gnome, il s'écoule grosso modo une minute.

Les lignes du boot défilent très rapidement puis tout s'arrête pendant 35 à 40 secondes après quoi s'affiche l'écran où je dois indiquer mon mot de passe et après l'avoir valider, je dois encore attendre 10 à 15 secondes avant que mon bureau gnome s'affiche.

Pour ce qui fsck, j'ai exécuté la commande tune2fs en fixant à 20 le nombre de boot avant que fsck ne s'exécute.

Je l'ai vérifié à plusieurs reprise : avant d'arriver à 20, il y a une ligne qui apparaît dans celles du boot qui dit (en anglais) : /dev/sda1 a été monté 19 fois ; fsck sera exécuté lors du prochain boot.

En revanche, si tu as lu le Wiki, la commande dumpe2fs qui permet de vérifier le nombre de boot total et combien de boot avant d'exécuter fsck ne fonctionne pas chez moi : elle plante en annonçant :

Code : Tout sélectionner

sudo dumpe2fs -h /dev/sda1 | grep -i 'mount count'
dumpe2fs 1.42.11 (09-Jul-2014)
dumpe2fs: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sda1

J'ai posté à ce sujet et j'attends qu'une des grosses têtes du forum veuille bien me venir en aide car je n'ai rien trouvé de probant avec Google.

EDIT : Je suis rouge de honte : ma partition racine d'Arch se trouve en /dev/sda6 et non en /dev/sda1 (c'est là qu'il y a W7).

Donc :

Code : Tout sélectionner

[okapi@Archie ~]$ sudo dumpe2fs -h /dev/sda6 | grep -i 'mount count'
dumpe2fs 1.42.11 (09-Jul-2014)
Mount count:              3
Maximum mount count:      20
[okapi@Archie ~]$ 

Comme tu le vois, j'ai booté 3 fois Arch et le fsck se fera au 20ème boot.

Donc, je te conseille de vérifier sur quelle partition se trouve ta Arch (avec gparted en root par exemple) et d'adapter la commande tune2fs en fonction du résultat.

[YoanMathieu]

Ok merci je regarderai , j'espere que tu trouvera comment résoudre ton problème de chargement de bureau , je vient de désactiver certaine chose au démmarage et je retombe a 39sec de boot , je pense donc me satisfaire de sa merci

[YoanMathieu]

Mais j'ai quand même le problème pour le bureau , tout et la mais les application prenne un temps fou a se lancer ! Chromium prend 12sec libre office s'affiche mais se charge en 10-15sec , la je sèche je sais pas d'ou sa peut venir

[mimile]

Re-

Je n'utilise pas chromium. J'utilise Firefox.

Au premier lancement de Firefox, ça dure environ 7 à 8 secondes.

En revanche, si après l'avoir fermé, je le relance pendant la même session, il démarre en 1 ou 2 secondes.

Pour libreoffice writer : premier démarrage en 5 à 6 secondes. Par la suite, démarrage quasi instantané.

Je pense que lors des premiers démarrages, il y a des plugins, fichiers et extensions qui doivent être activés/créés ce qui allongent la durée.

Lors de la fermeture, je pense que ces divers éléments restent en mémoire ce qui expliquerait que les seconds démarrages sont beaucoup plus rapides que les premiers.

Je me trompe peut-être sur toute la ligne mais il est un fait que les seconds démarrages sont quasi instantanés. (Je constate la même chose sous W7.

Pour en revenir à fsck, j'attire une nouvelle fois ton attention sur le fait que la commande tune2fs -c 20 doit pointer vers la partition racine (donc pas nécessairement /dev/sda1 - à vérifier avec gparted qu'on démarrer en console root : # gparted)

[oktoberfest]

Salut,

tu as peut-être un problème avec le parcage des têtes. Dans certains cas le disque range les têtes après quelques secondes d'inactivité, ce qui pose deux problèmes :
- un ralentissement car le disque doit ressortir les têtes pour un nouvel accès
- un vieillissement prématuré du disque.

Pour vérifier cela, il faut utiliser la commande smartctl. Tu peux obtenir le nombre de parcage déjà effectué par ton disque (par exemple sda) avec la commande :

Code : Tout sélectionner

# smartctl -a /dev/sda | egrep 'Cycle|Power'
  9 Power_On_Hours          0x0032   065   065   000    Old_age   Always       -       25654
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       118
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       63
193 Load_Cycle_Count        0x0032   121   121   000    Old_age   Always       -       238223

Les lignes intéressantes sont :
- Power_On_Hours : le temps (en heures) pendant lequel ton disque était alimenté
- Power_Cycle_Count : le nombre d'allumages électriques de ton disque
- Load_Cycl_Count : le nombre de parcage des têtes du disque

C'est la troisième ligne la plus intéressante. Maintenant tu peux faire un petit test :
- lancer la commande smartctl
- attendre 1 minute
- lancer la commande smartctl

Si la valeur du Load_Cycle_Count augmente, cela veut dire que le disque a parqué les têtes pendant la minute d'inactivité. Tu peux via la commande hdparm et un service systemd remédier à ce problème --> https://wiki.archlinux.fr/Hdparm#Parcage_du_disque

[YoanMathieu]

Ok merci pour vos reponse je testerai en rentrant a la maison !
Et pour fsck le problème et résolu me reste a voir pourquoi tout se lance lentement

[YoanMathieu]

Je pense que mon DD doit etre Hs car il gratte beaucoup au boot et au lancement d'application , hors que avant il était silencieux

[mélodie]

Je pense que mon DD doit etre Hs car il gratte beaucoup au boot et au lancement d'application , hors que avant il était silencieux

Je pense que ton problème vient surtout du fait que tu utilises Xfce4 : et celui-ci a une particularité avec une option pour détecter le réseau, afin de rendre celui-ci accessible dans le gestionnaire de fichiers (Thunar).

Je ne me rappelle jamais où est "ce truc-là" car j'utilise Openbox avec openbox-menu, et pcmanfm, je ne suis donc pas impactée par ce soucis.

Je reviens par ici dés que j'aurais remis la main sur le shemileblick.

[mélodie]

Salut,

Regarde sous /usr/share/gvfs/ et de là sous mounts : il devrait y avoir un fichier "network.mount". Si la ligne "AutoMount" est à "true" passe la à false.

(C'est pour la recherche et le montage automatique de réseau dans Thunar).

[mimile]

Salut,

tu as peut-être un problème avec le parcage des têtes. Dans certains cas le disque range les têtes après quelques secondes d'inactivité, ce qui pose deux problèmes :
- un ralentissement car le disque doit ressortir les têtes pour un nouvel accès
- un vieillissement prématuré du disque.

Pour vérifier cela, il faut utiliser la commande smartctl. Tu peux obtenir le nombre de parcage déjà effectué par ton disque (par exemple sda) avec la commande :

Code : Tout sélectionner

# smartctl -a /dev/sda | egrep 'Cycle|Power'
  9 Power_On_Hours          0x0032   065   065   000    Old_age   Always       -       25654
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       118
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       63
193 Load_Cycle_Count        0x0032   121   121   000    Old_age   Always       -       238223

Les lignes intéressantes sont :
- Power_On_Hours : le temps (en heures) pendant lequel ton disque était alimenté
- Power_Cycle_Count : le nombre d'allumages électriques de ton disque
- Load_Cycl_Count : le nombre de parcage des têtes du disque

C'est la troisième ligne la plus intéressante. Maintenant tu peux faire un petit test :
- lancer la commande smartctl
- attendre 1 minute
- lancer la commande smartctl

Si la valeur du Load_Cycle_Count augmente, cela veut dire que le disque a parqué les têtes pendant la minute d'inactivité. Tu peux via la commande hdparm et un service systemd remédier à ce problème --> https://wiki.archlinux.fr/Hdparm#Parcage_du_disque

Bonjour,

Je me greffe brièvement sur ce poste parce que la commande # smartctl -a /dev/sda | egrep 'Cycle|Power' ne renvoie chez moi que :

Code : Tout sélectionner

[okapi@Archie ~]$ sudo smartctl -a /dev/sda | egrep 'Cycle|Power'
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       6620
 12 Power_Cycle_Count       0x0032   099   099   020    Old_age   Always       -       1393

Pas trace de :

Code : Tout sélectionner

192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       63
193 Load_Cycle_Count        0x0032   121   121   000    Old_age   Always       -       238223

Quid ?

[mélodie]

Salut,

tu as peut-être un problème avec le parcage des têtes. Dans certains cas le disque range les têtes après quelques secondes d'inactivité

Des secondes d'inactivité durant le boot me semble peu probable.

[YoanMathieu]

Voila j'ai tester tout ce que vous m'avez dit mais sa ne change rien a mon problème , et pour "network.mounts" sa me dit permission non accordé pour enregistrer

Merci

[jean_no]

Salut

et pour "network.mounts" sa me dit permission non accordé pour enregistrer

Lorsque ça te dit ce genre de chose, postes la commande que tu as exécuté et le résultat de la sortie de la commande.
Note : commande à exécuter en root!
A+

[mélodie]

Salut

et pour "network.mounts" sa me dit permission non accordé pour enregistrer

Lorsque ça te dit ce genre de chose, postes la commande que tu as exécuté et le résultat de la sortie de la commande.
Note : commande à exécuter en root!
A+

+1.

Note aussi d'utiliser des outils en console pour manipuler des fichiers en tant que root. Cela t'évitera des mauvaises surprises toujours possibles. Par exemple, utilise l'éditeur de texte nano, ou bien encore mcedit (qui fait partie du paquet mc et qui est simplissime d'utilisation).

[mimile]

Salut,

tu as peut-être un problème avec le parcage des têtes. Dans certains cas le disque range les têtes après quelques secondes d'inactivité

Des secondes d'inactivité durant le boot me semble peu probable.

Je suis quasiment certain que pendant le temps de latence de 35 à 40 secondes à la fin de l'affichage des lignes de boot, il se passe des choses en arrière-plan car vers la fin de ce temps d'attente, le témoin qui indique que le pavé numérique est activé s'allume (en fait, quand il accède au fichier /etc/gdm/Init/Defaults à la fin duquel j'ai ajouté les lignes suivantes avant le exit final :

Code : Tout sélectionner

if [ -x /usr/bin/numlockx ]; then
exec /usr/bin/numlockx on
fi

Toutes les recherches que j'ai effectuées se sont avérées vaines. Tant pis ! je prends mon mal en patience.

En ce qui concerne les têtes de lectures, je ne sais que penser.

J'ai deux disques de 500 Go : /dev/sda et /dev/sdb

/dev/sda contient W7 (sda1 - ntfs) deux partitions de stockage (sda2 et sda3 en ntfs) - deux partitions Arch - deux partition Wheezy et une swap.

/dev/sdb ne contient qu'une seule partition ntfs qui ne contient que des videos et des mp3.

Quand je suis sous W7 et que je n'accède pas à sdb, il est évident que celui-ci s'arrête de tourner au bout d'un certain temps car quand j'y accède par la suite, j'entends nettement qu'il se remet en route.

Ce phénomène ne se produit pas avec Arch ; j'en conclus que sdb ne s'arrête pas et donc que les têtes de lecture ne se parquent pas.

Cela tient peut-être à une particularité de mes disques : Seagate Barracuda sata

En revanche, quand je sors Arch de veille, j'entends nettement les deux disques se remettre en marche.

[mélodie]

Étant donné que les partitions en ext4 et autres btrfs ne fragmentent pas de manière visible et sensible, j'aurais plutôt tendance à stocker tout ce qui est fichier personnel sur ce type de partition et non sur des Ntfs.

Je suis quasiment certain que pendant le temps de latence de 35 à 40 secondes à la fin de l'affichage des lignes de boot, il se passe des choses en arrière-plan car vers la fin de ce temps d'attente, le témoin qui indique que le pavé numérique est activé s'allume (en fait, quand il accède au fichier /etc/gdm/Init/Defaults à la fin duquel j'ai ajouté les lignes suivantes avant le exit final :

J'ai Archlinux et deux partitions Ubuntu maison sur le disque dur (500 Go) et un second disque dur pour des backups en 500 Go aussi (en ext4) et le boot de ma machine ne me laisse pas le temps d'aller chercher un café. Un peu plus loin dans ton post tu sembles dire que tu n'as pas ce problème sous Arch, alors tu m'as perdue, pour le coup.

Si tu veux, je veux bien que tu essaies de mieux expliquer ?

Seagate Barracuda SATA je ne vois pas pourquoi il ralentirait le boot. Connais-tu le numéro de modèle de ton disque dur ?

[misaine]

e suis quasiment certain que pendant le temps de latence de 35 à 40 secondes à la fin de l'affichage des lignes de boot, il se passe des choses en arrière-plan car vers la fin de ce temps d'attente, le témoin qui indique que le pavé numérique est activé s'allume (en fait, quand il accède au fichier /etc/gdm/Init/Defaults à la fin duquel j'ai ajouté les lignes suivantes avant le exit final :

if [ -x /usr/bin/numlockx ]; then
exec /usr/bin/numlockx on
fi


Toutes les recherches que j'ai effectuées se sont avérées vaines. Tant pis ! je prends mon mal en patience.

la commande dmesg devrait te montrer ce qui se passe et à quel moment ça coince.