[boot] démarrage très lent

[lydstyl]

Bonjour à tous, je viens d'Ubuntu et je suis nouveau sur Arch (qui semble devenir mon OS préféré) que je test en même temps que debian unstable.

Mon boot est très lent, il dur plus de 3 minutes. Au début j'avais un boot rapide et je pense que le problème est survenu après que j'ai installé Debian unstable. J'ai beaucoup de partions (Windows 7, Ubuntu 13.04, Arch avec /boot /home séparées, Debian Sid et 2 partitions de données dont une en ext4 qui est dans mon fstab).

Voici une photo de mon écran au moment où le boot bloque juste après Grub. Le disque dur ne semble plus tourner puis au bout de 3 minutes le ddur reprend et le login de Arch apparait.
https://www.dropbox.com/s/911lvrpy6hupk ... arrage.jpg



et voici le retour de 2 commandes pour identifier le soucis :

Code : Tout sélectionner

[lyd@SqueletArch ~]$ systemd-analyze
Startup finished in 13.881s (kernel) + 3min 2.650s (userspace) = 3min 16.532s
[lyd@SqueletArch ~]$ 
[lyd@SqueletArch ~]$ systemd-analyze blame
         11.684s dhcpcd@enp5s0.service
          2.313s smbd.service
          1.752s systemd-logind.service
          1.571s systemd-fsck@dev-disk-by\x2duuid-6540533b\x2de2f2\x2d4e95\x2d88a3\x2d2685bda8d9c8.service
          1.395s gdm.service
          1.245s systemd-fsck@dev-disk-by\x2duuid-ec72a32d\x2d8954\x2d42f2\x2dbbb8\x2dd25536cf3a3d.service
           905ms accounts-daemon.service
           795ms systemd-vconsole-setup.service
           769ms dhcpcd.service
           546ms systemd-static-nodes.service
           495ms boot.mount
           457ms colord.service
           403ms systemd-user-sessions.service
           337ms polkit.service
           296ms systemd-udev-trigger.service
           293ms sys-kernel-debug.mount
           292ms systemd-journal-flush.service
           276ms dev-mqueue.mount
           273ms systemd-sysctl.service
           243ms sys-kernel-config.mount
           213ms dev-hugepages.mount
           200ms systemd-remount-fs.service
           190ms tmp.mount
           179ms upower.service
           133ms systemd-random-seed-load.service
            73ms systemd-udevd.service
            71ms udisks2.service
            65ms systemd-tmpfiles-clean.service
            53ms home.mount
            39ms systemd-tmpfiles-setup.service
            23ms rtkit-daemon.service
           900us sys-fs-fuse-connections.mount
[lyd@SqueletArch ~]$ 

[EDIT modo]sera plus clair sur un nouveau sujet[/EDIT]

[FoolEcho]

Salut,

Ton système est-il bien à jour ?

Sinon c'est l'espace utilisateur qui prend tant de temps... Peut-être un souci au niveau de X (le pilote utilisé vu ta capture d'écran ?) ou de ton interface graphique... Hmmm... Tu as aussi fuse, mais ça n'a pas l'air d'impacter (à tout hasard: http://wiki.archlinux.fr/Systemd#Montage).

Tu pourrais poster le journal complet d'un démarrage ? (pastebin)

[lydstyl]

Ton système est-il bien à jour ?

Oui mon system est bien à jour et je fais souvent un sudo yaourt -Suya et le terminal me répond que c'est à jour. De plus mon system fonctionne à merveille c'est juste le temps de boot qui est long.

Sinon c'est l'espace utilisateur qui prend tant de temps... Peut-être un souci au niveau de X (le pilote utilisé vu ta capture d'écran ?) ou de ton interface graphique... Hmmm...

Je ne pense pas que ce soit le pilote graphique qui à l'air de bien fonctionner mais c'est vrai que j'ai toujours eu ce message byzar que l'on voit sur la photo (mais il était là aussi quand mon system bootait rapidement avant l'installation de debian). J'utilisais le même /home avec Debian, que je viens de supprimer (mais le soucis de boot reste là). Je me demande si c'est pas au niveau de la partition /boot (peut etre que Debian l'a modifié?), est il possible de réinstaller juste le /boot ?
Après j'ai installé plusieurs interfaces graphiques et au début j'ai eu des soucis avec openbox mais maintenant elles fonctionnent toutes (xfce, openbox, wmii, gnome3) avec gdm.

Tu as aussi fuse, mais ça n'a pas l'air d'impacter (à tout hasard: http://wiki.archlinux.fr/Systemd#Montage).

Je n'ai pas très bien compris ce qu'est FUSE mais est il possible de le réinstaller pour voir si ça change qqchose ?
Voici mon fstab:

Code : Tout sélectionner

# 
# /etc/fstab: static file system information
#
# <file system>	<dir>	<type>	<options>	<dump>	<pass>
# /dev/sdb8
UUID=130bd332-9ac0-410e-a59c-48b5a630d300	/         	ext4      	rw,relatime,data=ordered	0 1

# /dev/sdb6
UUID=6540533b-e2f2-4e95-88a3-2685bda8d9c8	/boot     	ext2      	rw,relatime,stripe=4	0 2

# /dev/sdb9
UUID=ec72a32d-8954-42f2-bbb8-d25536cf3a3d	/home     	ext4      	rw,relatime,data=ordered	0 2

# /dev/sdb5
UUID=8ebe8f54-9164-4619-b231-6e7c382ccdf8	none      	swap      	defaults  	0 0



# /dev/sdb1 ou /media/SqueletHome partition avec mes films et des sauvegardes
#UUID=a035c09a-4891-422a-b9fd-62bf41a6f57f	/media/SqueletHome	ext4	defaults,nofail	0 2
UUID=a035c09a-4891-422a-b9fd-62bf41a6f57f	/media/SqueletHome	ext4	defaults,nofail	0 0

Tu pourrais poster le journal complet d'un démarrage ? (pastebin)

je dois envoyer quel fichier ?

voila ce que donne dmesg :
http://pastebin.com/CN6VmYUC

[Anghirrim]

Non, pour le journal complet d'un démarrage c'est:
"journalctl -b"

[Xorg]

«byzar» s'écrit «bizarre», au passage...
C'est un drôle de réflexe que de vouloir «réinstaller juste le /boot», je crois que tu n'as pas conscience que le /boot contient simplement un noyau compressé et ses initrd (sous ArchLinux, un standard et un fallback), ainsi que quelques fichiers étant propre à ton booloader, telle que sa configuration (ou une partie de lui-même dans le cas de Grub).
Donc on ne touche pas au noyau compressé, tu peux reconstruire les RAM Disque Initiaux avec la commande :

Code : Tout sélectionner

# mkinitcpio -p linux

Ce qui aura peu d'intérêt je pense... Et toucher au bootloader ne changera rien vu qu'il boot correctement ton système (à moins qu'il y ait de mauvais paramètres dans la ligne de boot du noyau mais j'en doute).

Après utiliser le même /home que ta Debian ne devrait pas influencer. Encore, si tu utilises le même nom d'utilisateur sous Debian et ArchLinux avec le même $HOME, dans le pire des cas ça pourrait peut-être interférer dans ton espace-utilisateur, mais là tu n'es même pas logué à ce stade là, donc ce n'est pas le fait que ton /home soit partagé qui pose problème.

Utilise aussi le PasteBin pour la sortie de journalctl -b s'il te plaît.

[lydstyl]

Merci pour vos réponses et désolé pour mon mauvais français.

Je ne pense plus que ce soit le /home partagé. Je précise que mon utilisateur Debian était /home/lydsyl et que mon utilisateur Arch est /home/lyd

voici ce que donne journalctl -b
http://pastebin.com/bWexfbsr

et voici ce que donne mkinitcpio -p linux

Code : Tout sélectionner

[lyd@SqueletArch ~]$ mkinitcpio -p linux
==> Building image from preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> ERROR: Unable to write to /boot/initramfs-linux.img
==> Building image from preset: 'fallback'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> ERROR: Unable to write to /boot/initramfs-linux-fallback.img

[widapit]

Salut !

mkinitcpio -p linux est à lancer en root ...

[lydstyl]

J'ai lancé mkinitcpio -p linux en root et tout s'est bien passé :
==> Image generation successful

mais le démarrage d'Arch est toujours lent.

[Anghirrim]

Je suis allé voir ton pastebin... tu es sûr que c'est le retour de ton journalctl -b complet? Parce que là, on ne voit rien de lié à systemd, ni chargement kernel.

[lydstyl]

tu es sûr que c'est le retour de ton journalctl -b complet?

j'ai lancé le journalctl -b en root cette fois et il est plus long, le voici :
http://pastebin.com/iyjfnmah

[Xorg]

Tu as démarré ton système à 19:17:51.
À 19:17:54, ton système commence à monter les partitions et à 19:17:58, il finit. Donc 4 secondes pour monter tes nombreuses partitions.
À 19:18:02, nouveau bloque ton système pendant une minute et 18 secondes.
Et à priori, à 19:19:54 GDM se lance.

Deux minutes et trois secondes, ça fait quand même. Je trouve ton log très lourd pour une installation récente, mais bon. Enfin dans tout les cas, c'est nouveau qui te pose problème.

[Anghirrim]

@lydstil: Ton utilisateur est-il dans le groupe systemd-journal? C'est peut-être pour cela que tu as un log tronqué en non root.

[lydstyl]

Enfin dans tout les cas, c'est nouveau qui te pose problème.

Je me suis dit la même chose même s'il me semble que quand j'avais fraichement installé Arch mon boot était rapide.
J'ai suivi ce wiki http://wiki.archlinux.fr/NVIDIA#Installation_2 et j'ai remplacé xf86-video-nouveau par le pilote propriétaire nvidia. Le boot était aussi long mais rien ne s'affichait à l'écran jusqu'à l'écran de login gdm.
J'ai ensuite remplacé nvidia par nvidia-beta et le boot était toujours aussi long mais des choses s'affichaient à nouveau.
Pour finir j'ai réinstallé xf86-video-nouveau puisqu'il me semble le mieux approprié pour ma gtx-670.

Ton utilisateur est-il dans le groupe systemd-journal?

Je ne sais pas si ça va répondre à ta question mais :
--il y a une ligne "systemd-journal190:" dans mon fichier /etc/group
--il y a une lgne "lyd1000:/home/lyd:/bin/bash" dans mon fichier /etc/passwd

[widapit]

ça veut dire que le groupe et l'utilisateur existent !!
pour savoir à quel(s) groupe(s) appartient ton utilisateur tu lances

Code : Tout sélectionner

groups

[lydstyl]

Code : Tout sélectionner

[lyd@SqueletArch ~]$ su
Mot de passe : 
[root@SqueletArch lyd]# gpasswd -a lyd systemd-journal
Ajout de l'utilisateur lyd au groupe systemd-journal
[root@SqueletArch lyd]# groups
root bin daemon sys adm disk wheel log
[root@SqueletArch lyd]# su lyd
[lyd@SqueletArch ~]$ groups
users systemd-journal
[lyd@SqueletArch ~]$ 

[Anghirrim]

Parfait, du coup maintenant tu devrais pouvoir avec une sortie complète en lançant ton "journalctl -b", même en utilisateur.

Mais bon, ça ne résoud pas ton problème. Cela dit en passant, tu as un quantité astronomique de "failed" dans le log de ton boot!! Notamment avec dbus, gdm et tint2.

Ça ne doit pas aider.

Du coup tu as des blocages lors du lancement de nouveau et tous ces fails... Il y a un moyen de démarrer nouveau en "verbose" ou avec un journal dédié?

Au fait, voilà les moments de blocage de ton boot:

Code : Tout sélectionner

-- Logs begin at mar. 2013-04-23 21:07:04 UTC, end at mer. 2013-05-01 20:16:59 UTC. --
mai 01 19:18:02 SqueletArch kernel: nouveau E[  PGRAPH][0000:01:00.0] ROP0 ch 1 [0x000007fc92] 0x80000000 0x80000001

mai 01 19:18:02 SqueletArch kernel: nouveau E[  PGRAPH][0000:01:00.0] ROP1 ch 1 [0x000007fc92] 0x80000000 0x80000000

mai 01 19:18:02 SqueletArch kernel: nouveau E[  PGRAPH][0000:01:00.0] ROP2 ch 1 [0x000007fc92] 0x80000000 0x80000000

mai 01 19:18:02 SqueletArch kernel: nouveau E[  PGRAPH][0000:01:00.0] ROP3 ch 1 [0x000007fc92] 0x80000000 0x80000000

mai 01 19:19:20 SqueletArch systemd[1]: Job dev-disk-by\x2duuid-8ebe8f54\x2d9164\x2d4619\x2db231\x2d6e7c382ccdf8.device/start timed out.

mai 01 19:19:20 SqueletArch systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-8ebe8f54\x2d9164\x2d4619\x2db231\x2d6e7c382ccdf8.device.

mai 01 19:19:20 SqueletArch systemd[1]: Dependency failed for /dev/disk/by-uuid/8ebe8f54-9164-4619-b231-6e7c382ccdf8.

......

mai 01 19:19:37 SqueletArch polkitd[319]: Registered Authentication Agent for unix-session:c1 (system bus name :1.17 [gnome-shell --mode=gdm], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale fr_FR.UTF-8)

mai 01 19:19:37 SqueletArch /usr/bin/dbus-launch[335]: JS LOG: GNOME Shell started at Wed May 01 2013 19:19:37 GMT+0000 (UTC)

mai 01 19:19:52 SqueletArch gdm-password][480]: pam_unix(gdm-password:session): session opened for user lyd by (unknown)(uid=0)

mai 01 19:19:52 SqueletArch systemd-logind[253]: New session 1 of user lyd.

mai 01 19:19:52 SqueletArch systemd-logind[253]: Linked /tmp/.X11-unix/X0 to /run/user/1000/X11-display.

......


mai 01 19:19:57 SqueletArch /etc/gdm/Xsession[487]: ** (nm-applet:541): WARNING **: fetch_connections_done: error fetching connections: (32) Unit dbus-org.freedesktop.NetworkManager.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.NetworkManager.service' for details..

mai 01 19:19:57 SqueletArch /etc/gdm/Xsession[487]: ** (nm-applet:541): WARNING **: Failed to register as an agent: (32) Unit dbus-org.freedesktop.NetworkManager.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.NetworkManager.service' for details.

mai 01 19:20:13 SqueletArch /etc/gdm/Xsession[487]: (process:629): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed

.........

mai 01 19:20:13 SqueletArch dbus-daemon[255]: dbus[255]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.NetworkManager.service': Unit dbus-org.freedesktop.NetworkManager.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.NetworkManager.service' for details.

mai 01 19:20:52 SqueletArch systemd[1]: Job dev-disk-by\x2duuid-8ebe8f54\x2d9164\x2d4619\x2db231\x2d6e7c382ccdf8.device/start timed out.

mai 01 19:20:52 SqueletArch systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-8ebe8f54\x2d9164\x2d4619\x2db231\x2d6e7c382ccdf8.device.

En revanche, il semble que tu aies lancé ton journalctl 10 à 15mn après ton boot. Tu peux le refaire juste après ton arrivée sur le bureau stp?

De plus, peux-tu nous donner les sorties de:
- systemd-analyze blame
- systemd-analyze plot > plot.svg (fichier plot.svg qui se trouvera dans ton /home)
Ça permettra de voir si, en plus du chargement des modules, etc... certains services systemd mettent du temps à se lancer.
Pas besoin d'être en root pour lancer ça.

[lydstyl]

Bon alors d'abord merci beaucoup pour votre aide. Je viens de remplacer mon Ubuntu par Arch que je trouve beaucoup mieux. J'ai donc refait une installation fraiche et mon problème est résolu. Je boot en environ 15 secondes mais Arch est maintenant sur mon SSD (beaucoup plus rapide) alors je réponds au dernières questions pour le cas où il y aurait des choses mal configurées :

journalctl -b
http://pastebin.com/S4jYE5w0

systemd-analyze blame

Code : Tout sélectionner

           515ms media-windowsSofts.mount
           178ms systemd-journal-flush.service
           148ms upower.service
           123ms systemd-static-nodes.service
           123ms systemd-vconsole-setup.service
           113ms dev-hugepages.mount
           107ms systemd-udev-trigger.service
           103ms sys-kernel-config.mount
            93ms alsa-restore.service
            83ms systemd-tmpfiles-setup.service
            83ms systemd-sysctl.service
            70ms dev-mqueue.mount
            60ms sys-kernel-debug.mount
            53ms media-SqueletHome.mount
            47ms systemd-logind.service
            42ms polkit.service
            40ms systemd-fsck@dev-disk-by\x2duuid-e6a90f07\x2d5f6c\x2d47d0\x2db36a\x2df24b4fa37d7f.service
            33ms systemd-fsck@dev-disk-by\x2duuid-a0b50484\x2d1ec3\x2d4d6c\x2d8dc3\x2da7e7cc41b30a.service
            33ms tmp.mount
            29ms udisks2.service
            27ms systemd-remount-fs.service
            26ms dev-disk-by\x2duuid-2c6dfa16\x2dc2fc\x2d482c\x2d940a\x2d2837d81cfd70.swap
            13ms systemd-udevd.service
            13ms sys-fs-fuse-connections.mount
            13ms systemd-user-sessions.service
            10ms home.mount
             7ms systemd-random-seed-load.service
             3ms boot.mount

et enfin le plot.svg
https://www.dropbox.com/s/pfkwszsc9fkee5z/plot.svg

[Anghirrim]

Salut,

Du coup plus de "failed" dans ton "journalctl -b" et pas de blocages. Ca semble réglé.

En revanche ton plot.svg est étrange.Il dure 101 secondes!

[Xorg]

En revanche ton plot.svg est étrange.Il dure 101 secondes!

Oui, tout à droite en bas on voit que network.target, smbd.service, multi-user.target et graphical.target se lancent entre 101 et 102 secondes après le début du boot. Du coup, oui, très étrange. À 20 secondes aussi ça coince.